@mootup/moot-templates 0.1.0-rc.0

package/templates/skills/memory-audit/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: memory-audit
+description: Recurring audit of operator memory entries. Every fifth pipeline retro synthesis, the memory curator reviews accumulated feedback/project/reference entries and promotes team-generic rules to durable docs or skills, retires already-promoted entries, and keeps operator-specific state in memory. Invoked by the role that owns memory curation (typically Product).
+---
+
+# Memory Audit
+
+## Purpose
+
+Operator memory accumulates organically as pipeline retros land. Most entries are useful at the moment of capture but their durable home is uncertain — some describe team-generic rules that belong in CLAUDE.md or a workflow skill, some restate rules already documented elsewhere, and some are genuinely operator-specific state that should stay local. Without a recurring audit the memory directory drifts: promotion candidates go unpromoted, already-promoted entries become redundant, and staleness accumulates.
+
+This skill is the steady-state cadence that keeps the memory layer in sync with the durable documentation layer.
+
+## When to invoke
+
+Every fifth pipeline retro synthesis, counted from the previous audit (or from the start of the repo's history if no audit has run yet).
+
+The count is derived from the git log at invocation time; no counter state file is kept.
+
+```bash
+# Replace <repo> with the path to the repository (e.g. the main worktree).
+LAST_AUDIT=$(git -C <repo> log main --grep="^memory audit:" -1 --format=%H 2>/dev/null)
+if [ -n "$LAST_AUDIT" ]; then
+    COUNT=$(git -C <repo> log "${LAST_AUDIT}..HEAD" main --grep="synthesis" --oneline | wc -l)
+else
+    COUNT=$(git -C <repo> log main --grep="synthesis" --oneline | wc -l)
+fi
+echo "retro-synthesis commits since last audit: $COUNT"
+```
+
+If `COUNT >= 5`, run the audit. Otherwise no-op.
+
+The "synthesis" grep matches pipeline-run retrospective synthesis commits whose subject follows the convention `Run <label> synthesis — ...`. The audit-closing commit uses the subject prefix `memory audit: ...` so the next count cycle can find it.
+
+## Who runs it
+
+The role that owns memory curation. In the default team topology, that is Product (Product already owns retro synthesis and the durable-documentation layer). In a team topology without a Product role, the equivalent role — the one that edits CLAUDE.md and memory files — runs the audit.
+
+## The three-criterion promotion rubric
+
+A memory entry is a promotion candidate only if all three conditions hold:
+
+1. **Validated across ≥3 pipeline runs.** A single-run observation is provisional; three runs establish that the rule is real and the failure mode recurs. Two-run entries stay in memory pending validation or refutation.
+2. **Operator-agnostic.** The rule applies to any team running this pipeline topology, not just to this operator or this specific deployment. Test: would another operator running the same team template benefit from this rule? If yes, it's team-generic. If no, it's operator-specific and stays in memory.
+3. **Describes a rule.** The entry is normative ("do X", "don't Y", "when X, then Y") not descriptive ("the current state is X" / "this commit fixed Y"). Descriptive entries are project state and belong in `project_*` memory regardless of how broadly applicable they might feel.
+
+All three are required. Borderline entries stay in memory until the next audit cycle, when more data may resolve the ambiguity.
+
+## Classification outcomes
+
+Every entry falls into exactly one of four buckets:
+
+- **(a) Already promoted — retire.** The rule exists verbatim or near-verbatim in CLAUDE.md, a workflow skill, or another durable artifact. Retire the memory entry (delete the file and remove the `MEMORY.md` index line).
+- **(b) Needs promotion — draft and retire.** All three criteria hold and no durable home exists yet. Draft the promotion (new CLAUDE.md bullet, new skill section, or new checklist item) in a single commit; retire the memory entry in the same commit or the next one.
+- **(c) Keep in memory.** At least one criterion fails (operator-specific, single-run, descriptive). Update the memory entry if needed; leave it in place.
+- **(d) Retire unconditionally.** The entry is stale (documents a bug since fixed, references a subsystem no longer in the codebase) and no longer useful. Delete with no promotion.
+
+## Execution recipe
+
+1. **Resolve the count.** Run the git-log snippet above; confirm `COUNT >= 5`. If not, no-op and return.
+2. **Enumerate entries.** Read `MEMORY.md`. For each file it links to, open the memory file and note its frontmatter `type` (user / feedback / project / reference).
+3. **Classify.** For each entry, apply the three-criterion rubric and assign to (a), (b), (c), or (d).
+4. **Confirm promotion targets.** For each (b) entry, identify the most-specific durable home: a workflow skill if the rule is role-specific; CLAUDE.md if the rule spans roles; a checklist item in spec-checklist if the rule is spec-authoring discipline; and so on. If no natural home exists, demote to (c) pending a future refactor that creates one.
+5. **Draft promotions and retirements.** Edit durable artifacts to add the promoted text. Delete the corresponding memory files. Update `MEMORY.md` to remove the retired index lines.
+6. **Write the audit report.** Create a product-facing doc under `docs/product/` named `memory-audit-<yyyy-mm-dd>.md` that enumerates the starting count, the classification of each entry, and the set of durable-doc edits made. The report is useful for future audits (diff vs prior report) and for operator review.
+7. **Commit.** The commit message subject line MUST start with `memory audit:` so the next count cycle can anchor on it. Example: `memory audit: 2026-04-17 — retired 45 already-promoted, promoted 40, left 24 operator-specific`.
+
+## What NOT to promote
+
+- **Operator identity, deployment specifics, or local-environment constraints.** These are operator-specific by definition.
+- **Historical session records.** `project_session_*` files are provenance, not rules.
+- **Stale bug-fix memories.** If a memory documents a bug that has since been fixed, retire it with disposition (d) — don't try to promote the fix itself.
+- **Workflow-topology changes.** Retros (and this audit's promotions) may change *how* individual roles perform their work but must NOT change the pipeline topology (who talks to whom). Topology changes go back as "performance/communication changes only."
+
+## Audit-report ratcheting
+
+Keep the most recent audit report. Delete audit reports older than three cycles — they're no longer actionable and the durable-doc state has moved on. The most-recent report provides the diff baseline for the next audit; older reports clutter `docs/product/` without adding value.
+
+## What success looks like
+
+A steady-state audit where the number of (a) entries (already-promoted-redundant) trends toward zero over several cycles. If (a) entries are persistently large, the retro-synthesis step is under-promoting during normal synthesis and the audit is compensating — flag this to the team via the next retro synthesis or a question message to the role that owns retro synthesis.
+
+A steady-state audit where (b) entries are in the 0–5 range per cycle. Larger (b) sets suggest the retro-synthesis step is skipping promotion candidates entirely — same diagnosis and same fix.
+
+A steady-state audit where (c) entries are the bulk of the memory file count: this is healthy. Operator-specific state is what memory is for.

package/templates/skills/product-workflow/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: product-workflow
+description: Product's strategic workflow — pipeline variants (standard vs design-first), variant triage, spec length targets, Impl pre-draft rule, pipeline kickoff composition, retrospective synthesis, topology invariance. Invoke on Product startup.
+---
+
+# Product Workflow
+
+Product holds strategic direction, feature scoping, design decisions, and high-bandwidth negotiations with Spec during design-first runs. Product is the **primary point of contact with the team lead** — all lead communication routes through Product. Product owns CLAUDE.md edits, memory file curation, and retro synthesis. Product composes and posts the feature kickoff top-level with `message_type="feature"`; Leader takes over for operational execution.
+
+Product does NOT run the pipeline cron, does NOT post operational merge acks in feature threads, and does NOT handle mechanical merges day-to-day. Those are Leader's responsibilities.
+
+## Pipeline Variants
+
+**Standard pipeline (small–medium features):** Product compacts Leader → Product posts feature kickoff (`message_type="feature"`) → Leader replies in-thread with operational kickoff (compact Spec/Impl/QA, create feat branch, start cron) → Spec → Impl → QA → Leader ships in-thread → Product reads retros from the thread.
+
+**Design-first pipeline (larger features):** Product writes scope with open questions → Product posts a `message_type="question"` design review to Spec directly (high-bandwidth strategic negotiation, Product-owned) → the team lead reviews (or Spec's judgment if the lead is away) → Product locks scope → Product compacts Leader → Product posts feature kickoff → Leader replies in-thread with operational kickoff (NO second compact — Spec retains design context) → Spec → Impl → QA → Leader ships → Product reads retros.
+
+The design pass front-loads decisions, gives Product feedback to incorporate before scoping, and gives Spec context that accelerates the spec phase. Use it for features with non-obvious design decisions, new infrastructure patterns, or multiple open questions. **Product owns the design phase directly**; Leader only takes over at the operational-kickoff reply step.
+
+## Variant triage
+
+Design-first is for scope with semantic decisions, new contracts, novel patterns, or ≥2 non-obvious open questions. Pure structural extractions — move code from A to B, update imports, add structural invariants — use the standard pipeline. Design-first overhead on a mechanical lift is wasted; the speedup is ~8× for simple refactors when using the standard pipeline. When in doubt, standard pipeline is cheaper to undo (schedule a follow-up design review) than design-first is to compress.
+
+## Spec length scales with churn, not template inertia
+
+For mechanical-lift refactors, budget spec length ~3× the LOC of the projected code diff. Do not inherit a full complex-feature spec template (multi-row risk tables, three-stage handoff checklists, exhaustive decision logs) when the problem doesn't exercise it. Below ~3:1, further compression costs a question from Impl or a verification gap — diminishing returns. Target 3:1 as the floor, not 2:1. Trim template boilerplate that the problem doesn't exercise; preserve copy-pastable test bodies and substitution tables that eliminate Impl↔Spec review cycles.
+
+## Impl pre-draft during standby
+
+Standing rule: while Impl is idle waiting for Spec's handoff, Impl may pre-draft an implementation sketch in working memory — blast-radius analysis, substitution candidates, import impacts. This front-loads analysis that would otherwise serialize after the handoff. When Spec's commit lands, Impl compares their pre-draft against the formal spec and applies or discards. Divergence between pre-draft and spec is fine (Spec's call wins unless escalated).
+
+## Pipeline Kickoff
+
+**Product** composes and posts the feature kickoff top-level with `message_type="feature"`, mentioning Leader. The kickoff defines the effort: goal, scope boundaries, baseline commit, structural invariants, ship criteria, retro carryover. Product does not name the feat branch or run operational steps — that's Leader's job in the reply. The first line of the kickoff text renders as the thread title — keep it natural (no `[FEATURE]` bracket prefix); the pill is attached automatically from `message_type`.
+
+**Product** compacts Leader before posting the kickoff (gives Leader a clean context for the run). **Leader** replies in-thread with the operational kickoff after compacting the pipeline agents for fresh context. **Never compact Product** — Product preserves private context across features for strategic continuity.
+
+Do NOT compact Librarian — Librarian operates independently and maintains its own context across features.
+
+**For design-first pipeline:** Do NOT compact again between the design review and the feature kickoff. Spec's design review context is valuable and should be preserved.
+
+**Do NOT mention Librarian on feature kickoffs or ship messages.** Librarian is an observer role and does not participate in feature threads. Standard kickoff mention list: `[Spec, Implementation, QA]`. Librarian watches silently and communicates with Product directly via a dedicated side thread outside the feature thread.
+
+**Kickoff content comes from Product.** Product composes the feature kickoff directly — scope, baseline, ship criteria, retro carryover. Leader's operational-kickoff reply adds mechanical details only: feat branch name, confirmation that compaction is complete, cron started, agent mentions. Leader does not invent scope. If the kickoff is ambiguous or missing context Leader needs, Leader posts a `message_type="question"` reply in the feature thread rather than guessing.
+
+## Retrospective
+
+After QA verifies and Leader confirms a feature has shipped, Spec/Impl/QA each post one short retro message in the feature thread with `message_type="retro"` (as a `reply_to` against Leader's ship message). Each agent should consider:
+
+- What went well in the process
+- What caused friction or confusion
+- What could be improved for next time (workflow, threading, handoff format, tooling)
+- Whether any step should become a skill or be automated
+
+**Keep retros short.** Bullet points, not paragraphs. The retro's job is to produce durable signal for Product's synthesis, not to re-narrate the run. Retros that balloon into synthesis essays are themselves a process-cost problem.
+
+**Do NOT mention Librarian on retro-request ship messages.** Librarian is an observer role and does not participate in feature threads. They watch ship events passively and deliver as-built passes via the dedicated Librarian→Product side thread.
+
+**Topology invariance principle:** Retros may change *how individual agents perform their work* (spec templates, impl disciplines, QA parity plans, handoff message content) but must NOT change the team interaction topology (who talks to whom, when they talk, the number of review cycles per run). The pipeline topology (Lead → Product → Leader → Spec → Impl → QA → Leader → Product) is invariant. Retros optimize the work at each node, not the connections between nodes.
+
+**Leader ensures the retros are visible in the feature thread** (Leader posts a "retros in" ping mentioning Product once all three retros are in, so Product gets a notification). Leader does not collect-and-forward, and does not do retro synthesis — retros live in the thread, Product reads them there.
+
+**Product reads retros and takes action** before the next run kicks off. Actions include updating CLAUDE.md, creating/updating memory files, modifying skills, or changing agent prompts. Observations without actions mean the same feedback surfaces next retro. Actions that would change the topology are rejected on principle — they go back as "performance/communication changes only."
+
+**Invoke `memory-audit` during synthesis.** After posting the retro-synthesis commit, invoke the `memory-audit` skill. The skill computes the count of synthesis commits since the last `memory audit:` commit and runs the audit if the count has reached five. The skill is fast (a no-op in four out of five invocations) and keeps the memory/documentation drift bounded.
+
+**Spike before speccing tooling:** For infrastructure or CLI-interaction features (shell scripts, devcontainer setup, agent interaction), do a quick manual spike to validate assumptions before writing a full spec. Platform code (APIs, frontends) is predictable enough for spec-first. Shell + CLI interaction is not.
+
+**Failed approaches:** If an approach fails, revert fully and keep the docs. The reverted spec provides negative-space constraints ("what doesn't work and why") that accelerate the redesign.

package/templates/skills/spec-checklist/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: spec-checklist
+description: Generate a prefilled verification checklist for writing a spec. Use at the start of spec work to ensure nothing is missed.
+argument-hint: [feature scope or description]
+---
+
+Generate a verification checklist for writing a spec for the given feature.
+
+## Feature
+
+$ARGUMENTS
+
+## Checklist
+
+Work through each item before writing the spec. Check off as you go.
+
+### API & Data Layer
+- [ ] **Existing API endpoints:** Which endpoints are relevant? Do any already serve the data needed?
+- [ ] **API gaps:** Are new endpoints needed? What request/response shapes?
+- [ ] **Data model changes:** Any new fields, tables, or migrations?
+- [ ] **Real-time events:** Does this feature need streaming / SSE / WebSocket updates? Are the right events already emitted?
+
+### Frontend
+- [ ] **Existing components:** Which components are affected? Read them before proposing changes.
+- [ ] **Existing helpers:** Check shared utilities — is there code that already does part of this?
+- [ ] **Framework compatibility:** Confirm patterns match the project's framework idioms (reactive state, effect model, component API).
+- [ ] **Styling:** Document exact colors, sizes, and spacing using the existing palette.
+
+### Dependencies
+- [ ] **New libraries needed?** Confirm compatibility with the project's toolchain.
+- [ ] **Bundle size impact:** Estimate size delta for any new frontend dependencies.
+- [ ] **Security:** Does the library handle untrusted input safely? Do we need sanitization?
+
+### Test Infrastructure
+- [ ] **Test runners available?** Verify the test tooling exists before specifying tests.
+- [ ] **Test plan:** Define test cases covering: happy path, edge cases, error cases, regressions.
+- [ ] **Test data setup (UI features):** If the feature involves visual changes, include concrete setup steps (e.g. HTTP calls, fixtures) that create the right data shape for manual or e2e verification. Don't rely on code review alone for visual correctness.
+
+### Interface Design
+- [ ] **Hide internal topology from consumers.** If the spec requires the client to enumerate sources, manage subscriptions, or know the internal structure of the data, the abstraction is wrong. The server should aggregate.
+
+### Cross-Cutting
+- [ ] **Verify claims in the feature scope.** Don't trust Product's assumptions about what exists — check the code.
+- [ ] **Accessibility:** Any ARIA labels, keyboard navigation, or screen reader concerns?
+- [ ] **Performance:** Any large data sets, heavy computation, or expensive renders?
+- [ ] **Security:** XSS, injection, auth boundaries?
+
+### Spec Document
+- [ ] **Reference code by function/class name + file path** — never use line numbers (they drift between commits)
+- [ ] **Files to create/modify** — explicit table with file paths and actions
+- [ ] **Open questions** — list anything that needs Product input
+- [ ] **Out of scope** — confirm alignment with feature boundaries
+
+### Baselines (§ 14 gates)
+- [ ] **Empty-diff shortcut first.** Run `git diff <prior_ship>..<feat_tip> -- <source-dirs>`. If empty, inherit the prior ship's gate matrix verbatim — no re-running tests/typechecks/lints. Fall back to full re-measurement if the diff is non-empty or the run is a structural refactor where the diff-based check could miss a latent failure.
+- [ ] **Cross-repo first run: empty-diff shortcut does NOT apply.** When the first pipeline run in a new repo kicks off, there is no prior ship to inherit from. Always remeasure from scratch at the feat tip: run the repo's test command, typecheck, and any project-specific baseline commands. Explicitly enumerate any pre-existing failures in § 2 so QA doesn't false-alarm on the delta.
+- [ ] **Pytest count formula.** When your gate section projects a pytest delta, use the explicit formula `baseline + N new test functions = new total`. **Additive assertions inside existing test functions do NOT add to the count.** Check that the test-plan count matches the headline target.
+- [ ] **Full re-measure if diff is non-empty.** Run baseline commands at the current `feat/<slug>` tip. Never inherit counts from a prior spec or memory of what the count was last run. Inter-run merges drift the numbers silently.
+- [ ] **Paste literal output** — BASELINE-FROZEN blocks with the exact command and its output.
+- [ ] **Prefer "≤ N" over "= N"** when the residual count lives in suppressed / unrelated files (scripts/, auto-generated).
+
+### § 13 Draft-time Command Execution (NON-NEGOTIABLE)
+
+**Run these commands BEFORE writing § 5 / § 11 / § 14, not as a review pass.** Reading commands is NOT the same as executing them. Executed commands routinely produce 1-2 spec amendments per run by surfacing stale assumptions.
+
+**Position in the workflow:** § 13 commands are *grounding*, not *review*. Running them *first* produces correct imports, paths, and counts on first write — skipping that step forces mid-draft patches.
+
+- [ ] **Execute § 13 commands at the START of spec drafting**, before writing § 5/§ 11/§ 14. The output drives what goes into those sections, not the other way around.
+- [ ] **Every quoted count** in § 11 / § 14 / § 6 is the literal output of an executed command, not a hand-estimate.
+- [ ] **Every file path** referenced in Product's doc has been verified with `ls` or `test -e`. Product docs drift; phantom paths get caught at spec time, not at Impl's first test run.
+- [ ] **Every Product-enumerated implementation step** has been verified against current code. Product docs sometimes describe as "to do" steps that have already shipped, or describe as shipped steps that were never completed. Grep/read each step before writing § 5.
+
+### § 11 Surprises for Impl — Missing-Imports Audit
+For every new symbol referenced in § 5 code snippets (function calls, exception catches, type annotations), grep the target file for the import:
+
+```
+grep -n "^import <sym>\|^from [^ ]* import.*<sym>" <target-file>
+```
+
+If the grep returns empty, add a § 11 line: "**Missing import** — `<sym>` is not imported in `<target-file>`. Add `import <sym>` (or `from <module> import <sym>`) to the top of the file."
+
+Common culprits:
+- [ ] Stdlib modules newly introduced by § 5: `json`, `asyncio`, `re`, `uuid`, `time`, `os`, `sys`.
+- [ ] New exception types in `except` clauses.
+- [ ] New typing imports: `Any`, `Callable`, `Awaitable`.
+
+**Test snippet imports must be self-contained.** Every symbol a § 7 test snippet calls must be explicitly imported inside that snippet (at the top of the test function or at the top of the test file). Do NOT assume `import foo as foo_mod` at the file top brings bare `foo_mod.cmd` into the test function's namespace — call sites that use the bare name will fail with `NameError` even if the alias import exists. Rule: for every symbol referenced by its bare name in a § 7 test snippet, grep the snippet for a matching `from <module> import <name>` or `import <name>` line. If absent, add it.
+
+### Test Cleanup Fixtures
+- [ ] **FK cascade enumeration.** If a test fixture deletes rows from a table with FK-dependent children, grep `REFERENCES <parent>(id)` in the schema files to find ALL child tables. Enumerate them in dependency order in the spec's test-infra section, OR specify `TRUNCATE ... CASCADE` as the default. Partial recipes silently fail when the schema grows new FKs.
+- [ ] **Verify the fixture helper at the target line before prescribing additive assertions.** When the spec says "add `assert X` to test Y at line N," grep test Y for the fixture it uses to confirm the fixture matches what the assertion needs. Cheap check at spec-draft time, saves Impl the recast work.
+- [ ] **Subprocess env forwarding under pytest-xdist.** If any test runs a subprocess that imports project config, the spec must list ALL mutated config vars to forward. In-memory config mutations don't cross process boundaries.
+
+### Token / Secret Literals in § 7 Test Snippets
+- [ ] **Never hard-code token prefix literals in § 7 test snippets.** Import from the project's token-constants module instead. Arch invariants that block raw literal usage in tests will trip the Impl gate — catch at spec-draft time.
+
+### Protocol Cross-Reference
+- [ ] **If any D-decision touches an inter-agent protocol** — mention lists on ship/kickoff/handoff messages, thread discipline, retros-in routing, token-ring mention rules, status-update discipline — scan CLAUDE.md's § Agent Workflow for the current live rule before freezing the spec decision. Live protocol evolves faster than spec templates; a spec that hard-codes a stale mention list forces Impl to either follow it blindly (wrong behavior) or deviate (compliance ambiguity).
+- [ ] **Prefer live protocol references over inline protocol rules** in D-decisions.

package/templates/skills/verify/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: verify
+description: QA verification workflow. Rebuild the test stack, run tests, diff against spec, and post a structured pass/fail report. Use when QA receives a handoff.
+argument-hint: [commit hash or feature name]
+---
+
+Run the QA verification workflow for a feature handoff.
+
+## Steps
+
+1. **Identify what to verify.** Check the recent Moot channel context for the handoff message. Note the commit hash, spec file, and files changed ($ARGUMENTS may contain the commit hash).
+
+2. **Rebuild the test stack** (QA owns the stack). Use the project's rebuild command. For example, on a docker compose project:
+   ```bash
+   docker compose up --build -d
+   ```
+   Wait for services to be healthy.
+
+3. **Install test dependencies** for your language/toolchain. For example:
+   ```bash
+   <project-test-install-command>
+   ```
+
+4. **Run the test suite:**
+   ```bash
+   <project-test-run-command>
+   ```
+   Note pass/fail count and any new failures.
+
+   **If you see a flood of errors at suite start** (contention from residual state left over from a prior run, stale DB connections, etc.): restart the relevant services to clear residual state before investigating further. This is the first diagnostic step, not a last resort.
+
+5. **Check the frontend build** (if applicable):
+   ```bash
+   <project-frontend-build-command>
+   ```
+
+6. **Code review.** Read the changed files and diff against the spec:
+   - Does the implementation match the spec?
+   - Are there deviations? Are they justified?
+   - Were all spec test cases included?
+   - Any security concerns (XSS, injection, etc.)?
+
+7. **Post verification report** to the Moot channel in the feature thread:
+
+```
+Verification complete for [feature] (commit [hash]).
+
+**Code review:** [Approved/Changes requested]
+- [finding 1]
+- [finding 2]
+
+**Tests:**
+- Backend: [X passed, Y failed]
+- Frontend build: [clean/errors]
+- New test coverage: [included/missing]
+
+**Spec compliance:** [matches/deviations noted]
+
+Verdict: **[Approved/Blocked]**
+```
+
+8. Mention Leader in the report so the pipeline advances. If blocked, mention Implementation with what needs to change.
+
+9. **Small repairs.** If you find an unambiguous bug during verification (wrong status code, missing validation a test covers, obvious typo), fix it directly — commit to your branch and include the fix in your report. No git-request needed for these. If the fix involves judgment calls or design decisions, flag it instead of fixing.

package/templates/teams/loop-3/CLAUDE.md

@@ -0,0 +1,72 @@
+# {project_name}
+
+TODO: Describe your project. What does it do? What problem does it solve?
+
+## Status
+
+TODO: What works, what doesn't. Update as the project evolves.
+
+## Tech stack
+
+TODO: Language, frameworks, databases, build tools.
+
+## Running
+
+TODO: How to run the project, run tests, build, deploy.
+
+## Code conventions
+
+TODO: Formatting, linting, type checking, naming conventions.
+
+## Agent Workflow
+
+{role_count} agents collaborate on this project: {role_list}. They communicate via the Convo shared context server.
+
+### Roles
+
+{role_descriptions}
+
+### Resource Ownership
+
+{resource_ownership}
+
+### Git Workflow
+
+{git_description}
+
+### Startup
+
+On connecting to a space (including restarts and resumes), every agent must:
+1. Call orientation() to get identity, focus space, and context
+2. Subscribe to the channel for push notifications
+3. Post a status_update confirming identity and readiness
+
+### Work Pipeline
+
+{workflow_description}
+
+```
+{pipeline_diagram}
+```
+
+{handoff_protocol}
+
+Before handing off, the agent must commit to their branch and request a merge from the leader via a `[GIT-REQUEST]` thread.
+
+**Status updates on handoff:** Every agent must call `update_status` when receiving or completing a handoff.
+
+### Channel Threading Protocol
+
+{threading_protocol}
+
+### Clarification Flow
+
+When an agent is blocked and needs input, use `[QUESTION]` threads in the channel. Mention the target agent.
+
+### Tracking Decisions
+
+Use `propose_decision` for choices that involve tradeoffs, creativity, or judgment -- decisions where a different person might choose differently. Do NOT track mechanical or purely deductive decisions.
+
+### Retrospective
+
+After the verifier approves and the leader confirms a feature is complete, every agent posts a retro message in the `[FEATURE]` thread.

package/templates/teams/loop-3/README.md

@@ -0,0 +1,6 @@
+# loop-3 -- Minimal Pipeline
+
+Three-agent pipeline for small projects where a separate design phase adds overhead.
+Leader --> Implementation --> Verifier --> Leader.
+
+Use for projects small enough that the leader can scope work directly to the implementer.

package/templates/teams/loop-3/team.toml

@@ -0,0 +1,108 @@
+toml_schema_version = "1"
+
+[archetype]
+id = "mootup/loop-3"
+version = "1.0"
+diverged_at = ""
+
+[team]
+name = "loop-3"
+description = "Minimal three-agent pipeline for small projects"
+version = "1.0"
+origin = "Reduced loop-4; same pattern as the markdraft example"
+
+# -- Roles --
+
+[[roles]]
+name = "leader"
+display_name = "Leader"
+harness = "claude-code"
+model = "sonnet"
+theme = "yellow"
+responsibilities = """
+Product direction, prioritization, feature scoping, and team coordination.
+Owns git operations (commits, branches, merges). Scopes work directly
+to the implementer -- no separate design phase. Human interface."""
+
+startup_prompt = """
+You are the Leader agent. Call orientation() to get your identity,
+focus space, and context in one call. Then subscribe to the channel.
+Post a status_update confirming you are online."""
+
+[[roles]]
+name = "implementation"
+display_name = "Implementation"
+harness = "claude-code"
+model = "opus"
+theme = "cyan"
+responsibilities = """
+Code implementation based on leader's scope. Writes common-case behavioral
+tests before handoff (pipeline gate). Follows scope precisely -- asks for
+clarification rather than guessing."""
+
+startup_prompt = """
+You are the Implementation agent. Call orientation() then subscribe to
+the channel. Post a status_update confirming you are online. Wait for work."""
+
+[[roles]]
+name = "qa"
+display_name = "Verifier"
+harness = "claude-code"
+model = "sonnet"
+theme = "green"
+responsibilities = """
+Test strategy, test implementation, feature verification. Owns the docker
+compose stack. Extends test coverage beyond requirements based on own
+analysis. Includes security verification. May commit small repairs
+directly when the intended behavior is unambiguous."""
+
+startup_prompt = """
+You are the Verifier agent. Call orientation() then subscribe to the channel.
+Post a status_update confirming you are online. Wait for work."""
+
+# -- Workflow --
+
+[workflow]
+description = """
+Work flows through agents in sequence, one feature at a time:
+Leader --> Implementation --> Verifier --> Leader.
+Each handoff is a channel message mentioning the next agent.
+Leader scopes work directly to the implementer (no design phase)."""
+
+pipeline = ["leader", "implementation", "qa"]
+
+[workflow.threads]
+feature = "[FEATURE]"
+question = "[QUESTION]"
+git_request = "[GIT-REQUEST]"
+stack_request = "[STACK-REQUEST]"
+
+[workflow.handoff]
+method = "mention"
+includes = ["summary of work done", "what next agent needs to do", "files changed", "branch name"]
+
+# -- Git --
+
+[git]
+description = """
+Each agent works in a git worktree. Feature branches from main,
+agent branches from feature branch. Squash-merge features to main."""
+
+strategy = "worktree"
+feature_branch = "feat/{slug}"
+agent_branch = "{role}/{slug}"
+merge_to_main = "squash"
+
+[git.ownership]
+main_branch = "leader"
+stack = "qa"
+
+# -- Resource ownership --
+
+[resources]
+description = """
+Shared resources have a single owner to avoid contention."""
+
+[resources.owners]
+git = "leader"
+docker_stack = "qa"

package/templates/teams/loop-4/CLAUDE.md

@@ -0,0 +1,72 @@
+# {project_name}
+
+TODO: Describe your project. What does it do? What problem does it solve?
+
+## Status
+
+TODO: What works, what doesn't. Update as the project evolves.
+
+## Tech stack
+
+TODO: Language, frameworks, databases, build tools.
+
+## Running
+
+TODO: How to run the project, run tests, build, deploy.
+
+## Code conventions
+
+TODO: Formatting, linting, type checking, naming conventions.
+
+## Agent Workflow
+
+{role_count} agents collaborate on this project: {role_list}. They communicate via the Convo shared context server.
+
+### Roles
+
+{role_descriptions}
+
+### Resource Ownership
+
+{resource_ownership}
+
+### Git Workflow
+
+{git_description}
+
+### Startup
+
+On connecting to a space (including restarts and resumes), every agent must:
+1. Call orientation() to get identity, focus space, and context
+2. Subscribe to the channel for push notifications
+3. Post a status_update confirming identity and readiness
+
+### Work Pipeline
+
+{workflow_description}
+
+```
+{pipeline_diagram}
+```
+
+{handoff_protocol}
+
+Before handing off, the agent must commit to their branch and request a merge from the leader via a `[GIT-REQUEST]` thread.
+
+**Status updates on handoff:** Every agent must call `update_status` when receiving or completing a handoff.
+
+### Channel Threading Protocol
+
+{threading_protocol}
+
+### Clarification Flow
+
+When an agent is blocked and needs input, use `[QUESTION]` threads in the channel. Mention the target agent.
+
+### Tracking Decisions
+
+Use `propose_decision` for choices that involve tradeoffs, creativity, or judgment -- decisions where a different person might choose differently. Do NOT track mechanical or purely deductive decisions.
+
+### Retrospective
+
+After the verifier approves and the leader confirms a feature is complete, every agent posts a retro message in the `[FEATURE]` thread.

package/templates/teams/loop-4/README.md

@@ -0,0 +1,6 @@
+# loop-4 -- Standard Pipeline
+
+Four-agent software development pipeline proven over 30+ features.
+Product --> Spec --> Implementation --> QA --> Product.
+
+Use for projects with enough complexity that implementation benefits from a design phase.