cohesive

Use this agent when a Cohesive `rewrite-specs` pass has just produced rewritten specs on a `design/<slug>` branch that need fresh-eyes review before implementation. The agent reviews only the file paths it is given — the spec-diff patch, the rewritten spec files, the rewrite branch — with no inherited conversation context, and returns a verdict of Approved / Issues Found / Design Incoherent against the Cohesive cohesion rubric. Examples: <example> Context: A spec rewrite for "intake classification refactor" has just landed on branch design/intake-classification. user: "Review the spec rewrite on design/intake-classification." assistant: "I'll dispatch the spec-cohesion-reviewer agent for a fresh-eyes review of the rewritten specs against the substrate model and approved direction." <commentary>The user asked for a fresh-eyes review of a spec rewrite — exactly what this agent is for. The agent will read only the listed files and return a structured verdict.</commentary> </example> <example> Context: The Cohesive `validate-rewrite` skill is invoking this agent automatically. user: (skill invocation passes the agent a list of rewritten spec paths, a spec-diff patch path, and the branch name) assistant: "Reviewing the listed specs in fresh context per the cohesion rubric..." <commentary>The agent must NOT read prior conversation. Only the explicitly-passed file paths plus the cohesion rubric and substrate model references are in scope.</commentary> </example>

Use this agent during a Cohesive architecture review (Phase 3) when judging whether a future agent (or new human contributor) could safely make a small correct change with bounded context — or whether the codebase depends on memory it doesn't hold. This is the cohesive-specific lens that distinguishes Cohesive's reviews from generic code review. Examples: <example> Context: cohesive-review --scope codebase Phase 3 dispatch. user: (skill invocation passes the claimed-system-shape and substrate discovery) assistant: "Judging agent-readiness: could a future agent change subsystems in this codebase with bounded context, or does each change require global understanding?" <commentary>This agent looks for hidden context dependencies — rules that aren't in the docs, patterns an agent would predictably violate, scars an agent wouldn't know about.</commentary> </example> <example> Context: cohesive-review --scope diff on a PR adding a new feature. user: (skill invocation passes the diff) assistant: "Checking whether this addition makes the surrounding code more or less agent-ready." <commentary>For diff scope, the agent asks whether the change increases or decreases the context required for future changes in the same area.</commentary> </example>

Use this agent when `cohesive:implement-cohesively` extend mode has completed code execution against an extension rewrite and needs an end-of-run fresh-eyes review verifying every sibling site is updated AND the diff stays within extension shape. The agent reviews only the file paths it is given — the spec-diff patch, the per-pass plan, the branch name, the rewrite-tip SHA, the substrate discovery report (the sibling-site list), and the change-surface description — with no inherited conversation context. Returns a verdict of Covered / Sites Missing / Bigger than extension. Examples: <example> Context: implement-cohesively extend mode has just completed executing-plans against design/add-home-surfacerole; the branch carries the implementation commits past the rewrite-tip SHA. The skill is dispatching the solo end-of-run reviewer. user: "Implementation complete. Run cross-mirror sweep." assistant: "I'll dispatch the cross-mirror-reviewer agent to verify every sibling site was updated and the diff stayed within extension shape." <commentary>The user wants end-of-run sibling-site coverage + extension-shape verification — exactly what this agent is for. The agent reads only the listed paths and returns a structured verdict.</commentary> </example> <example> Context: implement-cohesively extend mode is invoking this agent automatically per its Hard constraint #4 (solo dispatch in extend mode). user: (skill invocation passes the spec-diff path, the per-pass plan path, the branch name, the rewrite-tip SHA, the discovery report path, and the change-surface description) assistant: "Reviewing the implementation in fresh context per the extend-mode reviewer protocol..." <commentary>The agent must NOT read prior conversation. Only the explicitly-passed paths plus the canonical references are in scope.</commentary> </example>

Use this agent when `cohesive:implement-cohesively` has completed code execution against a spec rewrite and needs an end-of-run fresh-eyes review verifying every promise in the spec diff is covered by the implementation diff. The agent reviews only the file paths it is given — the spec-diff patch, the per-pass plan, and the implementation-diff (computed from the rewrite-tip SHA to the current branch tip) — with no inherited conversation context. Returns a verdict of Covered / Drift / Incomplete. Examples: <example> Context: implement-cohesively has just completed executing-plans against design/add-retry; the branch carries the implementation commits past the rewrite-tip SHA. The skill is dispatching the end-of-run reviewer pair. user: "Implementation complete. Run delta coverage." assistant: "I'll dispatch the delta-coverage-reviewer agent to compare the implementation diff against every promise in the spec diff." <commentary>The user wants end-of-run coverage verification — exactly what this agent is for. The agent reads only the listed paths and returns a structured verdict.</commentary> </example> <example> Context: implement-cohesively skill is invoking this agent automatically per its Hard constraints (parallel dispatch alongside cohesive:review-diff). user: (skill invocation passes the spec-diff path, the per-pass plan path, the branch name, and the rewrite-tip SHA) assistant: "Reviewing the implementation in fresh context per the dual-reviewer protocol..." <commentary>The agent must NOT read prior conversation. Only the explicitly-passed paths plus the canonical references are in scope.</commentary> </example>

