plan-tasks

Name: plan-tasks
Author: Codagent-AI

28stars1forks

How to install plan-tasks?

codagent-ai/agent-skills/plan-tasks

$npx -y skills add Codagent-AI/agent-skills --skill plan-tasks

Installs into the current project.

Summary

Creates a structured implementation task breakdown for a structured change, synthesizing proposal, design, and specs into self-contained per-task files. Use when the tasks artifact is the next step in a change.

Files · 1

View on GitHub

SKILL.md

1	# Plan Tasks
2
3	Create self-contained task files from a change's proposal, design, and specs. Assume each task goes to a skilled agent with no prior context. Include the decisions, paths, constraints, and verbatim scenarios that agent needs, but avoid line-by-line implementation instructions.
4
5	Announce: "I'm using the plan-tasks skill to create the task breakdown."
6
7	## 1. Read inputs and code
8
9	Read `proposal.md`, `design.md`, and every `specs/*/.md` in the provided change directory. Skip material already read in this session.
10
11	Research only enough code to identify:
12
13	- affected files, interfaces, and conventions;
14	- structural obstacles that could make implementation significantly harder;
15	- documentation that must change with the behavior.
16
17	## 2. Size the whole change
18
19	Estimate implementation effort before drafting task boundaries. Consider novelty, uncertainty, architectural reach, provider or platform breadth, migration and cutover risk, and verification burden. Discount mechanical propagation across files, adapters, UI surfaces, docs, and tests. Never infer size from requirement, scenario, layer, or candidate-task counts.
20
21	Use the estimate as a task-count budget:
22
23	\| LOE \| Task count \| Calibration \|
24	\| --- \| ---: \| --- \|
25	\| Small \| 1 \| Cohesive, patterned work with limited uncertainty, even across many files. \|
26	\| Medium \| 2 \| A substantial feature or refactor with a contract change, migration, or second implementation-sized risk cluster. \|
27	\| Large \| 3–4 \| A major subsystem change with high novelty, integration breadth, production transition, or extensive verification. Prefer 3. \|
28	\| XL \| 5+ \| Program-scale work spanning multiple major subsystems or capabilities. Start at 5; justify every additional task. \|
29
30	Choose the smallest fitting size. A difficult replacement of one subsystem is usually Large, not XL.
31
32	For Medium or larger changes, or ambiguous provider, migration, feasibility, cutover, or cleanup boundaries, read [references/task-sizing.md](references/task-sizing.md) before decomposing.
33
34	Only after sizing, decide whether serious structural obstacles warrant a behavior-preserving refactor task. Prefer inline refactoring. If a standalone refactor is necessary, count it inside the selected budget.
35
36	## 3. Form delivery units
37
38	One task is one meaningful outcome a generalist agent can implement, test, and review in a focused session. A task may be a broad vertical slice; it is not a TDD step, requirement, scenario, layer, UI surface, adapter, or file group.
39
40	Apply these rules:
41
42	1. Group every layer needed for one outcome: schema, config, logic, UI, tests, and docs.
43	2. Split only for an independently meaningful outcome, distinct implementation risk, real sequencing or release gate, or substantial independently verifiable foundation.
44	3. Fold scaffolding, migrations, dependencies, and refactors into the outcome that first exercises them unless independently risky and review-worthy.
45	4. Prefer seams with narrow, stable handoffs. If the next task would inherit broad unfinished plumbing, overlapping edits, or many implicit assumptions, merge the candidates. A boundary should reduce context transfer, not create a large handoff surface.
46	5. Merge candidates that would normally land in one PR, are not useful separately, or exist only to prepare for the next task.
47
48	Do not create standalone tasks for tests, ordinary documentation, setup surfaces, adapter flags, or other plumbing belonging to an outcome. Prompt-, config-, or skill-only changes are usually one task unless they deliver independently releasable capabilities.
49
50	### Cross-check the count
51
52	Compare the candidate count with the independent LOE budget:
53
54	- Above the band: merge the most coupled candidates.
55	- Below the minimum: re-check the estimate; never invent work to satisfy it.
56	- Within a range: use the lower count unless another boundary is concrete and implementation-significant.
57	- Multiple cohesive outcomes in one task: split and raise the LOE if needed.
58	- For every task after the first, explain internally why it cannot be folded into another. "Different requirement/layer/UI," "many files/adapters," "cleaner," or "easier to track" are not sufficient.
59
60	Proceed autonomously once the cross-check passes. Do not ask for approval or count selection. Stop only for a source-artifact contradiction that makes implementation unsafe to plan.
61
62	## 4. Write task files
63
64	Write every task under `tasks/` before ordering:
65
66	- One task: `<2-4-word-slug>.md`
67	- Multiple tasks: eventually `<NN>-<2-4-word-slug>.md`, where the numeric prefix determines runner order
68
69	Use real repository paths and resolve all placeholders.
70
71	### Single-task format
72
73	Reference the design and every spec by exact relative path instead of duplicating them. Omit `## Spec`.
74
75	```markdow

People who liked this also viewed

6 picks

Type

plan-tasks

28stars1forks

View on GitHub

How to install plan-tasks?

codagent-ai/agent-skills/plan-tasks

$npx -y skills add Codagent-AI/agent-skills --skill plan-tasks

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Plan Tasks
2
3	Create self-contained task files from a change's proposal, design, and specs. Assume each task goes to a skilled agent with no prior context. Include the decisions, paths, constraints, and verbatim scenarios that agent needs, but avoid line-by-line implementation instructions.
4
5	Announce: "I'm using the plan-tasks skill to create the task breakdown."
6
7	## 1. Read inputs and code
8
9	Read `proposal.md`, `design.md`, and every `specs/*/.md` in the provided change directory. Skip material already read in this session.
10
11	Research only enough code to identify:
12
13	- affected files, interfaces, and conventions;
14	- structural obstacles that could make implementation significantly harder;
15	- documentation that must change with the behavior.
16
17	## 2. Size the whole change
18
19	Estimate implementation effort before drafting task boundaries. Consider novelty, uncertainty, architectural reach, provider or platform breadth, migration and cutover risk, and verification burden. Discount mechanical propagation across files, adapters, UI surfaces, docs, and tests. Never infer size from requirement, scenario, layer, or candidate-task counts.
20
21	Use the estimate as a task-count budget:
22
23	\| LOE \| Task count \| Calibration \|
24	\| --- \| ---: \| --- \|
25	\| Small \| 1 \| Cohesive, patterned work with limited uncertainty, even across many files. \|
26	\| Medium \| 2 \| A substantial feature or refactor with a contract change, migration, or second implementation-sized risk cluster. \|
27	\| Large \| 3–4 \| A major subsystem change with high novelty, integration breadth, production transition, or extensive verification. Prefer 3. \|
28	\| XL \| 5+ \| Program-scale work spanning multiple major subsystems or capabilities. Start at 5; justify every additional task. \|
29
30	Choose the smallest fitting size. A difficult replacement of one subsystem is usually Large, not XL.
31
32	For Medium or larger changes, or ambiguous provider, migration, feasibility, cutover, or cleanup boundaries, read [references/task-sizing.md](references/task-sizing.md) before decomposing.
33
34	Only after sizing, decide whether serious structural obstacles warrant a behavior-preserving refactor task. Prefer inline refactoring. If a standalone refactor is necessary, count it inside the selected budget.
35
36	## 3. Form delivery units
37
38	One task is one meaningful outcome a generalist agent can implement, test, and review in a focused session. A task may be a broad vertical slice; it is not a TDD step, requirement, scenario, layer, UI surface, adapter, or file group.
39
40	Apply these rules:
41
42	1. Group every layer needed for one outcome: schema, config, logic, UI, tests, and docs.
43	2. Split only for an independently meaningful outcome, distinct implementation risk, real sequencing or release gate, or substantial independently verifiable foundation.
44	3. Fold scaffolding, migrations, dependencies, and refactors into the outcome that first exercises them unless independently risky and review-worthy.
45	4. Prefer seams with narrow, stable handoffs. If the next task would inherit broad unfinished plumbing, overlapping edits, or many implicit assumptions, merge the candidates. A boundary should reduce context transfer, not create a large handoff surface.
46	5. Merge candidates that would normally land in one PR, are not useful separately, or exist only to prepare for the next task.
47
48	Do not create standalone tasks for tests, ordinary documentation, setup surfaces, adapter flags, or other plumbing belonging to an outcome. Prompt-, config-, or skill-only changes are usually one task unless they deliver independently releasable capabilities.
49
50	### Cross-check the count
51
52	Compare the candidate count with the independent LOE budget:
53
54	- Above the band: merge the most coupled candidates.
55	- Below the minimum: re-check the estimate; never invent work to satisfy it.
56	- Within a range: use the lower count unless another boundary is concrete and implementation-significant.
57	- Multiple cohesive outcomes in one task: split and raise the LOE if needed.
58	- For every task after the first, explain internally why it cannot be folded into another. "Different requirement/layer/UI," "many files/adapters," "cleaner," or "easier to track" are not sufficient.
59
60	Proceed autonomously once the cross-check passes. Do not ask for approval or count selection. Stop only for a source-artifact contradiction that makes implementation unsafe to plan.
61
62	## 4. Write task files
63
64	Write every task under `tasks/` before ordering:
65
66	- One task: `<2-4-word-slug>.md`
67	- Multiple tasks: eventually `<NN>-<2-4-word-slug>.md`, where the numeric prefix determines runner order
68
69	Use real repository paths and resolve all placeholders.
70
71	### Single-task format
72
73	Reference the design and every spec by exact relative path instead of duplicating them. Omit `## Spec`.
74
75	```markdow

People who liked this also viewed

6 picks

Type