菜单
Turn current context into a concise implementation spec. Use when a user wants to define what to build, capture requirements, or create a bounded technical/product spec before implementation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Implement a bounded code change from a request, spec, or implementation plan. Use when executing implementation work and choosing between quick, bounded, and tracked modes.
Manage tracked feature work with `.ai/current-work.md`, handoffs, and archive rules.
Turn a bounded functional spec into an implementation plan. Use when architecture, code structure, sequencing, migration, and verification must be decided before implementation.
Map a large or unclear initiative into facts, decisions, open frontier, and next work without writing a spec or implementation plan. Use when scope, architecture, dependencies, or sequencing are still genuinely uncertain before creating a spec.
Collapses deterministic multi-step repository research, aggregation, indexing, validation, and transformation into one small purpose-built local script and one Bash run. Use when a task would otherwise require 6+ related read/search/tool calls, iterates over many files or records, cross-references results, or requests batch analysis; do not use for small exploration or broad mutations.
Create a concise ADR for a durable, consequential architectural decision.
| name | to-spec |
| description | Turn current context into a concise implementation spec. Use when a user wants to define what to build, capture requirements, or create a bounded technical/product spec before implementation. |
Create a spec from the task context. Use the task-provided output path; if missing, follow project-memory artifact conventions. Ask only for critical missing scope, constraints, or acceptance criteria.
A good spec lets an executor with zero prior context know what to build, why, constraints, and done criteria. Be explicit, concrete, and self-contained. Prefer tables/lists/code blocks over filler. Define domain terms on first use. Include examples and edge cases only when behavior is non-obvious.
questionnaire when several decisions belong together.| Complexity | Spec weight |
|---|---|
| Small bug/config/single behavior | Problem, solution, acceptance criteria. Skip filler. |
| Medium feature/integration | Scope, decisions, acceptance criteria, key interfaces/examples. |
| Large but bounded system | Definitions, interfaces, edge cases, rationale, risks. |
Use .ai/<slug>-spec.md for tracked work when you control the path. If tracked work is active, follow project-memory: keep decisions, rationale, rejected alternatives, and open questions easy to lift into current-work.md.
Include only relevant sections:
---
title: [Concise title]
date_created: [YYYY-MM-DD]
status: Draft | Review | Approved | Deprecated
---
# [Spec title]
## Problem and goal
## Scope
## Constraints and decisions
## Interfaces and data contracts *(if relevant)*
## Examples and edge cases *(if relevant)*
## Testing decisions
## Acceptance criteria
## Out of scope
## Risks and assumptions
## Alternatives considered *(if relevant)*
## Definitions *(if relevant)*
## Open questions *(if any)*
## References
to-plan — turn a bounded spec into an architecture- and code-focused implementation plan.project-memory — tracked-work lifecycle and archive rules.