Sp planning
Use when the user asks for a concrete implementation plan for an agreed change before code is written.From its SKILL.md
npx -y skills add tta-lab/ttal-cli --skill sp-planningAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 23 stars23 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.6 KB, as published. Nobody here has run it
Implementation Planning
Write a plan that a skilled developer can execute without rediscovering the design. FlickNote is the single source of truth.
1. Explore Reality
Before planning:
- Read the relevant code, tests, docs, and repository rules.
- Search prior work with
flicknote find <keywords>. - Map existing constraints, interfaces, dependencies, and failure modes.
- Confirm the target repository.
Do not design from filenames or assumptions.
2. Confirm the Approach
Before writing the detailed plan, tell the user:
- What exists now
- The proposed approach and why
- The main trade-off or risk
Stop for explicit alignment if the direction has not already been approved.
3. Define the Plan
Include:
- Goal and anti-goals
- Exit criteria expressed as observable behavior
- Exact scope and files
- Ordered implementation stages
- Test strategy and exact verification commands
- Risks, dependencies, and rollout concerns
For behavior changes and bug fixes, plan a TDD sequence:
- Add a focused test.
- Run it and confirm the expected failure.
- Implement the minimum change.
- Run focused and broader tests.
- Refactor only while green.
Mechanical deletions, generated files, and configuration-only work do not need invented tests; state the appropriate verification instead.
4. Keep Scope Executable
Split the plan into separate deliverable phases when:
- Multiple repos can ship independently
- A stage has a separate rollback boundary
- The plan is too large to review or verify as one change
Record dependencies between phases in the plan. Do not create tasks automatically.
5. Persist to FlickNote
Create or update one note in the orientation project:
flicknote add --project orientation flicknote detail <id> --tree flicknote modify <id>
Use this structure:
Plan: <title>
Goal
Anti-goals
Current state
Approach
Implementation stages
Test strategy
Exit criteria
Risks and dependencies
Each stage must name the files, behavior change, tests, verification, and commit boundary when useful.
Worker-Eye Check
Re-read the saved note as the implementer:
- Are paths and commands accurate?
- Is each stage self-contained and ordered?
- Are hidden assumptions written down?
- Would execution require another design decision?
- Is the scope small enough to deliver safely?
Update the FlickNote note until the answers are clear. Return its ID and a concise summary. Stop; do not start implementation or invoke another skill.