beislid

Use when the user asks to babysit a PR, run /babysit, keep a PR green, monitor review/CI until ready, or optionally close out a PR through configured merge/capture/retro automation. Can run directly; host goal/persistence support is optional.

Audit Beislið workflow config and probe each capability. Use when the user says "doctor", "/doctor", "audit my config", "check my workflow", "probe everything", "what's set up", or after editing workflow.md. Reports gaps in conversational prose; does not modify config or skills. Pass `--refresh` to force re-probing even if the cache is fresh.

Author, approve, and export execution envelopes for AFK slices in a standalone strong-model session. Use only when the user explicitly invokes /envelope with a ticket id, approved Work Contract/spec file, or batch. Other skills may recommend it but must never auto-route into it. Ends with an approved, validated, repo-committed bundle under .beislid/exports/ that an external runner executes later.

Use when you have an approved design or requirements for a multi-step task, before writing code. Creates a file-level implementation plan with TDD as the default rhythm, host-agent task tracking, and parallel task batching.

Use when starting work on a ticket after checking out the feature branch. Fetches the ticket, explores the codebase, routes vague tickets through spec, routes large work through break-spec, then hands implementation-ready work to blueprint and implement. Adapts to whatever ticket tracker and domain tooling the environment provides — driven by `<repo>/.beislid/workflow.md`.

Use when the user says "ready-for-review", "ready for review", "prepare for review", or "finalize for review", or when work is ready for PR review handoff. Bookend to kickoff: gates, review, final check, and PR handoff. Do NOT use for mid-implementation commits or unfinished work. Reads workflow.md and probes capabilities lazily.

Use when the user says "retro", "/retro", "retrospect", "post-run retro", "tune workflow", "refine gates", "improve workflow.md", or asks what should change after a run. Reviews available run/session evidence and the whole `.beislid/workflow.md`, then recommends workflow improvements. Does not edit config; route accepted changes through `setup`.

Use when the user says "review-response", "respond to review", "review comments are back", or "QA sent feedback", or when existing PR review comments or QA feedback need a response. This is the post-review response skill. Do NOT use when the user wants to write reviews, start new work (use kickoff), or create a PR (use ready-for-review). Reads `<repo>/.beislid/workflow.md` and probes lazily. Supports prompt profiles for agent-ready review comments.

Configure Beislið project config (`.beislid/workflow.md`) interactively, or update an installed Beislið distribution. Use when the user says "setup", "/setup", "setup update", "/setup update", "update beislid", "configure beislid", "set up workflow", "add scopes", "change ticket source", "reconfigure beislid", or any intent to add, change, or remove a workflow.md section. Walks through sections conversationally; shows a diff before any destructive write.

Trigger immediately when the user says any of: 'design this', 'plan the implementation', 'plan this out', 'how should we build', 'implementation plan', 'before I write code', 'design the feature', 'figure out how to build'. Also use for implementation design once desired behavior is known: before creating features, building components, adding functionality, or modifying behavior. Do not skip this skill and start coding directly — if a trigger phrase appears, route here even if auto mode is active. Do not use for open-ended product brainstorming or vague requirements; use spec first. No code until design is approved.

Use when the user wants to review someone else's PR, says 'review this PR', 'look at this PR', 'check this PR', shares a PR URL with review intent, or asks to post PR review comments. Fetches the PR diff, runs the review contract, drafts safe comments, and posts only after approval.

Use when the user asks for a visual HTML evidence/explanation artifact: 'show-me', 'show me this', 'make a proof deck', 'make an HTML deck', 'visualize this as HTML', 'this would be better as slides', 'make this visual', 'create a walkthrough deck', 'document this visually', or 'review this visually'. Manual/user-requested only in v1. Produces a polished local HTML portfolio/deck with evidence, media, logs, provenance, and clear missing-evidence markers.

Break an approved spec/PRD or Work Contract into phased vertical slices. Use when the user says 'break this spec down', 'phase this', 'create a plan from this', 'decompose this feature', or when spec/kickoff classifies work as multi_slice/project slice planning.

Use when the user asks for 'fresh eyes', 'one last review', 'final review pass', 'whole diff review', or a post-fix pre-PR review. Runs a side-effect-free final whole-diff pass for cross-file consistency, config drift, stale docs, limits, baseline compatibility, and issues iterative review can miss.

Review a local diff or supplied patch against requirements. Produces severity-categorized findings and a readiness verdict. Side-effect-free primitive used by ready-for-review, future rinse-style loops, PR patrol workflows, and ad-hoc review requests.

Trigger immediately when the user says any of: 'spec it out', 'spec this out', 'before you build', 'before we build', 'before implementation', 'let's discuss before building', 'discuss and spec', 'PRD this', 'shape this', 'product spec', 'lightweight spec'. Also use for brainstorming, vague tickets, product shaping, or writing a lightweight product spec/PRD when the problem, scope, desired behavior, or success criteria are unclear. Do not skip this skill and answer conversationally yourself — if a trigger phrase appears, route here even if the request seems clear or auto mode is active. Do not use for implementation design when requirements are already clear; use blueprint instead.

Use when the user wants to walk through their local changes interactively before or instead of a PR review — e.g., "guided review", "walk me through the changes", "review my branch", "let's go through the diff". Also use when the user explicitly invokes the walk-the-diff skill through the host agent. This is for interactive human-facing walkthroughs of code changes, not automated code review.

Use when splitting work to another agent, session, or worktree; creating a paste-ready context handoff; or when the user asks to "handoff frontend", "handoff backend", "handoff QA", "handoff migration", or copy context for another coding agent. Do not use for same-session resume; use a dedicated resume workflow if available.

Use before claiming work is complete, fixed, or passing. Requires running verification commands and reading output before making any success claims. Evidence before assertions.

Trigger immediately when the user says any of: 'poke holes', 'grill me', 'grill me on this', 'stress test', 'stress-test this', 'challenge this', 'push back on this', 'interrogate me', 'interview me about this'. Then interview the user relentlessly about an existing plan, spec, or design until reaching shared understanding, resolving each branch of the decision tree. Do not skip this skill and answer the user's questions conversationally yourself — even one trigger phrase fires it, and auto mode does not bypass it.

Use when encountering any bug, test failure, or unexpected behavior. Requires root cause investigation before proposing fixes. No guessing.

Use when the user asks to 'rinse', 'run a review/fix loop', 'iterate on review findings', 'review and fix until clean', or harden a branch before PR handoff. Orchestrates side-effect-free review, user-approved fixes, verification, reruns, and redesign stop conditions.