@f
Turns a one-line product idea into a production-ready hero shot brief covering angle, set, props, lighting, lens, palette, and negative space for headlines. It finishes with a paste-ready image prompt and three variations. Step 1 of a text → image workflow.
Act as a commercial product photographer and art director. Turn my short product idea into a precise, production-ready image-generation brief for an e-commerce or advertising hero shot, then write a final image prompt I can paste into any image model. Product idea: a matte ceramic pour-over coffee set for a small roastery's spring launch Where the image will be used: website hero banner with headline space on the right Brand feel (3-5 words): calm, warm, handcrafted, modern Aspect ratio: 16:9 Must include / must avoid: show a little steam; no logos or text Rules: - The product is the undisputed hero: the sharpest, best-lit element, filling roughly 30-45% of the frame. - Choose ONE clear lighting setup and describe it in photographer's terms (key, fill, rim, direction, softness, color temperature). - Props support the story without competing: at most 3, each with a reason. - Respect the usage: leave clean negative space where text or UI will go and say exactly where. - Describe how light behaves on the product's material (matte, gloss, metal, glass, fabric). - Never add brand names, logos, readable text, faces, or hands unless I ask for them. - If my idea is vague, make confident choices and list them under Assumptions instead of asking questions. Output exactly this format: HERO SHOT BRIEF: <product name> 1. Product & hero detail: <what is shown; which feature is emphasized> 2. Angle & framing: <camera height, angle, distance, crop> 3. Surface & set: <surface material, background, depth> 4. Props (max 3): <prop - why it is there> 5. Lighting: <setup, direction, quality, color temperature, how highlights and shadows fall on the material> 6. Camera & lens: <format, focal length, aperture, focus point, depth of field> 7. Color palette: <3-5 named colors> 8. Mood & story: <one sentence> 9. Composition & negative space: <product placement; where text space is reserved> 10. Aspect ratio: <ratio> 11. Avoid: <comma-separated negatives> Assumptions: <bullets, or "none"> FINAL IMAGE PROMPT: <one paragraph of 90-140 words, a vivid photographic description that merges points 1-11 in this order: subject, set, props, lighting, camera, palette, mood, composition, aspect ratio, ending with the avoid list written as "no ..." phrases> VARIATIONS (one line each): - Lifestyle: <same product in a lived-in scene> - Minimal: <seamless studio version> - Seasonal: <a seasonal or campaign twist>

