constellation

Use when creating, editing, reviewing, or rendering software architecture or flow diagrams — C4 diagrams (system context, container, component, deployment, dynamic), sequence diagrams, request-flow visuals, or any Mermaid authoring where the rendered output must be readable. Also use when a Mermaid diagram renders with overlapping labels, parse errors, or a single-column layout, or when the user asks to "diagram the architecture", "draw the request flow", "map the sequences", or wants LucidChart-quality output from Mermaid.

Use when about to create a feature, build a component, add functionality, modify behavior, or start any new work — or when the user asks how should we, what approach, which way, explore options, design X, or spec this out. Triggers before any code, scaffold, or implementation skill runs.

Use when one request spans multiple domains (e.g. code + tests + docs + security + diagrams), has independent workstreams that could run concurrently, or is too large for a single agent in one pass — symptoms include "do all of X, Y, and Z", a multi-part review, or a task that would obviously thrash one agent's context

Use when defining product requirements, writing or updating a PRD, spec'ing out a feature, or deciding what to build — or when the user says write requirements, create a PRD, define the product, what should we build, or hands over stakeholder/engineering feedback to fold into an existing PRD. Especially for non-technical users translating a conversation into structured requirements.

Use when you want brutal, worst-case review of code resilience -- failure modes, race conditions, blast radius, and edge cases optimistic reviewers miss.

Use when reviewing code or a PR for high-confidence, real-exploitation security vulnerabilities (>80% confidence threshold, low false positives).

Use when saving or restoring agent context across sessions -- the user asks to save state, create a handoff, or pause, or the context window nears capacity; or to resume with load handoff, resume from, or continue where we left off.

Use when reviewing a pull request or diff, giving PR feedback, validating an implementation against a Jira ticket or spec, after completing a feature or task, before merging to main, or whenever you need a fresh set of eyes on changes before they ship

Use when committing, opening a PR, creating or naming a branch, resolving a merge conflict, setting up a worktree, squashing, rebasing, or wrapping up a finished branch — i.e. any hands-on git operation where the output (commit message, PR body, branch name, conflict resolution) needs to be correct.

Use when you have 2+ tasks that touch different files or subsystems and could run at the same time — e.g. several test files failing for unrelated reasons, multiple independent bugs, or parallel review/investigation work

Use when a PRD.md exists and is about to be handed to engineering, fed into a roadmap, or declared "ready"; when the user asks "is this PRD ready", "validate my requirements", or "check this PRD"; when prd-author finishes a draft or iteration; or when a PRD arrived from a stakeholder and its quality is unknown

Use when executing an implementation plan of mostly-independent tasks in the current session by delegating each task to a subagent — symptoms include an approved plan with discrete tasks, wanting to preserve controller context, or needing per-task review without human-in-the-loop between tasks

Use when encountering any bug, test failure, crash, flaky test, build failure, performance problem, or unexpected behavior — before proposing or attempting any fix; especially when a quick patch looks obvious, you are under time pressure, or a previous fix did not work.

Use when about to write or modify production code — implementing a feature, fixing a bug, changing behavior, or refactoring — before any implementation exists; also when tempted to write tests after the code, to skip tests because the code seems "too simple," to keep already-written code "as reference," or when under time pressure to ship without tests.

Use when starting any conversation - establishes how to find and invoke constellation skills before any response, including clarifying questions

Use when you have a spec, brainstorm output, or approved requirements for a multi-step task and are about to write an implementation plan or start touching code — symptoms include "let's build this", a PRD/roadmap/spec handed off, or a task too large for a single edit.

Use when a PLAN.md exists and is about to be shown to a human for approval, when finishing the Plan phase, when asked "is this plan ready" or to review/score a plan, or any time a plan would otherwise be presented without a fresh validation run

Use when you have finished a task, completed a major feature, fixed a complex bug, or are about to merge to main — any point where you would otherwise move on, commit, or open a PR without an independent review of the diff

Use when implementation is done and you must decide how to integrate the work — about to merge, push, open a PR, delete a branch, clean up a worktree, or are asked "are we done / what's next" after the last task or batch completes

Use when starting feature work that needs isolation from the current workspace, before executing an implementation plan, or before dispatching implementation subagents — symptoms include uncommitted changes you want to preserve, parallel work on multiple branches, or a plan/spec ready to implement.

Use when an approved or validated PRD exists and the next move is breaking it into phases — symptoms include a PRD handed off from Product, "turn this PRD into a plan", "create a roadmap from requirements", "decompose this into milestones", or starting a new project that needs phased sequencing before any specs or code.

Use when you have a written implementation plan to execute inline (no subagents available) — single-session execution of a plan's tasks in a repo without the fellowship/subagent harness.

Use when you receive code review feedback, PR comments, or suggested changes — from a human partner or an external reviewer — and are about to respond or implement; especially when feedback seems unclear, technically questionable, or you feel the urge to agree and start coding immediately

Use when about to claim work is complete, fixed, done, passing, or working — before committing, opening a PR, marking a task done, moving to the next task, or trusting a subagent's success report; also when you catch yourself about to write "Great!", "Perfect!", "should work", or any wording implying success