القائمة
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.