Promote a repeated, verified Yarbrain procedure candidate into a user-owned Agent Skill or propose an update to an existing one. Use after the same procedure succeeds in independent episodes or when the user explicitly requests reusable automation; do not promote facts, policy, or unexplained workarounds.
Convert a completed session or queued Yarbrain session locator into an immutable episode and reviewable knowledge or procedure candidates. Use after substantial work, before context loss, or when pending session records need extraction; never update canonical notes or active skills.
Create or adopt a user-controlled Yarbrain Markdown vault and configure lifecycle hooks to find it. Use when setting up Yarbrain, moving its vault, or repairing a missing vault structure; do not use for routine capture or maintenance.
Audit and conservatively maintain a configured Yarbrain vault for structural errors, stale knowledge, duplication, conflicts, unprocessed evidence, and skill drift. Use periodically or when recall quality declines; make deterministic checks first and require approval for semantic consolidation or archival.
Retrieve a small, relevant set of current Yarbrain notes, episodes, and approved procedures for an upcoming task. Use before substantial debugging, design, planning, or repeated work where prior knowledge can change the approach; remain read-only.
Search, compare, and reconcile pending Yarbrain memory candidates with canonical semantic notes through reviewable patches. Use when processing inbox/memory candidates, resolving conflicting evidence, or applying an explicitly approved knowledge patch; do not capture sessions or promote procedures.
Generate and evaluate genuinely different approaches to a product, workflow, or system problem. Use when the user explicitly wants a bold, contrarian, experimental, or non-incremental alternative and a testable recommendation.
Refine underdefined product or system architecture through focused interactive decisions. Use when the user wants architecture sparring before a formal implementation plan or contract update.
Implement behavior through a red-green-refactor cycle when focused automated tests are proportionate. Use for product behavior changes and for engineering tooling and infrastructure only when native checks are insufficient and concrete complexity or failure risk warrants dedicated tests.
Review a complete change for unwanted scope, redundant or residual artifacts, review-obscuring churn or prose, hollow verification, and work shifted to reviewers. Use before human review and after review-driven fixes, not for general implementation review or AI-authorship inference.
Explain a pull request, commit range, branch, or local diff from a system-design perspective. Use for practical understanding of changed behavior, boundaries, flow, ownership, operations, risks, and verification rather than defect review.
Report all repository changes that entered a target branch during one required date or period, grouped by product change and written as plain English for a broad audience. Use for daily, weekly, date-range, or relative-period change summaries rather than explaining one known diff.
Audit CI workflow architecture and effectiveness without modifying it. Use when triggers, jobs, commands, quality gates, caches, artifacts, matrices, permissions, release paths, or deployment automation may be stale, redundant, unsafe, or unjustified.
Run an independent Claude Opus review of the complete current change against the repository's default branch, then verify its findings locally. Use after focused checks pass when you want a second model to review the change before further edits or delivery.
Verify terminal-hosted CLI or TUI behavior with repeatable local evidence. Use for output, prompts, interactive input, signals, hangs, resizing, startup, exit status, or terminal restoration.
Orchestrate an adaptive multi-agent pull-request review that combines structural and semantic context, assigns risk-based reviewer prompts at runtime, deduplicates and verifies findings, and renders an evidence-backed review. Use when a pull request or local change needs independent review lanes, adversarial…
Triage unresolved CodeRabbit feedback on the current GitHub pull request. Use for read-only disposition and, only when separately authorized, scoped remediation and remote thread closure.
Assess method-level change risk with the Change Risk Anti-Patterns (CRAP) index and recommend focused testing or complexity reduction. Use when a repository configures CRAP measurement, cyclomatic complexity and automated test coverage data are available, or a user asks what CRAP means, how to calculate or interpret…
Create one concise evidence-linked product journey record for one actor pursuing one goal. Use when product behavior needs traceable ownership, acceptance, telemetry, or service-flow documentation for a current decision or delivery gate.
Review dependency provenance and reproducibility without modifying them. Use when manifests, lockfiles, vendor state, generated dependency state, registries, fetched tools, or version pins change.
Review documentation for drift caused by the current code or configuration change. Use to identify concrete inaccuracies and, when authorized, repair only directly affected documentation.
Audit or improve general repository documentation against implemented behavior. Use for deliberate README or documentation-quality work not owned by a more specific documentation skill.
Review infrastructure-as-code and rendered deployment configuration without modifying it. Use before plan, apply, or deploy when targeting, replacement, state, availability, cost, ordering, or recovery blast radius may change.
Create one or more Jira issues through acli from user-approved drafts using heading-based Context, Acceptance criteria, and Engineering notes sections. Use only when explicitly invoked to create Jira issues; use jira-issue-refine when requirements still need refinement.