plan-docslisted

# Structured, stateful plan files Convention for `plans/YYYY-MM-DD-topic.md` — one file per idea or design, a YAML frontmatter `status` field so its lifecycle is visible without opening it, and a firm rule that `plans/` stays a working set, not a permanent archive. Rationale, prior art, and worked examples: [`references/design-rationale.md`](references/design-rationale.md). Whether an existing tool should have been adopted instead — the markdown task trackers, git-bug, beads, and why cross-repo is the case none of them solves cheaply — is [`references/prior-art-task-trackers.md`](references/prior-art-task-trackers.md). ## What this skill reads, runs and writes - **Reads**: the session repo's `plans/`, both plans stores (`$PLANS_HOME`, default `~/plans`, and its sensitive sibling), its own config (`$PLAN_DOCS_CONFIG`, else `~/.config/plan-docs/config.toml`, else `%APPDATA%\plan-docs\` on Windows), the directory names under `projects_root` (to derive the private terms `scan` gates on — names only, never contents), git history of the session repo and the stores, and, on Claude Code, the transcript path named by `$CLAUDE_CODE_SESSION_ID` to anchor the cross-repo guard. - **Runs**: `git` — read commands everywhere; `git commit` only on the store, through `commit`. The history-purge sequence in "Never let a client's identity reach a repo you publish" is printed for you to run; the script never runs it. - **Writes**: its own config, through `install`, `config set`,