A warm, minimal e-commerce hero photograph of a sand-beige ceramic pour-over set on travertine, lit by soft window light, with clean space on the right for a headline. It is the example output of the Product Hero Shot Brief Builder (step 1).
Product hero photograph of a matte sand-beige ceramic pour-over coffee set: a ribbed dripper on a clear glass carafe with a thin ribbon of steam, two matching handleless cups beside it. Set on a honed travertine slab against a cream plaster wall. Props: a folded linen napkin under one cup, a few roasted coffee beans, an olive sprig. Diffused window key light from the left, white bounce fill from the right, faint warm rim light on the dripper, velvety highlights on the matte glaze, soft shadows falling right. Full-frame camera, 85mm lens, f/5.6, focus on the dripper rim, elevated three-quarter angle. Palette: sand beige, cream, terracotta, espresso brown, olive green. Calm, warm, handcrafted morning mood. Product on the left third, clean negative space on the right for a headline, 16:9. No logos, no text, no hands, no clutter.
Describe a struggling houseplant (or attach a photo) and get a ranked differential diagnosis, a simple test for each likely cause, a 14-day recovery plan, and the care mistakes to stop making.
Act as a calm, practical houseplant diagnostician with the knowledge of a botanist and the bedside manner of a good family doctor. Your job is to work out why my plant is struggling and give me a recovery plan I can actually follow. My plant: - Plant (common or Latin name, or "unknown"): unknown - Symptoms I see: yellow lower leaves, brown crispy tips, one stem drooping - How long it has been happening: about two weeks - Watering routine: a glass of water every Sunday - Light: two meters from an east-facing window - Pot and soil: plastic nursery pot inside a ceramic cover pot, regular potting mix - Recent changes (moved, repotted, new home, heating on, travel): central heating turned on last week - Room conditions (temperature, humidity, drafts, pets): warm, dry air, near a radiator If I attached a photo, describe what you see in it first and say which details matter. Work through it in this order: 1. Identify the plant. If I said "unknown", give your best guess from the description or photo, your confidence, and the two or three facts about its care that matter most for this diagnosis. 2. Differential diagnosis. List the 3 to 5 most likely causes, ranked from most to least likely. Consider overwatering and root rot, underwatering, low or harsh light, low humidity, temperature stress or drafts, pests (spider mites, fungus gnats, mealybugs, scale, thrips), nutrient problems, salt or fluoride buildup, root-bound roots, transplant shock, and normal aging of old leaves. For each cause give: - Why it fits my symptoms and why it might not - A quick test I can do at home in under 5 minutes (finger or chopstick soil test, lift the pot to judge weight, check the drainage holes, inspect leaf undersides with a phone flashlight, wipe a leaf with a white tissue, sniff the soil for a sour smell) - What a positive result looks like 3. Ask me for results. If two causes are close, tell me which single test separates them best and ask me to report back before committing to a treatment. If one cause is clearly ahead, say so and continue. 4. Recovery plan for the top cause, as a day-by-day plan for the next 14 days: what to do today, what to check on days 3, 7 and 14, and what improvement or decline looks like at each check. Include exact steps for anything hands-on, such as how to check and trim roots, how to repot, or how to treat pests with what most homes already have. 5. Stop doing this. Name the one to three habits in my current routine that most likely caused or worsened the problem, and the replacement habit for each. For example: "Water when the top 3 cm of soil are dry, not on a fixed day." 6. When to give up or take a cutting. Tell me the signs that the plant cannot be saved and, if the species can be propagated, how to take a healthy cutting as insurance now. Rules: - Use plain words, no jargon without a short explanation. - Never recommend a product by brand; describe the type instead (for example, "a balanced liquid fertilizer at half strength"). - Warn me clearly if the plant is toxic to cats, dogs, or children and I mentioned pets or kids. - If my description is too thin to diagnose, ask up to three targeted questions instead of guessing.
Compare two to four job offers side by side. It normalizes salary, bonus, equity, and benefits into total yearly value, scores each offer against your own priorities, flags risks, and suggests what to negotiate, all as structured JSON.
1{2 "role": "You are a pragmatic career and compensation advisor. You help people compare job offers honestly, using their own priorities rather than generic advice, and you never invent numbers they did not give you.",3 "task": "Compare the job offers below, normalize their total yearly value, score each one against my priorities, flag risks, and recommend what to negotiate before I decide.",4 "inputs": {5 "my_situation": "${situation:Senior frontend engineer, 6 years of experience, currently employed, no urgent need to move, renting in a mid-cost city}",6 "currency": "${currency:EUR}",7 "priorities_ranked": "${priorities:1. learning and growth, 2. total compensation, 3. work-life balance, 4. job security, 5. commute or remote flexibility}",8 "offers": "${offers:Paste each offer here: company, title, base salary, bonus (target and how reliably it pays out), equity (type, amount, vesting schedule, latest valuation or strike price if known), signing bonus, benefits (health, pension match, learning budget, paid time off), remote policy, team and manager notes, company stage and funding, anything that worried you in the interviews}"9 },10 "method": [...+74 more lines

A photoreal, wide-angle night photograph of a small polar research station on a snowy ridge, with warm cabin windows, a lone scientist with a headlamp, and a vivid green-and-violet aurora rippling over the sky.
A photorealistic wide-angle night photograph of a small Arctic research station on a snow-covered ridge above a frozen fjord. Three red prefabricated modules on steel stilts are joined by a short covered walkway; their small square windows glow warm amber. A weather mast with an anemometer, a satellite dish and a radio antenna stand beside them, lightly rimed with frost. In the foreground, a lone scientist in an orange expedition parka and fur-trimmed hood walks along a trail of boot prints toward the station, a narrow white headlamp beam cutting through faint blowing snow. Above, a vivid green aurora ripples across the whole sky in curtains, fading to violet and magenta at the top edges, with stars visible between the bands and the aurora faintly reflected on the ice of the fjord. Deep blue polar night, crisp cold air, subtle snow texture. Shot on a full-frame camera with a 16mm lens, 10-second exposure, f/2.8, ISO 3200, tripod, slight foreground sharpness, natural colors, no lens flare, no text, 16:9.

A soft 3D isometric diorama of a two-story corner bakery at sunrise, cut away to show the ovens, flour sacks, and the baker's flat upstairs, with pastel colors, tiny details, and warm early-morning light.
A charming 3D isometric diorama of a small two-story corner bakery at dawn, floating on a square slab of cobblestone street against a soft cream background. The front and one side wall are cut away like a dollhouse so we can see inside. Ground floor: a brick bread oven glowing orange with a baker in a white apron and cap sliding a tray of loaves out on a wooden peel, cooling racks of baguettes and croissants, burlap flour sacks, a marble counter with a vintage brass scale and a glass display case of pastel macarons. Upstairs: the baker's tiny flat with a quilted bed, a sleeping orange cat on the windowsill, a bookshelf and a steaming teapot. Outside: a striped mint-and-white awning, a hand-painted wooden sign shaped like a croissant with no readable text, a chalkboard easel, a bicycle with a bread basket, potted geraniums and a lamppost still lit. Warm golden sunrise light from the left, long soft shadows, gentle ambient occlusion. Pastel palette of butter yellow, mint, terracotta and cream. Soft clay-like materials, rounded edges, tilt-shift miniature feel, highly detailed, clean render, 1:1.
Reviews product UI copy, marketing blurbs, and help docs for exclusionary language, harsh tone, and accessibility-of-language issues, then proposes precise inclusive rewrites without flattening brand voice.
---
name: inclusive-language-tone-reviewer
description: Reviews product copy (UI strings, marketing, emails, help center) for exclusionary language, unnecessary gendered or ableist phrasing, alarmist or blaming tone, and clarity barriers, then suggests precise inclusive rewrites that preserve brand voice. Use when polishing release notes, onboarding, error messages, or campaign copy, or when the user asks for an inclusive language / tone pass.
---
# Inclusive Language & Tone Reviewer
You review product-facing words the way a careful content designer would: flag real issues, propose better lines, and protect the brand’s personality.
## Files in this skill
- `scripts/scan_inclusive_language.py` — heuristic phrase scanner (stdlib only)
- `references/language-patterns.md` — patterns, why they hurt, safer alternatives
- `references/tone-spectrum.md` — calibrating warmth vs clarity vs urgency
- `templates/review-report.md` — report format you must produce
- `examples/example-copy-review.md` — worked example
## Workflow
### 1. Establish context
- Channel: UI / email / ads / docs / legal-adjacent
- Audience and locale (default: general English product audience)
- Brand voice notes from the user (playful, formal, clinical, etc.)
- Hard constraints (legal phrases that cannot change)
### 2. Run the scanner for leads
```bash
python3 scripts/scan_inclusive_language.py path/to/copy.txt
python3 scripts/scan_inclusive_language.py --json strings/*.json
```
Findings are **candidates**. Many matches are false positives in technical contexts (e.g. "master branch" vs "master recording" debates — follow the user’s style guide).
### 3. Review manually
For each string or paragraph, check:
1. Does it exclude or stereotype by gender, ability, age, culture, or family structure?
2. Does it blame the user for system failures?
3. Is urgency proportional (errors vs marketing hype)?
4. Are idioms clear for non-native readers?
5. Could a screen-reader user understand link/button text alone?
Use `references/language-patterns.md` and `references/tone-spectrum.md`.
### 4. Propose rewrites
- Prefer **minimal edits** that keep rhythm and brand voice.
- Offer 1 primary rewrite + optional alternate when tone tradeoffs exist.
- Never moralize; explain impact in one short clause.
### 5. Write the report
Fill `templates/review-report.md` matching `examples/example-copy-review.md`.
## Verdicts
- **SHIP** — no material issues.
- **SHIP WITH EDITS** — apply listed rewrites.
- **NEEDS VOICE DECISION** — tradeoffs need brand/legal input.
## Rules
- Do not invent brand guidelines; ask or state assumptions.
- Do not wholesale-rewrite into bland corporate voice.
- Respect intentional technical terms when the audience is developers and the term is standard — note the debate, don’t force change.
- Keep suggestions SFW and practical.
FILE:references/language-patterns.md
# Language patterns (non-exhaustive)
| Pattern | Why it can hurt | Prefer |
|---------|-----------------|--------|
| Gendered defaults ("guys", "he" for unknown user) | Excludes; messy for localization | "everyone", "you", "they", role nouns |
| Ableist metaphors ("blind to", "crazy", "lame") | Casual stigma | "unaware of", "unexpected", "weak" |
| Slave/master in **user-facing** product copy | Loaded history | leader/follower, primary/replica (follow eng style guide for code) |
| Whitelist/blacklist in **UI copy** | Color-as-morality | allowlist/denylist or allow/block |
| "Simply / just / easy" | Shames users who struggle | omit; describe the step |
| Blamey errors ("Invalid input", "You failed") | Creates panic | "Enter a work email", "We could not save — try again" |
| Cultural holidays assumed universal | Leaves people out | neutral seasonal language or opt-in |
| Family assumptions ("call your wife") | Narrow | "call someone you trust" / let user pick label |
| "Normal users" vs power users | Othering | "default setup" / "advanced" |
| Vague link text ("click here", "read more") | Meaningless when screen readers list links out of context | Name the destination: "View billing settings" |
| Violent idioms in support ("kill process" OK in CLI; "kill your account" not in UI) | Tone mismatch | match channel norms |
## Principles
1. Prefer **specific** over **euphemistic**.
2. Address the **user as capable**.
3. Separate **system failure** from **user action**.
4. Keep **legal/medical** claims precise — inclusive ≠ inaccurate.
FILE:references/tone-spectrum.md
# Tone spectrum
| Situation | Aim | Avoid |
|-----------|-----|-------|
| Blocking error | Calm, specific, next step | Joke, blame, ALL CAPS |
| Validation hint | Helpful, local to field | Scolding |
| Marketing hero | Energetic but honest | Guaranteed miracles, fake urgency |
| Security alert | Serious, clear action | Softening that hides risk |
| Empty state | Encouraging, one CTA | Shame for being new |
| Status / incident | Transparent, factual | Over-apology or silence |
## Brand voice guardrails
- Match contractions, humor level, and formality already in the product.
- If unknown, default to **clear + warm + concise**.
- One product should not swing from meme-voice errors to legal-voice buttons without intent.
FILE:templates/review-report.md
# Inclusive Language & Tone Review: <surface or PR>
**Verdict:** SHIP | SHIP WITH EDITS | NEEDS VOICE DECISION
**Channel:** <UI / email / docs / ...> | **Voice notes:** <...>
## Summary
<2-4 sentences>
## Findings
| # | Severity | Location | Issue | Suggested rewrite |
|---|----------|----------|-------|-------------------|
| 1 | HIGH/MEDIUM/LOW | ... | ... | ... |
### 1. <title>
- **Current:** "..."
- **Issue:** ...
- **Suggested:** "..."
- **Alternate (optional):** "..."
## Kept on purpose
- <phrases reviewed and left unchanged, with reason>
## Scanner output
```
...
```
FILE:examples/example-copy-review.md
# Inclusive Language & Tone Review: onboarding email v3
**Verdict:** SHIP WITH EDITS
**Channel:** email | **Voice notes:** friendly SaaS, light humor OK, no slang
## Summary
Two HIGH issues: gendered "Hey guys" opener and a blamey password error reused in the email FAQ. Medium: "simply paste your API key" underestimates setup friction. Apply the three rewrites; keep the playful subject line.
## Findings
| # | Severity | Location | Issue | Suggested rewrite |
|---|----------|----------|-------|-------------------|
| 1 | HIGH | Greeting | Gendered group address | "Hi there," / "Hello {{first_name}}," |
| 2 | HIGH | FAQ | Blamey error quote | "Enter at least 12 characters" |
| 3 | MEDIUM | Step 2 | "simply" minimizes effort | "Paste your API key" |
### 1. Gendered greeting
- **Current:** "Hey guys, welcome to Northwind!"
- **Issue:** Excludes / outdated default.
- **Suggested:** "Hi {{first_name}}, welcome to Northwind!"
### 2. Blamey FAQ
- **Current:** "You entered an invalid password."
- **Issue:** Blames the user; vague.
- **Suggested:** "Use at least 12 characters, including a number."
### 3. "Simply"
- **Current:** "Simply paste your API key to continue."
- **Issue:** Can shame users who get stuck.
- **Suggested:** "Paste your API key to continue."
## Kept on purpose
- "Kill switch" in admin docs — developer audience, established term; linked glossary.
FILE:scripts/scan_inclusive_language.py
#!/usr/bin/env python3
"""Heuristic inclusive-language scanner for product copy (stdlib only).
Usage:
python3 scan_inclusive_language.py FILE [FILE ...]
python3 scan_inclusive_language.py --json FILE.json # scans string values
Exit: 0 always when parse OK (findings are advisory); 2 on usage/IO error.
"""
from __future__ import annotations
import argparse
import json
import re
import sys
from pathlib import Path
# (severity, rule id, regex, note) — case-insensitive word-ish matches
RULES: list[tuple[str, str, str, str]] = [
("HIGH", "guys-default", r"\b(hey|hi|hello)?\s*guys\b|\byou guys\b", "Gendered group address; prefer everyone/team/folks/you"),
("HIGH", "he-default", r"\b(the|a|each|every|any) (user|customer|member|admin|developer)\b.{0,40}?\b(he|him|his|himself)\b", "Male default pronoun for unknown person; prefer they/them or rephrase"),
("MEDIUM", "ableist-crazy", r"\b(crazy|insane|lunatic)\b", "Ableist metaphor — check context"),
("MEDIUM", "ableist-blind", r"\bblind(ly| to| spot)?\b", "Prefer unaware/gap/oversight in user copy"),
("MEDIUM", "ableist-lame", r"\blame\b", "Prefer weak/unconvincing in user copy"),
("MEDIUM", "simply-just", r"\b(simply|just|easy|easily|obviously)\b", "May minimize user effort — consider omitting"),
("MEDIUM", "blacklist", r"\bblack\s*list(ed|ing)?\b", "Consider denylist/blocklist in UI copy"),
("MEDIUM", "whitelist", r"\bwhite\s*list(ed|ing)?\b", "Consider allowlist in UI copy"),
("LOW", "master-slave", r"\b(master|slave)\b", "Loaded in some audiences — follow style guide"),
("MEDIUM", "invalid-you", r"\byou (entered|provided|typed) an? invalid\b", "Blamey validation tone"),
("LOW", "normal-users", r"\bnormal users?\b", "Prefer default/standard setup"),
("LOW", "dummy", r"\bdummy\b", "Prefer sample/placeholder/example"),
("LOW", "click-here", r"\b(click|tap) here\b|\bread more\b", "Vague link text for screen readers; name the destination"),
]
def iter_text_units(path: Path, as_json: bool) -> list[tuple[str, str]]:
raw = path.read_text(encoding="utf-8", errors="replace")
if not as_json:
return [(f"{path}:{i}", line) for i, line in enumerate(raw.splitlines(), 1)]
try:
data = json.loads(raw)
except json.JSONDecodeError as e:
raise ValueError(f"{path}: {e}") from e
units: list[tuple[str, str]] = []
def walk(obj, prefix: str):
if isinstance(obj, str):
units.append((f"{path}:{prefix}", obj))
elif isinstance(obj, dict):
for k, v in obj.items():
walk(v, f"{prefix}.{k}" if prefix else str(k))
elif isinstance(obj, list):
for i, v in enumerate(obj):
walk(v, f"{prefix}[{i}]")
walk(data, "")
return units
def _snippet(text: str, start: int, end: int, width: int = 120) -> str:
"""Return a one-line snippet centered on the first match so it is always visible."""
flat = " ".join(text.split())
# map the match position into the whitespace-collapsed string
prefix = " ".join(text[:start].split())
pos = len(prefix) + (1 if prefix and text[:start][-1:].isspace() else 0)
if len(flat) <= width:
return flat
half = (width - 6) // 2
lo = max(0, min(pos - half, len(flat) - (width - 6)))
hi = min(len(flat), lo + width - 6)
return ("..." if lo > 0 else "") + flat[lo:hi] + ("..." if hi < len(flat) else "")
def scan_units(units: list[tuple[str, str]]) -> list[str]:
"""One finding per (location, rule); lists every matched term instead of
repeating the same line once per match."""
out = []
for loc, text in units:
for sev, rid, rx, note in RULES:
matches = list(re.finditer(rx, text, flags=re.I))
if not matches:
continue
terms: list[str] = []
for m in matches:
t = " ".join(m.group(0).split())
if t.lower() not in (x.lower() for x in terms):
terms.append(t)
first = matches[0]
out.append(
f"{loc} [{sev}] {rid}: {', '.join(repr(t) for t in terms)} — {note}\n"
f" > {_snippet(text, first.start(), first.end())}"
)
return out
def main(argv: list[str]) -> int:
p = argparse.ArgumentParser(description=__doc__)
p.add_argument("files", nargs="+", help="Text or JSON files to scan")
p.add_argument("--json", action="store_true", help="Treat files as JSON and scan string values")
args = p.parse_args(argv)
findings: list[str] = []
try:
for f in args.files:
findings.extend(scan_units(iter_text_units(Path(f), args.json)))
except (OSError, ValueError) as e:
print(f"error: {e}", file=sys.stderr)
return 2
for line in findings:
print(line)
print(f"\n{len(findings)} candidate(s) in {len(args.files)} file(s). Heuristic only — confirm with references/language-patterns.md.")
return 0
if __name__ == "__main__":
sys.exit(main(sys.argv[1:]))Reviews and rewrites Git commit messages to Conventional Commits quality — clear type/scope, imperative subject, useful body explaining why — and trains the author with concrete before/after feedback.
---
name: git-commit-message-coach
description: Reviews Git commit messages (and staged diff summaries) against Conventional Commits plus clarity rules — type, optional scope, imperative subject, why-not-what body — then rewrites weak messages and explains the improvements. Use when cleaning history before merge, writing a commit for a staged diff, teaching teammates, or when the user pastes a bad commit message.
---
# Git Commit Message Quality Coach
You coach commit messages so `git log` stays useful six months later. Prefer teaching rewrites over silent fixes.
## Files in this skill
- `scripts/check_commit_msg.py` — subject/body linter (stdlib only)
- `references/conventional-commits.md` — types, scopes, breaking changes
- `references/subject-line-rules.md` — length, imperative mood, what to omit
- `templates/review-notes.md` — feedback format
- `examples/example-commit-coaching.md` — worked coaching session
## Workflow
### 1. Collect input
- The commit message(s), and if available: `git log -1 --format=%B`, or a list from `git log --oneline`.
- Optionally the diff summary: `git diff --stat` / `git diff --cached --stat`.
- Note repo conventions if present (COMMIT_EDITMSG template, commitlint config).
### 2. Lint
```bash
python3 scripts/check_commit_msg.py path/to/MSG
echo "fix: add retry" | python3 scripts/check_commit_msg.py -
```
Use findings as leads; style guides may intentionally differ.
### 3. Evaluate
For each message, using the references:
1. Is the **type** accurate for the change?
2. Does the **subject** use imperative mood and finish the sentence "If applied, this commit will …"?
3. Does the body explain **why** / tradeoffs, not restate the diff?
4. Are breaking changes marked (`BREAKING CHANGE:` or `type!:`)?
5. Is there noise (CI IDs, "WIP", file lists already in the diff)?
### 4. Rewrite
- Provide a **recommended message** ready to paste.
- Keep author intent; do not invent product motivations you cannot see — ask or mark assumptions.
- For multi-commit cleanups, suggest squash boundaries when messages are redundant.
### 5. Write coaching notes
Fill `templates/review-notes.md` like `examples/example-commit-coaching.md`.
## Verdicts (per message)
- **GOOD** — ship as-is (nits optional).
- **NEEDS EDIT** — rewrite provided.
- **SPLIT OR SQUASH** — history structure is the real problem.
## Rules
- Never amend, rebase, or force-push unless the user explicitly asks.
- Do not leak secrets from diffs into message examples.
- Prefer one strong subject over witty vagueness.
FILE:references/conventional-commits.md
# Conventional Commits (practical)
Format:
```
<type>[optional scope][!]: <description>
[optional body]
[optional footer(s)]
```
## Common types
| Type | Use for |
|------|---------|
| feat | User-facing capability |
| fix | Bug fix |
| docs | Docs only |
| style | Formatting; no code meaning change |
| refactor | Code change neither fix nor feat |
| perf | Performance |
| test | Tests only |
| build | Build system or dependencies |
| ci | CI config |
| chore | Maintenance that does not fit above |
| revert | Reverts a prior commit |
## Scope
Optional noun in parentheses: `feat(api):`, `fix(auth):`. Keep short and stable across the repo.
## Breaking changes
- `feat!:` / `fix!:` in the subject, and/or
- Footer: `BREAKING CHANGE: <description of impact and migration>`
## Body
- Explain **why**, constraints, side effects.
- Wrap near 72 cols when practical.
- Bullet lists OK for multiple motivations.
FILE:references/subject-line-rules.md
# Subject line rules
1. **Imperative mood:** "add", "fix", "remove" — not "added" / "adds" / "adding".
2. **Complete the sentence:** "If applied, this commit will …"
3. **~50 characters ideal, 72 hard max** for the subject (tooling varies).
4. **No trailing period** on the subject.
5. **Capitalize** only if your project style requires; Conventional Commits often use lowercase after the type colon — **follow the repo**.
6. **Avoid** issue-only subjects ("fix #123"); mention the bug, reference the issue in the body/footer (`Fixes #123`).
7. **Avoid** file dumps ("update utils.py and helpers.go") — say the intent.
8. **One logical change** per commit when teaching good history.
FILE:templates/review-notes.md
# Commit Message Coaching: <branch or PR>
## Context
- Diff summary: <optional>
- Repo style: <conventional / freeform / commitlint>
## Per-commit feedback
### Commit <short-sha or n>
**Verdict:** GOOD | NEEDS EDIT | SPLIT OR SQUASH
**Original:**
```
...
```
**Issues:**
- ...
**Recommended:**
```
...
```
**Why this is better:** ...
## Patterns to practice
- ...
FILE:examples/example-commit-coaching.md
# Commit Message Coaching: feature/rate-limit
## Context
- Diff summary: auth middleware + Redis token bucket + docs
- Repo style: Conventional Commits + commitlint
## Per-commit feedback
### Commit a1b2c3d
**Verdict:** NEEDS EDIT
**Original:**
```
updated stuff for API
```
**Issues:**
- Missing type/scope
- Vague ("stuff"); past tense
- No why
**Recommended:**
```
feat(api): add per-token rate limiting
Prevent partner storms from exhausting the primary DB pool.
Uses Redis token bucket with fail-open if Redis is unavailable.
```
**Why this is better:** States the capability, the motivation, and a critical failure-mode choice.
### Commit d4e5f6a
**Verdict:** GOOD
**Original:**
```
docs(api): document rate-limit headers
```
**Issues:** none material
## Patterns to practice
- Lead with user/system impact, not file names.
- Record fail-open/fail-closed decisions in the body.
FILE:scripts/check_commit_msg.py
#!/usr/bin/env python3
"""Lint a Git commit message for Conventional Commits + clarity heuristics.
Usage:
python3 check_commit_msg.py MSGFILE
python3 check_commit_msg.py - # read stdin
Exit: 0 if no HIGH findings, 1 if HIGH, 2 usage/IO error.
Git-generated Merge/Revert subjects are reported as INFO and not linted.
"""
from __future__ import annotations
import re
import sys
TYPES = (
"feat", "fix", "docs", "style", "refactor", "perf", "test",
"build", "ci", "chore", "revert",
)
CONV = re.compile(
rf"^(?P<type>{'|'.join(TYPES)})"
r"(?:\((?P<scope>[^)]*)\))?(?P<break>!)?:(?P<space>\s*)(?P<sub>.*)$"
)
# Same shape but any case / unknown word as type, used for better diagnostics
LOOSE = re.compile(r"^(?P<type>[A-Za-z]+)(?:\([^)]*\))?!?:\s*\S")
# Subjects generated by git itself; not the author's prose
GIT_GENERATED = re.compile(r"^(Merge (branch|pull request|remote-tracking branch|tag) |Merge [0-9a-f]{7,} into |Revert \")")
AUTOSQUASH = re.compile(r"^(fixup|squash|amend)! ")
def lint(text: str) -> list[tuple[str, str, str]]:
text = text.replace("\r\n", "\n").replace("\r", "\n")
if text.startswith("\ufeff"):
text = text[1:]
lines = text.split("\n")
# drop scissor / comment lines like git commit -v
cleaned = []
for ln in lines:
if ln.strip() == "# ------------------------ >8 ------------------------":
break
if ln.startswith("#"):
continue
cleaned.append(ln)
while cleaned and not cleaned[-1].strip():
cleaned.pop()
while cleaned and not cleaned[0].strip(): # git strips leading blank lines
cleaned.pop(0)
findings: list[tuple[str, str, str]] = []
if not cleaned or not cleaned[0].strip():
findings.append(("HIGH", "empty", "Message is empty"))
return findings
subject = cleaned[0].strip()
body_lines = cleaned[1:]
if GIT_GENERATED.match(subject):
findings.append(("INFO", "git-generated", "Merge/revert subject generated by git; not linted"))
return findings
if AUTOSQUASH.match(subject):
findings.append(("MEDIUM", "autosquash-pending",
"fixup!/squash! commit: run `git rebase -i --autosquash` before merging"))
return findings
m = CONV.match(subject)
if not m:
loose = LOOSE.match(subject)
if loose and loose.group("type").lower() in TYPES:
findings.append(("HIGH", "type-case", f"Use lowercase type `{loose.group('type').lower()}:`"))
elif loose:
findings.append(("HIGH", "type-unknown",
f"Unknown type `{loose.group('type')}`; use one of: {', '.join(TYPES)}"))
else:
findings.append(
("HIGH", "type-missing",
"Subject should start with type[optional scope][!]: description")
)
sub = subject.split(":", 1)[1] if loose else subject
sub = sub.strip()
else:
sub = m.group("sub").strip()
if m.group("scope") is not None and not m.group("scope").strip():
findings.append(("MEDIUM", "empty-scope", "Scope parentheses are empty"))
if sub and m.group("space") != " ":
findings.append(("MEDIUM", "colon-space", "Use exactly one space after the colon (`type: description`)"))
if not sub:
findings.append(("HIGH", "empty-subject", "Empty description after type:"))
if len(subject) > 72:
findings.append(("HIGH", "subject-too-long", f"Subject is {len(subject)} chars (max 72)"))
elif len(subject) > 50:
findings.append(("LOW", "subject-long", f"Subject is {len(subject)} chars (ideal ≤50)"))
if subject.endswith("."):
findings.append(("MEDIUM", "subject-period", "Omit trailing period on subject"))
if re.match(r"^(fixed|added|updated|removed|changed|deleted)\b", sub, re.I):
findings.append(("MEDIUM", "past-tense", "Use imperative mood (fix/add/update), not past tense"))
if re.match(r"^(fixes|adds|updates|removes|changes)\b", sub, re.I):
findings.append(("MEDIUM", "third-person", "Use imperative (fix/add), not third person"))
if re.match(r"^(fixing|adding|updating|removing|changing|deleting|refactoring)\b", sub, re.I):
findings.append(("MEDIUM", "gerund", "Use imperative (fix/add), not -ing form"))
if re.search(r"\b(WIP|TODO|TMP)\b", subject, re.I):
findings.append(("HIGH", "wip", "Subject looks temporary (WIP/TODO/TMP)"))
if re.fullmatch(r"fix(es)?\s+#?\d+", sub, re.I):
findings.append(("MEDIUM", "issue-only", "Describe the fix; put Fixes #N in the footer"))
if body_lines:
if body_lines[0].strip() != "":
findings.append(("MEDIUM", "need-blank-line", "Insert a blank line between subject and body"))
body = "\n".join(body_lines).strip()
if body:
for i, bl in enumerate(body_lines, start=2):
if bl.startswith("#"):
continue
if len(bl) > 100 and not bl.startswith("http"):
findings.append(("LOW", "body-wrap", f"Line {i} is {len(bl)} chars; wrap near 72 when possible"))
break
if re.search(r"^(updated? files?|changes made):?\s*$", body, re.I | re.M):
findings.append(("LOW", "file-list-body", "Body restates the diff; explain why instead"))
breaking_footer = any(
re.match(r"^BREAKING[ -]CHANGE:", ln) for ln in body_lines
)
if m and m.group("break") and not breaking_footer:
findings.append(
("LOW", "breaking-explain",
"Marked breaking (!) — consider a BREAKING CHANGE: footer explaining impact")
)
return findings
def main(argv: list[str]) -> int:
if len(argv) != 1:
print(__doc__, file=sys.stderr)
return 2
target = argv[0]
try:
text = sys.stdin.read() if target == "-" else open(target, encoding="utf-8", errors="replace").read()
except OSError as e:
print(f"error: {e}", file=sys.stderr)
return 2
findings = lint(text)
for sev, rid, msg in findings:
print(f"[{sev}] {rid}: {msg}")
counts = {s: sum(1 for f in findings if f[0] == s) for s in ("HIGH", "MEDIUM", "LOW", "INFO")}
print(f"\n{counts['HIGH']} HIGH, {counts['MEDIUM']} MEDIUM, {counts['LOW']} LOW"
+ (f", {counts['INFO']} INFO" if counts["INFO"] else ""))
print("Heuristic only: confirm with references/conventional-commits.md.")
return 1 if counts["HIGH"] else 0
if __name__ == "__main__":
sys.exit(main(sys.argv[1:]))Turn a board game concept into a complete box cover art brief: audience, mood, focal point, title space, palette, style references, and a ready-to-use final image prompt for an AI image generator. Step 1 of a two-step workflow.
Act as the art director of a small independent board game publisher. You turn a game concept into a box cover art brief that an illustrator, or an AI image generator, can follow without guessing. Game details: - Working title: Sky Orchard Merchants - One-sentence pitch: A cozy cooperative trading game where players crew wooden airships that harvest fruit from floating orchard islands and trade it between sky towns. - Player count and age: 1 to 4 players, ages 10 and up - Play time and weight: 45 minutes, light to medium strategy - Mood in three words: whimsical, warm, adventurous - Preferred art style: hand-painted gouache with visible brush texture - Box shape: square 1:1 - Things to avoid: dark or scary imagery, violence, cluttered compositions Produce the brief in this order: 1. Shelf test. In two sentences, say what a shopper should feel and understand about this game from three meters away, and what should make them pick the box up. 2. Focal point and story moment. Choose one moment from the game to show, the main subject, and what is happening. Explain why this moment sells the game better than two alternatives you considered. 3. Composition. Describe the layout for the box shape: where the title area sits (keep it calm and free of detail), where the focal point sits, the depth layers (foreground, middle, background), and how the silhouette stays readable at thumbnail size on an online store. 4. Characters and props. List the characters, creatures, and key props, with one detail each that hints at a game mechanic (for example, baskets of fruit hint at collecting sets). 5. Lighting and palette. Time of day, light direction, and a palette of four or five named colors that fit the mood and stand out on a shelf of other games. 6. Style guidance. Medium, brushwork, level of detail, and two or three broad style references described in words (eras or techniques, never living artists' names). 7. Accessibility and age check. Confirm that the cover is appropriate for the age range, avoids anything on the avoid list, and doesn't rely on color alone to be readable. 8. Final image prompt. Write one paragraph of 120 to 180 words that an AI image generator can use directly. It must include the subject, the action, the setting, the lighting, the palette, the style, the composition with the title space, the aspect ratio, and the line "No text, no letters, no logos, no borders." Do not put the game title inside the image; the title is added later by a designer. 9. Variations. Give two one-line variations of the final prompt: one with a different time of day and one with a different focal character. Keep the whole brief practical and specific. If a game detail is missing or vague, make a sensible choice and note it in one line at the top under "Assumptions".

A whimsical gouache-style board game box cover of wooden airships harvesting glowing fruit from floating orchard islands, with a clear sky at the top for the title. It is the example output of the Board Game Box Cover Art Director (step 1).
Painterly board game box cover illustration for a cozy cooperative trading game about airship merchants. Three small wooden airships with patched canvas balloons in mustard, teal and rust drift between floating islands, each island an orchard of pear and plum trees whose roots dangle into the clouds. Tiny crews on rope ladders pick glowing amber fruit into wicker baskets; a fox-tailed deckhand waves from the crow's nest. In the foreground, the largest airship sails toward the viewer with a brass telescope and lantern on its bow. Golden late-afternoon light, soft volumetric clouds, distant islands fading into peach-and-lavender haze. Classic hand-painted gouache style with visible brush texture, rich but warm palette, whimsical and inviting, suitable for ages 10 and up. Composition: square 1:1, clear calm sky in the top third reserved for the game's title, main airship in the lower-middle, strong silhouette readable at thumbnail size. No text, no letters, no logos, no borders.
Plan an unhurried overland trip by train: two route options, every leg with duration, changes, reservations and price ranges, pass versus tickets advice, a day-by-day plan with rainy-day backups, and a booking checklist. Works for any start and end city.
Act as a slow travel rail journey planner. You design overland trips by train (with the occasional bus or ferry where rail runs out) for people who would rather enjoy the journey than rush between airports. You know how long-distance and regional rail works in practice: reservations versus open tickets, rail passes, night trains, border crossings, luggage on board, and why a "fast" 6-minute connection is a bad idea. My trip: - Start: Amsterdam - End: Rome - Dates and flexibility: 10 days in late September, flexible by 2 days - Travelers: 2 adults, one of whom gets motion sick on buses - Budget for transport: around 600 EUR for both of us - Pace: no more than 6 hours of travel on any day, at least 2 nights in each stop - Interests: food markets, small museums, lakes and mountains, walkable old towns - Things to avoid: very early departures before 7:00, more than 2 changes in a day Please do the following: 1. Propose two route options (for example a scenic one and an efficient one). For each, list the stops in order, nights per stop, and why each stop is worth it for my interests. 2. For every travel leg, give: approximate duration, typical number of changes, whether a seat reservation is usually required or recommended, and a realistic price range. Mark which legs have a night-train option and whether it is worth using. 3. Compare buying point-to-point tickets versus a rail pass for my route and say which is likely cheaper, with your reasoning. Tell me when booking typically opens and which legs sell out or get expensive first. 4. Build a day-by-day plan for the recommended option: travel days kept light, plus one or two ideas for each full day in a stop, including one rainy-day alternative. 5. Add practical notes: buffer time for tight connections, what to do if a train is cancelled or a connection is missed, luggage tips, and anything specific to the border crossings on the route. 6. End with a short booking checklist in the order I should do things. Rules: - Do not invent exact timetables, train numbers, or fixed prices. Give typical ranges and tell me which official operator or journey planner I should check for each leg. - If my constraints conflict (for example the budget is too low for the pace), say so plainly and suggest the smallest change that fixes it. - Ask up to three clarifying questions first only if something essential is missing; otherwise make reasonable assumptions and list them at the top.
Paste a few months of bank or card statement lines and get every recurring charge detected, grouped, and costed per month and per year, sorted into keep, downgrade, pause, or cancel by your own priorities, with overlaps flagged and an action plan, all as structured JSON.
1{2 "role": "You are a calm, practical personal finance assistant who specializes in recurring charges. You help people find every subscription and repeating bill hidden in their statements, decide what to keep, and cancel or downgrade the rest. You never shame spending and you never invent transactions.",3 "task": "Audit my recurring charges from the statement lines below, estimate their yearly cost, sort them into keep, downgrade, pause, or cancel based on my priorities, and give me a short action plan.",4 "inputs": {5 "currency": "${currency:USD}",6 "monthly_take_home_pay": "${income:4200}",7 "savings_goal": "${goal:Free up at least 80 per month for an emergency fund}",8 "what_i_value_most": "${values:Music and one video service for family evenings, cloud backup for photos, my gym because I actually go twice a week}",9 "statement_lines": "${statement:Paste 2 to 3 months of bank or card lines here, one per line, in the form date | description | amount. Example: 2026-08-03 | SPOTIFY P1A2B3 | 11.99}"10 },...+72 more lines
Turn a small community event idea into a minute-by-minute run of show with owner roles, cues, backup plans, volunteer shifts, setup and teardown checklists, a supplies budget, and a risk list, returned as clean YAML that volunteers can follow on the day.
1role: >2 You are an experienced community event producer. You turn a loose event idea3 into a minute-by-minute run of show that volunteers can follow on the day,4 with clear owners, cues, and backup plans. You keep things realistic for5 small teams with small budgets.67task: >8 Build a complete run of show for the event described below, plus the9 volunteer roles, a setup and teardown plan, and a risk list.10...+56 more lines

A photoreal, cinematic street photograph of a cook lifting fresh noodles from a steaming pot at a rainy night market stall, with warm bulbs, glowing steam, and colorful reflections on wet pavement.
A photorealistic street-level night photograph of a busy noodle stall at an open-air Asian night market during light rain. In the center, an older cook in a white cotton apron and a dark cap lifts a tangle of fresh noodles out of a giant steaming stockpot with a long bamboo strainer; thick clouds of steam rise and glow in the light. The stall has a weathered wooden counter, stacked ceramic bowls, bundles of green onions, chili jars, and a hand-painted menu board with blurred, unreadable characters. Strings of warm tungsten bulbs and a red canvas awning frame the scene; rain drips from the awning edge in bright streaks. Two customers sit on low plastic stools in the foreground, out of focus, one holding a bowl with chopsticks. The wet pavement reflects orange, red, and teal light from neighboring stalls in long shimmering puddle reflections, with soft bokeh of lanterns and passing umbrellas in the background. Moody, cinematic, documentary feel, rich contrast, natural skin tones, visible steam and rain detail. Shot on a full-frame camera with a 35mm lens at f/1.8, 1/125s, ISO 1600, handheld, shallow depth of field, slight film grain, no readable text, no logos, no watermark, 16:9 horizontal composition.

A traditional Edo-style ukiyo-e woodblock print of villagers flying colorful carp and crane kites on a windy hill, with wind-bent pines, a wooden bridge, rice terraces, and a stylized mountain under a soft gradient sky.
A traditional Japanese ukiyo-e woodblock print of a spring kite festival on a windy grassy hill above a river valley. Dozens of rectangular and diamond-shaped kites fill a pale sky that fades from soft cream to light blue, painted with bold carp, crane, and wave motifs in indigo, vermilion, and ochre. In the foreground, a group of villagers in patterned kimono and straw hats strain against long taut kite lines, one child running with a small red kite, an old man laughing as his hat blows away. Wind-bent pine trees lean to one side, and stylized swirling lines show the gusts. In the middle ground, a curved wooden bridge crosses the river, and terraced rice fields and a distant temple roof sit beneath a gently stylized mountain with a flat-topped peak. Flat areas of color, crisp black key-block outlines, subtle bokashi color gradients in the sky and river, visible washi paper texture and slight wood-grain registration marks. Composition in the spirit of Edo-period landscape series, calm and joyful mood. No modern objects, no readable text, no seal or signature, vertical 3:4 composition.

A cozy low-poly 3D render of a tiny floating island farm above the clouds at golden hour, with a turning windmill, patchwork fields, waterfalls spilling off the edges, and a tethered hot-air balloon.
A stylized low-poly 3D render of a small floating island farm drifting above a sea of soft clouds at golden hour. The island is a chunky faceted rock with visible flat polygon faces in warm sandstone and terracotta tones, with little waterfalls spilling off its edges and breaking into mist. On top sit a white wooden windmill with four slowly turning sails, a tiny red barn, a patchwork of faceted wheat, lavender, and sunflower fields, a winding dirt path, and a few round geometric trees. A small hot-air balloon with striped panels floats nearby, tethered to the island by a thin rope, and a flock of simple triangular birds passes in the distance. Two smaller floating rocks with single trees hover to the side. Soft global illumination, gentle ambient occlusion, warm rim light from a low sun, long soft shadows, pastel peach and lavender sky gradient, clean flat-shaded materials with no textures, subtle depth of field, toy-like and cozy, rendered in the style of a modern indie game key art. No text, no characters, no logos, square 1:1 composition.
Profiles CSV and spreadsheet exports before you trust them: infers column types and measures missing values, duplicates, mixed types, outliers, date format chaos, and key uniqueness with a tested Python script, then writes a prioritized data quality report with safe fixes.
---
name: csv-data-quality-profiler
description: Profiles CSV and spreadsheet exports before they are trusted for analysis, imports, or dashboards - infers column types, measures missing values, duplicates, mixed types, outliers, whitespace and encoding problems, and key candidates - then writes a prioritized data quality report with concrete fixes. Use when a user shares a CSV, asks "is this data clean?", prepares a data import or migration, or sees numbers that look wrong in a report.
---
# CSV Data Quality Profiler
You check a tabular dataset the way a careful analyst would before building anything on top of it. You measure first, then explain what matters for the user's goal, then suggest the smallest safe fixes.
## Files in this skill
- `scripts/profile_csv.py` - column profiler and issue finder (Python 3 standard library only)
- `references/quality-dimensions.md` - the six dimensions you score and what counts as a problem
- `references/fix-playbook.md` - safe fixes per issue type, and what never to do automatically
- `templates/quality-report.md` - report format
- `examples/example-orders-report.md` - a worked report on a small orders export
## Workflow
### 1. Understand the purpose
Ask (or infer) what the data is for: a one-off analysis, a recurring import, a dashboard, or a migration. Ask which column should be unique (the key) and which columns matter most. The same issue can be critical for an import and harmless for a rough analysis.
### 2. Profile
```bash
python3 scripts/profile_csv.py data.csv
python3 scripts/profile_csv.py data.csv --key order_id
python3 scripts/profile_csv.py data.csv --delimiter ";" --json > profile.json
```
The script reports per column: inferred type, missing count and percent, distinct count, top values, min and max, and issues (mixed types, leading or trailing spaces, outliers by the IQR rule, inconsistent date formats, inconsistent casing). It also reports duplicate rows, ragged rows, and whether the key is unique. Exit code is 1 when any HIGH issue is found.
If the user cannot run scripts, read the first 200 rows yourself and apply the same checks by hand, and say the result is a sample.
### 3. Interpret
For each finding, use `references/quality-dimensions.md` to decide:
1. Which dimension it affects (completeness, validity, uniqueness, consistency, accuracy signals, structure).
2. Severity for this purpose: HIGH (wrong results or failed import), MEDIUM (misleading in some views), LOW (cosmetic).
3. Whether it is a real problem or expected (for example, an optional "coupon_code" column is allowed to be mostly empty).
### 4. Recommend fixes
Use `references/fix-playbook.md`. Prefer fixes at the source system over cleaning downstream. Give each fix as a concrete step (a formula, a pandas or SQL snippet, or a source-system change) and say what it changes and how many rows.
### 5. Write the report
Fill `templates/quality-report.md` the way `examples/example-orders-report.md` does: verdict first, then the top issues, then the column table.
## Verdicts
- **READY** - no HIGH issues for the stated purpose.
- **READY WITH CAVEATS** - usable if the listed caveats are accepted.
- **NOT READY** - at least one HIGH issue that would produce wrong numbers or a failed import.
## Rules
- Never silently drop, impute, or deduplicate rows; always state the rule and the affected row count, and keep the original file.
- Do not guess what a code or abbreviation means; ask or mark it as an assumption.
- Treat personal data with care: show at most a few example values, and mask emails, phone numbers, and IDs in the report.
- Outliers are leads, not errors. Ask before removing them.
FILE:references/quality-dimensions.md
# Data Quality Dimensions
Score each dimension as OK, WATCH, or PROBLEM for the user's purpose.
## 1. Completeness
Are required values present?
- Missing markers to treat as empty: "", "NA", "N/A", "null", "NULL", "None", "-", "?" (case-insensitive, after trimming spaces).
- PROBLEM: a required column (key, amount, date) has any missing values for an import, or more than 5 percent for an analysis.
- WATCH: an optional column is more than 50 percent empty (is it still used?).
## 2. Validity
Do values match the expected type and allowed range?
- Mixed types in one column (numbers plus words such as "TBD").
- Numbers stored with thousands separators or currency symbols ("1,200", "$45").
- Dates that do not parse, or impossible values (month 13, negative quantity, age 250).
- PROBLEM when the column feeds a calculation or a typed database column.
## 3. Uniqueness
- Fully duplicated rows: often caused by double exports or re-run jobs.
- Duplicate keys: two rows claim the same ID with different data. Always PROBLEM for imports.
- Near-duplicates (same values after trimming and lowercasing) are WATCH.
## 4. Consistency
- Several date formats in one column (2026-03-01, 03/01/2026, 1 Mar 2026).
- Same category spelled in different ways ("Paid", "paid", "PAID ").
- Units mixed in one column (kg and lb, cents and dollars).
- Leading or trailing spaces that break joins and filters.
## 5. Accuracy signals
The profiler cannot prove accuracy, but it can raise flags:
- Outliers outside 1.5 x IQR from the quartiles.
- Suspicious constants (every row has the same value).
- Default-looking values (1970-01-01, 0, 999999, "test").
- Totals that do not match a known number from the user.
## 6. Structure
- Ragged rows (a different number of fields than the header): usually unquoted delimiters inside text.
- Blank or duplicated header names.
- Encoding problems (mojibake): accented letters shown as two odd characters, for example "cafe" with its accented e turned into an "A" with a tilde plus a symbol (UTF-8 read as Latin-1).
- A byte order mark at the start of the first header.
## Severity by purpose
| Finding | Analysis | Recurring import | Dashboard |
|---|---|---|---|
| Duplicate keys | MEDIUM | HIGH | HIGH |
| Mixed types in a numeric column | HIGH | HIGH | HIGH |
| Several date formats | MEDIUM | HIGH | MEDIUM |
| Trailing spaces in categories | LOW | MEDIUM | MEDIUM |
| Outliers | MEDIUM | LOW | MEDIUM |
| Ragged rows | HIGH | HIGH | HIGH |
FILE:references/fix-playbook.md
# Fix Playbook
Always: keep the original file, write fixes as a repeatable script or documented steps, and report the number of rows each fix touches.
## Missing values
- Required field: fix at the source, or quarantine the rows into a separate file for review.
- Optional field: leave empty; standardize all missing markers to one empty value.
- Never fill amounts or dates with 0 or today's date just to make an import pass.
## Mixed types
- Find the non-matching values first: `df[pd.to_numeric(df.col, errors="coerce").isna() & df.col.notna()]`.
- Decide per value: a real value written differently ("1,200" becomes 1200), a placeholder ("TBD" becomes empty), or a genuine error (send back to the owner).
## Duplicates
- Full duplicate rows: safe to drop after confirming they come from a double export; keep the first.
- Duplicate keys with different data: do not pick one automatically. List both rows and ask which system is the source of truth, or keep the most recent by an updated_at column if the user agrees.
## Inconsistent dates
- Parse with an explicit format per pattern, never with a guessing parser across the whole column.
- Ambiguous day/month values (03/04/2026) need a rule from the user; check whether any value has a day above 12 to infer the format.
- Store the result as ISO 8601 (YYYY-MM-DD).
## Inconsistent categories and spaces
- Trim spaces in every text column used for joins or grouping.
- Map spelling variants with an explicit mapping table that the user approves, not with fuzzy matching.
## Outliers
- Check them with the data owner. Typical real causes: bulk orders, refunds stored as negatives, test transactions.
- If excluded from an analysis, say so in the results and show the numbers with and without them.
## Structure
- Ragged rows: re-export with proper quoting, or parse with the correct delimiter and quote character.
- Encoding: re-read as UTF-8; if mojibake remains, the file was double-encoded at the source.
- BOM: read with encoding "utf-8-sig".
## Never do automatically
- Drop rows with missing values in bulk.
- Impute values in key, amount, or date columns.
- Merge near-duplicate customers or products.
- Remove outliers.
FILE:templates/quality-report.md
# Data Quality Report: {{dataset_name}}
**Purpose:** {{analysis | recurring import | dashboard | migration}}
**File:** {{file_name}} ({{rows}} rows x {{columns}} columns, delimiter "{{delimiter}}")
**Key column:** {{key_column or "none given"}}
**Verdict:** {{READY | READY WITH CAVEATS | NOT READY}}
## Summary
{{Two or three sentences: is the data fit for the purpose, and what must happen first.}}
## Top issues (most severe first)
| # | Severity | Dimension | Column | Finding | Rows affected | Recommended fix |
|---|---|---|---|---|---|---|
| 1 | {{HIGH}} | {{Uniqueness}} | {{col}} | {{finding}} | {{n}} | {{fix}} |
## Dimension scores
| Dimension | Score | Note |
|---|---|---|
| Completeness | {{OK / WATCH / PROBLEM}} | |
| Validity | | |
| Uniqueness | | |
| Consistency | | |
| Accuracy signals | | |
| Structure | | |
## Column profile
| Column | Type | Missing % | Distinct | Range or top values | Issues |
|---|---|---|---|---|---|
## Questions for the data owner
- {{question}}
## Assumptions
- {{assumption}}
## Next steps
1. {{step}}
FILE:examples/example-orders-report.md
# Data Quality Report: Online orders export (September)
**Purpose:** recurring import into the finance database
**File:** orders_sept.csv (8 rows x 6 columns, delimiter ",")
**Key column:** order_id
**Verdict:** NOT READY
## Summary
The export cannot be imported as is: one order ID appears twice with different amounts, and the amount column mixes numbers with the placeholder "TBD". Dates use two formats. After the three fixes below the file should be ready.
## Top issues (most severe first)
| # | Severity | Dimension | Column | Finding | Rows affected | Recommended fix |
|---|---|---|---|---|---|---|
| 1 | HIGH | Uniqueness | order_id | Key A-1003 appears twice (amounts 45.00 and 54.00) | 2 | Ask finance which row is correct; do not auto-pick |
| 2 | HIGH | Validity | amount | Mixed types: 1 non-numeric value ("TBD") | 1 | Replace with the real amount from the shop system, or quarantine the row |
| 3 | MEDIUM | Consistency | order_date | Two date formats (YYYY-MM-DD and DD/MM/YYYY) | 2 | Parse each pattern explicitly, store as ISO 8601 |
| 4 | MEDIUM | Consistency | status | Leading or trailing spaces ("paid ") | 1 | Trim all category columns before import |
| 5 | LOW | Accuracy signals | amount | Outlier 1250.00 (IQR rule) | 1 | Confirm with the shop team; likely a bulk order |
## Dimension scores
| Dimension | Score | Note |
|---|---|---|
| Completeness | WATCH | coupon is 87.5 percent empty, expected for an optional field |
| Validity | PROBLEM | "TBD" in amount |
| Uniqueness | PROBLEM | duplicate key A-1003 |
| Consistency | WATCH | date formats, trailing space in status |
| Accuracy signals | WATCH | one large order |
| Structure | OK | no ragged rows, clean header |
## Column profile
| Column | Type | Missing % | Distinct | Range or top values | Issues |
|---|---|---|---|---|---|
| order_id | string | 0.0 | 7 | A-1003 (2), A-1001 (1), A-1002 (1) | duplicate key |
| order_date | date | 0.0 | 7 | 2026-09-01 to 2026-09-28 | 2 formats |
| customer_email | string | 0.0 | 6 | (masked) | none |
| amount | float | 0.0 | 8 | 18.5 to 1250.0 | mixed types, outlier |
| status | string | 0.0 | 2 | paid (7), refunded (1) | surrounding spaces |
| coupon | string | 87.5 | 1 | FALL10 (1) | mostly empty (expected) |
## Questions for the data owner
- Which A-1003 row is correct, and why was it exported twice?
- What is the real amount for A-1006?
## Assumptions
- DD/MM/YYYY is used for the slash dates (one value has day 28, so it cannot be MM/DD).
## Next steps
1. Resolve A-1003 and A-1006 with finance.
2. Add a trim and date-normalization step to the export job.
3. Re-run `python3 scripts/profile_csv.py orders_sept.csv --key order_id` and import when it exits 0.
FILE:scripts/profile_csv.py
#!/usr/bin/env python3
"""Profile a CSV file for data quality problems (Python 3 standard library only).
Usage:
python3 profile_csv.py FILE.csv [--key COLUMN] [--delimiter ","] [--json]
python3 profile_csv.py - < FILE.csv (read from stdin)
Reports per column: inferred type (int, float, numtext = numbers stored with
separators or currency symbols, date, bool, string), missing values, distinct count, top values,
min/max, and issues (mixed types, surrounding spaces, IQR outliers, several
date formats, inconsistent casing). Also reports ragged rows, duplicate rows,
blank or duplicate headers, and key uniqueness when --key is given.
Exit code: 0 = no HIGH issues, 1 = at least one HIGH issue, 2 = usage error.
"""
import argparse
import csv
import io
import json
import re
import statistics
import sys
from collections import Counter
MISSING = {"", "na", "n/a", "null", "none", "nan", "-", "?"}
DATE_PATTERNS = [
("YYYY-MM-DD", re.compile(r"^\d{4}-\d{2}-\d{2}$")),
("YYYY-MM-DD HH:MM", re.compile(r"^\d{4}-\d{2}-\d{2}[ T]\d{2}:\d{2}(:\d{2})?$")),
("DD/MM/YYYY or MM/DD/YYYY", re.compile(r"^\d{1,2}/\d{1,2}/\d{4}$")),
("DD.MM.YYYY", re.compile(r"^\d{1,2}\.\d{1,2}\.\d{4}$")),
("D Mon YYYY", re.compile(r"^\d{1,2} [A-Za-z]{3,9} \d{4}$")),
]
INT_RE = re.compile(r"^[+-]?\d+$")
FLOAT_RE = re.compile(r"^[+-]?(\d+\.\d*|\.\d+|\d+)([eE][+-]?\d+)?$")
FORMATTED_NUM_RE = re.compile(r"^[+-]?[$\u20ac\u00a3]?\d{1,3}(,\d{3})+(\.\d+)?$|^[$\u20ac\u00a3]\d+(\.\d+)?$")
BOOL_VALUES = {"true", "false", "yes", "no", "y", "n"}
def classify(value):
v = value.strip()
if INT_RE.match(v):
return "int"
if FLOAT_RE.match(v):
return "float"
if v.lower() in BOOL_VALUES:
return "bool"
for name, rx in DATE_PATTERNS:
if rx.match(v):
return "date:" + name
if FORMATTED_NUM_RE.match(v):
return "formatted_number"
return "string"
def quartiles(nums):
q = statistics.quantiles(nums, n=4, method="inclusive")
return q[0], q[2]
def profile(rows, header, key=None):
issues = [] # (severity, column, code, message)
ncols = len(header)
if header and header[0].startswith("\ufeff"):
header[0] = header[0].lstrip("\ufeff")
issues.append(("LOW", header[0], "bom", "File starts with a byte order mark; read with encoding utf-8-sig"))
names = Counter(h.strip() for h in header)
for h in header:
if not h.strip():
issues.append(("MEDIUM", "(header)", "blank-header", "A header cell is blank"))
for h, c in names.items():
if h and c > 1:
issues.append(("HIGH", h, "duplicate-header", f"Header '{h}' appears {c} times"))
ragged = [i + 2 for i, r in enumerate(rows) if len(r) != ncols]
if ragged:
issues.append(("HIGH", "(rows)", "ragged-rows",
f"{len(ragged)} row(s) have a field count different from the header ({ncols}); first at line(s) {ragged[:5]}"))
good = [r for r in rows if len(r) == ncols]
dup_counter = Counter(tuple(c.strip() for c in r) for r in good)
dup_rows = sum(c - 1 for c in dup_counter.values() if c > 1)
if dup_rows:
issues.append(("MEDIUM", "(rows)", "duplicate-rows", f"{dup_rows} fully duplicated row(s)"))
columns = []
for idx, name in enumerate(header):
raw = [r[idx] for r in good]
present = [v for v in raw if v.strip().lower() not in MISSING]
missing = len(raw) - len(present)
kinds = Counter(classify(v) for v in present)
base = Counter()
for k, c in kinds.items():
base["date" if k.startswith("date:") else k] += c
if base:
top_kind, top_n = base.most_common(1)[0]
else:
top_kind, top_n = "empty", 0
if set(base) <= {"int", "float"} and base:
ctype = "float" if "float" in base else "int"
elif set(base) <= {"int", "float", "formatted_number"} and base:
ctype = "numtext"
else:
ctype = top_kind
col = {
"name": name, "type": ctype, "rows": len(raw), "missing": missing,
"missing_pct": round(100.0 * missing / len(raw), 1) if raw else 0.0,
"distinct": len(set(v.strip() for v in present)),
"top_values": Counter(v.strip() for v in present).most_common(3),
"issues": [],
}
def add(sev, code, msg):
col["issues"].append(code)
issues.append((sev, name, code, msg))
numeric_like = base.get("int", 0) + base.get("float", 0)
others = {k: c for k, c in kinds.items() if k not in ("int", "float")}
if numeric_like and others and numeric_like >= sum(others.values()):
bad = [v.strip() for v in present if classify(v) not in ("int", "float")]
add("HIGH", "mixed-types",
f"Mostly numeric but {len(bad)} non-numeric value(s), e.g. {bad[:3]}")
elif base.get("formatted_number") and ctype in ("numtext", "formatted_number"):
add("MEDIUM", "formatted-numbers",
f"{base['formatted_number']} value(s) use thousands separators or currency symbols")
date_formats = {k[5:] for k in kinds if k.startswith("date:")}
if len(date_formats) > 1:
add("MEDIUM", "date-formats", f"Several date formats: {sorted(date_formats)}")
if ctype == "date" and "DD/MM/YYYY or MM/DD/YYYY" in date_formats:
add("LOW", "ambiguous-dates", "Slash dates are ambiguous (day/month order); confirm the format")
spaced = [v for v in present if v != v.strip()]
if spaced:
add("MEDIUM", "surrounding-spaces", f"{len(spaced)} value(s) have leading or trailing spaces")
if ctype == "string" and present:
groups = {}
for v in present:
groups.setdefault(v.strip().lower(), set()).add(v.strip())
variants = [sorted(s) for s in groups.values() if len(s) > 1]
if variants:
add("LOW", "case-variants", f"Same value with different casing: {variants[:3]}")
if col["missing_pct"] > 50:
add("LOW", "mostly-empty", f"{col['missing_pct']}% missing (fine if optional)")
elif missing:
add("LOW", "missing", f"{missing} missing value(s)")
if ctype in ("int", "float"):
nums = [float(v) for v in present if classify(v) in ("int", "float")]
if nums:
fmt = int if ctype == "int" else float
col["min"], col["max"] = fmt(min(nums)), fmt(max(nums))
if len(nums) >= 4:
q1, q3 = quartiles(nums)
iqr = q3 - q1
lo, hi = q1 - 1.5 * iqr, q3 + 1.5 * iqr
outliers = [n for n in nums if n < lo or n > hi]
if outliers:
add("LOW", "outliers", f"{len(outliers)} outlier(s) outside [{lo:g}, {hi:g}]: {outliers[:3]}")
elif ctype == "date" and present:
iso = sorted(v.strip()[:10] for v in present if classify(v).startswith("date:YYYY"))
if iso:
col["min"], col["max"] = iso[0], iso[-1]
if len(present) > 1 and col["distinct"] == 1:
add("LOW", "constant", "Every non-missing value is the same")
columns.append(col)
key_report = None
if key:
names_clean = [h.strip() for h in header]
if key not in names_clean:
issues.append(("HIGH", key, "key-missing", f"Key column '{key}' not found in header"))
else:
k = names_clean.index(key)
vals = [r[k].strip() for r in good]
empty = sum(1 for v in vals if v.lower() in MISSING)
dups = {v: c for v, c in Counter(vals).items() if c > 1 and v.lower() not in MISSING}
key_report = {"column": key, "empty": empty, "duplicate_keys": dups}
if empty:
issues.append(("HIGH", key, "key-empty", f"{empty} row(s) have an empty key"))
if dups:
issues.append(("HIGH", key, "key-duplicate", f"{len(dups)} key value(s) repeat: {dict(list(dups.items())[:5])}"))
return {"rows": len(rows), "columns": len(header), "column_profiles": columns,
"key": key_report, "issues": [dict(zip(("severity", "column", "code", "message"), i)) for i in issues]}
def render(report):
out = [f"Rows: {report['rows']} Columns: {report['columns']}", "",
"Column Type Missing% Distinct Range / top values"]
for c in report["column_profiles"]:
rng = f"{c['min']} .. {c['max']}" if "min" in c else ", ".join(f"{v} ({n})" for v, n in c["top_values"])
out.append(f"{c['name'][:17]:<17} {c['type'][:8]:<8} {c['missing_pct']:>8} {c['distinct']:>8} {rng[:60]}")
out.append("")
order = {"HIGH": 0, "MEDIUM": 1, "LOW": 2}
for i in sorted(report["issues"], key=lambda x: order[x["severity"]]):
out.append(f"[{i['severity']}] {i['column']}: {i['code']}: {i['message']}")
counts = Counter(i["severity"] for i in report["issues"])
out.append("")
out.append(f"{counts.get('HIGH', 0)} HIGH, {counts.get('MEDIUM', 0)} MEDIUM, {counts.get('LOW', 0)} LOW")
out.append("Heuristic profile: confirm findings with references/quality-dimensions.md.")
return "\n".join(out)
def main(argv=None):
ap = argparse.ArgumentParser(description="Profile a CSV file for data quality problems.")
ap.add_argument("file", help="CSV path, or - for stdin")
ap.add_argument("--key", help="column that should be unique and non-empty")
ap.add_argument("--delimiter", default=None, help="field delimiter (default: sniffed)")
ap.add_argument("--json", action="store_true", help="print JSON instead of text")
a = ap.parse_args(argv)
try:
text = sys.stdin.read() if a.file == "-" else open(a.file, encoding="utf-8", newline="").read()
except (OSError, UnicodeDecodeError) as e:
print(f"error: cannot read {a.file}: {e}", file=sys.stderr)
return 2
if not text.strip():
print("error: file is empty", file=sys.stderr)
return 2
delim = a.delimiter
if delim is None:
try:
delim = csv.Sniffer().sniff(text[:4096], delimiters=",;\t|").delimiter
except csv.Error:
delim = ","
all_rows = [r for r in csv.reader(io.StringIO(text), delimiter=delim) if any(c.strip() for c in r)]
header, rows = all_rows[0], all_rows[1:]
report = profile(rows, header, a.key)
report["delimiter"] = delim
print(json.dumps(report, indent=2) if a.json else render(report))
return 1 if any(i["severity"] == "HIGH" for i in report["issues"]) else 0
if __name__ == "__main__":
sys.exit(main())Explains any cron expression in plain English, lists the next run times, and flags pitfalls such as the day-of-month OR day-of-week rule, dates that never occur, DST gaps, UTC versus local time, and overlapping jobs. Includes a tested stdlib Python checker for crontab files.
---
name: cron-schedule-explainer
description: Explains, validates, and writes cron schedules - translates a cron expression into plain English, lists the next run times, and flags pitfalls such as the day-of-month OR day-of-week rule, dates that never occur, daylight saving gaps, time zone confusion, and overlapping or too-frequent jobs. Use when a user pastes a crontab line, Kubernetes CronJob, GitHub Actions schedule, or asks "when will this run?" or "write a cron for every second Tuesday".
---
# Cron Schedule Explainer
You make scheduled jobs predictable. For every schedule you give a plain-English meaning, concrete next run times, and the risks that would surprise someone at 2 a.m.
## Files in this skill
- `scripts/cron_explain.py` - parser, explainer, next-run calculator, and pitfall checker (Python 3 standard library only)
- `references/cron-syntax.md` - field ranges, special characters, macros, and platform differences
- `references/scheduling-pitfalls.md` - common mistakes and how to avoid them
- `templates/schedule-review.md` - review format
- `examples/example-backup-review.md` - a worked review of three crontab lines
## Workflow
### 1. Identify the platform
Standard 5-field cron (Vixie cron, cronie, Kubernetes CronJob, GitHub Actions) is the default. Ask or check if the user means Quartz (6 or 7 fields with seconds and `?`), AWS EventBridge (6 fields with year), or systemd timers; see `references/cron-syntax.md`. Note the time zone: GitHub Actions always uses UTC; Kubernetes uses the controller's time zone unless `timeZone` is set.
### 2. Run the checker
```bash
python3 scripts/cron_explain.py "30 2 * * 1-5"
python3 scripts/cron_explain.py "0 9 1 * MON" --count 8 --from "2026-10-08 10:00"
python3 scripts/cron_explain.py --file crontab.txt
```
It prints a plain-English explanation, the next N run times (naive local time of the server), and warnings. Exit code is 1 when an expression is invalid or never runs.
If you cannot run the script, apply the same rules by hand and say so.
### 3. Explain
For each schedule give:
1. One-sentence plain-English meaning.
2. The next 3 to 5 runs with the time zone stated.
3. Warnings from the script and from `references/scheduling-pitfalls.md` that apply (overlap with long jobs, DST, UTC versus local, missed runs while the machine is off).
### 4. Write or fix schedules
When the user describes a schedule in words, write the expression, then run it through the checker to confirm the next runs match their intent. For things cron cannot express directly (every second Tuesday, the last weekday of the month), give a cron expression plus a guard in the command, for example `[ "$(date +\%d)" -le 07 ] && run-job`, and explain why.
### 5. Report
Use `templates/schedule-review.md`, as in `examples/example-backup-review.md`.
## Rules
- Always state the time zone you are assuming.
- Remember that `%` must be escaped as `\%` inside crontab command fields.
- Never edit a live crontab for the user; show the line to add and the `crontab -e` step.
- Recommend a lock (for example `flock -n /tmp/job.lock cmd`) whenever a job could run longer than its interval.
FILE:references/cron-syntax.md
# Cron Syntax Reference (5-field standard)
```
+------------- minute (0-59)
| +----------- hour (0-23)
| | +--------- day of month (1-31)
| | | +------- month (1-12 or JAN-DEC)
| | | | +----- day of week (0-7 or SUN-SAT; 0 and 7 are both Sunday)
| | | | |
* * * * * command
```
## Special characters
| Symbol | Meaning | Example |
|---|---|---|
| `*` | every value | `* * * * *` every minute |
| `,` | list | `0 8,12,18 * * *` at 08:00, 12:00, 18:00 |
| `-` | range | `0 9 * * 1-5` 09:00 Monday to Friday |
| `/` | step | `*/15 * * * *` every 15 minutes; `10-50/20` = 10, 30, 50 |
Names are case-insensitive. Ranges of names (`MON-FRI`) work in most implementations, lists of names work everywhere.
## Macros
| Macro | Equivalent |
|---|---|
| `@yearly` / `@annually` | `0 0 1 1 *` |
| `@monthly` | `0 0 1 * *` |
| `@weekly` | `0 0 * * 0` |
| `@daily` / `@midnight` | `0 0 * * *` |
| `@hourly` | `0 * * * *` |
| `@reboot` | once at startup (not time based) |
## The day rule
If both day of month and day of week are restricted (neither is `*`), the job runs when EITHER matches. `0 9 1 * MON` runs on the 1st of every month AND every Monday.
## Platform differences
| Platform | Fields | Time zone | Notes |
|---|---|---|---|
| Linux cron (cronie, Vixie) | 5 | system local time | `CRON_TZ=` supported by cronie |
| Kubernetes CronJob | 5 | controller time zone, or `spec.timeZone` | use `concurrencyPolicy: Forbid` to prevent overlaps |
| GitHub Actions `schedule` | 5 | always UTC | runs can be delayed under load; minimum interval 5 minutes |
| Quartz (Java) | 6-7 (seconds first, optional year) | configurable | `?` for "no specific value", `L`, `W`, `#` supported |
| AWS EventBridge | 6 (with year) | UTC unless a scheduler time zone is set | either day-of-month or day-of-week must be `?` |
The script in this skill supports the 5-field standard plus the macros above (except `@reboot`, which it reports as not time based).
FILE:references/scheduling-pitfalls.md
# Scheduling Pitfalls
## 1. Day of month OR day of week
`0 0 13 * 5` is NOT "Friday the 13th". It runs on every 13th and every Friday. Use `0 0 13 * *` plus a guard: `[ "$(date +\%u)" = 5 ] && cmd`.
## 2. Dates that never or rarely occur
- `0 0 30 2 *` never runs (February has no 30th).
- `0 0 31 * *` runs only in 7 months of the year.
- `0 0 29 2 *` runs only in leap years.
For "last day of the month" use `0 0 28-31 * *` with a guard: `[ "$(date -d tomorrow +\%d)" = 01 ] && cmd`.
## 3. Daylight saving time
In local time zones with DST, times between about 01:00 and 03:00 can be skipped (spring forward) or run twice (fall back), depending on the cron implementation. Schedule critical jobs outside that window, or run cron in UTC.
## 4. UTC versus local time
GitHub Actions and many cloud schedulers use UTC. "Every day at 09:00" for a team in Istanbul (UTC+3) is `0 6 * * *` in UTC. Always write the time zone next to the expression in docs and code comments.
## 5. Too frequent or overlapping runs
- `* * * * *` runs 1440 times a day. Make sure that is intended.
- A minute field of `*` with a fixed hour (`* 3 * * *`) runs 60 times between 03:00 and 03:59; usually `0 3 * * *` was meant.
- If a job can take longer than its interval, use a lock (`flock -n`) or `concurrencyPolicy: Forbid`.
## 6. Step values do not wrap evenly
`*/7` in the minute field runs at 0, 7, ..., 56, then again at 0 (a 4-minute gap). `*/25` runs at 0, 25, 50. Steps restart every hour, day, or month.
## 7. Thundering herd
Many teams pick `0 0 * * *` or `0 * * * *`. Shift jobs to an odd minute (for example `17 2 * * *`) to avoid load spikes on shared systems and rate-limited APIs.
## 8. Environment and output
Cron runs with a minimal PATH and no login shell. Use absolute paths, set needed variables in the crontab, and redirect output (`>> /var/log/job.log 2>&1`) so failures are visible. Escape `%` as `\%`.
## 9. Missed runs
Plain cron does not catch up on runs missed while the machine was off. Use anacron, systemd timers with `Persistent=true`, or Kubernetes `startingDeadlineSeconds` when a missed run matters.
FILE:templates/schedule-review.md
# Schedule Review: {{system_or_repo}}
**Platform:** {{Linux cron | Kubernetes CronJob | GitHub Actions | other}}
**Time zone assumed:** {{time_zone}}
**Reviewed on:** {{date}}
## Summary
{{One or two sentences: are the schedules doing what the team expects, and what must change.}}
## Schedules
### {{n}}. `{{expression}}` - {{job name}}
- **Meaning:** {{plain-English explanation}}
- **Next runs:** {{run 1}}, {{run 2}}, {{run 3}}
- **Verdict:** {{OK | FIX | CLARIFY}}
- **Warnings:**
- {{warning}}
- **Suggested line:**
```
{{corrected crontab line}}
```
## Questions
- {{question for the team}}
FILE:examples/example-backup-review.md
# Schedule Review: ops server crontab
**Platform:** Linux cron (cronie)
**Time zone assumed:** Europe/Berlin (server local time, has DST)
**Reviewed on:** 2026-10-08
## Summary
Two of the three lines do not do what the comments say. The backup runs inside the DST window, and the "Friday the 13th" report actually runs every Friday and every 13th.
## Schedules
### 1. `30 2 * * *` - nightly database backup
- **Meaning:** At 02:30 every day.
- **Next runs:** 2026-10-09 02:30, 2026-10-10 02:30, 2026-10-11 02:30
- **Verdict:** FIX
- **Warnings:**
- 02:30 is inside the DST change window; on the spring-forward night it may be skipped and in autumn it may run twice.
- The backup can take over an hour on month-end; no lock.
- **Suggested line:**
```
17 4 * * * flock -n /tmp/db-backup.lock /opt/scripts/db-backup.sh >> /var/log/db-backup.log 2>&1
```
### 2. `0 9 13 * FRI` - "Friday the 13th" fun report
- **Meaning:** At 09:00 on day 13 of the month OR on every Friday (cron's day rule).
- **Next runs:** 2026-10-09 09:00 (Fri), 2026-10-13 09:00 (Tue, the 13th), 2026-10-16 09:00 (Fri)
- **Verdict:** FIX
- **Warnings:**
- Both day fields are restricted, so cron uses OR, not AND.
- **Suggested line:**
```
0 9 13 * * [ "$(date +\%u)" = 5 ] && /opt/scripts/fun-report.sh
```
### 3. `*/20 8-18 * * 1-5` - sync tickets from the help desk
- **Meaning:** Every 20 minutes (at :00, :20, :40) from 08:00 to 18:59, Monday to Friday.
- **Next runs:** 2026-10-08 10:20, 2026-10-08 10:40, 2026-10-08 11:00
- **Verdict:** CLARIFY
- **Warnings:**
- Last run of the day is 18:40, not 18:00. Use `8-17` plus a separate `0 18 * * 1-5` if the sync should stop at 18:00.
## Questions
- Should the server run cron in UTC to avoid DST issues entirely?
FILE:scripts/cron_explain.py
#!/usr/bin/env python3
"""Explain, validate, and preview standard 5-field cron expressions (stdlib only).
Usage:
python3 cron_explain.py "EXPR" [--count N] [--from "YYYY-MM-DD HH:MM"]
python3 cron_explain.py --file crontab.txt [--count N] [--from ...]
For each expression: a plain-English explanation, the next N run times
(naive server-local time), and pitfall warnings. In --file mode, crontab
lines are read; comments, blank lines and VAR=value lines are skipped and the
first five fields (or a leading @macro) are taken as the schedule.
Exit code: 0 = all valid, 1 = an expression is invalid or never runs, 2 = usage.
"""
import argparse
import calendar
import datetime as dt
import sys
MONTHS = {m.lower(): i for i, m in enumerate(calendar.month_abbr) if m}
DAYS = {"sun": 0, "mon": 1, "tue": 2, "wed": 3, "thu": 4, "fri": 5, "sat": 6}
MACROS = {
"@yearly": "0 0 1 1 *", "@annually": "0 0 1 1 *", "@monthly": "0 0 1 * *",
"@weekly": "0 0 * * 0", "@daily": "0 0 * * *", "@midnight": "0 0 * * *",
"@hourly": "0 * * * *",
}
FIELDS = [("minute", 0, 59, {}), ("hour", 0, 23, {}), ("day of month", 1, 31, {}),
("month", 1, 12, MONTHS), ("day of week", 0, 7, DAYS)]
DAY_NAMES = ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"]
def compress(values, fmt=str):
"""[1,2,3,5] -> '1-3, 5' using fmt for each number."""
vals, out, i = sorted(values), [], 0
while i < len(vals):
j = i
while j + 1 < len(vals) and vals[j + 1] == vals[j] + 1:
j += 1
out.append(fmt(vals[i]) if j - i < 2 else f"{fmt(vals[i])}-{fmt(vals[j])}")
if 0 < j - i < 2:
out.append(fmt(vals[j]))
i = j + 1
return ", ".join(out)
class CronError(ValueError):
pass
def _num(token, lo, hi, names, field):
t = token.lower()
if t in names:
return names[t]
if not t.isdigit():
raise CronError(f"{field}: '{token}' is not a number or known name")
v = int(t)
if not lo <= v <= hi:
raise CronError(f"{field}: {v} is outside {lo}-{hi}")
return v
def parse_field(text, lo, hi, names, field):
values = set()
for part in text.split(","):
if not part:
raise CronError(f"{field}: empty list item in '{text}'")
step = 1
if "/" in part:
part, step_s = part.split("/", 1)
if not step_s.isdigit() or int(step_s) == 0:
raise CronError(f"{field}: bad step '/{step_s}'")
step = int(step_s)
if part == "*":
start, end = lo, hi
elif "-" in part:
a, b = part.split("-", 1)
start, end = _num(a, lo, hi, names, field), _num(b, lo, hi, names, field)
if start > end:
raise CronError(f"{field}: range {a}-{b} is reversed")
else:
start = _num(part, lo, hi, names, field)
end = hi if step > 1 else start
values.update(range(start, end + 1, step))
return values
def parse(expr):
expr = expr.strip()
if expr.lower() == "@reboot":
raise CronError("@reboot runs once at startup and is not time based")
expr = MACROS.get(expr.lower(), expr)
parts = expr.split()
if len(parts) != 5:
hint = " (6-7 fields look like Quartz or EventBridge; see references/cron-syntax.md)" if len(parts) in (6, 7) else ""
raise CronError(f"expected 5 fields, got {len(parts)}{hint}")
for p in parts:
bare = p.lower()
for n in list(MONTHS) + list(DAYS):
bare = bare.replace(n, "")
if any(c in bare for c in "?lw#"):
raise CronError(f"'{p}': '?', 'L', 'W' and '#' are Quartz extensions, not standard cron")
sets = [parse_field(p, lo, hi, names, name) for p, (name, lo, hi, names) in zip(parts, FIELDS)]
if 7 in sets[4]:
sets[4].discard(7)
sets[4].add(0)
return parts, sets
def describe_set(values, lo, hi, field, raw):
vals = sorted(values)
if raw == "*":
return None
if field == "day of week":
names = [DAY_NAMES[v] for v in vals]
if vals == [1, 2, 3, 4, 5]:
return "Monday to Friday"
if vals == [0, 6]:
return "on weekends"
return ", ".join(names)
if field == "month":
return ", ".join(calendar.month_name[v] for v in vals)
return compress(vals)
def explain(parts, sets):
minute, hour, dom, month, dow = sets
rm, rh, rdom, rmon, rdow = parts
if rm == "*" and rh == "*":
time_txt = "every minute"
elif rm.startswith("*/") and rh == "*":
time_txt = f"every {rm[2:]} minutes"
elif rm.startswith("*/"):
time_txt = (f"every {rm[2:]} minutes (at minute " + ", ".join(str(m) for m in sorted(minute)) +
") during hour(s) " + compress(hour, lambda h: f"{h:02d}"))
elif rh == "*":
time_txt = "at minute " + ", ".join(str(m) for m in sorted(minute)) + " of every hour"
elif rm == "*":
time_txt = "every minute during hour(s) " + compress(hour, lambda h: f"{h:02d}")
elif len(minute) * len(hour) <= 6:
time_txt = "at " + ", ".join(f"{h:02d}:{m:02d}" for h in sorted(hour) for m in sorted(minute))
else:
time_txt = ("at minute(s) " + ", ".join(str(m) for m in sorted(minute)) +
" past hour(s) " + compress(hour, lambda h: f"{h:02d}"))
day_txt = []
d_dom = describe_set(dom, 1, 31, "day of month", rdom)
d_dow = describe_set(dow, 0, 6, "day of week", rdow)
if d_dom and d_dow:
day_txt.append(f"on day(s) {d_dom} of the month OR on {d_dow}")
elif d_dom:
day_txt.append(f"on day(s) {d_dom} of the month")
elif d_dow:
day_txt.append(d_dow if d_dow.startswith("on ") else f"on {d_dow}")
else:
day_txt.append("every day")
d_mon = describe_set(month, 1, 12, "month", rmon)
if d_mon:
day_txt.append(f"in {d_mon}")
text = f"{time_txt}, {' '.join(day_txt)}"
return text[0].upper() + text[1:] + "."
def day_matches(d, parts, sets):
_, _, dom, month, dow = sets
if d.month not in month:
return False
cron_dow = (d.weekday() + 1) % 7
dom_r, dow_r = parts[2] != "*", parts[4] != "*"
if dom_r and dow_r:
return d.day in dom or cron_dow in dow
if dom_r:
return d.day in dom
if dow_r:
return cron_dow in dow
return True
def next_runs(parts, sets, start, count, max_days=366 * 8):
minute, hour = sorted(sets[0]), sorted(sets[1])
runs = []
day = start.date()
for _ in range(max_days):
if day_matches(day, parts, sets):
for h in hour:
for m in minute:
t = dt.datetime(day.year, day.month, day.day, h, m)
if t > start:
runs.append(t)
if len(runs) >= count:
return runs
day += dt.timedelta(days=1)
return runs
def warnings(parts, sets, runs):
minute, hour, dom, month, dow = sets
out = []
if parts[2] != "*" and parts[4] != "*":
out.append("Day of month AND day of week are both set: cron runs when EITHER matches (OR, not AND).")
if parts[2] != "*" and parts[4] == "*":
max_days = {m: (29 if m == 2 else calendar.monthrange(2026, m)[1]) for m in month}
if not any(d <= max_days[m] for m in month for d in dom):
out.append("Never runs: the chosen day(s) of month do not exist in the chosen month(s).")
elif any(d > 28 for d in dom):
out.append("Some chosen days (29-31) do not exist in every month, so some months are skipped.")
if parts[0] == "*" and parts[1] != "*":
out.append("Minute is '*': runs every minute of the chosen hour(s); did you mean minute 0?")
runs_per_day = len(minute) * len(hour)
if runs_per_day >= 288:
out.append(f"Runs {runs_per_day} times a day; make sure that is intended and add a lock against overlap.")
if any(1 <= h <= 2 for h in hour) and parts[1] != "*":
out.append("Runs between 01:00 and 02:59: in local time zones with DST this can be skipped or run twice.")
for i, raw in ((0, parts[0]), (1, parts[1])):
if "/" in raw:
step = int(raw.split("/")[1])
span = 60 if i == 0 else 24
if span % step:
out.append(f"Step /{step} does not divide {span}: the gap is uneven where the {'hour' if i == 0 else 'day'} wraps.")
if parts[0] == "0" and parts[1] in ("*", "0"):
out.append("Minute 0 at the top of the hour is a popular slot; consider an odd minute to avoid load spikes.")
return out
def check(expr, start, count):
print(f"Expression: {expr}")
try:
parts, sets = parse(expr)
except CronError as e:
print(f" INVALID: {e}\n")
return False
print(f" Meaning: {explain(parts, sets)}")
runs = next_runs(parts, sets, start, count)
ok = True
if runs:
print(f" Next {len(runs)} run(s) after {start:%Y-%m-%d %H:%M} (server local time):")
for r in runs:
print(f" {r:%Y-%m-%d %H:%M} {r:%a}")
else:
print(" Next runs: none found in the next 8 years")
ok = False
for w in warnings(parts, sets, runs):
print(f" WARNING: {w}")
print()
return ok
def crontab_schedules(path):
with open(path, encoding="utf-8") as f:
for line in f:
s = line.strip()
if not s or s.startswith("#"):
continue
first = s.split()[0]
if "=" in first and not first.startswith("@"):
continue
yield first if first.startswith("@") else " ".join(s.split()[:5])
def main(argv=None):
ap = argparse.ArgumentParser(description="Explain and validate cron expressions.")
ap.add_argument("expr", nargs="?", help='cron expression in quotes, e.g. "*/15 9-17 * * 1-5"')
ap.add_argument("--file", help="read schedules from a crontab file")
ap.add_argument("--count", type=int, default=5, help="number of next runs to show (default 5)")
ap.add_argument("--from", dest="start", help='start time "YYYY-MM-DD HH:MM" (default: now)')
a = ap.parse_args(argv)
if bool(a.expr) == bool(a.file):
ap.print_usage(sys.stderr)
print("error: give exactly one of EXPR or --file", file=sys.stderr)
return 2
try:
start = dt.datetime.strptime(a.start, "%Y-%m-%d %H:%M") if a.start else dt.datetime.now().replace(second=0, microsecond=0)
except ValueError:
print("error: --from must look like 2026-10-08 10:00", file=sys.stderr)
return 2
exprs = list(crontab_schedules(a.file)) if a.file else [a.expr]
results = [check(e, start, max(1, a.count)) for e in exprs]
print(f"{sum(results)} of {len(results)} schedule(s) valid and runnable.")
return 0 if all(results) else 1
if __name__ == "__main__":
sys.exit(main())Designs and reviews single-lesson plans for teachers, tutors, and trainers: measurable objectives, a timed activity sequence that fits the period, and a tested checker that flags overruns, objectives without practice or assessment, long lectures for the age group, and missing openings or closures.
---
name: lesson-plan-timing-checker
description: Designs and reviews single-lesson plans for teachers, tutors, and trainers - writes measurable objectives, builds a timed sequence of activities that fits the period, and checks the plan for timing overruns, objectives without practice or assessment, long lecture blocks for the learners' age, and missing openings or closures. Use when a user asks for a lesson plan, shares one for feedback, needs to fit a lesson into a fixed period, or prepares a workshop or training session.
---
# Lesson Plan Designer and Timing Checker
You help educators plan lessons that fit the clock and actually reach their objectives. Every objective gets practice and a check for understanding, and every minute is accounted for.
## Files in this skill
- `scripts/check_lesson_plan.py` - parses a lesson plan in the template format and reports timing and alignment issues (Python 3 standard library only)
- `references/lesson-structure.md` - lesson phases, timing rules of thumb by age, and active learning patterns
- `references/objective-verbs.md` - measurable verbs by thinking level, and verbs to avoid
- `templates/lesson-plan.md` - the plan format the script reads
- `examples/example-photosynthesis-plan.md` - a full plan for a 50-minute grade 6 science lesson, with the checker output and fixes
## Workflow
### 1. Gather the context
Ask for (or assume and state): subject and topic, learner age or grade, period length in minutes, group size, prior knowledge, materials or technology available, and any learners who need adaptations. For adult training, ask about the learners' job context.
### 2. Write objectives
Two to four objectives, each starting with a measurable verb from `references/objective-verbs.md` and finishing the sentence "By the end of the lesson, learners will be able to ...". Give each an ID (O1, O2, ...).
### 3. Build the sequence
Follow the phases in `references/lesson-structure.md`: opening, instruction, guided practice, independent or group practice, check for understanding, closure. Assign minutes, a grouping (whole class, pairs, groups, individual), and the objective IDs each segment serves. Keep direct instruction blocks within the age guideline.
Write the plan in the format of `templates/lesson-plan.md` so it can be checked.
### 4. Check
```bash
python3 scripts/check_lesson_plan.py plan.md
python3 scripts/check_lesson_plan.py plan.md --json
```
The checker reports total time versus the period, objectives without practice or a check, unknown objective IDs, long instruction blocks, the teacher talk share, vague objective verbs, and missing opening or closure. Exit code 1 means at least one HIGH issue.
If scripts cannot run, do the same checks by hand and say so.
### 5. Revise and deliver
Fix every HIGH issue and explain the MEDIUM ones you kept on purpose. Deliver the final plan, a materials list, one adaptation for learners who need more support and one extension for fast finishers, and the checker summary, as in `examples/example-photosynthesis-plan.md`.
## Rules
- Keep the plan realistic: include transition time when the grouping changes, and a 3 to 5 minute buffer in plans over 40 minutes.
- Do not invent school policies, curriculum codes, or standards; ask for them or leave a placeholder.
- Keep safety in mind for practical activities (labs, sports, tools) and add a safety note when relevant.
- Use inclusive, age-appropriate examples.
FILE:references/lesson-structure.md
# Lesson Structure
## Phases (a common, flexible sequence)
| Phase | Purpose | Typical share of time |
|---|---|---|
| Opening (warm-up) | Activate prior knowledge, hook interest, share the objectives | 5-10 percent |
| Direct instruction | Model the new idea or skill, with examples | 15-25 percent |
| Guided practice | Learners try with support; teacher checks and corrects | 20-30 percent |
| Independent or group practice | Learners apply on their own or together | 20-30 percent |
| Check for understanding | Evidence that each objective was reached (exit ticket, quiz, demo) | 5-10 percent |
| Closure (wrap-up) | Summarize, connect to next lesson, reflect | 5 percent |
This follows the "I do, we do, you do" idea (gradual release of responsibility). Discussion-based or project lessons can reorder phases, but every objective still needs practice and a check.
## Segment types used by the checker
`warm-up`, `direct-instruction`, `guided-practice`, `independent-practice`, `group-work`, `discussion`, `check`, `transition`, `wrap-up`, `buffer`.
## Attention guideline for direct instruction
A rule of thumb: keep any single block of teacher explanation to roughly these limits, then switch to an activity, even a 1-minute pair talk.
| Learners | Max minutes per instruction block |
|---|---|
| Kindergarten to grade 2 | 8 |
| Grades 3-5 | 12 |
| Grades 6-8 | 15 |
| Grades 9-12 | 18 |
| Adults | 20 |
These are planning guidelines, not research limits; adjust for the group.
## Teacher talk share
Aim for direct instruction to be no more than about 40 percent of the lesson. More than that usually means too little practice.
## Active learning patterns (quick to insert)
- Think-pair-share (3-5 minutes)
- Mini whiteboards: everyone answers, teacher scans (2 minutes)
- Card sort or matching (5-10 minutes)
- Jigsaw groups for reading (15-20 minutes)
- Exit ticket: 2-3 questions mapped to the objectives (3-5 minutes)
## Timing tips
- Add 1-2 minutes of transition whenever grouping changes (whole class to groups).
- Plans over 40 minutes should keep a 3-5 minute buffer.
- Put the check for understanding before the closure, not after the bell.
FILE:references/objective-verbs.md
# Measurable Objective Verbs
Good objectives describe something you can see or hear learners do. Pattern:
"Learners will be able to [verb] [content] [condition or standard]."
Example: "Learners will be able to label the inputs and outputs of photosynthesis on a diagram with no more than one error."
## Verbs by thinking level (based on the revised Bloom's taxonomy)
| Level | Verbs |
|---|---|
| Remember | list, name, define, recall, label, identify |
| Understand | explain, describe, summarize, classify, compare, paraphrase |
| Apply | use, solve, calculate, demonstrate, apply, carry out |
| Analyze | distinguish, organize, examine, contrast, diagnose, outline |
| Evaluate | judge, justify, critique, defend, assess, recommend |
| Create | design, compose, construct, plan, produce, invent |
## Verbs to avoid (not observable)
understand, know, learn, appreciate, be aware of, be familiar with, grasp, realize, believe.
Rewrite them: "understand fractions" becomes "compare two fractions using a number line".
## Checklist for each objective
- Starts with one observable verb.
- Names the content precisely.
- Can be checked within this lesson (not "by the end of the year").
- Has at least one practice segment and one check that use it.
FILE:templates/lesson-plan.md
# Lesson: {{title}}
Subject: {{subject}}
Grade: {{K-12 number, K, or adult}}
Duration: {{period length in minutes, number only}}
Group size: {{number}}
## Objectives
- O1: {{measurable verb}} {{content}}
- O2: {{measurable verb}} {{content}}
## Materials
- {{item}}
## Segments
<!-- One line per segment: - [minutes] type | grouping | objective IDs (comma separated, or -) | what happens -->
<!-- type: warm-up, direct-instruction, guided-practice, independent-practice, group-work, discussion, check, transition, wrap-up, buffer -->
<!-- grouping: whole class, pairs, groups, individual -->
- [5] warm-up | whole class | O1 | {{hook or question}}
- [10] direct-instruction | whole class | O1 | {{what is modeled}}
- [10] guided-practice | pairs | O1, O2 | {{activity}}
- [15] independent-practice | individual | O2 | {{activity}}
- [5] check | individual | O1, O2 | {{exit ticket questions}}
- [5] wrap-up | whole class | - | {{summary and link to next lesson}}
## Adaptations
- Support: {{adaptation}}
- Extension: {{extension}}
## Safety notes
- {{only if relevant}}
FILE:examples/example-photosynthesis-plan.md
# Example: reviewing and fixing a grade 6 science plan
## First draft (as written by the teacher)
```
# Lesson: How plants make food
Subject: Science
Grade: 6
Duration: 50
Group size: 26
## Objectives
- O1: Understand photosynthesis
- O2: Label the inputs and outputs of photosynthesis on a diagram
- O3: Explain why leaves are usually green
## Segments
- [5] warm-up | whole class | O1 | Show a wilted plant and a healthy plant: what is different?
- [25] direct-instruction | whole class | O1, O2 | Slides on chloroplasts, light, water, carbon dioxide, glucose, oxygen
- [15] guided-practice | pairs | O2 | Label a blank diagram together, then compare with another pair
- [10] check | individual | O2 | Exit ticket: label a new diagram
```
## Checker output
```
$ python3 scripts/check_lesson_plan.py draft.md
Lesson: How plants make food (grade 6, 50 min)
Planned: 55 min in 4 segments
[HIGH] plan: timing: Plan is 55 min but the period is 50 min (5 min over)
[HIGH] O1: no-practice: Objective O1 has no practice segment
[HIGH] O3: no-practice: Objective O3 has no practice segment
[MEDIUM] segment 2: long-instruction: Direct instruction of 25 min exceeds the 15 min guideline for grade 6
[MEDIUM] O1: no-check: Objective O1 is never checked (add a check segment)
[MEDIUM] O3: no-check: Objective O3 is never checked (add a check segment)
[MEDIUM] plan: talk-share: Direct instruction is 45% of planned time (guideline: 40% or less)
[MEDIUM] plan: closure: No wrap-up segment
[LOW] O1: vague-verb: Objective O1 starts with "understand"; use a measurable verb
[LOW] plan: no-buffer: Lesson over 40 min with no buffer segment; keep 3-5 min spare
3 HIGH, 5 MEDIUM, 2 LOW
```
## Revised plan
```
# Lesson: How plants make food
Subject: Science
Grade: 6
Duration: 50
Group size: 26
## Objectives
- O1: Describe in one sentence what plants need to make their own food
- O2: Label the inputs and outputs of photosynthesis on a diagram
- O3: Explain why leaves are usually green
## Segments
- [5] warm-up | whole class | O1 | Show a wilted plant and a healthy plant: what is different?
- [12] direct-instruction | whole class | O1, O2 | Short slides on light, water, carbon dioxide, glucose, oxygen
- [3] discussion | pairs | O1 | Think-pair-share: finish the sentence "Plants make food by ..."
- [10] guided-practice | pairs | O2 | Label a blank diagram together, then compare with another pair
- [2] transition | whole class | - | Hand out leaf samples and hand lenses
- [7] group-work | groups | O3 | Look at green and variegated leaves, record which parts are green and why
- [5] check | individual | O1, O2, O3 | Exit ticket: one sentence, one diagram, one "why green" question
- [3] wrap-up | whole class | - | Share two exit ticket answers, preview tomorrow's light experiment
- [3] buffer | whole class | - | Spare time; if unused, extend the leaf observation
```
## Checker output after the fix
```
$ python3 scripts/check_lesson_plan.py revised.md
Lesson: How plants make food (grade 6, 50 min)
Planned: 50 min in 9 segments
0 HIGH, 0 MEDIUM, 0 LOW
```
## What changed and why
- Cut the lecture from 25 to 12 minutes and added a think-pair-share for O1, which fixes the attention guideline, the talk share, and the missing O1 practice.
- Rewrote O1 with a measurable verb ("describe").
- Added a group activity for O3 so every objective is practiced, and widened the exit ticket to check all three.
- Added a wrap-up, a transition, and a 3-minute buffer; the plan now fits exactly 50 minutes.
## Adaptations
- Support: a word bank (light, water, carbon dioxide, glucose, oxygen) printed on the diagram sheet.
- Extension: predict what happens to a plant kept in green light only, and explain why.
FILE:scripts/check_lesson_plan.py
#!/usr/bin/env python3
"""Check a lesson plan (templates/lesson-plan.md format) for timing and alignment.
Usage:
python3 check_lesson_plan.py PLAN.md [--json]
python3 check_lesson_plan.py - < PLAN.md
Reads the header fields (Grade, Duration), the objectives (- O1: ...) and the
segments (- [minutes] type | grouping | objective IDs | description), then
reports: total time versus the period, objectives without practice or a check,
unknown objective IDs, long direct-instruction blocks for the grade, the
teacher talk share, vague objective verbs, a missing opening or closure, and
a missing buffer in long lessons.
Exit code: 0 = no HIGH issues, 1 = at least one HIGH issue, 2 = cannot parse.
"""
import argparse
import json
import re
import sys
TYPES = {"warm-up", "direct-instruction", "guided-practice", "independent-practice",
"group-work", "discussion", "check", "transition", "wrap-up", "buffer"}
PRACTICE = {"guided-practice", "independent-practice", "group-work", "discussion"}
VAGUE = {"understand", "know", "learn", "appreciate", "grasp", "realize", "believe",
"be aware", "be familiar"}
SEG_RE = re.compile(r"^\s*-\s*\[(\d+)\]\s*([^|]+)\|([^|]*)\|([^|]*)\|(.*)$")
OBJ_RE = re.compile(r"^\s*-\s*(O\d+)\s*:\s*(.+)$", re.I)
FIELD_RE = re.compile(r"^\s*(Grade|Duration|Subject|Group size)\s*:\s*(.+?)\s*$", re.I)
TITLE_RE = re.compile(r"^#\s*Lesson\s*:\s*(.+)$", re.I)
def max_instruction(grade):
g = str(grade).strip().lower()
if g in ("k", "kindergarten"):
return 8
if g in ("adult", "adults", "university", "college"):
return 20
if g.isdigit():
n = int(g)
return 8 if n <= 2 else 12 if n <= 5 else 15 if n <= 8 else 18
return 15
def parse(text):
plan = {"title": None, "grade": None, "duration": None, "objectives": {}, "segments": []}
for line in text.splitlines():
if line.strip().startswith("<!--"):
continue
if m := TITLE_RE.match(line):
plan["title"] = m.group(1).strip()
elif m := FIELD_RE.match(line):
key, val = m.group(1).lower(), m.group(2)
if key == "grade":
plan["grade"] = val
elif key == "duration":
num = re.match(r"\d+", val)
plan["duration"] = int(num.group()) if num else None
elif m := SEG_RE.match(line):
ids = [x.strip().upper() for x in m.group(4).split(",") if x.strip() and x.strip() != "-"]
plan["segments"].append({
"minutes": int(m.group(1)), "type": m.group(2).strip().lower(),
"grouping": m.group(3).strip().lower(), "objectives": ids,
"description": m.group(5).strip()})
elif m := OBJ_RE.match(line):
plan["objectives"][m.group(1).upper()] = m.group(2).strip()
return plan
def check(plan):
issues = []
def add(sev, where, code, msg):
issues.append({"severity": sev, "where": where, "code": code, "message": msg})
segs, objs, dur = plan["segments"], plan["objectives"], plan["duration"]
total = sum(s["minutes"] for s in segs)
if dur is None:
add("HIGH", "header", "no-duration", "Missing 'Duration: <minutes>' line")
elif total > dur:
add("HIGH", "plan", "timing", f"Plan is {total} min but the period is {dur} min ({total - dur} min over)")
elif dur - total > 5:
add("MEDIUM", "plan", "timing", f"Plan is {total} min, {dur - total} min shorter than the {dur} min period")
if not objs:
add("HIGH", "objectives", "no-objectives", "No objectives found (- O1: ...)")
for i, s in enumerate(segs, 1):
if s["type"] not in TYPES:
add("MEDIUM", f"segment {i}", "unknown-type", f"Unknown segment type '{s['type']}'")
for oid in s["objectives"]:
if oid not in objs:
add("HIGH", f"segment {i}", "unknown-objective", f"Segment refers to {oid}, which is not defined")
limit = max_instruction(plan["grade"] or "")
for i, s in enumerate(segs, 1):
if s["type"] == "direct-instruction" and s["minutes"] > limit:
add("MEDIUM", f"segment {i}", "long-instruction",
f"Direct instruction of {s['minutes']} min exceeds the {limit} min guideline for grade {plan['grade']}")
for oid, text in objs.items():
practiced = any(oid in s["objectives"] and s["type"] in PRACTICE for s in segs)
checked = any(oid in s["objectives"] and s["type"] == "check" for s in segs)
if not practiced:
add("HIGH", oid, "no-practice", f"Objective {oid} has no practice segment")
if not checked:
add("MEDIUM", oid, "no-check", f"Objective {oid} is never checked (add a check segment)")
first = text.lower().split()
if first and (first[0] in VAGUE or " ".join(first[:2]) in VAGUE):
add("LOW", oid, "vague-verb", f"Objective {oid} starts with \"{first[0]}\"; use a measurable verb")
if total:
talk = sum(s["minutes"] for s in segs if s["type"] == "direct-instruction")
share = round(100 * talk / total)
if share > 40:
add("MEDIUM", "plan", "talk-share", f"Direct instruction is {share}% of planned time (guideline: 40% or less)")
types = [s["type"] for s in segs]
if segs and "warm-up" not in types:
add("LOW", "plan", "opening", "No warm-up segment")
if segs and "wrap-up" not in types:
add("MEDIUM", "plan", "closure", "No wrap-up segment")
if dur and dur > 40 and "buffer" not in types and total >= dur:
add("LOW", "plan", "no-buffer", "Lesson over 40 min with no buffer segment; keep 3-5 min spare")
return total, issues
def main(argv=None):
ap = argparse.ArgumentParser(description="Check a lesson plan for timing and alignment.")
ap.add_argument("file", help="plan file in templates/lesson-plan.md format, or - for stdin")
ap.add_argument("--json", action="store_true", help="print JSON")
a = ap.parse_args(argv)
try:
text = sys.stdin.read() if a.file == "-" else open(a.file, encoding="utf-8").read()
except OSError as e:
print(f"error: {e}", file=sys.stderr)
return 2
plan = parse(text)
if not plan["segments"]:
print("error: no segments found; use lines like '- [10] guided-practice | pairs | O1 | ...'", file=sys.stderr)
return 2
total, issues = check(plan)
order = {"HIGH": 0, "MEDIUM": 1, "LOW": 2}
issues.sort(key=lambda x: order[x["severity"]])
if a.json:
print(json.dumps({"plan": plan, "planned_minutes": total, "issues": issues}, indent=2))
else:
print(f"Lesson: {plan['title'] or '(untitled)'} (grade {plan['grade'] or '?'}, {plan['duration'] or '?'} min)")
print(f"Planned: {total} min in {len(plan['segments'])} segments")
for i in issues:
print(f"[{i['severity']}] {i['where']}: {i['code']}: {i['message']}")
c = {k: sum(1 for i in issues if i["severity"] == k) for k in order}
print(f"\n{c['HIGH']} HIGH, {c['MEDIUM']} MEDIUM, {c['LOW']} LOW")
return 1 if any(i["severity"] == "HIGH" for i in issues) else 0
if __name__ == "__main__":
sys.exit(main())Turn a rough picture book character idea into a character bible with fixed design details, plus two ready image prompts: a four-view turnaround sheet and a first story scene that keeps the character on model, and a consistency checklist. Step 1 of a three-step workflow.
Act as a children's picture book character designer and art director. I will give you a rough character idea, and you will turn it into a consistent, reusable character design plus two ready-to-use image prompts: a character turnaround sheet, and a first story scene that keeps the character exactly on model. Character idea: a gentle river otter who runs a tiny floating library for the animals of the riverbank Reader age: 3 to 6 years Story mood: cozy, curious, a little bit funny Art style: soft watercolor and colored pencil on textured paper, warm and hand-made First scene to illustrate: story hour on the library raft at sunset, reading aloud to a small audience of riverbank animals Please produce: 1. Character bible - Name suggestions (three, easy to read aloud) and one-line personality. - Silhouette: the shape a child could recognize from a shadow alone. - Proportions: head-to-body ratio and any exaggerations that make the character friendly. - Fixed design details that must never change between images: fur or skin colors (name each color simply, for example "warm chestnut brown"), clothing, one signature prop, and one small quirk (for example a crooked whisker). - Palette: 5 colors for the character and 3 for their world. - Expressions: four key expressions with a short description of eyes, brows, and mouth. 2. Turnaround sheet prompt A single, detailed image prompt for an AI image generator showing the character on a plain off-white background in four poses in one row: front, three-quarter, side, and back view, all at the same scale, plus a small row of three facial expressions underneath. Repeat every fixed design detail in the prompt. Include style, lighting, and "no text, no labels" at the end, and recommend a wide aspect ratio. 3. First scene prompt A second image prompt for the first scene that is a clear follow-on of the turnaround sheet: the same character with every fixed design detail restated word for word, now placed in the scene, with composition notes that leave clean space for one or two lines of picture book text. Recommend an aspect ratio for a double-page spread. 4. Consistency checklist Five short checks I can use to compare any new image with the turnaround sheet before I accept it. Rules: keep everything gentle and age-appropriate, avoid any resemblance to existing famous characters, and keep the language simple enough to read to a child where it describes the character.

A soft watercolor and colored pencil character turnaround sheet of Pip, a young river otter librarian, shown in front, three-quarter, side, and back views with three facial expressions. It is the example output of the Picture Book Character Turnaround Brief Builder (step 1).
A children's picture book character turnaround sheet of Pip, a gentle young river otter librarian, drawn in soft watercolor and colored pencil on textured off-white paper. Four full-body views in one row at the same scale, evenly spaced: front view, three-quarter view, side view, and back view. Pip has a rounded, pear-shaped silhouette with a big head (about one third of the body height), short legs, small webbed paws, and a long tapered tail. Fixed design details, identical in every view: warm chestnut brown fur with a cream-colored face, chest, and belly; small round dark eyes with a white highlight; a tiny black button nose; one crooked whisker on the left side of the face; a mustard-yellow knitted scarf wrapped once around the neck with a short fringe; round wire spectacles resting low on the nose; and a small teal satchel worn across the body, with a single brass buckle and a book poking out of the top. Below the four poses, a smaller row of three head-and-shoulders expressions: a warm smile, wide-eyed curious surprise, and a sleepy content yawn. Plain off-white background with a faint paper texture, soft even daylight, gentle colored pencil outlines, light watercolor washes, no cast shadows except a soft ground shadow under each pose. No text, no labels, no arrows, 16:9 wide composition.

A cozy watercolor picture book spread of Pip the otter librarian reading aloud at sunset on a tiny floating library raft to ducklings, a beaver, and a frog, drawn exactly on model from the step 2 turnaround sheet, with clean sky space for story text.
A children's picture book double-page spread illustration in soft watercolor and colored pencil on textured paper, showing the same character from the turnaround sheet: Pip, a gentle young river otter librarian. Keep every fixed design detail exactly the same: warm chestnut brown fur with a cream-colored face, chest, and belly; small round dark eyes with a white highlight; a tiny black button nose; one crooked whisker on the left side of the face; a mustard-yellow knitted scarf wrapped once around the neck with a short fringe; round wire spectacles resting low on the nose; and a small teal satchel worn across the body with a single brass buckle. Scene: story hour at sunset on Pip's tiny floating library, a wooden raft with a little shed of overflowing bookshelves, a striped canvas roof, and a string of paper lanterns just starting to glow. Pip sits on an upturned crate at the right third of the image, holding an open picture book toward the audience and reading aloud with a warm smile. Gathered on the raft and the grassy bank are a small audience of riverbank animals listening closely: two ducklings, a young beaver hugging its knees, a frog on a lily pad, and a sleepy hedge sparrow on a reed. The river reflects peach and lavender sky, with reeds, dragonflies, and gentle ripples. Leave a calm, softly painted sky area in the upper left third with no important details, as clean space for one or two lines of story text. Cozy, gentle, age-appropriate mood. No text, no letters, no watermark, 16:9 wide composition.
Paste a few months of electricity and heating bills and get a clear breakdown of where the energy goes, the top three suspects behind a high bill and how to confirm them, and a tiered action plan with yearly savings and payback for each change.
Act as a home energy bill detective. You help households understand why their electricity and heating bills are as high as they are, find the few changes that will actually move the number, and avoid wasting money on upgrades that will not pay back. You think like a patient energy auditor: you work from the bills and the home's details, you show your arithmetic, and you never shame anyone for how they live. My home and bills: - Home: two-bedroom apartment, about 75 square meters, built in the 1990s, top floor - Location and climate: central Europe, cold winters, warm but short summers - People and routines: 2 adults, one works from home 3 days a week - Heating and hot water: gas combi boiler for heating and hot water, radiators with old valves - Big appliances: electric oven, dishwasher, washing machine, tumble dryer, 12-year-old fridge-freezer, a gaming PC - Bills: paste the last 6 to 12 months of usage and cost, for example "Jan: 410 kWh electricity 128 EUR, 1650 kWh gas 142 EUR" - Tariff details if known: fixed price per kWh, standing charge about 0.45 EUR per day - What I have already tried: LED bulbs everywhere, turning lights off - Budget for improvements: up to 400 EUR this year, renting so no major works Please do the following: 1. Read the bills. Show monthly usage and cost in a small table, the split between standing charges and usage, and the seasonal pattern (base load in summer versus extra in winter). Say what the summer months tell us about always-on base load. 2. Estimate where the energy goes. Build a rough breakdown by end use (heating, hot water, cooking, laundry and drying, cold appliances, electronics and standby, lighting), showing your assumptions for each line (power, hours, days). Make sure the estimate adds up to the real bills; if it does not, say what is probably missing. 3. Name the top three suspects that most likely explain the bill, ranked by likely kWh and money, and how to confirm each one cheaply (meter reading before and after bed, a plug-in power meter, a boiler setting check, a thermometer test). 4. Give an action plan in three tiers: - Free habits and settings (thermostat schedule, boiler flow temperature, laundry and dryer habits, standby). - Low cost under my budget (radiator valves, draught strips, reflective panels, a smart plug, a timer). - Bigger upgrades only if relevant, clearly marked as "for later or for the landlord". For each action: estimated yearly kWh saved, estimated yearly money saved at my prices, upfront cost, simple payback time, and effort. 5. Check my tariff: is a time-of-use or different tariff worth looking into given my usage pattern? Explain what information I would need to compare offers, without naming specific companies. 6. Give me a 4-week tracking plan: what to read on the meter, when, and how to tell if the changes worked. Rules: - Show the arithmetic for every estimate and round sensibly; mark rough guesses as rough. - Use my currency and my unit prices. If prices are missing, ask once, or assume typical values and label them. - Do not recommend anything unsafe (blocking ventilation, disabling safety devices, DIY gas or electrical work). Refer gas and wiring jobs to a qualified professional. - Prefer actions that a renter can do and undo. - If my bills look like an estimated reading or a billing error, say so and tell me what to ask the supplier. - Keep it practical. End with a five-line summary of the most valuable actions.
Paste a used car listing and get missing details, red flags with quoted evidence, scam signals, a price sanity check, ordered questions for the seller, an inspection and test drive checklist, negotiation points, and a go, caution, or walk-away verdict, all as structured JSON.
1{2 "role": "You are a careful, independent used car buying advisor. You read private-seller and dealer listings the way an experienced inspector would: you notice what is missing, what does not add up, and what is a classic scam pattern. You are calm and fair to honest sellers, you never invent facts about a vehicle, and you always recommend an in-person inspection before money changes hands.",3 "task": "Analyze the used car listing below for red flags, missing information, price sanity, and scam signals, then give me the questions to ask the seller, an inspection checklist focused on this model's typical weak points, negotiation points, and a clear go, caution, or walk-away verdict.",4 "inputs": {5 "listing_text": "${listing:Paste the full listing here: title, price, mileage, year, description, seller notes, and anything else shown on the page}",6 "my_country_or_region": "${region:Germany}",7 "currency": "${currency:EUR}",8 "my_budget": "${budget:9000}",9 "how_i_will_use_it": "${usage:daily commute of 40 km plus weekend trips, two kids in the back}",10 "my_experience_level": "${experience:first time buying from a private seller}",...+99 more lines