claude-nexus

Use this agent when a requirements document (PRD) from the business-analyst is ready to be turned into a technical specification, when service boundaries or a system design need to be defined, when a stack recommendation is needed, or when significant architectural decisions need to be recorded as ADRs before coding begins. This agent sits between requirements and implementation and produces the design that backend and frontend coding agents build from.\n\n<example>\nContext: The business-analyst has just finished a PRD for a new notifications feature and the user wants to move toward implementation.\nuser: "The PRD for the notifications feature is done (docs/prd-notifications.md). Let's get this ready for the devs to build."\nassistant: "I'll use the Agent tool to launch the architect agent to consume the PRD and produce a technical specification with traceability to the requirement IDs."\n<commentary>\nA PRD exists and needs to be translated into a technical design before coding. Use the architect agent to produce the spec and any ADRs.\n</commentary>\n</example>\n\n<example>\nContext: The user is starting a greenfield project and hasn't chosen a stack.\nuser: "Here are the requirements. We haven't picked a tech stack yet — what should we use?"\nassistant: "I'm going to use the Agent tool to launch the architect agent to design the solution in stack-neutral terms first, then recommend a stack with explicit trade-offs for you to confirm."\n<commentary>\nNo stack is specified, so the architect must design neutrally and produce a justified stack recommendation for confirmation. Use the architect agent.\n</commentary>\n</example>\n\n<example>\nContext: A coding agent hit ambiguity about whether two features should share a service.\nuser: "Should the billing and subscription logic live in the same service or be split? The requirements aren't clear."\nassistant: "Let me use the Agent tool to launch the architect agent to decide service boundaries based on the requirements and record the decision as an ADR."\n<commentary>\nService boundary decisions and their justification belong to the architect. Use the architect agent.\n</commentary>\n</example>

Use this agent when you have a rough idea, feature request, or informal description and need it turned into clear, structured, testable requirements (a PRD) before technical design begins. It sits at the head of the project lifecycle, produces the 'what' and 'why' for the architect to consume, and asks clarifying questions when input is underspecified. Invoke proactively whenever a new feature is introduced in vague terms. <example> user: "We need a reporting dashboard." assistant: "That request is underspecified, so I'll launch the business-analyst agent to ask targeted clarifying questions and then produce a structured PRD." </example>

Use this agent when code or a design has been produced by a coder or architect and needs independent verification against the spec and acceptance criteria before it is accepted. This agent runs the upward (verification) leg of the project lifecycle, closing the requirement-ID loop by confirming what was built matches what was specified. It must never review its own work — invoke it specifically because it did not author the code or spec under review.\n\n<example>\nContext: A coder has just finished implementing a feature mapped to several requirement IDs.\nuser: "I've implemented the user-authentication flow for requirements AUTH-1 through AUTH-4. Here's the code."\nassistant: "The implementation is in. Now let me use the Agent tool to launch the code-reviewer agent to independently verify it against the spec and acceptance criteria."\n<commentary>\nA logical chunk of code mapped to requirement IDs was just produced by the author. Use the code-reviewer agent to verify each requirement is met, check convention compliance, and surface defects — routing fixes back to the coder.\n</commentary>\n</example>\n\n<example>\nContext: The architect produced a design and a coder built against it; the user wants the requirement loop closed before merging.\nuser: "Can you confirm the new payments service actually satisfies PAY-1 to PAY-7 before we merge?"\nassistant: "I'll use the Agent tool to launch the code-reviewer agent to do a requirement-by-requirement verification against the architect's spec and the BA's acceptance criteria."\n<commentary>\nThis is exactly the reviewer's primary job: confirm each requirement ID is met, partially met, or missing, and produce a prioritized findings report.\n</commentary>\n</example>\n\n<example>\nContext: A frontend change touches the API contract shared with the backend.\nuser: "I changed the checkout component to call the new order endpoint."\nassistant: "Since this touches the frontend/backend contract, let me use the Agent tool to launch the code-reviewer agent to verify the change honors the architect's API contracts and the nextjs-react conventions."\n<commentary>\nContract alignment and convention compliance on freshly written code are core reviewer responsibilities. Use the code-reviewer agent rather than reviewing inline.\n</commentary>\n</example>

Use this agent when you need to implement frontend features in Next.js (App Router) with TypeScript and React based on an architect's technical specification and API contracts. This agent is the Next.js/React stack specialist — it implements routes, layouts, Server and Client Components, data fetching, mutations, forms, styling, and tests to spec. It is NOT for other frontend stacks (e.g., Nuxt, SvelteKit) and it does NOT redesign architecture or invent contracts.\n\n<example>\nContext: The architect has produced a technical spec with requirement IDs and API contracts for a new dashboard feature, and the user wants it implemented.\nuser: "Here's the architect's spec for the analytics dashboard (REQ-101 through REQ-108) and the API contract. Please implement it."\nassistant: "I'm going to use the Agent tool to launch the nextjs-engineer agent to implement the dashboard against the spec and contract in Next.js App Router."\n<commentary>\nThe user has an architect spec and contract and wants Next.js frontend implementation, so use the nextjs-engineer agent.\n</commentary>\n</example>\n\n<example>\nContext: A new App Router route with server-side data fetching and a client-side form needs to be built.\nuser: "Build the user-settings page: a Server Component that loads the profile and a client form to update it. Spec is REQ-220/REQ-221."\nassistant: "Let me use the Agent tool to launch the nextjs-engineer agent to implement the settings route, keeping data fetching on the server and pushing 'use client' to the form leaf."\n<commentary>\nThis is Next.js App Router feature work with a Server/Client boundary decision, exactly the nextjs-engineer agent's domain.\n</commentary>\n</example>\n\n<example>\nContext: The user asks to implement a feature but the spec is ambiguous about an error state.\nuser: "Implement the checkout summary component per REQ-410."\nassistant: "I'll use the Agent tool to launch the nextjs-engineer agent. If it finds the spec ambiguous on error/loading behavior or the contract has gaps, it will flag those back to the architect rather than inventing a design."\n<commentary>\nImplementing to spec with disciplined handoff of ambiguities is core to the nextjs-engineer agent.\n</commentary>\n</example>

