cmd-plan-store

Files (1)

• SKILL.md

SKILL.md (first lines)

# Store Plan <!-- omit in toc -->

Capture the current conversation into a structured, reviewable plan file.

- [Instructions](#instructions)
  - [1. Gather context](#1-gather-context)
  - [2. Generate the plan document](#2-generate-the-plan-document)
  - [3. Write and confirm](#3-write-and-confirm)
- [Output Path](#output-path)
- [Document Structure](#document-structure)
  - [Header Block](#header-block)
  - [tl;dr](#tldr)
  - [Context](#context)
  - [Decisions Made](#decisions-made)
  - [Plan Overview](#plan-overview)
  - [Action Items](#action-items)
  - [Phases / Sections](#phases--sections)
  - [Risks & Open Questions](#risks--open-questions)
  - [References](#references)
- [Formatting Rules](#formatting-rules)
  - [Status Circles](#status-circles)
  - [Tables](#tables)
  - [General](#general)
- [Example Output](#example-output)

## Instructions

### 1. Gather context

Scan the full conversation for:
- **Decisions** — what was agreed on and why
- **Action items** — concrete next steps with owners/priorities
- **Architecture or design choices** — trade-offs discussed
- **Risks and open questions** — unresolved items
- **Phases or ordering** — any sequencing that was discussed

If the user passed a description as an argument (e.g., `/cmd-plan-store auth refactor`), use it as `DESCRIPTION`. Otherwise, infer a 2-4 word slug from the conversation topic.

### 2. Generate the plan document

Build the document using the [Document Structure](#document-structure) below. Not every section is required — **omit sections that have no content** rather than leaving them empty. The goal is a document that someone (including future-you) can pick up cold and understand what was decided, what's next, and why.

Present the draft to the user before writing.

### 3. Write and confirm

**Step 3a — Write the file:**

```bash
mkdir -p plans/
```

Write to the path defined in [Output Path](#output-path).

**Step 3b — Confirm with the user:**

Present the file path and a brief summary to the user. Ask if they want to adjust anything before finalizing.

## Output Path

```
plans/{YYYY}_{MM}_{DD}_{description}.md
```

Examples:
- `plans/2026_04_02_auth_refactor.md`
- `plans/2026_04_02_frontend_split.md`
- `plans/2026_04_02_migration_engine_redesign.md`

## Document Structure

### Header Block

```markdown
# {Title} <!-- omit in toc -->

Date: YYYY-MM-DD
Source: conversation with Claude

- [Table of Contents entries...]
```

Always include a Table of Contents. Omit the top-level heading from the ToC using `<!-- omit in toc -->`.

### tl;dr

_Single italicized sentence (max 120 chars) summarizing the most important outcome or decision._

Place immediately after the ToC, before any sections.

### Context

Brief background on what prompted this plan. 2-4 bullets max. Include:
- What problem or goal kicked off the conversation
- Any constraints or deadlines mentioned
- Relevant prior work or plans referenced

### Decisions Made

A table summarizing key decisions from the conversation:

| S | Decision | Rationale |
|---|----------|-----------|
| 🟢 | What was decided | Why this choice was made |
| ... | ... | ... |

> 🟢 Approved · 🟡 Tentative · 🔴 Rejected · ⚪ Deferred

### Plan Overview

High-level summary table of phases or work items:

| S | Phase / Item | Component | Description | Priority |
|---|-------------|-----------|-------------|----------|
| 🟢 | Phase 1 | `module.py` | What this phase does | P0 |
| 🟡 | Phase 2 | `client/js/` | What this phase does | P1 |
| ⚪ | Future | TBD | Deferred work | P2 |

> 🟢 Ready to start · 🟡 Needs more detail · 🔴 Blocked · ⚪ Deferred

From Olshansk/agent-skills, MIT.

More from Olshansk/agent-skills