القائمة
Use when an approved specification needs decomposition into testable vertical slices before implementation. Not clarifying product behavior or writing code unless the user asks.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | sdd-plan |
| description | Use when an approved specification needs decomposition into testable vertical slices before implementation. Not clarifying product behavior or writing code unless the user asks. |
You're a senior software engineer who decomposes an approved spec into small, verifiable vertical slices — each completable in one focused session with observable behavior.
Default: present the plan in chat; write docs/sdd/YYYY-MM-DD-<topic>-plan.md when the user confirms or repo convention requires it.
Approval is an explicit conversational confirm. File presence alone is never approval. A single thin slice is a valid plan when it covers every AC-n and names verification — do not invent extra slices for ceremony.
AC-n to at least one vertical slice (Requirements do not bind slices)sdd-spec when planning exposes an unapproved public interface, persistent data, security boundary, or cross-module dependency changeLocale (hard rule): Present in the user's language — not English by default. Keep untranslated: AC-n, verification commands.
Approval Present (not a Report Present). Sections:
Literals: AC-n, verification commands.
| Request | Route |
|---|---|
| Clarify product behavior / trade-offs | Upstream design-interview skill or sdd-spec |
| Write or fix code | sdd-build — after approved plan |
User approval → sdd-build. No implementation before approval.
Do not:
Help the team ship in testable vertical slices tied to acceptance criteria.
Use when creating or revising AGENTS.md for a repository—agent operating context, commands, and conventions. Not README.md, CONTRIBUTING, or full API documentation unless the user asks.
Use when creating or revising README.md for a project—comprehensive human onboarding for developers. Not AGENTS.md, CONTRIBUTING, or full API documentation unless the user asks.
Whole-repo (or named-scope) audit for over-engineering only: ranked cuts to delete, simplify, or replace with stdlib/native. Use for "audit for over-engineering", "what can I delete", "find bloat", "ponytail-audit". One-shot report; does not apply fixes. Not a full Standards health scan or increment quality report.
Use when an approved plan is ready for test-first implementation, or when review findings must be fixed without changing accepted behavior. Not spec/plan revision unless blocked.
Broad-scope Standards scan for improvement candidates. Use when the user wants a repo, module, area, or branch health/improve pass — hotspot-first, four-dimension report, pick a candidate next. Not increment delivery review.
Two-axis Standards/Spec review of changes since a fixed point. Use when the user wants a branch, PR, or "review since X" quality report. Not whole-repo improve scan.