# ROADMAP — Standards Longer-term backlog for the standards repo: future agents, commands, and cross-repo standards to hash out and build later. Near-term status lives in `AGENTS.md` → `## Current state`. Items here are parked, not committed — we iterate on them when we pick one up. Newly captured cross-repo ideas land in `INBOX.md` first and graduate here on triage. --- ## 1. Cross-repo quality-gate standard (linters / pre-commit hooks / CI) **Why:** with agents writing the code, these stop being developer conveniences and become the falsifiable rails that let an agent check its own work — write, get told exactly what's wrong, iterate, verify. The *standard* is authored here; *application* is per-repo (in each repo's AGENTS.md), because what's best-in-class differs by language/stack. **The principle to encode:** every code repo should give its agent a fast, deterministic, agent-runnable feedback loop — the subset of checks that run without a human and can't be skipped. Tier it: - **Linter/formatter** — per-stack (e.g. ruff/black, eslint/prettier, gofmt). Fast, runs on every change; the agent fixes before moving on. - **Pre-commit hook** — the unskippable gate: runs the linter + quick tests and blocks the commit if they fail. This is the highest-ROI piece and the first to add. - **CI on push** — the heavier rebuild + full test suite. Lower priority for solo repos on Gitea (Gitea Actions exists); add when a repo has real collaborators or releases. **This repo's own first instance:** it's Markdown + symlinks, so its quality gate isn't a code linter — it's a pre-commit hook that runs the **structural checks** this repo already has an agent for: relative-symlink integrity (`AGENTS.md ← CLAUDE.md`, `docs/guides/* ← .claude/rules/*`, the `adapters/` directory symlinks) and internal-link validity. The `portability-checker` agent encodes the invariants; the hook makes the deterministic subset unskippable. Build this as the worked example of the standard. Concrete checks to start with: (a) the `type` enum is identical across `guides/capture.md`, `INBOX.md`, and `AGENTS.md`; (b) `CLAUDE.md` is a relative symlink resolving to `AGENTS.md`; (c) every `adapters/claude/{commands,agents}/*.md` wrapper has a matching `guides/.md` substance file (no wrapper-without-guide drift). **Open questions:** one shared hook framework (pre-commit.com) vs. hand-rolled per repo; how the standard gets *adopted* into a repo (a `/harden` command that installs the right linter+hook for the detected stack?); whether to define a minimal "agentic-ops baseline" checklist doc alongside the other four standards docs. ## 2. `roundup` — cross-project status agent (the inverse of capture/triage) **Why:** a global "what should I do next / which project to focus on" view. Capture/triage push items *down* into project repos; roundup reads back *up* across all of them. **Shape:** a command (`/roundup`, run from `~/Projects`) that fans out one read-only subagent per repo to read that repo's `AGENTS.md` (`## Current state`) and `ROADMAP.md`, plus reads the standards `INBOX.md` for not-yet-triaged items. It synthesizes **one aggregated to-do list across all projects, grouped by priority**, including items that haven't been pushed down to a repo yet. Mirror `full-eval`'s orchestrator pattern: fan out, then synthesize into one report; the per-repo readers can be the generic `Explore` agent or a small dedicated reader. **Division of labor (the user's explicit call):** the agent *reads and reports* — it gathers and presents findings grouped by priority; it does **not** decide the best use of time. Prioritizing across projects is a back-and-forth the user does on top of the report. So the output is a clean, evidence-backed inventory, and the "what's actually worth doing now" conversation happens after, in the main thread. **Open questions:** which folders count as "my projects" (scan `~/Projects`, skip non-repos and the standards repo itself?); how to keep it cheap (cap readers, summarize hard); whether roundup output is ephemeral or written to a `STATUS.md` in the standards repo for diffing over time like `EVALUATION.md`. ## 3. Deterministic inbox surfacing — SessionStart hook (optional upgrade over the portable line) **Why:** the portable mechanism (the inbox-check line in every repo's AGENTS.md) is model-interpreted and therefore skippable. A Claude `SessionStart` hook that greps `INBOX.md` for the current repo's tag and prints matching items is deterministic and unskippable — the same quality-gate logic as item 1, applied to capture. **Tradeoff:** hooks are Claude-specific and per-repo, so they don't travel to other vendors. Decision already made: keep the AGENTS.md line as the **belt-and-suspenders portable default**, and offer the hook as an opt-in upgrade for repos where you want the guarantee. Possible form: a snippet the quality-gate `/harden` flow (item 1) installs alongside the linter hook. ## 4. Thread the inbox-check line into bootstrapping **Why:** right now adding the portable inbox-check line to a repo is manual. It should be automatic so every repo inherits it. - Add the line to the AGENTS.md template in `retrofit-playbook.md` (Step 1, prompt A) and to the `/retrofit` guide's Phase 4. - Thread the canonical `.gitignore` block (now in `portability.md` → "What git tracks") into `retrofit-playbook.md` Step 0 and the new-repo bootstrap, so every repo's committed `.gitignore` carries it rather than relying on a global excludesfile. - Consider a one-time sweep command that adds it to every existing repo's AGENTS.md. - Decide whether the canonical wording lives in `how-i-work.md` (so it's truly universal) or stays a per-repo line. ## 5. `new-project` — idea → scoped → scaffolded → Gitea repo **Why:** the inverse of `/retrofit`. Retrofit moves an *existing* project onto disk; this takes a captured `(new)` inbox idea and turns it into a real, standards-compliant repo. It closes the capture loop: `/capture (new) …` → bootstrap → a repo that already has AGENTS.md, the CLAUDE.md symlink, ROADMAP.md, the canonical `.gitignore`, and the inbox-check line. **Shape:** a command (`/new-project`, run from `~/Projects`), main-thread and collaborative — scoping is a conversation, not a delegated job. Phases: 1. **Workshop the scope** — back-and-forth to sharpen objectives, non-goals, stack, and the key early decisions. Pull the seed from the `(new)` inbox item if one exists. This is the high-value step and stays interactive (like roundup, the reasoning is the user's). 2. **Seed prompt** — synthesize the workshop into a concrete project brief / initial build prompt plus a scaffolding plan; get the user's sign-off. 3. **Scaffold** — create the new folder under `~/Projects`, write the initial AGENTS.md (from the brief) + CLAUDE.md symlink, ROADMAP.md, README, the canonical `.gitignore`, `.claude/` wiring, and the starting directory structure. Compliant from line one. 4. **Publish** — `git init` + initial commit, create the Gitea repo, add the remote, push (reuse retrofit-playbook Part 4; if no Gitea API token is available, hand back the manual "create empty repo, copy URL" step). Then remove the `(new)` item from the inbox. **Open questions:** Gitea repo creation — API token vs. manual UI step; how much scaffolding is generic vs. stack-specific (does it call a `/harden` step from item 1 to install the stack's linter+hook?); whether the workshop output also seeds the first `## Current state`.