plan-work-items

Featured

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 units, or break the plan down into grabbable pieces. Do not use when there is no implementation plan yet or the plan is not yet trusted — use plan-implementation to produce the plan or iterative-plan-review to harden it first. Does not sequence work into demoable delivery phases — use plan-a-phased-build for that. Does not write code — use tdd to implement a work item.

Data & Documents 263 stars 23 forks Updated today MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
81
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

## Project Context - CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f` - project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f` - feature-implementation-plan.md: !`find . -maxdepth 5 -name "feature-implementation-plan.md" -type f` - personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"` - project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""` As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used. # Plan Work Items Break an implementation plan into vertical slices (tracer bullets) and write them as work items to a single `work-items.md` file. This skill mostly coordinates: reading the boundary this work descends from, locating the plan or context, resolving where the file goes, printing the breakdown, writing the work-items file. It runs autonomously apart from two named turns: the confirmation turn it takes when no boundary record exists, and the single stop for an input only the user can supply. Step 5 is where the judgement comes into play, in dividing up the plan...

Details

Author
testdouble
Repository
testdouble/han
Created
4 months ago
Last Updated
today
Language
Shell
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Featured

work-items-to-jira

Break a work-items.md file (produced by /plan-work-items) into independently-grabbable Jira tickets, one per slice, in a single Jira project. Use when you want to turn a work-items file into Jira tickets, publish work items as Jira issues, or create implementation tickets that can be worked on and tracked in Jira. Requires a configured Atlassian MCP server. Does not produce the work-items file itself — use plan-work-items to break a plan into work items first. Does not post to GitHub — use work-items-to-issues for GitHub issues.

263 Updated today
testdouble
Code & Development Featured

work-items-to-issues

Break a work-items.md file (produced by /plan-work-items) into independently-grabbable GitHub issues, one per slice, in each slice's target repo. Use when you want to turn a work-items file into GitHub issues, publish work items as issue tickets, or create implementation tickets that can be worked on and tracked on GitHub. Does not produce the work-items file itself — use plan-work-items to break a plan into work items first. Does not review code or post pull request comments — use post-code-review-to-pr for that.

263 Updated today
testdouble
Code & Development Featured

plan-implementation

Builds a feature implementation plan from an existing feature specification (or equivalent context) through a facilitated team conversation. Use when the user wants to plan how to implement, build, deliver, or ship a feature that has already been specified. Does not specify what the feature should do — use plan-a-feature first. Does not design the contract for an interface — use design-an-api. Does not refine or stress-test an already-written plan — use iterative-plan-review. Runs its resolution rounds to completion and holds its questions until after they finish; to review each round as it lands, use pairing.

263 Updated today
testdouble