leyline

Use when starting any conversation - establishes how to find and use Leyline skills, requiring a Skill check before any response including clarifying questions.

Use when implementing any task whose "Files:" block touches a user-facing surface, before writing the code for that surface. Enforces the DRAW-BUILD-RECONCILE cycle: the UX artifact is the source of truth, the implementation instantiates it, and any divergence is resolved explicitly. An overlay during stage 5 alongside test-driven-development.

Use after the product spec is approved, before any implementation work. Pressure-tests the spec with a 100-question self-interrogation where each question builds on the previous answer. Returns critical issues, strengths, and a revised proposal. Material revisions loop back to brainstorming.

Use when authoring a new skill for the Leyline plugin, modifying an existing skill's behavior-shaping text, or adding to the testing-anti-patterns / forbidden-phrases lists. Applies TDD-for-prose - baseline pressure test without the skill, write the minimal skill text that rebuts the observed rationalizations, verify compliance, refactor against new loopholes.

Use whenever you are about to claim a user-facing surface is complete - before committing, before marking the task done, before any success claim. Requires running an accessibility check fresh in the current message and reading its output before any completion claim. An overlay during stage 5 alongside verification-before-completion.

Use when the human partner asks to build, add, change, or modify anything (features, components, functionality, behavior). Explores intent, requirements, and design before implementation. Hard-gated; nothing implements until the human partner approves the written product spec.

Use when the approved product spec touches any user-facing surface, before any implementation skill runs on that surface. Explores flows, states, accessibility, and voice. Hard-gated; nothing implements until the human partner approves the written UX spec.

Use at stage 2 after the UX spec has been approved and deep-discovery has cleared the product spec, when scope warrants dedicated UX pressure-testing. Runs a 100-question interrogation targeted at flows, state completeness, accessibility, voice, and platform appropriateness. Material revisions loop back to design-brainstorming.

Use during stage 5 execution when two or more genuinely independent problems surface at the same time, each understandable without context from the others. Dispatches one fresh subagent per problem concurrently. Not a pipeline stage; a tactical skill called from within subagent-driven-development.

Use when a committed plan exists, the harness does NOT support subagent dispatch, and the implementation is ready to begin. Executes the plan inline with human-partner checkpoints, task-by-task. Fallback to subagent-driven-development; hands off to stage 7 review on completion.

Use when implementation is complete, Stage 7 reviews are cleared, and the branch is ready to integrate. Verifies tests fresh, determines base branch, presents four options (merge local / push and PR / keep / discard), executes the chosen path, and cleans up the worktree. Pipeline terminates here.

Use when receiving code review feedback, before implementing any suggestion. Drives the READ -> UNDERSTAND -> VERIFY -> EVALUATE -> RESPOND -> IMPLEMENT response pattern one finding at a time. Blocks performative agreement and blind implementation.

Use when receiving design review feedback, before implementing any UX or accessibility suggestion. Drives the same READ -> UNDERSTAND -> VERIFY -> EVALUATE -> RESPOND -> IMPLEMENT pattern as receiving-code-review, with additional forbidden phrases that block UX-specific performative agreement and taste-based dismissal.

Use at stage 7 after all tasks complete and before merging, to verify the entire feature meets requirements. Dispatches the code-reviewer subagent with branch-level constructed context (SHAs, plan excerpt, product spec reference, review log). Per-task quality review is a separate Stage 5 path via code-quality-reviewer-prompt.md; do not invoke this skill per-task.

Use when completing any task or feature that touches a user-facing surface, before merging a branch with UX changes. Dispatches the design-reviewer subagent in parallel with requesting-code-review, with constructed context (UX spec path, surfaces touched, accessibility evidence, SHAs).

Use when a committed plan exists in the worktree, the harness supports subagent dispatch, and the implementation is ready to begin. Dispatches a fresh subagent per task (implementer, spec reviewer, code-quality reviewer, plus design reviewer when surfaces are touched). Hands off to stage 7 review on completion.

Use when any bug, test failure, or unexpected behavior surfaces, before proposing or applying any fix. Enforces four sequential phases (root cause investigation, pattern analysis, hypothesis formation, verification) and blocks fix proposals until root cause is identified. An overlay during stage 5.

Use when implementing any feature, bug fix, refactor, or behavior change, before any production code is written. Enforces RED-GREEN-REFACTOR. The failing test is written first, observed failing for the right reason, then the minimal code that passes is written. An overlay on every stage-5 code task.

Use when starting feature work that needs isolation from the current workspace, or before executing implementation plans. Creates an isolated git worktree with systematic directory selection and a green-baseline test gate. Runs after Interrogate, before Plan.

Use whenever you are about to claim that work is complete, fixed, or passing - before committing, creating a PR, or reporting status. Requires running the verification command fresh in the current message and reading its output before any claim is made. An overlay during stage 5 and every handoff in the pipeline.

Use when you have approved specs and a clean worktree with a green baseline, before any code is written. Decomposes the specs into 2-5 minute tasks with exact file paths, complete code, and verification. Runs inside the worktree from stage 3; hands off to subagent-driven-development or executing-plans.