القائمة
When the user wants to create an implementation plan. When the user says "let's implement this" or "create a plan". When a design has been approved and is ready to be broken into tasks.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | writing-plans |
| description | When the user wants to create an implementation plan. When the user says "let's implement this" or "create a plan". When a design has been approved and is ready to be broken into tasks. |
| tools | ["read","edit"] |
Without a concrete task breakdown, implementation plans are vague and unexecutable — developers waste time figuring out what to do instead of doing it. This skill breaks approved designs into bite-sized, independently testable tasks (2-5 minutes each) so any agent or developer can execute them without ambiguity.
Understand scope and architecture decisions before breaking anything down — incorrect task boundaries cause rework.
Each task must have exactly: goal, files, changes, tests, and dependencies.
Task 1: Add user login endpoint
Dependencies: None
Files: src/auth/login.py, tests/test_login.py
Changes:
- Add POST /login route with email+password validation
- Return JWT token on success, 401 on failure
Tests: pytest tests/test_login.py -v (expect 2 passing tests)
Estimated time: 5 min
Tasks that take > 10 minutes cannot be assigned to a single subagent cleanly — split them. ✅ 2-5 minutes per task ✅ Single responsibility ✅ Independently testable
# Verify the plan covers all design requirements
grep -c "^Task" PLAN.md # should match number of design subtasks
PLAN.md in project root with all tasks, ready for prg plan --from-design DESIGN.md.
❌ Vague task descriptions ❌ Tasks without test criteria ❌ Missing file paths ❌ Tasks that take > 10 minutes ❌ Unclear dependencies
When the user wants to add a new feature or capability. When the user says "I want to build" or "I'm thinking about". When requirements are unclear and need to be refined.
When the user says they are ready for review or wants to create a PR. When the user asks to check if code is ready for review. When the task or feature is complete and needs quality validation.
When the user approves a plan and wants to execute it. When the user says "execute the plan" or "let's go" or "start implementation". When a PLAN.md exists and is ready to be executed task-by-task.
When the user is implementing a new feature or fixing a bug. When the user wants to write tests first before writing code. When the user is refactoring and needs to verify behaviour is preserved.
Systematic code review workflow — evaluate changes for correctness, style, security, and test coverage before merging. When the user asks to review code or a pull request. When the user says "check code quality" or "look over this diff". When the user requests feedback on changes before merging.
Restart containers, prune images, tail logs.