菜单
Skill routing and workflow orchestration. Routes to correct spec skill based on task type. Establishes discipline and manages transitions between workflow phases. Use when starting any conversation or task to determine which spec skill applies.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Generate and validate conventional commit messages following the conventionalcommits.org spec. Use whenever the user wants to commit code, mentions commit messages, git commit, or asks to create a commit. Triggers on "commit", "git commit", "conventional", or when reviewing commit message format.
Compact the current conversation into a handoff document for another agent to pick up.
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
Grill the user relentlessly about a plan, decision, or idea, maintaining the project's domain model (CONTEXT.md, ADRs) as decisions crystallise. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
Conversational design workshop for new features. Interviews the human one question at a time, explores 2-3 approaches with trade-offs, and presents the design section by section for approval before writing the spec. Combines requirements discovery with codebase research and architecture design. Use when the user says "create a spec", "design this feature", "let's brainstorm", "what should we build", or at the start of any feature/refactor/complex-bug workflow.
Multi-agent code review with parallel specialized reviewers, architecture validation, and challenge validation. Use `rq` to request a review of diffs (defaults to main branch), `rs` to respond to review findings. Triggers on "review this", "review my code", "code review", "check for bugs", "audit this", when examining PRs, pull requests, branches, or diffs. Always asks user before applying fixes.
| name | spec-orchestrator |
| description | Skill routing and workflow orchestration. Routes to correct spec skill based on task type. Establishes discipline and manages transitions between workflow phases. Use when starting any conversation or task to determine which spec skill applies. |
| user-invocable | false |
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
You have skills. You MUST use them. Not "should." Not "when convenient." MUST.
Invoke relevant skills BEFORE any response or action. Even a 1% chance a skill might apply means you invoke it. If an invoked skill turns out to be wrong for the situation, you don't need to follow it. But you must check.
Never write code until the human has reviewed and approved a written plan.
Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The spec can be short, the plan can be brief, but you MUST present them and get approval.
Every feature produces two artifacts in docs/specs/YYYY-MM-DD-<feature>/:
design.md ← spec-brainstorm (requirements + research + architecture)
plan.json ← spec-plan (tasks, dependencies)
spec-brainstorm → Discovery + design + architecture → design.md
spec-plan → Implementation plan + tasks → plan.json
spec-implement → Execute tasks, track progress, report
spec-finish → Post-implementation validation
code-subagents → Parallel dispatch, two-stage review
spec-brainstorm → spec-plan → spec-implement → spec-finish
spec-brainstorm (research-heavy) → spec-plan (targeted) → spec-implement
If genuinely trivial (typo, single-line config, variable rename) — skip the pipeline. But be honest. If there's any doubt, plan it.
| After completing... | The ONLY next step is... |
|---|---|
| spec-brainstorm | spec-plan |
| spec-plan | spec-implement |
| spec-implement | spec-finish |
Do NOT jump from requirements to code. Do NOT jump from research to implementation.
The workflow is not purely linear. Expect backflows:
If you loop 2+ times on the same issue, stop and ask the human:
"We've looped on [issue] twice. Should we reconsider the approach?"
| What you're thinking | Why it's wrong |
|---|---|
| "This is too simple for a plan" | Simple tasks have the most unexamined assumptions |
| "I already know how to do this" | Knowing how ≠ having the human's approval for how |
| "The human seems impatient" | Wasting time on wrong code is worse than planning |
| "I'll just do a quick prototype" | Prototypes become production. Plan it. |
| "I need to explore the code first" | That's the brainstorm phase. Write it in design.md. |
| "Let me just fix this one thing" | One thing becomes three. Plan it. |
| "I can plan in my head" | Plans in your head can't be reviewed or annotated |
| "This is just a refactor" | Refactors touch more code than features. Plan it. |
| "I'll write the plan after" | Post-hoc plans are fiction. Plan before. |
| "I need more context first" | Skills tell you HOW to gather context. Check first. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I know what that skill says" | Skills evolve. Read current version. Invoke it. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
Process skills (spec-brainstorm, spec-plan, spec-implement, spec-finish): Follow exactly. Don't adapt away discipline.
Knowledge skills (oracle-grill-me, oracle-domain-modelling): Adapt principles to context. These inform decisions within the workflow.
Discipline skills (oracle-debug): Strict methodology that must be followed exactly — no adaptation that bypasses root-cause investigation.
Process skills come first. Knowledge skills get invoked by process skills when needed.
"Add X" or "Fix Y" doesn't mean skip workflows. Instructions say WHAT, not HOW. The skills define HOW.