--- description: Arrange the .pm board — create/promote…
Community ralph loop for docs, sourced from github. Verified exit condition, evaluator-gated.
--- description: Arrange the .pm board — create/promote workstreams, milestones, tasks; mark done; show status argument-hint: "[status | new workstream <title> | add <wN> <idea> | promote <wN/NNN> | new milestone <wN> <title> | add-task <wN/mN> <title> | done <wN/mN/tNNN>]" allowed-tools: Read, Write, Edit, Bash(ls: ), Bash(find: ), Bash(cat: ) --- # Task: Arrange the .pm board /pm is the only command that writes to .pm/ . It arranges milestones and tasks under the conventions below. /pm-brainstorm proposes; /pm materializes. This file is the canonical definition of the board conventions — hierarchy, sizing rule, quality gate, standing closing tasks, templates. /pm-brainstorm reads it at runtime and must not restate or diverge from it. Parse the subcommand from $ARGUMENTS (default = status ). ## The .pm hierarchy | Level | Path | Meaning | Effort | | --- | --- | --- | --- | | Workstream | wN/ ( w1 , w2 , w3 , …) | a themed track / "worker" roadmap; README.md + inbox notes | — | | Inbox note | wN/NNN.md ( w1/005.md ) | one idea or a sub-hour unit of work, plain markdown | ≤ ~1h | | Milestone | wN/mN/ ( m1 , m2 , …) | a shippable chunk: REA
claude-code
More docs loops
Keep docs in sync with main
On every push to main, check whether changed code drifted from the docs in /docs and open a PR fixing anything out of date.
/schedule on every push to main, check whether the changed code drifted from the docs in /docs, and open a PR fixing anything out of date
docshigh risk
Ralph the docs backlog
Document one undocumented public module per fresh-context iteration, verifying every code sample compiles and accumulating style rules in guardrails so the docs read like one author wrote them.
/loop fresh context each iteration: read docs-backlog.json, docs/STYLE.md, and .ralph/guardrails.md; pick the top undocumented module, write its reference page with a runnable example, execute the example to prove it works, and mark the module done; add any style or structure decision to .ralph/guardrails.md; stop when the backlog is empty or after 20 turns
docsmedium risk
Close the gaps before you build
Fill documentation gaps until requirements, technical design, acceptance criteria, and test strategy describe one buildable system.
Prepare [project] for implementation. Ensure its documents cover requirements, technical design, tasks with acceptance criteria, and test strategy. Each round, fix the largest gap or contradiction that could make two competent engineers build different systems. Keep details traceable, record assumptions, and ask before product forks. Recheck consistency, then have two independent reviewers describe the components, data model, dependencies, and definition of done. Stop when they materially agree and every artifact is testable, or a decision needs the user.
docslow risk