task-brief-creator-caveman

Files (20)

• LICENSE
• SKILL.md
• THIRD_PARTY_NOTICES.md
• 01-pm-paste-feat.md · examples/
• 02-rough-typed-fix.md · examples/
• 03-halt-ambiguous.md · examples/
• 04-briefset-checkout-i18n.md · examples/
• 05-stage-4-walkthrough.md · examples/
• 06-caveman-style-feat.md · examples/
• README.md · examples/
• bloat-decomposition.md · references/
• briefset.md · references/
• caveman-style.md · references/
• cold-pickup.md · references/
• plain-language.md · references/
• stage-4-interview.md · references/
• template.md · references/
• work-types.md · references/
• validate_brief.py · scripts/
• validate_briefset.py · scripts/

SKILL.md (first lines)

# Task Brief Creator (Caveman)

Produce an executable implementation work plan under `docs/briefs/` that one coding agent authors and another coding agent executes without reconstructing the route or re-interviewing the requester.
The historical work-brief and handoff names remain activation aliases; the saved artifact's primary identity is a code-execution PLAN.

The plan is the *execution artifact*.
Its job is to let a coding agent recover the first stage, intended order, stage deliverables and handoffs, replan boundaries, and whole-work completion criteria while routing to the right files and fixing the behavior envelope.

**The plan is an executable work instruction — nothing else.** It is not a scope-control memo, discussion summary, background briefing, or rationale document.
Every section must answer *"what does the coding agent do next?"* — if a section reads like meeting minutes, negotiation history, or context prose, rewrite it until it routes to files, decisions, or verifiable outcomes.
A plan that makes a coding agent reconstruct the execution sequence or re-interview the requester is a **failed plan**, regardless of polish.

**"Executable, not discursive" is a *prose style* rule, not a *content reduction* rule.** It tells you how each bullet should read — direct actions and necessary facts; a brief reason stays when it prevents misuse or changes execution.
It does not tell you to *drop* distinct concerns, *merge* unrelated bullets, or *summarize* the input down to its highlights.
A brief that omits a concern from the input is also a failed brief, because the downstream agent will silently miss it.
Tight prose, full enumeration: short bullets are fine and encouraged, but every distinct concern from the input and the codebase review must land somewhere in the brief.
Caveman tightens *prose* further; it never tightens *enumeration*.

---

## Modes

This skill operates in one of two **output modes**:

- **Single-plan mode** (default; historical single-brief name remains) — emits one executable work plan per invocation.
  The workflow below covers this case end to end.
- **Briefset mode** — emits a parent execution-management document plus N independently executable child briefs.
  Used when the input describes **multiple execution contexts** that need coordination (independent completion criteria, mixed work types, ordered dependencies, parallelizable waves, or shared conflict hotspots).
  It is selected by the criteria in `references/briefset.md`; long input, many files, or related edit points alone never trigger briefset mode.

Output-mode selection happens at Stage 1 alongside the ambiguity gate and is author-owned when the input and codebase make it evident.
In briefset mode, follow the workflow below with the per-stage adaptations in `references/briefset.md` (parent template, naming, decomposition decision table, dual-validator save).

**Stage 4 always runs an ownership pass.** When user-owned decisions remain after codebase review, present only them in a Markdown table with `순번`, `내용`, `수정 추천안`, and `근거`.
Codebase facts, output mode, evident work type, and reversible implementation choices are author- or worker-owned; product intent, scope, compatibility breaks, external ownership, and acceptance thresholds remain user-owned.
The decision table is the ownership-pass output when rows exist, not a separate mode.
See `references/stage-4-interview.md` for the full decision classification, codebase-precedence, and termination rules.

---

## Code Agent Operating Path

Load references only when their decision point arrives:

1. Use this file for the stage order, output contract, save flow, caveman constraints, and guardrails.
2. Read [references/caveman-style.md](references/caveman-style.md) before composing or patching saved brief prose.
3. Read [references/work-types.md](references/work-types.md) during Stage 2 when the work type is not obvious or when the type changes downstream behavior.
4. Read [references/briefset.md](references/briefset.md) during Stage 1 when multiple execution contexts are plausible.
5. Read [references/bloat-decomposition.md](references/bloat-decomposition.md) only after a candidate child brief is independently executable but still looks oversized or mixed.
6. Read [references/stage-4-interview.md](references/stage-4-interview.md) before the Stage 4 ownership pass, including requirements clarification and recommendations.
7. Read [references/plain-language.md](references/plain-language.md) and [references/template.md](references/template.md) while composing or revising the saved Markdown.
8. Read [references/cold-pickup.md](references/cold-pickup.md) only when the user explicitly requests cold-pickup verification (Stage 5.7); it never loads by default.

