Executes a feature's tasks.md against its designs, producing working, tested, committed code — the construction step of the per-feature loop. Runs after detailed-design and ui-design, autonomously: one task at a time in order, each task's done-when demonstrated by actually running it (tests pass, migrations apply), committed per task, until every task including the final verification task is checked. Tests are written per task in the project's established frameworks and are never weakened, skipped, or edited to pass. Diverging reality escalates to the design's amendment path — the skill implements the design; it never quietly redesigns. Bounded fix attempts per task (default 3); a blocked task stops with an honest WIP state, never a fake green. Use per feature, after its technical-design.md and ui-design.md exist. Trigger on "implement this feature", "implement the next feature", "execute the tasks", "build FEAT-N", or "continue the implementation". Scope: this feature only — no drive-by refactors.
Produces the per-feature technical design — the first skill in the construction loop, run once for each vertical slice as it reaches the front of the implementation plan. Reads the feature's spec from the plan, the FR/UC IDs it implements, the architecture's conceptual domain model and ADRs, and the live codebase (contracts and schema earlier features already established), then designs the feature concretely: API contracts (endpoints, request/response shapes, error codes), the physical schema changes (migrations — architecture owns the conceptual model; new entities escalate to an architecture amendment, never local invention), component-level design, acceptance criteria, and an ordered tasks.md breaking the feature into implementable tasks. Use after project-scaffolding, per feature, before ui-design and implementation. Trigger on "design this feature", "detailed design for", "design the API for this feature", "create the technical design", or "design the next feature". Hands contracts to ui-design.
The independent auditor that closes the per-feature loop. Runs after feature-implementation declares a feature developer-done, and answers without the implementer's investment: does this feature actually satisfy its requirements? Audits the acceptance tests against the criteria (coverage per criterion, assertions that assert what the criterion says — rejecting and correcting weak tests), re-runs all suites fresh from the repo state, verifies requirements directly beyond the tests (FR behavior observed, binding NFRs measured), and reviews the feature's test diff for weakened or skipped tests. Delivers a verdict — accepted, rework, or design defect (each routed to its owner) — writes the feature's acceptance report, and on acceptance appends the RTM's Test ref, completing each requirement's lifecycle. Never fixes production code; corrects only test artifacts. Trigger on "verify the feature", "acceptance verification", "audit FEAT-N", "is the feature really done", or "run acceptance".
Runs the requirements-engineering phase — the first SDLC step, upstream of design. Through a thorough, area-by-area interview it elicits and specifies the complete requirements for a new application, proactively enumerating the standard sub-requirements for each capability area (for authentication: sign-up, sign-in, verification, password reset, logout) plus all non-functional requirements. Produces a structured SRS (ISO/IEC/IEEE 29148 lineage) in markdown, a separate use-case document in markdown, and a requirements traceability matrix. Also amends a finalized SRS — adding, updating, or removing requirements with stable IDs. Use at the start of a project before architecture and UX, or when changing existing requirements. Trigger on "gather requirements", "write an SRS", "requirements engineering", "specify the requirements", "add a requirement", or "update the requirements". Saves progress incrementally so long sessions can resume.
Turns the pipeline's design documents into a running system. Reads the architecture document and implementation plan, executes each ecosystem's current official project generator to create the real repo structure (one deployable unit per architecture container, monorepo by default), wires the walking skeleton end-to-end — UI shell with the design system's tokens.json, API, domain stub, local database — stands up the engineering foundations (CI, environments, test harness, deployment config written but not executed), and verifies empirically by building and running the skeleton test. Deploy-ready, not deployed. Use after implementation-planning and before per-slice work, when the plan's walking skeleton needs to become a real repo. Trigger on "scaffold the project", "set up the repo", "create the project structure", "build the walking skeleton", "initialize the codebase", or "stand up the skeleton". Checkpoints progress and resumes safely — never regenerates over a partial scaffold.
Designs the software architecture for a new application, service, or major feature through a structured interview, then produces an architecture document (arc42-style, with C4 diagrams in Mermaid and Architecture Decision Records). Use this whenever the user is starting a greenfield system or a significant new feature and would benefit from thinking through structure, quality attributes, tech stack, and trade-offs before writing code. Trigger on phrases like "design the architecture for", "I'm building a new app", "help me architect", "set up a new project/service", "what should the architecture be", "create an architecture doc/diagram", or any greenfield system-design discussion — even when the user does not say the word "architecture" explicitly but is clearly about to start building something new. If an SRS (docs/srs.md) exists, it designs from those requirements and NFRs, interviewing only for gaps. Prefer this skill over answering from memory whenever real architectural trade-offs are in play.
Designs the screens — the presentation half of each feature's low-level design, sibling to detailed-design. Runs in three modes: anchor (right after ux-foundations, designing 2-3 key screens to validate the design system before features build on it), per-feature (the construction loop — after detailed-design, designing that feature's SCR screens against its contracts), and re-verification (after a design.md amendment). Resolves strategy per screen: picks up screens that already exist in a connected design tool (Figma, Claude Design, Figma Make, Open Design, or any design tool), otherwise falls back per project policy to code-native specs or generation. Emits one uniform contract — docs/design-manifest.json keyed on SCR IDs — that downstream implementation reads regardless of which tool or strategy produced each screen. Trigger on "design the screens", "design anchor screens", "design this feature's UI", "ui design for", or "register the Figma designs". Screens conform to design.md or escalate — never fork it.
Establishes the UX and design foundations for an application before feature work begins — the "architecture of the UI." Consumes the upstream SRS (docs/srs.md) and architecture document (docs/architecture.md) when present, then builds the design system from one of four user-chosen source modes: research a new direction, extract from reference images, ingest an existing design file, or pull from a connected design tool (e.g., Figma via MCP). Produces docs/ux-foundations.md (personas, IA, navigation, flows, screen inventory per surface), docs/design.md (agent-ready design system: tokens, components, states, layout and usage rules), and tokens.json (W3C DTCG). Use in the design phase, after architecture and before implementation planning, for any application with one or more UI surfaces. Trigger on "design the UX foundations", "set up the design system", "what should the UI look like", "plan the screens and navigation", or "create the design language".