beislid

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.

Break an approved spec/PRD 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 finds work too large for one coherent PR.

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

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.

Use when the user asks for 'fresh eyes', 'one last review', 'final review pass', 'whole diff review', or a post-fix pre-ship 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.

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 continue-work if available.

Use when a PR has received review comments that need fixing, when QA has left feedback on a ticket, or when the user wants to address any kind of post-submission feedback on their work. Trigger phrases include "heard chef", "address feedback", "fix PR comments", "handle review", "handle QA feedback". Also trigger when the user mentions unresolved review threads, changes requested on a PR, QA comments to address, or a ticket bouncing back from review or testing. This is the response-to-feedback skill — if someone reviewed or tested the user's code and left comments, this is the skill to use. Do NOT use when the user wants to write reviews, start new work (use kickoff), or create a PR (use ship-it). Reads project config from `<repo>/.beislid/workflow.md` and probes capabilities lazily as needed.

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`.

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 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.

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

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 shipping. Orchestrates side-effect-free review, user-approved fixes, verification, reruns, and redesign stop conditions.

Configure Beislið project config (`.beislid/workflow.md`) interactively. Use when the user says "setup", "/setup", "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.

Use when the user says "ship it", "ready to PR", "let's ship", "open a PR", "create PR", "commit and push", "commit the changes and push", or when implementation is complete and it's time to push code for review. This is the bookend to kickoff. For new PRs, it takes a completed feature branch through quality gates, review, fresh-eyes, and PR creation. For existing PR updates, it runs gates, pushes, and reports the PR URL; review is skipped unless invoked manually first. Do NOT use for mid-implementation commits or for work that isn't ready for review. Reads project config from `<repo>/.beislid/workflow.md` and probes capabilities lazily as needed.

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.

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 before claiming work is complete, fixed, or passing. Requires running verification commands and reading output before making any success claims. Evidence before assertions.

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.