Plan goal: sequence the methodology project’s evolution from “lean reference artifact published by a solo maintainer” to “self-improving methodology referenced as one of the named options in AI-coding discussions” — without scaling maintainer hours linearly with adoption.
Last updated: 2026-05-25 (Step 1 of self-development bootstrap)
Related:
A portable, file-based methodology for software projects where humans and AI agents collaborate as peers. Markdown + git. No SaaS. No vendor lock-in. CC BY 4.0. Designed to make AI-collaborated software development sustainable past week 3 — for solo devs, small mixed teams, indie hackers, and engineering leaders — without enterprise overhead.
The methodology gets better over time via a self-improving cycle: insights from running the methodology on its own development become methodology improvements; the improved methodology improves the next cycle. Quality compounds without scaling maintainer hours.
Full vision in brief/01_vision.md.
Four phases, each with binary exit criteria. Phases gate: until the prior phase’s exit criteria are met, the next phase’s work is opportunistic at best.
Goal: methodology is complete, self-development bootstrap is operational, abstract docs are stable.
Exit criteria (all must hold):
methodology/ (per the latest semi-annual self-evaluation pass).templates/ (CLAUDE.md, AGENTS.md, AGENT_KICKOFF.md, AUTONOMOUS_LOOP.md, PROJECT_STRUCTURE.md, ROLE_BRIEFS.md) and are verified against the methodology’s required shape. The version-stamp clause was dropped on 2026-08-25, not fulfilled — see the convention sweep. A version stamp inside a template is a copy that goes stale on the adopter’s disk, where nothing can refresh it; the stamp belongs in SKILL.md and CHEATSHEET.md, which are read from the repo and both already carry one. The criterion was asking for exactly the drift v1.32.0 spent its time removing. (External-adoption testing is tracked as a health indicator, not a phase-exit criterion — adopter behavior is uncontrollable.)Active pillars: P1 Doc completeness, P2 Doc clarity, P3 Doc currency, P4 Tool compatibility, P9 Self-improvement velocity (cycle bootstrap).
Indicator of phase health: if maintainer hours exceed ~40/quarter sustained in this phase, the foundation work is too heavy and should be scoped down rather than pushed through.
Goal: adopters find the methodology, first stories emerge, contributor pipeline starts.
Exit criteria (all must hold):
Active pillars: P5 Adopter discoverability, P6 Example richness, P7 Community feedback loop become primary. Phase 1 pillars (P1–P4, P9) continue as baseline.
Indicator of phase health: discoverability signals climb but no adoption stories appear → people are bookmarking, not using; investigate friction (see brief/05_success_metrics.md “Counter-signals”).
Goal: methodology is on the field map; companies adopt internally; the methodology has earned a seat at the table when AI-coding methodologies are compared.
Exit criteria (all must hold):
Active pillars: P8 Maintenance sustainability becomes primary (now testable because traction exists). All other pillars continue as baseline.
Indicator of phase health: maintainer time stops feeling sustainable → reduce scope or invite co-maintainer per STATUS.md.
Goal: cross-pollination to peer methodologies; cycle has shifted methodology significantly; project has moved to shared-infrastructure mode.
Exit criteria (open-ended; the project lives here indefinitely):
No explicit “Phase 5.” Phase 4 is the steady state. If the project shifts beyond it (e.g., becomes a foundation-backed project, is forked into a new direction by a larger team), that’s a separate strategic event, not a planned phase.
Which pillars are primary (under active development) vs baseline (maintained but not the focus) at each phase:
| Pillar | Phase 1 | Phase 2 | Phase 3 | Phase 4 |
|---|---|---|---|---|
| P1 Doc completeness | primary | baseline | baseline | baseline |
| P2 Doc clarity | primary | baseline | baseline | baseline |
| P3 Doc currency | primary | primary | baseline | baseline |
| P4 Tool compatibility | primary | baseline | baseline | baseline |
| P5 Adopter discoverability | dormant | primary | baseline | baseline |
| P6 Example richness | dormant | primary | baseline | baseline |
| P7 Community feedback loop | dormant | primary | primary | baseline |
| P8 Maintenance sustainability | dormant | dormant | primary | baseline |
| P9 Self-improvement velocity | primary | primary | primary | primary |
Reading the table: primary means epics are actively chartered against the pillar in that phase; baseline means the pillar is maintained (drift catches via self-evaluation) but no new epics aim at it; dormant means the pillar exists and is named but isn’t actionable until a later phase.
P9 (Self-improvement velocity) is primary in every phase because the self-development cycle is the cross-cutting mechanism that improves the methodology regardless of which pillar is being worked.
Note on P4 (Tool compatibility) being primary in Phase 1: the original capability-layer seed in brief/08_capability_layers.md had Tool compatibility at P6, downstream of discoverability and examples. The Step 0 cross-AI review resequenced it to P4 because tool compatibility is a prerequisite for adoption — adopters who land on the repo immediately ask “does this work with my tool?” before reading further. Compatibility belongs in the foundation work alongside the doc-quality pillars, not in the adoption push that follows.
This plan is the entry point. Supporting research and pillar definitions live in adjacent docs.
00_master_plan.md (this doc) — vision, phases, pillar roadmap, doc index.../brief/)The brief is the upstream input to this plan. Treat as supporting research:
brief/00_brief.md — TL;DRbrief/01_vision.md — vision detailbrief/02_audience.md — primary + secondary segmentsbrief/03_competitive_landscape.md — maintainer-private competitive analysis (gitignored from v1.17.1; lives on maintainer’s disk for reference)brief/04_market_gaps.md — maintainer-private market-gap analysis (gitignored from v1.17.1; same reason)brief/05_success_metrics.md — qualitative success indicators (early + sustained); one operational rule on maintainer time; counter-signalsbrief/06_distribution.md — channels and sustainabilitybrief/07_tech.md — tech surfacebrief/08_capability_layers.md — the nine layers that became pillars../pillars/)../pillars/P<N>_<slug>.md).methodology/00_README.md — methodology indexmethodology/01_strategy.md — strategy-doc skeleton this plan followsmethodology/02_pillars.md — pillar-doc skeleton the pillars followThis plan re-evaluates on two cadences:
Phase-transition re-evaluation. When a phase’s exit criteria are met, the next phase becomes active. Before that transition: re-read this plan and the brief; assess whether the next phase’s exit criteria still make sense given what’s been learned; revise if needed; commit the revised plan as a release.
Semi-annual self-evaluation. Tied to the methodology’s self-evaluation cadence. Even within a phase, every six months: re-read this plan and the pillar set; classify gaps as “practice is wrong” / “docs are wrong” / “both”; ship revisions.
Memory-driven re-evaluation. If the stdlib growth loop surfaces a cluster of memory entries about strategy or pillar shape, that’s a signal to re-evaluate ad-hoc rather than waiting for the semi-annual.
No more frequent than that. Plans change deliberately, not in panic.
Drafted 2026-05-25 as Step 1 of the self-development bootstrap. Cross-AI reviewed and maintainer-approved before ship in v1.8.0. Lives at self-development/strategy/00_master_plan.md in the public repo.
The next step is Step 2 (first epics) — chartering 3–5 epics against the Phase 1 primary pillars. Gated on this plan’s stability.