Menu

Individual skill

ia-planning

0upvotes

Software implementation planning with optional file-based persistence. Use when asked to plan, when unresolved architecture or scope decisions need a durable record, or when multi-phase implementation needs recovery state. For the full research-and-issue workflow, use the ia-plan command (/ia-plan in Claude Code).

plugins/whetstone/skills/ia-planning/SKILL.md

Read pinned source

Source commit 5261531d15aea5e1a5f0b5a61af7c240bc17cf72

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 7, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
36
Repository last updated
Nov 9, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Planning

Produce the smallest plan that reduces implementation risk and preserves state costly to reconstruct. User requirements and verified facts govern the plan; a reference implementation supplies evidence about behavior, not independent authority to change scope.

## Procedure

1. Define the concrete outcome, evidence, binary or quantitative success threshold, scope boundaries, and stop conditions. If the request already names an artifact and success signal, use them. Otherwise repair activity-only goals before planning.
2. Separate the objective from the proposed mechanism: would the goal remain valid if the implementation changed? Ensure a colleague can understand the objective alone and verify it without knowing component internals.
3. Choose a full durable plan for interdependent phases, recovery needs, or work crossing context limits; an inline list for clear work fitting one session; direct implementation for clear scope and acceptance criteria. File and tool-call counts are signals, not triggers. Inspect hidden decisions such as cache TTL, invalidation, and key shape before treating work as simple.
4. Inspect existing tests, canonical commands, related code, and any existing brainstorm specification. Extend repository patterns. Record significant architectural tradeoffs in its ADR convention when needed.
5. Define files, ownership, interface contracts, dependencies, concrete tasks, verification, and exit conditions. Organize phases around runnable capabilities with implementation and tests together. Put high-variance decisions before mechanical work; keep execution dependencies in phase order.
6. Verify the plan against the user's requirements. Keep phase status and next step consistent. Never weaken acceptance criteria to match incomplete code or add speculative checks and machinery.
7. Deliver the plan when planning alone was requested. Continue implementation when already authorized. Ask about execution mode only if it materially changes cost, risk, isolation, or review quality.