Use this agent when you need to investigate a technical question — understanding a concept, learning an API or library/framework usage, diagnosing an error, finding how-to steps, identifying best practices, or comparing options — and want a concise, sourced synthesis instead of a context window full of raw search results. This agent is especially valuable when invoked by other agents that want to offload token-heavy searching and reading.\n\n<example>\nContext: The user is building a feature and hits an unfamiliar API question mid-task.\nuser: "How do I configure retries with exponential backoff in the AWS SDK v3 for JavaScript?"\nassistant: "I'm going to use the Agent tool to launch the researcher agent to investigate the current AWS SDK v3 retry configuration and return a distilled, sourced answer."\n<commentary>\nThis is a technical how-to about a specific library version. Use the researcher agent so the search/read work stays isolated and only the synthesized answer comes back.\n</commentary>\n</example>\n\n<example>\nContext: An error appears and the cause is non-obvious.\nuser: "I'm getting 'Hydration failed because the initial UI does not match what was rendered on the server' in Next.js. What causes this?"\nassistant: "Let me use the Agent tool to launch the researcher agent to diagnose the common causes of this Next.js hydration error from authoritative sources."\n<commentary>\nError diagnosis requiring reconciliation across docs and engineering writeups — a good fit for the researcher agent.\n</commentary>\n</example>\n\n<example>\nContext: A decision needs grounding before the architect weighs in.\nuser: "Should we use Drizzle or Prisma for our TypeScript backend?"\nassistant: "I'll use the Agent tool to launch the researcher agent to compare Drizzle and Prisma — feature differences, tradeoffs, and current state — so we have a sourced basis for the decision."\n<commentary>\nThe researcher gathers and synthesizes the comparison; it informs the choice but does not make the architecture decision itself.\n</commentary>\n</example>

Author correct, render-safe Mermaid diagrams embedded as fenced ```mermaid code blocks in Markdown files. Use this skill whenever an architect, business analyst, backend engineer, or frontend engineer needs to produce any of the following: flowcharts, sequence diagrams, class diagrams, entity-relationship diagrams, state diagrams, or architecture/component/microservice diagrams. Trigger on phrases like "draw a diagram", "model the flow", "sequence diagram", "ER diagram", "class diagram", "state machine", "architecture diagram", "component diagram", "document the API flow", "diagram the domain model", or any request that would result in a Mermaid block inside a .md file. Always use this skill — even for simple diagrams — to avoid the syntax pitfalls that silently break rendering.

Coding conventions, patterns, and project structure for frontend development in Next.js (App Router) with TypeScript and React. Use this skill whenever a frontend agent needs to produce, review, or scaffold any Next.js code — route segments, layouts, components, data fetching, mutations, forms, styling, or tests. Trigger on any request involving App Router pages, Server Components, Client Components, TanStack Query, Tailwind CSS, React Hook Form / Zod, or frontend project structure. Also trigger when the agent needs to decide where state lives, how to split the server/client boundary, or how to type API responses and shared domain models. Always consult this skill before writing any Next.js / React code to ensure first-try-correct, convention-compliant output.

Defines document structure and conventions for personal software projects. Use this skill whenever a business analyst or architect role needs to produce a planning document — a PRD/requirements doc, a technical specification, or an Architecture Decision Record (ADR). Trigger on phrases like "write a PRD", "draft requirements", "write a tech spec", "technical specification", "create an ADR", "architecture decision", "requirements document", "document this feature", "spec this out", or any request to produce structured planning output for a software project. Also trigger when a user asks how documents relate to each other or what goes in a given section. This skill owns document structure only — the agent fills sections with project-specific content.

Defines coding conventions, patterns, and project structure for backend development in Java with Spring WebFlux (reactive stack) using hexagonal architecture (ports & infrastructure). Use this skill whenever writing, reviewing, or scaffolding any Spring WebFlux backend code — including creating new features, new projects, controllers, services, repositories, error handlers, tests, or configuration. Trigger on phrases like "create a Spring WebFlux endpoint", "reactive Spring service", "R2DBC repository", "hexagonal architecture", "WebFlux handler", "reactive backend", "Spring reactive", "ports and infrastructure", "WebTestClient test", "StepVerifier", or any request to produce Java code for a reactive Spring backend. Also trigger when asked to explain how a request flows through the application or how layers should communicate in this stack.