How do I install the Plan Format skill?

Run npx skillmds@latest add jburlison/plan-format in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Plan Format safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Plan Format?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Plan Format free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Plan Format?

JBurlison (@jburlison) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Plan Format by jburlison — Agent Skill

Name: Plan Format
Author: JBurlison

File contents

Plan & Phase Document Formats

Overall Plan

Stored at .memory_bank/features/<feature-name>/plan.md.

Plan Template

# Implementation Plan: <Feature Name>

## Overview
Brief summary of the implementation approach.

## Phases

| Phase | Name | Description | Est. Complexity |
|-------|------|-------------|-----------------|
| 1 | <Phase Name> | Brief description | Low/Medium/High |
| 2 | <Phase Name> | Brief description | Low/Medium/High |
| ... | ... | ... | ... |

## Phase Order Rationale
Why phases are ordered this way. Dependencies between phases.

## Shared Considerations
- Patterns to follow across all phases
- Naming conventions specific to this feature
- Shared utilities or base classes needed

## Definition of Done
- [ ] All phases complete
- [ ] All tests passing
- [ ] All code reviews approved
- [ ] All phase reviews complete
- [ ] Final spec review approved

Individual Phase Document

Stored at .memory_bank/features/<feature-name>/phases/phase-N-<name>.md.

Phase Template

# Phase N: <Phase Name>

## Status
- **Status:** Not Started | In Progress | Implementation Complete | Testing | Review | Complete
- **Implementer Iterations:** 0
- **Review Iterations:** 0

## Objective
What this phase accomplishes.

## Prerequisites
- Dependencies on prior phases
- Required setup or configuration

## Tasks

### Task 1: <Task Name>
- [ ] Step 1.1: Description
- [ ] Step 1.2: Description
- [ ] Step 1.3: Description

### Task 2: <Task Name>
- [ ] Step 2.1: Description
- [ ] Step 2.2: Description

## Files to Create/Modify

| File | Action | Purpose |
|------|--------|---------|
| `path/to/file.cs` | Create | Description |
| `path/to/existing.cs` | Modify | Description |

## Acceptance Criteria (from Spec)
- [ ] AC reference: description
- [ ] AC reference: description

## Testing Notes
- Key scenarios to test in this phase
- Edge cases specific to this phase

## Implementation Log

| Date | Action | Details |
|------|--------|---------|

Guidelines

Phases should be independently testable — each phase produces working, testable code
Keep phases small — prefer more smaller phases over fewer large ones
Task steps should be atomic — one step = one clear action
Map acceptance criteria to phases — every AC must be covered by at least one phase
Update status fields as the phase progresses
Log implementation actions in the Implementation Log

---name: plan-formatdescription: Defines the implementation plan and individual phase document formats for C# feature development. Use when creating plans, breaking work into phases, or defining task checklists.---# Plan & Phase Document Formats## Overall PlanStored at `.memory_bank/features/<feature-name>/plan.md`.### Plan Template```markdown# Implementation Plan: <Feature Name>## OverviewBrief summary of the implementation approach.## Phases| Phase | Name | Description | Est. Complexity ||-------|------|-------------|-----------------|| 1 | <Phase Name> | Brief description | Low/Medium/High || 2 | <Phase Name> | Brief description | Low/Medium/High || ... | ... | ... | ... |## Phase Order RationaleWhy phases are ordered this way. Dependencies between phases.## Shared Considerations- Patterns to follow across all phases- Naming conventions specific to this feature- Shared utilities or base classes needed## Definition of Done- [ ] All phases complete- [ ] All tests passing- [ ] All code reviews approved- [ ] All phase reviews complete- [ ] Final spec review approved```## Individual Phase DocumentStored at `.memory_bank/features/<feature-name>/phases/phase-N-<name>.md`.### Phase Template```markdown# Phase N: <Phase Name>## Status- **Status:** Not Started | In Progress | Implementation Complete | Testing | Review | Complete- **Implementer Iterations:** 0- **Review Iterations:** 0## ObjectiveWhat this phase accomplishes.## Prerequisites- Dependencies on prior phases- Required setup or configuration## Tasks### Task 1: <Task Name>- [ ] Step 1.1: Description- [ ] Step 1.2: Description- [ ] Step 1.3: Description### Task 2: <Task Name>- [ ] Step 2.1: Description- [ ] Step 2.2: Description## Files to Create/Modify| File | Action | Purpose ||------|--------|---------|| `path/to/file.cs` | Create | Description || `path/to/existing.cs` | Modify | Description |## Acceptance Criteria (from Spec)- [ ] AC reference: description- [ ] AC reference: description## Testing Notes- Key scenarios to test in this phase- Edge cases specific to this phase## Implementation Log| Date | Action | Details ||------|--------|---------|```## Guidelines1. **Phases should be independently testable** — each phase produces working, testable code2. **Keep phases small** — prefer more smaller phases over fewer large ones3. **Task steps should be atomic** — one step = one clear action4. **Map acceptance criteria to phases** — every AC must be covered by at least one phase5. **Update status fields** as the phase progresses6. **Log implementation actions** in the Implementation Log

Frequently asked questions

Plan Format