Use this agent during a Cohesive architecture review (Phase 3) when checking whether the codebase is working *with* its frameworks, type system, and external libraries — or *against* them. Identifies friction with the ecosystem, reinvented primitives, type-system circumvention, and idiomatic mismatches. Examples: <example> Context: cohesive-review --scope codebase Phase 3 dispatch on a TypeScript+Next.js codebase. user: (skill invocation passes the claimed-system-shape and normative doc paths) assistant: "Reviewing library-native alignment: where is the code fighting Next.js, the type system, or other ecosystem conventions?" <commentary>The agent looks for custom abstractions over things the framework already provides, type circumvention (any/unknown casts), and patterns that fight the ecosystem.</commentary> </example> <example> Context: cohesive-review --scope codebase on a Python+SQLAlchemy codebase. user: (skill invocation passes the substrate) assistant: "Checking SQLAlchemy usage patterns and Python ecosystem alignment." <commentary>The agent adapts to the stack — its job is "is the code working with its tools" regardless of what those tools are.</commentary> </example>

Use when auditing a repo for missing memory — implicit rules, branchy behavior without matrices, invariants without enforcement, scars trapped in comments, stale docs. Single-pass scan, no reviewer-agent dispatch. Triggers on "audit substrate", "what memory is missing", "what specs/invariants/gotchas should we have but don't", "what's not yet substrate". For "what's wrong with the architecture" use `cohesive:review-codebase`; for "review my PR" use `cohesive:review-diff`.

Use before code when brainstorming a feature, refactor, or architecture change. Reads the substrate the codebase already has, captures current scope and future pressure separately, proposes 2–4 design options grounded in that substrate, then attacks each option through a 25-question pressure-test battery before recommending one. Triggers on "brainstorm a refactor of X", "design a feature for X", "what's the right way to add X", "how should we restructure X", "I'm thinking about Y, what do you think". Always pair with discover-substrate first; never produce code from this skill.

Use when the user wants to plan, refactor, design, brainstorm, audit, or review code in a way that should preserve specs, behavior matrices, named invariants, semantic linters, gotchas, architectural seams, tests, and future product direction. The Cohesive router. Triggers on "cohesively", "cohesive design", "design substrate-first", "brainstorm a refactor of X", "review the architecture for cohesion", "review the codebase for cohesion", "audit substrate", "what memory is missing", "review my diff for cohesion", "name an invariant", "encode a behavior matrix", "is this the right place to centralize", "rewrite the specs", "validate the rewrite". Picks the right Cohesive workflow, announces it, and chains the relevant subskills.

Use when starting substrate-first Cohesive work — before brainstorming a refactor, rewriting specs, or running a cohesion review — to inventory what specs, behavior matrices, named invariants, gotchas, semantic linters, CI checks, and local commands the codebase already carries, and to surface what's missing in the change surface. Substrate-first scope only; for general codebase exploration use Superpowers' research/exploration skills instead. Triggers on "discover substrate", "what specs/invariants/gotchas exist for X", "audit substrate before changing X", "what does Cohesive find in this repo".

Use after either validate-rewrite has returned Approved on a spec rewrite (standard mode) or rewrite-specs has landed an extension rewrite directly on a branch (extend mode), when the user wants to land code that makes the rewrite true. Drives a single-pass implementation where Cohesive owns the substrate-shaped intent (thin paragraph anchored to the spec diff) and the end-of-run reviewer dispatch — dual (delta-coverage-reviewer + cohesive:review-diff, AND-shape) in standard mode, or solo (cross-mirror-reviewer) in extend mode; Superpowers owns plan writing and TDD execution. Triggers on "implement the approved rewrite", "land docs with implementation", "implement-cohesively", "drive implementation against the rewrite", "ship the rewrite", "extend the existing concept". Always preceded by either validate-rewrite Approved (standard) or rewrite-specs extension commit (extend); always pairs with superpowers:writing-plans and superpowers:executing-plans.