vinyan

Review code changes for correctness, error handling, scope creep, and style. Use when the goal mentions reviewing a PR, diff, or file.

Walk through a stack trace or error log to find the root cause. Use when the goal mentions debugging, investigating an error, or tracking down a bug.

Write a Conventional Commits message describing a code change. Use when the goal mentions creating a commit, writing commit message, or committing changes.

Outline unit tests for a function or module before writing them. Use when the goal mentions writing tests, test plan, or test coverage.

Keep effort proportional to risk — prefer the cheapest sufficient workflow, escalate only on evidence, refuse over-analysis on simple tasks. Use when choosing depth, level, or workflow shape.

Map required capabilities to persona roles and available skills. Detect missing skill coverage and decide whether to acquire a skill, request one, or proceed generically. Use when scoping a workflow.

Coordinate multi-persona work with a shared blackboard, role boundaries, hand-off contract, conflict resolution, and final synthesis. Use when a task benefits from more than one persona.

Gather enough context before acting — read code, docs, specs, prior decisions; identify the source of truth; refuse to speculate. Use when investigating, researching, or before any non-trivial change.

Stay aligned with Vinyan governance — generator/verifier separation, no self-evaluation, deterministic routing, content-addressed evidence, trust gates. Use when designing routing, verification, or commits.

Decide whether a task produced reusable knowledge worth recording — repo memory, session memory, skill candidate, failed approach, prediction error. Use after non-trivial work concludes.

Shape the final output to user intent — concise answer vs implementation summary vs plan vs review report vs hand-off note. Use when producing the response the user actually receives.

Choose the right persona or hand-off chain — developer, architect, author, researcher, reviewer, mentor, assistant, concierge. Use when delegating, routing, or deciding who should handle a step.

Standardize a plan — objective, assumptions, affected surfaces, steps, verification, rollback, open questions. Use when producing a plan, design proposal, or implementation outline.

Recover from failed tool calls, bad routing, missing context, or failed verification. Diagnose, avoid retry loops, choose an alternate path, escalate only when truly blocked. Use when something failed.

Frame review output by severity, name the violated invariant, cite evidence, list missing tests, and state residual risk. Use when reviewing, auditing, critiquing, or producing a verdict.

Break complex work into ordered subgoals with explicit dependencies, expected outputs, and stopping conditions. Use when a task has multiple steps, unclear scope, or non-trivial coordination.

Decide the verification tier — typecheck, lint, affected tests, full suite, manual check. Use when finishing a change, reviewing one, or planning what evidence will prove the work.

Classify a request before acting — intent, expected artifact, ambiguity, risk, persona class. Use when starting any new request and deciding whether to clarify, route, answer directly, or run a workflow.