Scoped implementation worker. Invoked by 301-spec-implementation, 302-test-implementation, and 401-cleanup to make focused code or test changes inside a bounded file set and a single phase of work. Extends existing modules before creating new ones, follows project context and installed standards skills, and leaves…
Scoped decision-making worker. Invoked by orchestrating workflows — currently 901-feature-loop's Decision Consult — wherever a fork in the road would otherwise require asking the user. Given a brief with a concrete option set and the state behind it, owns the entire consult internally: verifies load-bearing facts…
Creative UI/UX design worker. Invoked by 106-ui-design, 107-ui-experience, and 108-ui-page-design — each calls this agent multiple times in parallel (typically three, one per assigned seed bet) to get genuinely divergent, opinionated design directions, then decides among the returned candidates itself. Each call is a…
Scoped review worker. Invoked by 900-feedback-loop as the Review role to check a named artifact or change set against explicit caller-supplied criteria and return a parseable verdict. Read-only: never edits files, never fixes what it finds. Reports either a clean confirmation or a numbered list of concrete required…
Scoped validation worker. Invoked by 301-spec-implementation, 302-test-implementation, and 401-cleanup to run one validation mode at a time (test, lint, or build), capture the exact output, and return concise diagnostics without modifying code. Uses the project's existing scripts and tooling where possible, falls back…
Use 100 to establish or refresh domain knowledge before project planning or feature design. Trigger it for prompts like "100", "domain knowledge", "domain research", "industry context", or when the project needs research-backed understanding of users, workflows, terminology, regulations, or differentiators.
Use 101 to define the project's core product framing: problem, users, differentiation, and success criteria. Trigger it for prompts like "101", "project overview", "create project overview", or when a new product idea needs a structured foundation before architecture or feature work.
Use 102 to define the system architecture, stack, major components, and testing approach. Trigger it for prompts like "102", "system architecture", "architecture doc", or "define the tech stack" when the project is ready for foundational technical decisions.
Use 103 to define the conceptual data model: entities, relationships, and business rules. Trigger it for prompts like "103", "data model", "conceptual data model", "entity relationships", or when the team needs a shared domain model before implementation choices.
Use 103.5 to define the conceptual data model as GraphQL SDL instead of markdown tables — entities, relationships, business rules, access rules, and data quality rules captured in a documentation-only schema that doubles as diagram source for an interactive visualizer. Trigger it for prompts like "103.5", "graphql…
Use 104 to define the backend architecture, including API structure, service layering, data access, and security patterns. Trigger it for prompts like "104", "backend architecture", "API design", or "service layer" when backend patterns need to be specified before coding.
Use 105 to define the frontend architecture: UI structure, component boundaries, state, and development patterns. Trigger it for prompts like "105", "frontend architecture", "component structure", or "state management" when frontend patterns need to be specified before UI design.
Use 106 to establish the visual design system and UI strategy for a project. It covers the design philosophy, color system, typography, layout principles, and component visual language. Trigger it for prompts like "106", "ui design", "design system", "visual design", or "color palette" when the project needs a…
Use 107 to define the UX architecture: navigation, interaction patterns, accessibility, error handling, and the page inventory. Trigger it for prompts like "107", "user experience", "navigation design", "interaction patterns", or "information architecture" before per-page design work begins.
Use 108 to design a specific page or view in detail, including layout, mockup, interactions, and responsive behavior. Trigger it for prompts like "108", "page design", "wireframe", or "design the [page] page" when a single route or view needs a detailed design spec.
Use 110 to define and prioritize the product's feature set as concise, reviewable slices. Trigger it for prompts like "110", "feature overview", "feature list", "feature backlog", or "what features should we build" after the main project framing is in place.
Use 201 to create a concise high-level design for a specific feature. It produces the feature overview and end-to-end user journey without going into test or implementation detail. Trigger it for prompts like "201", "high-level design", "feature design", or "HLD" when a feature needs a short overview before specs or…
Use 202 to write Gherkin behavior scenarios for a feature. It produces a structured specs.feature file with coverage sized to the task. Trigger it for prompts like "202", "test spec", "gherkin", "BDD scenarios", or "write specs" when the next step is defining behavior to test.
Use 203 to produce a codebase-grounded implementation plan for a feature. It maps the needed file changes and explains how the implementation should fit the existing code. Trigger it for prompts like "203", "implementation design", "technical design", or "how do I build this" when overview and spec artifacts already…
Use 204 to validate a feature's design artifacts before implementation begins. It reviews overview.md, specs.feature, and implementation.md for gaps, inconsistencies, and missed reuse. Trigger it for prompts like "204", "validate the feature", or "implementation readiness review" before coding starts.
Use 301 to implement a substantial change through the main SpecFlow spec-driven workflow. It handles preparation, tests-first implementation, separate cleanup passes, and final validation. Trigger it for prompts like "301", "spec implementation", or "implement this feature" when the work is large enough to benefit…
Use 302 to add or repair automated tests for behavior that already exists. Choose it when the missing work is test coverage, not broad production-code changes. Trigger it for prompts like "302", "test-only implementation", "write the tests", or "add E2E coverage".
Use 401 to clean up an already-changed source scope or test scope without turning it into a broad rewrite. Trigger it for prompts like "401", "cleanup this change", "refactor the touched files", or "tidy the tests", and run it separately for source and test cleanup.
Use 402 to investigate and correct a failing automated test by deciding whether the right fix is in the test, in production code, or in the expected behavior itself. Trigger it for prompts like "402", "fix this failing test", "is this a test issue or a product bug", or "triage the failing spec".
★not rated 11 1mo agoA72 tokens
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: