- Home
- Skills
- Fiberplane
- Claude Code Plugins
- Fp Planning
fp-planning_skill
18
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill fiberplane/claude-code-plugins --skill fp-planning- SKILL.md15.6 KB
Overview
This skill provides plan creation and breakdown patterns for the FP CLI so you can turn goals into structured, trackable issue hierarchies. It guides creating top-level plan issues, decomposing into atomic tasks, and modeling dependencies so work is sequenced and visible. Use it to produce reproducible plans that integrate with FP commands like fp issue create, fp issue update, and fp tree.
How this skill works
The skill treats plans as regular FP issues with rich descriptions and child issues for tasks and sub-tasks. It prescribes a hierarchy (Plan → Task → Sub-task), explicit dependency modeling (serial, parallel, fan-in, fan-out), and CLI patterns to create, update, and visualize the plan. It also suggests iteration practices: verifying dependencies, splitting large tasks, and updating issues as the plan evolves.
When to use it
- When you need to create a structured plan or roadmap inside FP
- When decomposing a feature into implementable tasks
- When designing implementation steps and assigning dependencies
- When you want to model task order (serial/parallel/fan-in/fan-out)
- When preparing tests, docs, and delivery criteria alongside implementation work
Best practices
- Start top-down: define the high-level goal, then break into level 2 and level 3 tasks
- Make tasks atomic: 1–3 hour scope, clear definition of done, testable output
- Model dependencies explicitly using fp issue update --depends to avoid hidden blockers
- Write clear descriptions: what, why, how, files, and definition of done
- Include testing and documentation tasks as first-class children of the plan
Example use cases
- Create a Plan issue for "Add user authentication" and add child issues for data models, OAuth, sessions, UI, and tests
- Break a large feature into a foundation → implementation → integration sequence with explicit dependencies
- Reorder work by updating dependencies when discovery shows a different task order
- Split a monolithic task into sub-tasks and keep the parent as the umbrella issue
- Have an agent generate detailed child tasks from a human-created outline and then review with the team
FAQ
No. Avoid markdown checkboxes. Create subissues with --parent so FP can track status, assignees, and dependencies.
How deep should the issue hierarchy go?
Typically 2–3 levels (plan/epic → task/feature → sub-task). You can nest deeper, but keep items small and actionable to maintain clarity.