--- name: using-supervibe-skills namespace: process description: 'Use when selecting, sequencing, or explaining Supervibe skills for a task. Maps user intent to skill chains without bypassing commands, receipts, CodeGraph, or confidence gates.' allowed-tools: - Read - Bash phase: planning prerequisites: [] emits-artifact: skill-routing-plan confidence-rubric: confidence-rubrics/agent-delivery.yaml gate-on-exit: false version: 1 last-verified: 2026-05-13T00:00:00.000Z --- # Using Supervibe Skills ## WorkflowGateV1 Write Hard Rule No durable writes before intake summary approval. This is a blocking condition for skill execution: WorkflowGateV1 and the active workflow must show a user-visible intake or pre-artifact summary and receive explicit approval before this skill creates or mutates durable artifacts, source files, PRDs, plans, graphs, tasks, prototypes, previews, receipts, or release files. Action phrases such as "do it", "start now", "skip questions", "go ahead", or "use swarm" are intent only and never approval. ## Overview Using Supervibe Skills owns the using-supervibe-skills workflow for the planning phase. It reads the triggering request, source artifacts, local runtime state, and required command or receipt proof, then emits `skill-routing-plan` with a concrete decision and handoff. Use it to turn using-supervibe-skills input into a bounded action; return BLOCKED when the source artifact, owner approval, validator output, or runtime receipt is missing. ## When to Use Use this before mixing several Supervibe skills, when a user asks which workflow applies, or when an agent needs to hand off between planning, execution, review, memory, and release skills. ## Expert Operating Standard Follow `/skills/using-supervibe-skills/references/skill-expert-operating-standard.md` and `/skills/using-supervibe-skills/references/runtime-routing-standards.md`: start from source of truth, preserve context evidence, apply scope safety, use real producers with runtime receipts for durable delegated outputs, verify before completion claims, and keep confidence below gate when evidence is partial. ## Practical Implementation Hardening Use this practice profile before selecting or combining skills: - Minimal-sufficient implementation ladder: start with the single owning command or smallest skill set that can handle the request. Prefer deletion of duplicate routes, existing skill contracts, standard library, native platform, and existing project capability before wrapper skills or new dispatch logic. - Deletion-first review: remove stale aliases, duplicated skill chains, prompt-only replacements, unused capability assumptions, and redundant routing text before adding another skill surface. - Dependency restraint: add a new dependency only after standard library, native platform, shipped Supervibe helper, and existing project options cannot route or verify the workflow; record owner, runtime cost, fallback, and rollback. - Safety exceptions: minimal skill selection stops when security, data loss, concurrency, migration, accessibility, provider-host runtime, regulated-domain, or irreversible release risk appears. Escalate to the owning command, reviewer, producer, validator, or final gate. - Behavior gate: every selected skill must map to user-visible behavior, operator safety, lifecycle state, or durable artifact semantics, with happy, failure, boundary, and regression expectations when applicable. - One focused runnable check: run the narrow command-router, skill source, receipt, or artifact check that exercises the selected chain. Keep broad suites and validators for the final gate unless the workflow explicitly asks for them. - Simplification ceiling and upgrade trigger: the simple path ends when a workflow crosses command ownership, durable artifacts, delegated proof, provider capability, or conflicting route authority. Upgrade trigger: route through the owning command/runtime before claiming the skill chain is ready. - Focused check: rerun the command match, skill-source resolution, or targeted `node --test tests/.test.mjs` that covers the changed route. ## Swarm-First Durable Work Gate Non-trivial durable work is swarm-first by default. The user does not need to request agents: select the smallest relevant skill-bound workers, reviewers, producers, validators, verifiers, or specialists by default. Manager/supervisor control owns graph authority, dependency order, bounded fan-out, synthesis, termination, close sweep, and hard-stop behavior. Dispatch only ready bounded work with selected skill identity, host invocation proof, runtime receipts, receipt proof, and scoped verification evidence. If work remains local because it is trivial/read-only or host dispatch is unavailable, record the exception and do not claim independent proof. Follow `/docs/references/swarm-first-skill-contract.md`. Named durable worker, reviewer, producer, validator, verifier, or specialist work requires real specialist dispatch through the host/runtime path with selected skill ids, resolved `SKILL.md` paths, runtime receipts or receipt-ready host invocation evidence, and scoped verification evidence. Inline or controller-authored work is diagnostic or trivial-only; it cannot satisfy durable proof, reviewer proof, producer proof, validator proof, verification proof, task closure, or graph task closure. ## Step 0 - Read source of truth Read the requested command, active plan/graph state, `AGENTS.md`, and the candidate skill files. For command, workflow, skill-chain, routing, or "which skill should run?" questions, read `/docs/workflow-entrypoints.md`, `/docs/command-surface.md`, and `/docs/skills-roster.md` before selecting the final skill chain. For session-start or context-bootstrap work, read `/docs/session-start-context-policy.md` before choosing a path. If durable artifacts or delegated work are involved, read receipt and agent-invocation rules before choosing a path. For source-impacting agent work, record CodeGraph MCP readiness separately from local CodeGraph index readiness. Prefer runtime-confirmed live-callable `codegraph` MCP tools for public symbols, dependency direction, and structural evidence. If the MCP is missing or configured-only, route with explicit degraded fallback through `/scripts/search-code.mjs` and the status next action; do not present search-code, grep, or an index-ready CLI as equivalent proof. ## Lifecycle route map Use this compact route map before composing skill chains. The command owner is authoritative when a row names a command; skills support the row but do not replace the command state machine. Treat "workflow chain" as a diagnostic topic, not as a standalone command or shortcut lifecycle. Brainstorm-first lifecycle rule: raw or ambiguous product, feature, UI, design, prototype, plan, graph, review, or ship requests enter `/supervibe-brainstorm` first. Bypass brainstorm only when the request provides an approved PRD, approved `productContext`, an existing reviewed plan, or an explicit maintenance, debugging, status, audit, doctor, update, adapt, or tiny-docs task. ### Public command-to-skill entrypoint taxonomy Public workflow-affecting commands have same-name skill entrypoints so hosts without slash-command support can still start the correct command-owned lifecycle. Utility commands stay documented command-owned exceptions and must not receive decorative same-name skills. The validator treats the workflow mapping and utility exception lists as separate outputs: active workflow-affecting commands appear in `commandMappings`, utility and diagnostic commands appear in `utilityCommandExceptions`, and stale rows for commands no longer shipped under `commands/` are orphan-row failures. | Public command concept | User-facing skill entrypoint | Taxonomy state | | --- | --- | --- | | `/supervibe-audit` | `supervibe:audit` | Same-name primary skill. | | `/supervibe-adapt` | `supervibe:adapt` | Same-name primary skill. | | `/supervibe-genesis` | `supervibe:genesis` | Same-name primary skill. | | `/supervibe-brainstorm` | `supervibe:brainstorm`, then `supervibe:idea-refine` and `supervibe:requirements-intake` | Same-name workflow skill; brainstorm approval stays command-owned. | | `/supervibe-plan` | `supervibe:plan`, then `supervibe:planning-and-task-breakdown` and `supervibe:plan` | Same-name workflow skill; plan review stays command-owned. | | `/supervibe-loop` | `supervibe:loop`, then `supervibe:autonomous-agent-loop` and dispatch skills | Same-name workflow skill; graph/runtime state stays command-owned. | | `/supervibe-design` | `supervibe:design`, then `supervibe:brandbook` and design/prototype skills | Same-name workflow skill; commandless hosts can select `design`, while `/supervibe-design` keeps durable state, artifacts, and approvals. | | `/supervibe-verify` | `supervibe:verify`, then `supervibe:verification` and test evidence skills | Same-name workflow skill; goal-mapped evidence stays command-owned. | | `/supervibe-review` | `supervibe:review`, then `supervibe:requesting-code-review`, `supervibe:code-review`, and `supervibe:receiving-code-review` | Same-name workflow skill; reviewer proof stays command-owned. | | `/supervibe-ship` | `supervibe:ship`, then `supervibe:git-workflow-and-versioning`, `supervibe:shipping-and-launch`, and `supervibe:pre-pr-check` | Same-name workflow skill; final gates stay command-owned. | | `/supervibe-preview` | `supervibe:preview-server` | Documented utility command exception; no `supervibe:preview` skill. | | `/supervibe-status` | `supervibe:audit`, `supervibe:project-memory`, `supervibe:code-search` | Documented utility command exception; no `supervibe:status` skill. | | `/supervibe-doctor` | `supervibe:stack-discovery`, `supervibe:trigger-diagnostics` | Diagnostic exception; no `supervibe:doctor` skill. | | `/supervibe-update` | `supervibe:adapt` only when drift handling or approved project sync is needed | Documented utility command exception; no `supervibe:update` skill. | | `/supervibe-gc` | `supervibe:deprecation-and-migration` only when cleanup policy or migration risk needs skill review | Documented utility command exception; no `supervibe:gc` skill. | Selecting one of these skill entrypoints triggers the command-owned workflow when a public command concept is present. The skill supplies routing method, specialist procedure, and evidence expectations; it must not create a parallel state machine for command-owned plan, graph, design, update, cleanup, review, or release lifecycles. ### Core workflow capability-pack rule Public user choice for the main lifecycle is the core workflow entrypoint skill: `supervibe:brainstorm`, `supervibe:plan`, `supervibe:design`, `supervibe:loop`, `supervibe:verify`, `supervibe:review`, or `supervibe:ship`. Specialist skills are capability modules loaded by those command-owned packs; they are not competing user choices for the same lifecycle. Each core pack must state required capabilities by phase and fail strictly. If a required pack member, producer, validator, reviewer, runtime proof lane, or verification gate is unavailable, return `BLOCKED` or route to the documented repair owner instead of continuing with a narrower standalone specialist. | Public entrypoint | Mandatory pack capability shape | | --- | --- | | `supervibe:brainstorm` | Intake context, requirements/PRD shaping, approval-bound handoff, confidence and verification. | | `supervibe:plan` | Source lineage, memory/CodeGraph, plan production, test strategy, review proof, graph readiness. | | `supervibe:design` | Design intelligence, interaction patterns, brandbook and tokens when needed, component/frontend bridge when needed, prototype sandbox and handoff, browser/runtime/visual/accessibility proof, verification. | | `supervibe:loop` | Reviewed graph scope, source evidence, scoped TDD, swarm dispatch, task proof, scoped verification, final-only broad gates. | | `supervibe:verify` | Goal map, automated checks, manual tester or browser/runtime/visual/accessibility proof when available and relevant, confidence, residual gaps. | | `supervibe:review` | Verified diff, review packet, severity-ranked reviewer proof, automated release checks, manual/runtime QA proof when available, ship handoff. | | `supervibe:ship` | Completed review proof, final gate, branch/version state, rollback/monitoring, release mutation lease, final verification. | Capability-pack selection discipline: - Public user-facing lifecycle choices are the entrypoint packs above. Specialist skills are internal modules selected by those packs when they own an artifact, tool lane, producer, reviewer, validator, runtime proof, or repair path. - Direct prototype, mockup, visual comp, screen, or production UI requests route to `supervibe:design` first; `supervibe:prototype`, `supervibe:brandbook`, component, frontend, browser, visual, and accessibility skills stay downstream. - PRD, plan, graph, execution, verification, review, and release requests preserve the owning command state before specialist selection. A downstream skill cannot replace approval state, plan-review proof, graph state, reviewer proof, or final release gates. - Do not create more micro-skills for a missing lifecycle detail. Strengthen the relevant core pack, route to an existing specialist module, or return `BLOCKED` with the missing evidence and repair owner. - When a core pack is unavailable, stale, or missing a required producer/proof lane, report the exact missing pack member or runtime proof and stop instead of silently selecting a narrower standalone skill. | User intent | Command owner | Supporting skills | Durable state | Stop condition | | --- | --- | --- | --- | --- | | Raw or ambiguous idea, product, feature, UI, design, prototype, plan, graph, review, or ship request | /supervibe-brainstorm | idea-refine, requirements-intake, prd | spec or productContext | blocking question, unapproved scope, or no bypass reason | | Approved spec needs implementation plan | /supervibe-plan --loop-ready | plan, planning-and-task-breakdown, documentation-and-adrs | plan artifact | missing source, scope, acceptance, or next user choice | | Explicit plan review or reviewer loop | /supervibe-plan --review | requesting-code-review, code-review, confidence-scoring | review artifact and receipts when claimed | missing reviewer proof, open major risk, or no user answer | | Reviewed plan with specialist review proof needs graph/tasks | /supervibe-loop --atomize-plan --plan-review-passed | loop, subagent-driven-development, dispatching-parallel-agents | work-item graph | missing review proof, graph field, or hard-stop route | | Active graph/task execution | /supervibe-loop | source-driven-development, code-search, tdd, incremental-implementation, dispatching-parallel-agents, subagent-driven-development, verification | graph state and task evidence | dependency blocker, missing source/TDD/worker proof, scope expansion, or final-only gate reached | | Design system, mockup, or prototype workflow | /supervibe-design | design-intelligence, brandbook, tokens-export, interaction-design-patterns, component-library-integration, prototype, frontend-ui-engineering, browser-runtime-verification, visual-regression-testing, prototype-handoff, verification | design artifacts and approval state | unresolved target, missing design/prototype proof, or canonical next action mismatch | | Workflow-chain status, health, or current next action | explicit `/supervibe-status` or `/supervibe-audit` surface | audit, project-memory, code-search, confidence-scoring, verification | diagnostic route/status/audit evidence only | stale memory/CodeGraph, command hard stop, or maturity proof gap | | Audit or 10/10 maturity assessment | /supervibe-audit | audit, context-engineering, project-memory, code-search, confidence-scoring | audit artifact | missing memory/CodeGraph evidence, receipt readiness, or command hard stop | | Initial Supervibe scaffold or managed setup | /supervibe-genesis | genesis, stack-discovery, project-memory, code-search, confidence-scoring, verification | scaffold bundle and genesis state | missing host, unsafe overwrite, missing approval receipt, or confidence below gate | | Cleanup, archive, or restore Supervibe runtime artifacts | /supervibe-gc | deprecation-and-migration only for cleanup policy risk; verification when a cleanup claim is made | cleanup report, manifest, archive, restore, and lifecycle state | missing dry-run, irreversible deletion risk, missing manifest, or unsafe cleanup target | | Review, release, merge, or final proof | /supervibe-review, then /supervibe-ship | requesting-code-review, code-review, receiving-code-review, test-strategy, browser-runtime-verification, pre-pr-check, shipping-and-launch, finishing-a-development-branch | review record and final gate evidence | any required review, QA/runtime, or release proof lane incomplete | Route order: 1. For explicit slash, terminal, npm-script, or command-owned skill entrypoint text, run deterministic internal preflight with `--preflight-command` and honor `missing_slash_command`, `HARD_STOP`, and `doNotSearchProject` before broad source inspection; do not infer a workflow command from ordinary natural language. 2. Apply the brainstorm-first lifecycle rule for raw or ambiguous product, feature, UI, design, prototype, plan, graph, review, or ship requests unless an approved PRD, approved `productContext`, existing reviewed plan, or explicit maintenance/debug/status/audit/doctor/update/adapt/tiny-docs bypass reason is present. 3. Do not invent `/supervibe-workflow-chain`, `workflow-chain`, or any standalone chain command. Route chain questions to the matched owner: `/supervibe-audit` for maturity/gap analysis, `/supervibe-status` for runtime health or next action, `/supervibe-plan --review` for formal plan review, `/supervibe-loop --atomize-plan --plan-review-passed` for graph creation, `/supervibe-loop` for active execution, and the repo final gate for release proof. 4. If a durable command owns the lifecycle row, use that command path and let skills provide method, not replacement state. 5. If no command owns the row, choose the smallest skill chain that preserves source evidence, memory/CodeGraph, receipts, and final verification. 6. If an active graph says tests, validators, or reviewers are final-only, record the final gate and continue implementation without starting those gates early. Retired execute-plan wording resolves to the `/supervibe-loop` rows above. Do not select or document a standalone execution skill for that retired wording. Reference: `/skills/using-supervibe-skills/references/skill-chain-map.md`. Fixture: `/tests/fixtures/skill-lifecycle-route-map.json`. Swarm-first routing rule: non-trivial durable work defaults to selected skill-bound workers, reviewers, testers, producers, or specialists with real host invocation proof. Controller summaries and self-review are diagnostic-only; they may prepare or reconcile work, but they do not satisfy independent proof. If routing stays local because the task is trivial, record a trivial exception with scope, rationale, selected skills considered, and the fact that no durable independent proof is being claimed. ## Anti-patterns - Ignoring the boundary: Do not use this skill to replace /supervibe-* commands that own durable workflow state. - Skipping brainstorm-first: Do not route ambiguous product, feature, UI, design, prototype, plan, graph, review, or ship requests directly to plan, design, loop, review, or release without a documented bypass reason. - Inventing a lifecycle shortcut: Do not create, recommend, or emulate a standalone workflow-chain command; explicit preflight, audit/status, plan-review, atomize, loop, and final-gate owners remain separate. - Collapsing gates: Do not let status or audit output stand in for plan-review proof, atomized graph state, loop task evidence, or final release verification. - Accepting the rationalization: "This is just routing, so receipts do not matter" - false for durable plans, graph writes, producer outputs, reviewers, and worker claims. - Proceeding despite this red flag: A command, producer, reviewer, or worker is named but no runtime receipt can be issued. - Letting the known failure mode happen: Over-routing: too many skills slow delivery without improving evidence. ## When not to use - Do not use this skill to replace `/supervibe-*` commands that own durable workflow state. - Do not use it to bypass `/supervibe-brainstorm` for raw or ambiguous product, feature, UI, design, prototype, plan, graph, review, or ship work unless an accepted bypass reason is present. - Do not use it as a hidden workflow-chain command; if a user asks for workflow-chain work, report the `--preflight-command` result for a named command or route to the canonical command owner for the current lifecycle step. - Do not continue when explicit command preflight returns `missing_slash_command`, `HARD_STOP`, or `doNotSearchProject`; report the route result and stop. - Do not use it to justify inline emulation of an agent, reviewer, worker, or producer. - Do not start tests, validators, or reviewers during graph/task development when the active graph or repository policy marks them final-only. - Do not use it when one obvious skill already covers a read-only answer. ## Decision tree ```text Raw or ambiguous product/feature/UI/design/prototype/plan/graph/review/ship request? -> /supervibe-brainstorm -> idea-refine -> requirements-intake or prd Need context for non-trivial work? -> context-engineering -> project-memory -> code-search Need a plan or task split? -> planning-and-task-breakdown -> plan -> requesting-code-review Need implementation? -> source-driven-development -> incremental-implementation -> loop -> verification Need UI implementation? -> frontend-ui-engineering -> browser-runtime-verification -> ui-review-and-polish Need API/interface contract? -> api-and-interface-design -> error-envelope-design/auth-flow-design -> documentation-and-adrs Need security hardening? -> security-and-hardening -> code-review -> verification Need parallel work? -> dispatching-parallel-agents -> subagent-driven-development Need review? -> code-review or doubt-driven-development -> receiving-code-review Need release? -> git-workflow-and-versioning -> shipping-and-launch -> pre-pr-check -> finishing-a-development-branch ``` ## Procedure 1. Read the user request, active command/graph state, current CodeGraph status, and any existing workflow receipt output; record the exact command, artifact path, receipt id, or missing-proof status used as evidence. 2. Run or inspect deterministic `--preflight-command` output only for explicit command input; if it returns `missing_slash_command`, `HARD_STOP`, or `doNotSearchProject`, stop and report that route result instead of inspecting source files to emulate the command. 3. Choose the lifecycle row from the route map. If a command owns the row, use that command as `commandOwner`; otherwise choose the smallest skill chain that covers source evidence, mutation risk, receipts, and final verification. 4. Branch on risk: when code, design artifacts, graph state, memory, provider config, or release state can change, include project memory plus CodeGraph before implementation; otherwise keep the chain diagnostic and low overhead. 5. Repair the chain when evidence is missing: remove decorative skills, add the missing owner skill, or return `BLOCKED` with `missingEvidence`, `blockedSkill`, and `nextAction` rather than claiming the skill was used. 6. Put reviewers, tests, validators, and release checks at the active graph's final gate unless the current command/plan explicitly makes them an earlier deliverable. 7. Verify the selected chain by naming the concrete validator or status command that would fail if the routing were wrong, then emit the routing plan with receipt and stop-condition fields. ## Common rationalizations - "This is just routing, so receipts do not matter" - false for durable plans, graph writes, producer outputs, reviewers, and worker claims. - "One agent can do everything faster" - false when independent work can be delegated without blocking the critical path. - "The user named a skill, so no source check is needed" - false when the skill depends on current project or provider state. ## Red flags - A command, producer, reviewer, or worker is named but no runtime receipt can be issued. - Multiple skills are listed without ownership, order, or stop conditions. - The selected path skips memory, CodeGraph, or verification for a code-changing task. - Session-start output is treated as delegated-work proof or as a replacement for workflow receipts. ## Checklist - Command owner identified. - Skill sequence has no duplicate responsibility. - Required workers/reviewers bind selected Supervibe skill bundle ids, resolved skill paths, declared tools, bounded scope, output contract, and real host invocation proof. - CodeGraph/memory requirements are explicit. - Session-start/context-bootstrap policy remains compact, host-neutral, and non-fatal. - Final verification command is named. ## Failure modes - Over-routing: too many skills slow delivery without improving evidence. - Under-routing: a single generic skill hides required producer or reviewer proof. - Stale routing: the selected skill chain ignores active graph or provider state. ## Output contract Return this parseable routing plan: ```yaml status: PASS|BLOCKED|PARTIAL lifecycleStage: idea|plan|graph|implementation|design|audit|release|diagnostic commandOwner: /supervibe-*|none selectedSkills: - id: supervibe: reason: evidence, mutation, review, or verification need nonBypassBoundaries: - command, receipt, CodeGraph, memory, or final-gate boundary requiredReceipts: - agent/reviewer/producer receipt or none with rationale verificationCommands: - exact command or deferred final-gate command stopConditions: - missing slash command, hard stop, missing source evidence, missing receipt, unsafe scope, or user approval needed confidence: 0-10 with cap reason nextAction: concrete run, repair, handoff, or stop step ``` ## Domain practice framework Use the Skill Routing Decision Matrix: | Signal | Required response | Failure if skipped | | --- | --- | --- | | Slash-command or explicit command request | Run explicit preflight and honor hard stops | Controller invents a command path | | Durable artifact or delegated specialist named | Require command owner plus runtime receipt | Inline emulation is mistaken for proof | | Design, graph, memory, provider, or release state | Include project memory and CodeGraph before edits | Stale context drives poor agent output | | One obvious low-risk answer | Use one skill and name verification | Over-routing burns tokens without quality gain | ## Examples - Worked example: input `/supervibe-audit --workflow-chain` -> `--preflight-command` resolves the audit owner; selected skills are `supervibe:audit`, `supervibe:project-memory`, `supervibe:code-search`, `supervibe:confidence-scoring`, and `supervibe:verification`; stop if scoped receipts or CodeGraph proof is missing. - Anti-example: input `build the approved prototype` -> do not select `prototype` alone. Use `/supervibe-design` as owner, require approved design-system state, prototype-builder/ui-polish/accessibility receipts, browser runtime proof, and final handoff verification. ## Guard rails - Do not invent skill ids. - Do not bypass command-agent-plan for slash-command durable work. - Do not claim a skill was used unless its workflow evidence exists. ## Verification - `npm run validate:skill-bundle-coverage` - `npm run validate:skill-content-quality` - `npm run validate:command-agent-enforcement` - `node --test /tests/session-start-context-policy.test.mjs` when session-start/context bootstrap behavior changes. - If routing behavior changes, rerun the specific command-router or command-agent-plan regression that covers the route; if it fails, repair the selected skill chain and rerun before completion. ## Supporting references - `/docs/workflow-entrypoints.md` - `/docs/command-surface.md` - `/docs/skills-roster.md` - `/skills/using-supervibe-skills/references/runtime-routing-standards.md` - `/skills/using-supervibe-skills/references/skill-chain-map.md` - `/skills/using-supervibe-skills/references/skill-bundle-anatomy-and-authoring.md` - `/skills/using-supervibe-skills/references/skill-self-check-pattern-pack.md` - `/tests/fixtures/skill-lifecycle-route-map.json` - `/tests/supervibe-commands-routing.test.mjs` - `/tests/command-agent-enforcement.test.mjs` ## Related - `supervibe:autonomous-agent-loop` - `supervibe:dispatching-parallel-agents` - `supervibe:context-engineering` - `supervibe:incremental-implementation` - `supervibe:api-and-interface-design` - `supervibe:frontend-ui-engineering` - `supervibe:security-and-hardening` - `supervibe:shipping-and-launch` - `supervibe:verification` - `/docs/session-start-context-policy.md` ## Supporting references ### Resource tree hardening - `references/practice-pack.md` - Read when using-supervibe-skills needs deeper load rules, local evidence anchors, gotchas, or a final checklist. - `references/skill-self-check-pattern-pack.md` - Load when creating, reviewing, or hardening skill self-check behavior for adversarial examples, stale evidence, confidence caps, replay checks, and improvement loops. - `scripts/self-check.mjs` - Run with `--check` before claiming the using-supervibe-skills resource tree is complete; add `--json` when machine-readable evidence is needed. - `evals/regression.json` - Use when tuning using-supervibe-skills trigger boundaries or checking should-trigger and should-not-trigger prompts. - `examples/workflow.md` - Load when a concrete using-supervibe-skills workflow example or anti-example would clarify the next action. - `templates/output-contract.md` - Use when emitting agent-output so status, evidence, blockers, confidence, and nextAction stay consistent.