planning-and-task-breakdown

Name: planning-and-task-breakdown
Author: pimenov

20stars2forks

How to install planning-and-task-breakdown?

pimenov/codex-first-skills-pack/planning-and-task-breakdown

$npx -y skills add pimenov/codex-first-skills-pack --skill planning-and-task-breakdown

Installs into the current project.

Summary

Turns ambiguous, large, multi-step, or handoff-prone work into sequenced tasks with outcomes, dependencies, stop-lines, acceptance criteria, and the right durable layer. Use when planning a feature, bugfix campaign, refactor, migration, deploy prep, client/internal work packet, L

Files · 1

View on GitHub

SKILL.md

1	# Planning And Task Breakdown
2
3	## Overview
4
5	Use this skill to turn "we should do X" into work that can actually be executed. The output should make order, dependencies, readiness, and stop-lines obvious.
6
7	This skill plans execution. It does not replace product thinking, code review, or implementation.
8
9	## Relationship To Other Skills
10
11	- Use `context-engineering` first when source of truth, project state, or constraints are unclear.
12	- Use `incremental-implementation` after a plan is ready and work should be executed in slices.
13	- Use `test-driven-development` for behavior-sensitive implementation tasks.
14	- Use `debugging-and-error-recovery` when the work starts from a failing system or bug.
15	- Use `doubt-driven-review` for high-stakes plans before production/data/auth/security mutations.
16	- Use `code-review-and-quality` when a produced implementation or task packet needs review.
17	- Use `source-driven-development` when task design depends on current framework, API, SDK, CLI, or platform behavior.
18
19	## Do Not Use
20
21	- Tiny tasks where the next action is obvious and safe.
22	- Pure brainstorming before the user wants executable work.
23	- Full product discovery when the core problem, audience, or success criteria are unknown; start with mini-PRD/discovery.
24	- Emergency incident recovery where stabilization must happen first.
25	- Creating Linear/Notion artifacts for raw thoughts that do not need durable execution memory.
26
27	## Core Loop
28
29	```text
30	INTENT -> MODE -> BREAKDOWN -> SEQUENCE -> READINESS -> HANDOFF
31	```
32
33	### 1. INTENT: State The Outcome
34
35	Before tasking, write one sentence:
36
37	```text
38	Target outcome: <what should be true when this work is done>
39	```
40
41	Then capture:
42
43	- who benefits or operates the result;
44	- current state;
45	- target state;
46	- non-goals;
47	- known constraints;
48	- risks or approval gates;
49	- source artifacts: issue, doc, repo, bug report, transcript, live state, or user request.
50
51	If the outcome is not clear, ask or run discovery before creating tasks.
52
53	### 2. MODE: Choose The Planning Layer
54
55	Pick the smallest layer that keeps the work safe.
56
57	\| Situation \| Use \|
58	\|---\|---\|
59	\| Quick safe work, one person, clear next action \| Chat plan or checklist \|
60	\| Implementation spans multiple files/slices \| Work Packet plus task list \|
61	\| New product/user workflow or fuzzy feature \| Mini-PRD before Work Packet \|
62	\| Needs execution across chats or people \| Linear issue/document \|
63	\| Human/client-facing overview \| Notion \|
64	\| Technical decision that should live with code \| Repo docs / ADR \|
65	\| Local sandbox or reusable process \| Local `RUNBOOK.md` / `SESSION_NOTES.md` \|
66
67	Do not duplicate the same plan into every layer by default. Put it where it will be used.
68
69	### 3. BREAKDOWN: Create Executable Tasks
70
71	Each task should have:
72
73	- outcome, not just activity;
74	- scope and non-scope;
75	- owner or execution mode when relevant;
76	- dependencies;
77	- acceptance criteria;
78	- verification/checks;
79	- stop-lines;
80	- links/source artifacts;
81	- expected output artifact.
82
83	Use this shape:
84
85	```text
86	Task: <verb + outcome>
87	Why: <reason>
88	Scope: <included>
89	Not doing: <excluded>
90	Depends on: <dependency or none>
91	Acceptance: <observable done criteria>
92	Verification: <checks/smoke/review>
93	Stop-lines: <when to pause>
94	Output: <code/doc/issue/comment/runbook/etc.>
95	```
96
97	Avoid tasks like "implement backend" or "fix UI". They hide too much. Split by outcome.
98
99	### 4. SEQUENCE: Order By Risk And Dependencies
100
101	Prefer this ordering:
102
103	1. Clarify contracts and source of truth.
104	2. Prove the riskiest unknown.
105	3. Build the smallest vertical slice.
106	4. Add edge cases and hardening.
107	5. Verify, review, and document.
108	6. Deploy or hand off only after readiness gates.
109
110	Name blockers explicitly:
111
112	```text
113	Blocked until:
114	- <fact/access/approval/test/data needed>
115	```
116
117	If tasks can run in parallel, say why they are independent. Do not parallelize tasks that edit the same files or mutate the same external system.
118
119	### 5. READINESS: Mark What Is Ready For Codex
120
121	A task is ready when:
122
123	- source of truth is identified;
124	- scope is bounded;
125	- acceptance criteria are testable;
126	- needed access is available or not needed;
127	- stop-lines are clear;
128	- no unresolved product decision is hidden inside implementation.
129
130	Use statuses:
131
132	- `Needs clarification`: missing decision or source.
133	- `Ready for discovery`: read-only investigation can start.
134	- `Ready for Codex`: bounded execution can start.
135	- `Needs approval`: next step mutates production/data/auth/external systems or changes scope.
136	- `Ready for smoke`: implementation done, user/live verific

