forsonny/leyline

using-leyline

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

design-driven-development

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…

deep-discovery

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…

writing-skills

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…

accessibility-verification

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…

brainstorming

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…

design-brainstorming

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.

design-interrogation

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…

dispatching-parallel-agents

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…

executing-plans

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…

finishing-a-development-branch

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…

receiving-code-review

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.

receiving-design-review

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…

requesting-code-review

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…

requesting-design-review

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,…

subagent-driven-development

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…

systematic-debugging

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…

test-driven-development

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…

using-git-worktrees

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.

verification-before-completion

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…

writing-plans

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…