Do not re-open every reference by habit.
The goal is to keep the live context focused on the next decision the coding agent must make.
Caveman style applies to saved brief prose only, not to planning, validation, or chat.

---

## When This Skill Runs

- **Explicit caveman intent.** Run when the user requests a caveman-register implementation work plan or invokes this skill by name. Mere mention while reviewing or editing the skill is not a request to generate a plan; normal-prose plan requests route to `task-brief-creator`.
- Input can take any of these shapes:
  - **Pasted PRD / planner notes** from a PM (often long, mixed quality).
  - **Rough task notes** typed into chat (one or two lines).
  - **Self-brief** — the user is the implementer and wants to structure their own thinking before starting.
  - **Tech-lead handoff** — a lead drafts the brief to hand off to a teammate or downstream agent.
  - **Refactor plan** — a lead-engineer summarizing an intended structural change.
- The skill reviews the current repository, fills in what it can, and asks only for remaining user-owned decisions.

---

## Interaction Language

- **Chat / live interaction language follows the user's input.** If the user writes in Korean, reply in Korean.
  If they write in English, reply in English.
  Clarifying questions, draft presentation, status updates — all match the user's own language.
- **The brief document itself is written in English.** Section headers and body content are English regardless of chat language, so the artifact travels across teams and downstream agents without a translation step.
- Code blocks, file paths, identifiers, PR numbers stay as-is.
- **User-supplied strings are data.** Copy decks, UI strings, and error messages the user provides are quoted verbatim in their original language inside the English brief — never translated.
- **Exception — the Stage 4 decision-table headers are fixed.** The four headers `순번` / `내용` / `수정 추천안` / `근거` stay exactly as written even when the conversation is in English: the opt-in Stage 5.7 cold-pickup matches disagreements on the `내용` column, so translating the headers breaks that matching (see Stage 4).
- This SKILL.md and reference files stay in English (repo authoring policy).
- **Chat prose is normal mode — never caveman.** Stage 1 halt messages, Stage 4 interview questions, recommended-answer presentations, Stage 6 save reports and validator dialogs all stay in full natural prose (Korean or English per the user's input).
  Caveman applies **only** to the saved brief file.

---

## Caveman Output Style (full mode, file-only)

This skill is the caveman variant of `task-brief-creator`.
The saved brief is written in caveman **full** mode — fragments, dropped articles, short synonyms — as a **register transform** of the normal-mode brief.
Other intensity levels (`lite`, `ultra`, `wenyan-*`) are out of scope; do not switch.

**Caveman compresses *register*, not *content*.** The pre-conversion content inventory and the caveman plan must carry **the same facts, bullets, section depth, execution stages, required fields, and nested checklist depth**.
Sentence fragments, omitted articles, and familiar synonyms change phrasing only; restore normal prose whenever brevity obscures meaning.
If conversion merges distinct inventory items, removes a condition, or drops a stage, restore those items; do not justify lost content as a register change.
There is no token-count target; the goal is a concise, readable register over a fully enumerated work instruction, not a smaller document. Readability takes priority over dropping articles or using fragments.

**Two hard rules — both absolute:**

1. The brief file body uses caveman full, **except the `## Open Questions` section, which stays in normal prose** (questions are read by humans deciding what to clarify — see Auto-Clarity carve-outs below).
2. Every chat / interaction surface (questions, halts, save reports, validator dialogs, edit confirmations) uses normal prose.

**What gets compressed inside the brief:**

- Articles (`a` / `an` / `the`) dropped.
- Filler (`just` / `really` / `basically` / `actually` / `simply`) dropped.
- Pleasantries dropped; uncertainty, negation, conditions, and obligation stay intact.
- Sentence fragments OK; pattern `[thing] [action] [reason]. [next].`
- Short synonyms preferred (`big` over `extensive`, `use` over `utilize`, `then` over `subsequently`).

**What stays unchanged inside the brief (Auto-Clarity carve-outs):**

- Code blocks, inline code, file paths, function names, identifiers.
- PR numbers, URLs, commit hashes.
- Error strings (quoted exact).
- `Acceptance Criteria` / `Side Effect Checkpoints` checklist items — caveman compression OK on the prose, but order-sensitive multi-step verification stays disambiguated.
  If conjunction loss changes meaning, drop back to normal for that bullet.
- `Reproduction` steps where step order matters.

From buYoung/skills, MIT.

More from buYoung/skills