People who liked this also viewed

6 picks

Type

planning-and-task-breakdown

20stars2forks

View on GitHub

How to install planning-and-task-breakdown?

pimenov/codex-first-skills-pack/planning-and-task-breakdown

$npx -y skills add pimenov/codex-first-skills-pack --skill planning-and-task-breakdown

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Planning And Task Breakdown
2
3	## Overview
4
5	Use this skill to turn "we should do X" into work that can actually be executed. The output should make order, dependencies, readiness, and stop-lines obvious.
6
7	This skill plans execution. It does not replace product thinking, code review, or implementation.
8
9	## Relationship To Other Skills
10
11	- Use `context-engineering` first when source of truth, project state, or constraints are unclear.
12	- Use `incremental-implementation` after a plan is ready and work should be executed in slices.
13	- Use `test-driven-development` for behavior-sensitive implementation tasks.
14	- Use `debugging-and-error-recovery` when the work starts from a failing system or bug.
15	- Use `doubt-driven-review` for high-stakes plans before production/data/auth/security mutations.
16	- Use `code-review-and-quality` when a produced implementation or task packet needs review.
17	- Use `source-driven-development` when task design depends on current framework, API, SDK, CLI, or platform behavior.
18
19	## Do Not Use
20
21	- Tiny tasks where the next action is obvious and safe.
22	- Pure brainstorming before the user wants executable work.
23	- Full product discovery when the core problem, audience, or success criteria are unknown; start with mini-PRD/discovery.
24	- Emergency incident recovery where stabilization must happen first.
25	- Creating Linear/Notion artifacts for raw thoughts that do not need durable execution memory.
26
27	## Core Loop
28
29	```text
30	INTENT -> MODE -> BREAKDOWN -> SEQUENCE -> READINESS -> HANDOFF
31	```
32
33	### 1. INTENT: State The Outcome
34
35	Before tasking, write one sentence:
36
37	```text
38	Target outcome: <what should be true when this work is done>
39	```
40
41	Then capture:
42
43	- who benefits or operates the result;
44	- current state;
45	- target state;
46	- non-goals;
47	- known constraints;
48	- risks or approval gates;
49	- source artifacts: issue, doc, repo, bug report, transcript, live state, or user request.
50
51	If the outcome is not clear, ask or run discovery before creating tasks.
52
53	### 2. MODE: Choose The Planning Layer
54
55	Pick the smallest layer that keeps the work safe.
56
57	\| Situation \| Use \|
58	\|---\|---\|
59	\| Quick safe work, one person, clear next action \| Chat plan or checklist \|
60	\| Implementation spans multiple files/slices \| Work Packet plus task list \|
61	\| New product/user workflow or fuzzy feature \| Mini-PRD before Work Packet \|
62	\| Needs execution across chats or people \| Linear issue/document \|
63	\| Human/client-facing overview \| Notion \|
64	\| Technical decision that should live with code \| Repo docs / ADR \|
65	\| Local sandbox or reusable process \| Local `RUNBOOK.md` / `SESSION_NOTES.md` \|
66
67	Do not duplicate the same plan into every layer by default. Put it where it will be used.
68
69	### 3. BREAKDOWN: Create Executable Tasks
70
71	Each task should have:
72
73	- outcome, not just activity;
74	- scope and non-scope;
75	- owner or execution mode when relevant;
76	- dependencies;
77	- acceptance criteria;
78	- verification/checks;
79	- stop-lines;
80	- links/source artifacts;
81	- expected output artifact.
82
83	Use this shape:
84
85	```text
86	Task: <verb + outcome>
87	Why: <reason>
88	Scope: <included>
89	Not doing: <excluded>
90	Depends on: <dependency or none>
91	Acceptance: <observable done criteria>
92	Verification: <checks/smoke/review>
93	Stop-lines: <when to pause>
94	Output: <code/doc/issue/comment/runbook/etc.>
95	```
96
97	Avoid tasks like "implement backend" or "fix UI". They hide too much. Split by outcome.
98
99	### 4. SEQUENCE: Order By Risk And Dependencies
100
101	Prefer this ordering:
102
103	1. Clarify contracts and source of truth.
104	2. Prove the riskiest unknown.
105	3. Build the smallest vertical slice.
106	4. Add edge cases and hardening.
107	5. Verify, review, and document.
108	6. Deploy or hand off only after readiness gates.
109
110	Name blockers explicitly:
111
112	```text
113	Blocked until:
114	- <fact/access/approval/test/data needed>
115	```
116
117	If tasks can run in parallel, say why they are independent. Do not parallelize tasks that edit the same files or mutate the same external system.
118
119	### 5. READINESS: Mark What Is Ready For Codex
120
121	A task is ready when:
122
123	- source of truth is identified;
124	- scope is bounded;
125	- acceptance criteria are testable;
126	- needed access is available or not needed;
127	- stop-lines are clear;
128	- no unresolved product decision is hidden inside implementation.
129
130	Use statuses:
131
132	- `Needs clarification`: missing decision or source.
133	- `Ready for discovery`: read-only investigation can start.
134	- `Ready for Codex`: bounded execution can start.
135	- `Needs approval`: next step mutates production/data/auth/external systems or changes scope.
136	- `Ready for smoke`: implementation done, user/live verific

People who liked this also viewed

6 picks

Type