repo-development

Repository development

Keep the workflow small, evidence-based, and friendly to concurrent Agents.

Repository governance

• Treat the repository as the Agent's working environment. When a recurring task is hard to route or verify, improve its existing owner, route, or Skill instead of adding a private workaround or another source of truth.
• Treat an Agent completion claim as a proposal. Targeted tests, independent verification, clean CI, and—when the change crosses an external boundary—a real integration run determine whether the change holds. Each proof is scoped to what it actually measured.
• Move work, PRs, decisions, guardrails, and releases only through their explicit lifecycle operations. Do not infer a state transition from phrases such as "done" or "ship it" and do not bypass its prerequisites.
• Detect entropy aggressively: stale temporary work, expired guardrails, duplicate tests, unused compatibility layers, and superseded abstractions. Automatically remove only generated, cached, or explicitly expiring material; propose reviewable candidates before deleting source, history, public interfaces, issues, or pull requests.
• Keep one authoritative writer for each fact. Observe or reference GitHub, Contracts, repository state, verification receipts, and NMG memory through their owning interfaces rather than mirroring them into a competing store.

Before editing

1. Run npm run agent:context -- <target-path>. Positional paths route the explicit scope without consulting Git. Use --changed only when dirty Git paths should be added automatically; that mode requires working Git inspection. Treat unknown reconciliation as missing applicable evidence, and drifted as a request to inspect the reported declaration, snapshot, or verification mismatch. Neither status is an architectural verdict.
2. Inspect git status --short; preserve unrelated changes and commit only your files.
3. Read the returned owning design and the exact code you will modify. Experiments are evidence, not normative design.
4. State a testable outcome. For defects and lifecycle work, write the failing behavior test first.
5. Immediately before the first substantive file write, register one open in-flight goal on the repo-development Task Board channel. Its content contains only goal, approach, and scope; use one entry for the coherent task, not one per file or step. Follow the daemon ownership rules in nmg-memory, and retain the returned entry ID: