code-ops-suite

Use when the user's global ~/.claude/CLAUDE.md needs to be created, brought up to the suite's current doctrine, or re-verified after the marketplace's standards moved.

Use when a repo's CLAUDE.md standards contract needs to be created, brought up to the house style, or re-verified against reality.

Use when you need to capture the WHY behind a codebase's architecture as decision records — backfilling load-bearing past decisions or authoring an ADR for a current one.

Use when you need an accurate API/interface reference for a codebase, generated from the code and types, not 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 when a repo's atlas — its durable, per-repo cache of judgment about the codebase — needs to be created, refreshed after the code moved, or consolidated from inbox observations. Freshness is decided mechanically by atlas-check.mjs; see code-ops-docs/40 Engineering/Techniques/atlas.md.

Use when you want a standardized real-scale calibration run of the suite against a target repo, in an isolated assess-only session, ending in a sanitized trend-table entry. Never quotes the target's internals back into this repo — see code-ops-docs/40 Engineering/Techniques/calibration-protocol.md.

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

Use when you want to know whether a repo is on the code-ops standard at all, how far out of conformance it is, and then have it brought back — the standards contract, the docs vault, the atlas, and doc drift, assessed in one pass and repaired under checkpoint.

Use when you need current, version-accurate docs for a library or framework before coding against its API — read from 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 have known CVEs and you want safe, staged upgrades verified at each step; never bulk-bumps.

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

Use when you want the most exhaustive end-to-end pass across all three plugins; token-expensive and checkpointed. Cross-plugin superset — requires code-ops-suite, rigor, and privacy-opsec-suite installed.

Use when you want grounded, high-value feature ideas mined from the codebase (not a generic wishlist). Discovery only — writes no code.

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

Use when you want the whole code-ops-suite run end-to-end on one codebase as a guided, checkpointed pipeline. Intra-plugin orchestrator; for the cross-plugin superset use everything.

Use when a long run must survive a context limit, session end, or operator change — capture the run's true state as a verifiable HANDOFF.md, or resume from one, re-verifying every claim first.

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 a codebase has inconsistent style or the artifacts of hasty/generated code and you want one professional, behavior-preserving standard. To close divergent implementations of a concept, see rigor:consistency-closure.

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 or be on-call for it.

Use when something is measurably slow or you want hot paths optimized with proof; profiles first. For broad behavior-preserving measured wins, see rigor:improve-measured.

Use when you want a rigorous pre-merge review of one PR/diff against all quality lenses. For a verification-bar review that blocks only on reproduced defects, use rigor:deep-review; for an anonymity gate, privacy-opsec-suite:opsec-pr-gate.

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

Use when you want to audit the marketplace's own prose for provider-specific assumptions (harness mechanics, tool names, hook semantics) that would mislead a reader on a different host. The mechanical render layer is already covered by build-codex-marketplace.mjs --check; this skill covers prose only.

Use when a FINDINGS_REGISTER.md already exists and you want its NEEDS-REVIEW/NEEDS-DESIGN items implemented safely 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 when you want to audit a completed orchestrated run's cost discipline — dispatch counts, artifact sizes, tier/effort mix — against the suite's own bounded-wave and routing doctrine. Consumes a finished run's artifact folder, not a live one.

Use when you need an adversarial security + privacy threat assessment of attack surface and deanonymization paths — deeper than the audit's security lens. For anonymity-specific egress/metadata/fingerprint work, use the 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 meaningful coverage or tests are flaky; builds characterization + regression tests. To audit whether existing tests actually catch faults, 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.