菜单
Use before dispatching any subagent or task. Compiles a verbose intent into a tight RTCO (Role, Task, Constraints, Context, Output) brief that minimizes tokens while preserving every guardrail. Mandatory before any Task/Agent dispatch.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use after verify-gate returns `ready`, as an optional security pass over a vibe run's diff before finish-branch. Runs a tiered threat-model review — universal code-security checks on every diff, plus AI-artifact checks when the diff builds a skill, agent, prompt, or MCP server — quotes verbatim file:line evidence, scores findings, and hard-gates the handoff on CRITICAL/HIGH with a written-waiver escape. Peer to review-pack; both optional, either may run before finish-branch.
Use to diagnose vibekit installation health — skill file integrity, runtime registration parity, `.vibekit/` directory health, `docs/` subdir presence, authoring-contract alignment. Reports verdict only by default; `--fix` auto-repairs safe items. Cross-runtime portable.
Use after verify-gate returns `ready` and before finish-branch or any outward-facing action. Performs a self-review pass (Reflexion-style) — the skill critiques its own completed work against the spec and the plan, surfaces issues in order of severity, and presents the diff to the user for explicit sign-off. No outward-facing action runs until the user approves.
Use when starting any conversation — establishes vibekit's auto-trigger discipline so pipeline skills (brainstorm, brief, plan, exec, verify, review, finish, memory) actually fire at their trigger points instead of being silently skipped.
Use when the user says "vibe" or gives a short intent like "add X", "build Y", "fix Z". Runs the full disciplined pipeline end-to-end — brainstorm → plan → isolated execution → verification — with minimal user interaction outside the brainstorm phase. The user only has to answer design questions; every other step is autonomous, guardrail-protected, and token-efficient. If the user does not say "vibe" explicitly, do not assume this skill applies.
You MUST use this before any creative or implementation work — creating features, building components, adding functionality, or modifying behavior. Runs a disciplined Socratic brainstorming loop (hard gate, one-question-at-a-time, 2-3 approaches, design doc, user approval) while keeping token overhead minimal. Questions, user answers, approaches, design, and the written spec are never compressed.
| name | brief-compiler |
| description | Use before dispatching any subagent or task. Compiles a verbose intent into a tight RTCO (Role, Task, Constraints, Context, Output) brief that minimizes tokens while preserving every guardrail. Mandatory before any Task/Agent dispatch. |
Before any subagent dispatch or delegated task. If you are about to write Task(...), Agent(...), or a pipeline step, this skill runs first to produce the brief.
Also invoke when: writing instructions for a parallel fan-out, authoring a scheduled job, preparing a handoff to another CLI.
Subagents with unbounded briefs drift. Verbose briefs burn tokens twice — once on the way in, again on the way back when the agent mirrors the verbosity. The RTCO template forces the caller to decide what good looks like before dispatch, and a machine-parseable output schema lets the return-side filter do its job.
Every compiled brief must have exactly these five sections, in this order:
ROLE: <one line. Specific identity. "Go test author for package X", not "helpful assistant">
TASK: <one imperative sentence. What must be true when done>
CONSTRAINTS:
- Edit ONLY files named in TASK or CONTEXT. No adjacent edits.
- Match existing style; do not refactor unrelated code.
- Do not delete pre-existing dead code; mention it in OUTPUT instead.
- You MAY halt with a NEEDS_INPUT return ONLY on spec-ambiguity (a spec/plan detail with two reasonable interpretations) OR missing-context (a file/API/library reference the brief did not provide). You MAY NOT use NEEDS_INPUT for environment, tooling, test, or dependency failures — those are task failures and go in `unexpected`.
- A NEEDS_INPUT return MUST include: `blocking_step` (verbatim quote of the plan step you halted at), `tried` (what you attempted to resolve from the brief alone — `n/a` is invalid), 2+ `options` with non-empty `label` and `summary`, and a `recommendation` (option label + reason, or exactly `none — no clear preference`). Vague returns are REJECTED by report-filter.
- Before halting with NEEDS_INPUT, roll back any uncommitted partial work (`git restore .`) and any commits made during this task attempt (`git reset --hard <pre-task-sha>`). Set `rolled_back: true` in the return.
- Budget cap: at most TWO NEEDS_INPUT signals on the same task across re-dispatches. A third halt is a task failure, not a question.
- <task-specific rule, one per line>
- <task-specific rule>
CONTEXT:
<only what the agent cannot derive. File paths with line numbers, exact snippets,
relevant facts the agent does not have. Nothing else>
OUTPUT:
<exact machine-parseable schema. JSON keys named. Or a fenced markdown structure
with every heading the agent must produce>
Missing field = invalid brief. Do not dispatch.
Rule of thumb: if the agent would get a worse result from the compressed form, don't compress that part.
Before (verbose, ~180 tokens):
Hey, could you please go and take a look at how authentication is currently
handled in this codebase? I'd really love to understand the flow end to end.
Specifically, I'm curious about the middleware layer. When you're done, could
you write up a summary of what you found? Thanks so much!
After RTCO (~68 tokens):
ROLE: Auth-flow researcher, read-only.
TASK: Map auth middleware end-to-end in this repo.
CONSTRAINTS:
- Read-only. No edits.
- Cite file:line for every claim.
CONTEXT:
Entry points suspected in cmd/server/*.go.
OUTPUT:
```json
{
"entry_points": [{"file": "...", "line": 0}],
"middleware_chain": ["..."],
"token_validation": {"file": "...", "line": 0, "approach": "..."},
"gaps": ["..."]
}
Token cost down ~60%. Output is parseable. Agent cannot drift into prose.
### Example B — implementation subagent (guardrails critical)
Before:
Please implement the dark mode toggle we discussed, making sure to follow TDD. Don't forget to run the tests. Thanks!
After RTCO:
ROLE: Frontend implementer, component-scope. TASK: Add dark-mode toggle matching plan.md section 3. CONSTRAINTS:
npm test -- ThemeToggle after each change; all must pass at end.Variant A — task complete:
{
"status": "complete",
"tests_added": ["path:line"],
"files_changed": ["path"],
"test_command": "string",
"test_output_tail": "string (last 20 lines of test runner output)",
"commits": ["sha — subject"]
}
Variant B — needs input (spec-ambiguity OR missing-context only):
{
"status": "needs_input",
"task_number": 0,
"task_title": "string",
"blocking_step": "verbatim plan step quote",
"ambiguity_type": "spec-ambiguity | missing-context",
"question": "string ending with ?",
"tried": "what you attempted from the brief alone",
"options": [
{"label": "A", "summary": "string"},
{"label": "B", "summary": "string"}
],
"recommendation": "option label + reason, or 'none — no clear preference'",
"rolled_back": true
}
Every CONSTRAINT bullet is verbatim. Test-first discipline preserved. No compression in the constraint block.
## Anti-patterns (reject the brief if you see these)
- "Please / thanks / could you" in ROLE or TASK — delete.
- CONSTRAINTS written as prose paragraphs — break into bullets.
- CONTEXT containing information the agent can derive ("this is a TypeScript project") — delete.
- OUTPUT specified as "a summary" or "let me know what you find" — replace with schema.
- Multiple tasks in one brief — split into multiple briefs, dispatch in parallel.
- Hidden state: "remember what we discussed earlier" — if the agent needs it, put it in CONTEXT.
- Compressing or paraphrasing the NEEDS_INPUT CONSTRAINTS block. The four bullets are guardrail-critical and the contract that makes the halt path honest. Verbatim or the brief is invalid.
## Algorithm
1. **Extract intent.** From the caller's verbose request, pull the single imperative.
2. **Assign role.** Narrow identity matching the task. Read-only vs mutate matters.
3. **List constraints.** What must be true during execution? What must not happen? Include test-first and verification gates if code changes.
4. **Gather context.** Only what the agent cannot see on its own. Prefer `path:line` references over pasted code.
5. **Specify output.** Pick JSON schema if downstream parses; structured markdown with fixed headings if human-read.
6. **Compress.** Trim ROLE + TASK to the minimum. Verify constraints, context refs, and output schema are byte-identical to your intent.
7. **Validate.** Run the checklist below. If any box fails, fix before dispatch.
## Pre-dispatch checklist
- [ ] ROLE is specific (names the thing, not "assistant").
- [ ] TASK is a single imperative sentence.
- [ ] CONSTRAINTS are bullets, each independently verifiable.
- [ ] CONTEXT contains only non-derivable info, with file:line refs where possible.
- [ ] OUTPUT is machine-parseable or has fixed headings.
- [ ] No pleasantries, no hedging, no "let me know".
- [ ] Every guardrail-critical line (test-first step, destructive warning, test command) is verbatim.
- [ ] If dispatching N agents, briefs are independent (no shared mutable state).
If any fails, fix the brief. Do not dispatch a leaky brief to save time.
## Output of this skill
A single RTCO block, ready to be passed directly as the `prompt` argument to `Task` / `Agent` / pipeline dispatcher. Nothing else. No meta-commentary.