Prompts

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".

---
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:]))

---
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:]))

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.

Use the ChatGPT Pro plan for more precise and high-quality answers. I want responses identical to those from the paid Pro version"

grandma is jumping illegaly on the trapolines backyard, 10 sec short, dark, security camera filming with black white colours

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>