agentleFS
FaisalAlqarniFaisalAlqarni/sp-ecc/skills/writing-plans/SKILL.md

writing-plans

Skill9 starsChanged 9 months agoMITView on GitHub

Use when you have a spec or requirements for a multi-step task, before touching code

We split this skill into the rules it gives an agent

5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 172 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before writing any plan content, always output:

    line 31
  2. Distinctive:

    Wait for human confirmation before investing in plan detail.

    line 38
  3. Distinctive:

    Before presenting the plan, check:

    line 130
  4. Distinctive:

    After saving the plan, ask for approval:

    line 139
  5. Very specific:

    REQUIRED SUB-SKILL: Use sp-ecc:subagent-driven-development

    line 149

“Common” is measured: kept by at least 6 in 10 of the 172 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Writing Plans

Overview

Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.

Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.

Announce at start: "I'm using the writing-plans skill to create the implementation plan."

Context: This should be run in a dedicated worktree (created by brainstorming skill).

Save plans to: docs/plans/YYYY-MM-DD-<feature-name>.md

Bite-Sized Task Granularity

Each step is one action (2-5 minutes):

  • "Write the failing test" - step
  • "Run it to make sure it fails" - step
  • "Implement the minimal code to make the test pass" - step
  • "Run the tests and make sure they pass" - step
  • "Commit" - step

Requirements Restatement (Step 1 of Every Plan)

Before writing any plan content, always output:

Requirements as I understand them:

  • [Requirement 1 — in your own words]
  • [Requirement 2]
  • [Assumption 1]

Wait for human confirmation before investing in plan detail. Misunderstandings caught here save hours of wasted implementation.

Plan Document Header

Every plan MUST start with this header:

# [Feature Name] Implementation Plan

> **For Claude:** REQUIRED SUB-SKILL: Use sp-ecc:executing-plans to implement this plan task-by-task.

**Goal:** [One sentence describing what this builds]

**Architecture:** [2-3 sentences about approach]

**Tech Stack:** [Key technologies/libraries]

**Complexity:** High / Medium / Low

**Risks:**
- HIGH: [risk — mitigation]
- MEDIUM: [risk — mitigation]

**Testing:** Unit: [what], Integration: [what], E2E: [if applicable]

---

Task Structure

### Task N: [Component Name]

**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`

**Depends on:** Task N (if applicable, omit if none)

**Step 1: Write the failing test**

```python
def test_specific_behavior():
    result = function(input)
    assert result == expected

Step 2: Run test to verify it fails

Run: pytest tests/path/test.py::test_name -v Expected: FAIL with "function not defined"

Step 3: Write minimal implementation

def function(input):
    return expected

Step 4: Run test to verify it passes

Run: pytest tests/path/test.py::test_name -v Expected: PASS

Step 5: Commit

git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"

## Remember
- Exact file paths always
- Complete code in plan (not "add validation")
- Exact commands with expected output
- Reference relevant skills with @ syntax
- DRY, YAGNI, TDD, frequent commits

## Phasing Large Features

For features spanning 10+ tasks, phase into independently shippable slices:
- **MVP:** Smallest slice that provides value
- **Core:** Complete happy path
- **Hardening:** Edge cases, error handling
- **Polish:** Optimization, monitoring

Each phase should be mergeable on its own.

## Plan Quality Red Flags

Before presenting the plan, check:
- [ ] Every task has exact file paths
- [ ] Testing strategy is included
- [ ] Dependencies between tasks are noted
- [ ] Each phase can ship independently (for large features)
- [ ] No steps say "add validation" — complete code is provided

## Execution Handoff

After saving the plan, ask for approval:

End every plan document with:

---
**READY?** Proceed / Modify: [changes] / Different approach: [alternative]

**"Plan complete and saved to `docs/plans/<filename>.md`. Ready to execute?"**

**If approved:**
- **REQUIRED SUB-SKILL:** Use sp-ecc:subagent-driven-development
- Stay in this session
- Fresh subagent per task + multi-stage review (spec, quality, security, verification gate)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.