القائمة
Design a feature or behavior change through dialogue. Use when asked to plan, scope, design, or break down work before coding.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create and update AGENTS.md project rules. Use when authoring or amending the cross-tool conventions agents must follow.
Write forward-looking startup instructions for the next session, then reset context to save costs. Use when the context is getting long or before switching focus.
Run pre-release checks, pick the version bump, and cut the release. Use when ready to tag and release.
Create and maintain a specification that states what to build, not how. Use when writing a spec, editing requirements, or defining acceptance criteria.
Run all review dimensions against a diff or a path. Use when reviewing a feature branch before merge, reviewing someone else's PR, or auditing a file path.
Create or update project documentation. Use when creating architecture docs, runtime docs, reference docs, or design documents that explain what the system does.
| name | plan |
| description | Design a feature or behavior change through dialogue. Use when asked to plan, scope, design, or break down work before coding. |
Design a feature or behavior change through dialogue.
If an issue number is given, fetch it with gh issue view $ARGUMENTS and use it as the starting point.
Have a design conversation about this task. Read the relevant code, share what you find, say what you think, and let the user shape the direction. The plan emerges from the dialogue — do not build it in isolation.
If a question can be answered by reading the code, read the code instead of asking. When scope is genuinely ambiguous, resolve it before drafting: ask one question at a time, in dependency order, each with your recommended answer — and only ask what the code can't tell you.
Ground every recommendation in current code, docs, and project rules. For non-trivial context gathering, spawn a few fast-tier readers in parallel (cap ~5; one per load-bearing file), then bring what you found back to the user before drafting — the read-back is a conversation turn, not a silent research phase.
Anything larger needs further decomposition. Slice vertically (complete paths through the stack), not horizontally (all types, then all implementations, then all tests).
Aligned means the user has explicitly agreed to a concrete proposal — not merely heard it. If you haven't gotten a confirming response, you're not aligned yet.
Summarize what was agreed: Outcome | Decisions made | Change list | Validation | Open questions.
Split into phases if the work is large. Each phase independently valuable and verifiable. Reference concrete files.
For non-trivial plans, track agreed steps in a checklist as the conversation progresses. When planning is done, the checklist is ready — hand it to the user and stop. Execution starts only when the user says so (typically via build).
build for execution discipline per sliceDo not implement inside this skill flow unless the user explicitly switches to execution.