Menu
SkillsMP has collected 11 skills from marktoda/cohesive. Open a skill to review its source and details.
Showing 11 of 11 collected skills.
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…
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…
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…
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…
Use when starting Cohesive on a codebase that has no Cohesive substrate yet — implicit substrate exists in comments, test names, branchy code, and conventions, but no named invariants, behavior matrices, or gotcha docs. Init scans for proto-substrate signals,…
Use after brainstorm-design has produced an approved direction and before any code is written. Hard-rewrites design docs, specs, behavior matrices, invariants, gotchas, and substrate maps to describe the chosen end state as if it were already true — not as…
Use after rewrite-specs has produced rewrite commits on a `design/<slug>` branch, before implementation. Runs a fresh-eyes review of rewritten docs/specs (reading the git diff directly) in a separate agent context that did not participate in the design…
Use when starting work in a codebase where substrate-first thinking applies — designing a feature, refactor, or architecture change that touches behavior or invariants; extending an existing concept (add a leaf to an enum, a row to a matrix, a sibling case);…
Use when reviewing a PR, branch, or working changes for cohesion — does the diff preserve documented behavior, named invariants, and substrate? Lighter than codebase review; dispatches two reviewer agents in parallel and renders verdict in chat. Triggers on…
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…
Use when reviewing a whole codebase or named subsystem for cohesion — does the implementation agree with the docs, are invariants enforced, are seams in the right places, can a future agent change this safely. Reads normative docs first; stops if specs are…