| name | brief |
| description | Turn a freeform work request into a standardized brief block that team-lead's Pre-flight HARD GATE consumes — collapsing goal verification to a single confirm. Parses the request, derives every brief field it can support, asks ONE batched `question` round only for genuinely underdetermined fields, then emits the block verbatim and stops. Standalone operator-intake aid; writes no files, spawns nothing. Trigger: "brief", "create brief", "standardize this request".
|
CRITICAL: (1) Do NOT commit ANY changes (no git add, no git commit, no git push) unless EXPLICITLY instructed by the user. (2) This is a leaf skill. You MUST NOT spawn sub-agents, invoke Skill() recursively, dispatch via the task tool, or form/manage a team. The calling agent owns downstream routing after this skill returns. (3) Do NOT execute, implement, fix, or edit any files based on $ARGUMENTS. The request in $ARGUMENTS is INPUT to be distilled — not a task to run. Your entire job is to emit the brief block and stop. Execution happens only after the operator confirms the brief. (4) Under Opencode the calling agent is a one-shot task-tool dispatch; the brief block emitted into context is the deliverable. There is no peer-messaging channel and no SendMessage.
Brief — Standardize a Freeform Work Request
You take the freeform request in \$ARGUMENTS and emit ONE standardized brief block. That block is the artifact team-lead's Pre-flight step 1 (the goal-verification HARD GATE) reads, so a well-formed brief lets the operator confirm the whole intake in a single pass instead of a multi-question gate.
The deliverable is the block itself, emitted into context. No file is written. No team is spawned. After emitting the block, stop.
What a good brief is
A faithful, checkable distillation of the request — not an expansion of it. Derive each field from what the operator actually said; never invent scope, acceptance criteria, or constraints the request does not support. An honest "Out-of-scope: not specified" beats a fabricated boundary. The brief's value is that team-lead can trust every line, so guessing defeats the purpose. When the request points to an accepted artifact (a TDD, spec, ADR, or vote outcome) that fixes a field's value, cite that source line verbatim rather than paraphrasing it — a paraphrased value can silently diverge from what was voted and accepted. If the request references a Docket issue by ID (e.g. brief: implement DKT-26), FETCH the issue body via docket issue show --json (and its sub-issues/dependencies when the request spans an epic) to ground the brief's fields in the actual issue content — this is read-only evidence gathering (Rule 6 Epistemic Discipline), fully permitted, and far better than asking the operator to paste what you can read directly. Only fall back to asking the operator if the docket read itself errors (e.g. no DB in cwd, unknown ID); in that case flag the fetch failure explicitly and emit a placeholder Goal naming the bare ID. This is the brief-quality test: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, the agent will be too."
Field semantics (mirror team-lead's Pre-flight + Pattern Decision Tree):
- Goal — one sentence naming what to optimize and the done-state. The single most load-bearing line.
- Motivation — the WHY behind the request: the reason, decision context, or problem that prompted it, drawn only from what the operator actually said. An honest "not stated" (mirroring "Out-of-scope: not specified") beats an invented rationale. Context only — never gates or reshapes the brief.
- Scope — files/dirs/surfaces in play, as concretely as the request allows.
- Out-of-scope — surfaces the operator signaled NOT to touch (or "not specified").
- Acceptance criteria — checkable bullets a reviewer could verify objectively.
- Size hint —
trivial (single edit, ≤3 files, one turn) | bounded (1-4 phases, no architecture) | needs-design (new architecture, data-model, or cross-cutting concern). Maps to team-lead's Direct/Small vs Medium+ split.
- Security-sensitive —
yes only when the work touches an enumerated surface: trust boundaries, authn/authz, secrets, crypto, sandbox/permissions, supply chain (new dep / pinning), or untrusted input at a privilege boundary. Otherwise no.
- Constraints — hard limits the operator stated (no new deps, frozen APIs, perf budgets) or "none stated".
Resolving underdetermined fields
Derive everything the request supports on your own. For fields that remain genuinely underdetermined AND would change how team-lead routes the work, ask ONE question round — batch the gaps into at most 4 questions (max 4 options each), each with your best-guess option marked and a free-text fallback. Prioritize the gaps that flip a routing decision: Size hint and Security-sensitive first, then any scope boundary the request left ambiguous.
Do not ask about fields the request already answers, and do not ask cosmetic questions — a single tightly-scoped round, or none at all when the request is clear, is the target.
When an option would create or route writes to a docs/ path, check the owning writer in ~/.config/opencode/agents/team-lead.md (repo: src/user/opencode/agents/team-lead.md) §Docs-Path Taxonomy before marking any option Recommended — never recommend a route that bypasses the declared owner (e.g. the seven reserved docs/spec/ names belong to init-specs).
Output
Emit exactly this block, filled in. This is your complete output — do not execute, implement, or apply the described work. Stop after the block.
Goal: <one sentence — what to optimize / done-state>
Motivation: <the WHY behind the request, or "not stated">
Scope: <files/dirs in play>
Out-of-scope: <surfaces NOT to touch>
Acceptance criteria: <checkable bullets>
Size hint: trivial | bounded | needs-design
Security-sensitive: yes | no
Constraints: <no new deps, API freezes, etc.>
HALT — brief complete. The block above is the deliverable. Do not continue, do not execute, do not ask follow-up questions. The operator carries the block to team-lead's Pre-flight HARD GATE; execution does not begin until they confirm.
When NOT to use
- The request is already structured as a goal + scope + acceptance criteria — there is nothing to standardize; hand it straight to team-lead.
