القائمة
Use when a spec or requirements exist and need to be broken into verifiable tasks with acceptance criteria. Explicit decomposition into tasks with clear definitions of done. Distinct from writing-plans which is output-focused.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute in a separate session with review checkpoints
| name | planning-and-task-breakdown |
| description | Use when a spec or requirements exist and need to be broken into verifiable tasks with acceptance criteria. Explicit decomposition into tasks with clear definitions of done. Distinct from writing-plans which is output-focused. |
Explicit task decomposition into verifiable units with acceptance criteria. This skill is distinct from writing-plans which is output-focused (produces a plan document). This skill focuses on decomposition process — turning a spec into a sequence of implementable, testable tasks.
Core principle: A task isn't done until it's verifiable. Every task needs a clear "done" criterion before it starts.
subagent-driven-development beginsDon't use when:
interview-me firstspec-driven-development firstRead the spec completely before breaking it down.
Rule: One task = one responsible party = one verification point
Each task must answer:
Sequential, parallel, or conditional.
interview-me — Used BEFORE this skill when requirements are unclearspec-driven-development — Used BEFORE this skill when no spec existssubagent-driven-development — Uses tasks from this skill for execution