Product & Design Skills

Architects new features through the full lifecycle. Use when designing, planning, implementing, or extending features. Triggers on 'new feature', 'design', 'plan', 'implement', 'architect', 'prd', 'spec'.

Use when acting as Agentry's conductor — routing a task to the least sufficient shape (one-shot / spec-first / decompose+verify), dispatching specialist subagents, gating approvals with the user, and sequencing a build end-to-end. Loaded by the /agentry:go front door.

Use when designing or fixing a user interface — establishing visual hierarchy, layout and spacing, typography, color and contrast, accessibility (WCAG contrast, keyboard, focus, labels), responsive behavior, interaction states, or consistency with an existing design system, and verifying the rendered result. Loaded for UI/UX and product-design work, not for backend or non-visual tasks.

Use when writing or changing code to satisfy a defined boundary — building a feature slice inside a Task contract, fixing a bug, wiring logic into files a task owns, or making a clean bounded edit. Covers both building new code and debugging existing code (the fixing mode). Loaded for code-writing work, not for design, decomposition, or review.

Use when assembling completed work and verifying the whole product against the Spec's acceptance criteria as observed end-to-end behavior — catching the "every task passed individually but the product is broken" integration gap. Loaded for the final whole-product check across the seams where independently-built tasks meet, not for verifying a single task or unit.

Use when investigating a genuine unknown — a question that can't be answered from what's already known and must be checked against current sources: a library/framework/API's current behavior or version, an external standard or best practice, a "how does X actually work" question spanning the web and the codebase, or any floating claim that needs verification before work depends on it. Loaded when recency or correctness of an external fact gates a decision, not for things the team already knows.

Use when verifying that work meets its acceptance criteria and is sound — checking a task or change against its spec, judging code quality, or applying a security lens (injection, authz/authn, secrets, path traversal, unsafe deserialization, SSRF). Loaded for adversarial, evidence-backed verification by someone other than the author — not for writing or fixing code.