plan-work-items

Name: plan-work-items
Author: testdouble

122stars12forks

How to install plan-work-items?

testdouble/han/plan-work-items

$npx -y skills add testdouble/han --skill plan-work-items

Installs into the current project.

Summary

Break a trusted implementation plan (or other provided context) into independently-grabbable, atomic work items, written to a single work-items.md file. Use when the user wants to convert a plan into work items, create implementation tickets or tasks, divide a plan into work unit

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
5	- feature-implementation-plan.md: !`find . -maxdepth 5 -name "feature-implementation-plan.md" -type f`
6
7	# Plan Work Items
8
9	Break an implementation plan into vertical slices (tracer bullets) and write them as work items to a single `work-items.md` file.
10
11	This skill mostly coordinates: locating the plan or context, resolving where the file goes, printing the breakdown, writing the work-items file. It runs autonomously end to end. Step 5 is where the judgement comes into play, in dividing up the plan.
12
13	## Operating Principles
14
15	- Run autonomously. After the initial request, run end to end without pausing for human confirmation. When a decision has a reasonable default (where the file goes, how the plan divides), make it, state it, and proceed. Print the work item breakdown for visibility, but never gate on approval to continue. Stop for the user only when the skill genuinely cannot continue without input — there is no plan or context to work from at all.
16	- One file, no repository awareness. This skill produces exactly one `work-items.md`. It does not split work by repository, count repositories, or reason about cross-repository integration. The breakdown is driven only by the plan or context it is given.
17	- Save incrementally — never lose work. Write the work-items file as soon as the title and intro are drafted, then append each work item as it is finalized. Do not buffer the whole document in conversation memory and write it at the end.
18
19	## Rules
20
21	- Do NOT modify, annotate, or comment on the source implementation plan or context. It is read-only input.
22	- Each work item is a vertical slice: a narrow but complete path through the relevant layers (schema, API, UI, tests) that is demoable or verifiable on its own. Not a layer, not a stub.
23	- Every work item body MUST link the reference artifacts an implementer needs: API/event contracts, design frames, schema docs, runbooks, ADRs, coding standards. A work item that consumes an HTTP endpoint or event payload MUST link the contract section that defines it.
24	- UI work items, when the plan folder has a `ui-designs/` subfolder, MUST reference the relevant design screenshots by a relative path from the work-items file to the screenshot. See [references/work-item-template.md](./references/work-item-template.md).
25	- `Depends on` lists other work items in this same file that must complete first, or `None`.
26	- NEVER include process artifacts in work item bodies or the preamble. Excluded categories: iteration histories, decision logs, review findings, team findings, facilitation summaries, gap analyses, and anything under an `artifacts/` subfolder of the plan that is not a contract or design reference. Restate plan-level decisions inline in the work item with `See plan: D-N` as the breadcrumb. Full include/exclude list in [references/reference-artifact-inventory.md](./references/reference-artifact-inventory.md).
27
28	## Process
29
30	### 1. Locate the implementation plan or context
31
32	The breakdown is built from an implementation plan when one exists, or from whatever context the user provided when one does not.
33
34	- If the user provided a file path, read it. If a feature name was given, look for `docs/features/<feature-name>/feature-implementation-plan.md` (or the equivalent under the project's documentation root).
35	- If nothing was provided, check for existing plans (the injected `feature-implementation-plan.md` results above help here). If there is exactly one, use it. If there are multiple, use the most recently updated one. If there are none, use whatever plan-like context the user supplied inline in the conversation.
36	- If the plan references other files (a feature specification, a contract file, an ADR), read those too. The plan content is the union of all these sources.
37	- If there is still no usable plan or context, ask the user — in one short message — for the implementation plan file path or the context to break down. Do not pro

People who liked this also viewed

6 picks

Type

plan-work-items

122stars12forks

View on GitHub

How to install plan-work-items?

testdouble/han/plan-work-items

$npx -y skills add testdouble/han --skill plan-work-items

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
5	- feature-implementation-plan.md: !`find . -maxdepth 5 -name "feature-implementation-plan.md" -type f`
6
7	# Plan Work Items
8
9	Break an implementation plan into vertical slices (tracer bullets) and write them as work items to a single `work-items.md` file.
10
11	This skill mostly coordinates: locating the plan or context, resolving where the file goes, printing the breakdown, writing the work-items file. It runs autonomously end to end. Step 5 is where the judgement comes into play, in dividing up the plan.
12
13	## Operating Principles
14
15	- Run autonomously. After the initial request, run end to end without pausing for human confirmation. When a decision has a reasonable default (where the file goes, how the plan divides), make it, state it, and proceed. Print the work item breakdown for visibility, but never gate on approval to continue. Stop for the user only when the skill genuinely cannot continue without input — there is no plan or context to work from at all.
16	- One file, no repository awareness. This skill produces exactly one `work-items.md`. It does not split work by repository, count repositories, or reason about cross-repository integration. The breakdown is driven only by the plan or context it is given.
17	- Save incrementally — never lose work. Write the work-items file as soon as the title and intro are drafted, then append each work item as it is finalized. Do not buffer the whole document in conversation memory and write it at the end.
18
19	## Rules
20
21	- Do NOT modify, annotate, or comment on the source implementation plan or context. It is read-only input.
22	- Each work item is a vertical slice: a narrow but complete path through the relevant layers (schema, API, UI, tests) that is demoable or verifiable on its own. Not a layer, not a stub.
23	- Every work item body MUST link the reference artifacts an implementer needs: API/event contracts, design frames, schema docs, runbooks, ADRs, coding standards. A work item that consumes an HTTP endpoint or event payload MUST link the contract section that defines it.
24	- UI work items, when the plan folder has a `ui-designs/` subfolder, MUST reference the relevant design screenshots by a relative path from the work-items file to the screenshot. See [references/work-item-template.md](./references/work-item-template.md).
25	- `Depends on` lists other work items in this same file that must complete first, or `None`.
26	- NEVER include process artifacts in work item bodies or the preamble. Excluded categories: iteration histories, decision logs, review findings, team findings, facilitation summaries, gap analyses, and anything under an `artifacts/` subfolder of the plan that is not a contract or design reference. Restate plan-level decisions inline in the work item with `See plan: D-N` as the breadcrumb. Full include/exclude list in [references/reference-artifact-inventory.md](./references/reference-artifact-inventory.md).
27
28	## Process
29
30	### 1. Locate the implementation plan or context
31
32	The breakdown is built from an implementation plan when one exists, or from whatever context the user provided when one does not.
33
34	- If the user provided a file path, read it. If a feature name was given, look for `docs/features/<feature-name>/feature-implementation-plan.md` (or the equivalent under the project's documentation root).
35	- If nothing was provided, check for existing plans (the injected `feature-implementation-plan.md` results above help here). If there is exactly one, use it. If there are multiple, use the most recently updated one. If there are none, use whatever plan-like context the user supplied inline in the conversation.
36	- If the plan references other files (a feature specification, a contract file, an ADR), read those too. The plan content is the union of all these sources.
37	- If there is still no usable plan or context, ask the user — in one short message — for the implementation plan file path or the context to break down. Do not pro

People who liked this also viewed

6 picks

Type