code-ops-suite

Use to capture the reasons behind a codebase's architecture as decision records, by backfilling load-bearing past decisions or writing an ADR for a current one.

Use when you need an accurate API or interface reference for a codebase, generated from the code and types, not from memory.

Use when you need a deep, diagram-rich architecture reference for a codebase, written for a senior engineer and grounded in the actual code.

Use to create a repo's atlas, its durable cache of codebase judgment, refresh it after code moves, or consolidate inbox notes. atlas-check sets freshness.

Use for a standard, isolated assess-only calibration run against a real-scale target repo. Ends in a sanitized trend entry and never quotes target internals.

Use when you want a broad, multi-lens review of an unfamiliar or drifting codebase. It writes a ranked findings backlog and applies only safe fixes.

Use to assess and repair a repo's standards contract, vault, atlas, and doc drift, or with scope global to align the user-wide Claude or Codex contract.

Use when you need current, version-accurate docs for a library or framework before coding against its API. It reads the installed version, not memory.

Use when you need a clear data-model reference for a codebase, generated from the real schema and migrations.

Use when you have a bug symptom and want it driven from reproduction to a root-cause fix at full rigor.

Use when dependencies are outdated or carry known CVEs and you want safe, staged upgrades verified at each step. It never bulk-bumps.

Use when docs have drifted from code and you want them reconciled into a clean single source of truth.

Use for a checkpointed pass over installed plugins, from one plugin pipeline to the cross-plugin superset. Pick plugins and a track: assess-only, full, feature.

Use when you want grounded, high-value feature ideas mined from the codebase rather than a generic wishlist. Discovery only, and it writes no code.

Use when feature specs already exist and you want them built incrementally. It requires specs as input.

Use when a long run needs a continue, compact, or transfer decision. A transfer captures verifiable state as HANDOFF.md; resume re-verifies every claim.

Use when deep review, OpSec review, or judgment evals should run locally before a PR, with exact-SHA receipts and optional GitHub status publication.

Use when code has inconsistent style or hasty-code artifacts and needs a behavior-preserving standard. Concept mode unifies a divergent concept and enforces it.

Use when you need a verified, code-grounded orientation guide, with an architecture diagram, for a new contributor.

Use when you need an operational runbook for a codebase, written for the senior engineer who has to operate it or be on call for it.

Use when something is measurably slow or hot paths need optimization with proof. Profiles first. For broad measured wins, use rigor:improve-measured.

Use when you have one big branch you want carved into a clean, reviewable stack of small PRs, each independently green and traceless.

Use to audit the suite on Claude, Codex, Grok, and OpenCode for host-specific assumptions in hooks, agents, skills, scripts, settings, manifests, and docs.

Use when a FINDINGS_REGISTER.md exists and its NEEDS-REVIEW and NEEDS-DESIGN items need safe implementation with tests. Requires a register as input.

Use when repository documentation must be extracted, refreshed, or proven current from one manifest-owned documentation hub.

Use to audit a finished run's cost discipline: dispatch counts, artifact sizes, and tier and effort mix. Requires its artifact folder, not a live run.

Use for an adversarial security and privacy threat model deeper than the audit's lens. Anonymity egress, metadata, and fingerprints go to privacy-opsec-suite.

Use when you want to implement one change, a feature or a one-off, end to end at high quality, shipped as a clean traceless PR.

Use when critical paths lack coverage or tests are flaky. Builds characterization and regression tests. To audit fault detection, use rigor:test-suite-audit.

Use when a repo needs its Obsidian docs vault created, an existing docs tree migrated into the standard layout, or an existing vault checked for conformance.