메뉴
Fast path for a small, well-understood feature or fix. Skips discuss/plan/verify ceremony but still writes one task file and still requires evidence before claiming completion.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Capture implementation decisions for a feature before planning begins — libraries, error handling, edge cases, scope boundary. First step of the full feature loop.
Run the task files produced by /feature-plan, one fresh-context executor subagent per task (or wave), one commit per completed task. Third step of the full feature loop.
Research (conditionally) and decompose an approved feature into per-task files. Second step of the full feature loop. Supports --thorough for a fuller research pass on unfamiliar or high-risk work.
Entry point for building a feature. Classifies scope and routes to the fast path or the full discuss/plan/execute/verify loop. Also reports status on an in-flight feature.
Single merged review pass (spec compliance + code quality + goal alignment) plus a hard evidence gate before the feature can be marked done. Fourth step of the full feature loop.
Initialize a new project from a rough idea. Deep interrogation, optional domain research, and a roadmap if needed — writes durable context to .context/ that every future session and skill reads from. One-time, whole-project setup — not for individual features within an already-initialized project.
| name | feature-quick |
| description | Fast path for a small, well-understood feature or fix. Skips discuss/plan/verify ceremony but still writes one task file and still requires evidence before claiming completion. |
| disable-model-invocation | true |
| allowed-tools | Bash, Agent, Read, Write |
<runtime_note>
Explicit-invocation only (/feature-quick). Never auto-triggers.
</runtime_note>
Handle a small task without the discuss → plan → execute → verify ceremony, while keeping two things the full loop has that are worth never skipping: a structured task record, and a hard evidence gate before claiming done.
Shared conventions — directory layout, file ownership, task statuses, in-flight definition, feature numbering, branch and commit policy — live in references/context-contract.md in the feature skill's directory (installed at ~/.claude/skills/feature/references/context-contract.md); follow it rather than re-deriving.
If you arrived here directly (not via /feature's classification) and the task actually looks multi-file, ambiguous, or research-dependent, say so and suggest /feature-discuss instead. Don't silently proceed with a fast-path task that isn't one.
Run orchestrator's Diagnose step mentally: at this size, it is almost always Single Session. If there's a clean, self-contained reason to spend a subagent (e.g., keeping exploratory output out of the main context), spawn exactly one — never more than one on the fast path.
If dispatching, use prompt-engineer's calibration-by-size logic in its normal (non-task-file) mode — there's no task file yet at this stage, so prompt-engineer reasons from the request directly, calibrated as Trivial or Medium per its own sizing guide.
Either the main session does it directly, or the dispatched subagent does, following whatever prompt-engineer produced.
mkdir -p .context/features/NNN-slug/tasks
Write a single file, .context/features/NNN-slug/tasks/001-<slug>.md, using the standard task template (see feature-plan's templates/task.md for the shape) — filled in after the fact rather than planned in advance. This keeps a consistent, greppable record even for fast-path work, without the up-front planning cost.
Before saying anything is done, fixed, or passing:
Words like "should work," "this looks right," or "probably passes" are a signal you skipped a step — go back and run the command.
Mark the task file's status as done, with the evidence noted. Suggest — don't run — /update-context if this change is significant enough to be worth a STATE.md refresh.