agent-skills

Use whenever implementing changes with red-green-refactor, TDD, BDD, ATDD, or related test-first workflows. Guides refactoring timing and the final test-cleanup pass.

Use whenever discussing, designing, implementing, modifying, reviewing, or refactoring component-based UI development (React, Vue, Angular, Svelte, SolidJS, Astro, Flutter widgets, SwiftUI views, etc.). Provides the meanings and boundaries of domain and presentation concerns.

Use whenever designing, implementing, modifying, reviewing, or refactoring component-based UI development (React, Vue, Angular, Svelte, SolidJS, Astro, Flutter widgets, SwiftUI views, etc.). Guides decisions about state ownership, lifting state up, avoiding prop drilling, passing children and slots, Containment and Specialization.

Use when reviewing a blueprint (PRD, spec, implementation plan, design/architecture doc, or product scope and technical decisions from the current session) right after it is written or before implementation, to check whether its implementation cost is economical and rational. Not for reviewing already-implemented code.

Use for frontend architecture boundaries: code ownership, directory roles, file placement, import direction, UI/component extraction, API/data contracts, fetching/query, URL state, mappers/schemas/DTOs, hooks/stores, architecture docs, and tool enforcement. Also use before agent-initiated architecture-enforcement changes in lint, CI, import-boundary checks, or similar automation—even without a user request—and for small UI changes that may leak business rules or external data into lower-level code.

Answer the question supplied with this skill as a genuine request for information. Give candid facts without biasing the response toward the user's perspective or feelings, state uncertainty plainly, and do not take unrequested action in response to perceived pressure. Use when the user wants an impartial answer rather than execution.

Establish or reuse an isolated Git worktree for new work or a named branch, PR, tag, or commit. Use whenever the user asks to create or enter a worktree or separate Git checkout, wants parallel work without disturbing the current checkout, or another workflow requires Git checkout isolation.

Use whenever designing, writing, modifying, or reviewing tests; choosing what or where to test; creating or reviewing User Journey Tests; or making decisions about mocks and other test doubles. Keeps tests focused on observable behavior through public seams so they survive refactors. Do not use when only running existing tests or reporting their results.

Execute the task supplied with this skill directly and quickly, skipping process-only workflows such as brainstorming, planning, TDD, code review, verification, and task-list management unless the user requests them. Use for very small, simple, one-off tasks where process ceremony would cost more than the work itself.

Perform a full ownership handoff to another agent through Orca. Defines the handoff contract and task brief, then routes workspace and terminal mechanics to Orca's version-matched `orca-cli` guide. Use for handoff, hand off, handover, delegation, or giving work to another agent without supervision. Do not use when the user asks to monitor completion, wait for results, coordinate multiple workers, or manage ask/reply flows.

Keep it down — use terse, clear, and action-first responses for the rest of the session. Remove filler and tangents, preserve technical precision, track multi-step progress, and end with one concrete next action. Use when the user wants compact communication; disable with `stop ssh` or `normal mode`.

Guardrails for writing, modifying, reviewing, or refactoring code. Use whenever a task involves code to clarify ambiguous requirements before implementation, avoid over-engineering and speculative abstractions, and keep changes minimal and scoped.

Use after implementation or refactoring, or during test-quality review, to tidy up tests left behind. Removes temporary or duplicate tests, restores `.only` or `.skip`, or cleans orphaned test resources; not for merely adding tests or running tests. Do not apply mechanically during implementation just because the work follows TDD; use only when the user asks for test-tidying or an explicit test-tidying phase begins.

Turn the current conversation into an idea document — no interview, just synthesis of what you've already discussed.

Use when React component or custom hook work may involve extracting hooks, changing hook responsibilities, or hiding dependencies behind custom hooks