Planning

Persistence

This skill belongs to the plans skill group. A persistence implementation decides where and how plans are stored. Before creating or updating a plan, find the setting:

R="$(git rev-parse --show-toplevel 2>/dev/null)/.ai/config.properties"; { cat "$R" ~/.ai/config.properties | grep '^persistence\.plans[[:space:]]*=[[:space:]]*[^[:space:]]'; cat "$R" ~/.ai/config.properties | grep '^persistence[[:space:]]*=[[:space:]]*[^[:space:]]'; } 2>/dev/null | head -1 | tr -d ' \t\r'

• No output: use local-ai-folder-markdown, the default for this skill group
• persistence.plans={value} or persistence={value}: use {value}. If ./persistence/{value}.md does not exist, tell the user the plans skill group has no {value} implementation and use local-ai-folder-markdown

Read ./persistence/{implementation}.md and follow it whenever this skill creates a plan or reads, writes or updates a planning document.

Every plan is identified by:

• {yyyy-mm-dd}, the date of the plan creation
• {task-name}, an extremely succinct name for the task in kebab-case

Planning documents

Use persistent planning documents as your working memory. Context windows are volatile and limited; anything important gets persisted.

• For any plan, you must create the following documents in the plan:
• plan — Track work breakdown and progress
• questions — Track your questions and the user's responses and vice versa
• findings — Store research and discoveries
• For multi-phase plans, you must also create:
• progress — Session log and test results
• Before creating the planning documents, you must read the starting templates in ./templates/
• You must use the starting templates when creating or updating planning documents to guide their structure and content. Write the content in Markdown; the persistence implementation decides how it is stored

Workflow

If you decide or are expected to produce a plan, follow the steps outlined in this section in order.

Step 1: Research & discover

• Gather requirements from the user's request
• Derive {task-name} — an extremely succinct name for the task, use kebab-case e.g. refactor-mfa-flow
• Create the plan and its findings document following the template: templates/findings.md
• Explore the codebase to understand the scope of the change
• Document findings in the findings document as you go

Step 2: Determine plan size

Based on your research, explicitly determine whether this is a multi-phase plan. A plan is multi-phase if it meets ANY of the following:

• More than 5 files will likely be modified
• More than 5 tool uses are expected
• More than 150 lines of code will change

Document your determination and reasoning at the top of the findings document under a ## Plan Size heading.

Step 3: Create remainaing planning documents

Create the remaining planning documents from the templates based on the determination in step 2 (see Planning documents). Populate the plan document with the plan and the questions document with any unresolved questions. Keep the questions document scaffolded even if you have no questions yet, as they may come up later. For multi-phase plans, also create the progress document as a stub — it will be populated during execution.

Step 4: Respond

• Return a summarised version of the plan to the user
• You must highlight if there are unresolved questions or if the plan is ready for implementation
• Recommend to the user that they rename this conversation:
• If running in GitHub Copilot, recommend: "You can run /rename {task-name} to rename this conversation."
• If running in Claude Code or Pi, recommend: "You can run /name {task-name} to name this conversation."
• Otherwise, recommend: "Consider renaming this conversation to {task-name} if your tool supports it."

Critical rules

1. Keep docs up-to-date

• Every plan — single-phase or multi-phase — must conclude with all planning documents up-to-date
• For multi-phase plans, this applies at the end of every phase, not just the final one
• The plan must have explicit actions to this effect that specifically refer to this planning skill (in each phase, for multi-phase plans)
• When updating planning documents, do so in line with their templates

2. Reference relevant skills

• During planning, you must check the skills available to you that apply to the work in that phase (e.g. rust-bevy-standards, java-conventions, tdd)
• Each phase must have a task to read the relevant skills, followed by a list of those skills
• Any development work must follow test-driven development practices i.e. you have to use your tdd skill for any code you write and task descriptions featuring development work must make this clear
• Do not edit any file in a phase until you have read every skill listed for that phase

3. The 2-action rule

"After every 2 view/browser/search operations, IMMEDIATELY save key findings to the findings document."

This prevents visual/multimodal information from being lost.

4. Read before decide

Before major decisions, read the plan document. This keeps goals in your attention window.

5. Update after act

After completing any phase:

• Update ## Status in the plan document
• Mark phase status: In progress → Complete
• Log any errors encountered
• Note files created/modified

6. Log ALL errors

Every error goes in the plan document (the single home for errors across all planning documents). This builds knowledge and prevents repetition.

7. Never repeat failures

if action_failed:
    next_action != same_action

Track what you tried. Mutate the approach.

The 3-strike error protocol

ATTEMPT 1: Diagnose & Fix
  → Read error carefully
  → Identify root cause
  → Apply targeted fix

ATTEMPT 2: Alternative Approach
  → Same error? Try different method
  → Different tool? Different library?
  → NEVER repeat exact same failing action

ATTEMPT 3: Broader Rethink
  → Question assumptions
  → Search for solutions
  → Consider updating the plan

AFTER 3 FAILURES: Escalate to User
  → Explain what you tried
  → Share the specific error
  → Ask for guidance

Templates

• templates/plan.md — Work breakdown and progress template
• templates/findings.md — Research storage template
• templates/progress.md — Session logging template
• templates/questions.md — Questions and responses template