carinyaparc

Instance bootstrap interview — detects existing instance state, guides repo creation (link-first), interviews business identity/services/cadence/targets, writes config/instance.json and target skeletons, then hands off to brand-creative setup. Use on first install, when the user says "set up my instance" or "bootstrap my agency workspace", or to re-check target bindings after config changes.

Create a competitive analysis brief for product strategy, feature prioritization, or sales enablement. Use when comparing competitors, mapping a feature area across rivals, or drafting battle cards. Do NOT use for user research synthesis (synthesize-research) or product strategy doc (product).

Run a weekly, monthly, or quarterly metrics review: scorecard, trends, bright spots, concerns, and recommended actions. Use when investigating a spike or drop, comparing performance against targets, or preparing a metrics readout. Do NOT use for stakeholder status updates (stakeholder-update) or product strategy (product).

Sparring partner for exploring a problem space, generating solutions, or stress-testing product thinking. Conversation, not a deliverable. Use when ideating, assumption-testing, or strategy exploration before a spec. Do NOT use for writing specs (write-spec) or product strategy doc (product).

Write a weekly or monthly status for leadership, announce a launch, escalate a risk, or tailor the same progress for exec, engineering, partner, customer, or board audiences. Use when drafting status updates or launch notes. Do NOT use for product strategy (product) or roadmap updates (roadmap).

Synthesize interview notes, survey data, or support tickets into themes, personas, opportunity areas, and roadmap recommendations. Use when turning raw research into structured findings. Do NOT use for competitive analysis (competitive-brief) or product strategy doc (product).

Turn a feature idea or problem statement into a structured feature spec or PRD with user stories, requirements, and success metrics. Use when drafting a PRD, feature spec, or requirements doc. Do NOT use for product strategy doc (product), epic task breakdown (tasks), or roadmap phasing (roadmap).

Review content seed PRs for on-page SEO — titles, meta descriptions, heading structure, keyword usage, and internal linking. Use when reviewing seed JSON or draft content before merge. Produces PR review comments only. Do NOT use for technical site audits (technical-seo-audit) or drafting content (draft-post).

Web development practice setup interview — detects or creates .agency/target.json binding, reads instance profile from `/agency-hub:setup`, interviews tech stack, deployment platform, connectors, and persona preference (six engineering personas vs merged), writes practice profile. Use on first install after `/agency-hub:setup`, when the user says "set up web development" or "bind target repo", or to redo engineering defaults only.

Use when the user wants to run a Ralph loop: an autonomous, self-referential delivery loop that drives a whole epic through implement, code review, fix, UX review, validate, commit, and merge request, one task per iteration, until a completion promise is emitted (ralph setup, ralph start), or to inspect or stop a running loop (ralph status, ralph cancel). Also supports simple ad-hoc loops that repeat a single prompt until done. Do NOT use to implement a single task once (implement), review a diff (code-review), or sign off an epic (validate) — the loop orchestrates those skills.

Use when the user wants a UX/design review of implemented UI — frontend components, pages, or flows — against the design source of truth (Figma via MCP, mockups, tokens, or style guide, whatever the repo provides), covering design fidelity, accessibility (WCAG 2.2 AA), interaction states, responsiveness, and design-system conformity; or to address UX review findings (ux-design-review fix, optionally scoped to an action tier). Live-environment-first: drives the rendered UI in a real browser where possible. Works with any framework or design tooling. Do NOT use for code correctness/security review (code-review), to review a design.md document (design), or to implement features (implement).

Use when the user is the reviewer of a merge request or pull request and wants it reviewed and the verdict published to the provider — inline comments on the right lines, threads resolved or replied to, and an approve / request-changes / comment decision. Handles first reviews and re-review rounds after the author pushes. Works with any codebase and any git provider — GitHub, GitLab, or Bitbucket — using MCP tools where available, provider CLIs otherwise. Do NOT use to review your own working diff before opening an MR (code-review), to open or babysit an MR (merge-request), or to implement changes (implement).

Use when the user wants to open a merge request or pull request for the current branch (merge-request create — the default — with a generated title, description, labels, and reviewer suggestions), or to babysit an open MR/PR to a merge-ready state (merge-request babysit) by watching CI, review comments, and merge conflicts. Works with any codebase and any git provider — GitHub, GitLab, or Bitbucket — using MCP tools where available, provider CLIs otherwise, and plain git as a last resort. Do NOT use to review code or an MR as its reviewer (code-review, merge-request-review) or to implement changes (implement).

Use when the user wants a code review of a branch, PR, or diff against its acceptance criteria and declared scope (whatever form they take in this repo), or to address review feedback without changing behaviour (code-review fix, optionally scoped to a blocking or warning action tier). Works with any language, delivery process, or issue tracker. Do NOT use to implement code, sign off completion of a larger body of work, or review rendered UI/UX (design fidelity, accessibility — use ux-design-review).

Use when the user wants to implement a task in code against approved design.md and .agency/work/{epic}/tasks.md. Do NOT use for code review (code-review), address review feedback (code-review fix), writing tasks (tasks), or design (design write).

Use when the user wants to write, review, or refine the product backlog, decompose delivery into epics, set Now-phase scope, or manage epic rows (e.g. CHK01). Default artefact .agency/backlog.md. Do NOT use for business strategy or PRD (product), phase exit criteria (roadmap), Gherkin tasks (tasks), epic design.md (design), architecture (solution), sprint retro (sprint), or pre-sprint doc alignment (docs). Task breakdown per epic lives at .agency/work/{epic}/ via tasks.

Use when the user wants to research, review, or enhance an agent skill on a regular cadence — weekly skill uplift, audit a SKILL.md against best practice, compare with popular external skills, fix working issues, or align with agentskills.io. Triggers on "review this skill", "enhance the X skill", "weekly skills review", "uplift this skill", "align with agentskills.io". Works on one skill or a batch. Do NOT use to create a skill from scratch (create-skill / author a new skill), route which skill to use (skills-index), or review product documentation (docs-review).

Use when the user wants ADR register planning, writing ADR-NNNN files, or ADR review under docs/architecture/decisions/. Triggers on "do we need an ADR", "write ADR-0007", "record this decision", "what decisions need making", "harvest ADRs from this epic". Do NOT use for full architecture narrative (solution), epic design (design), or product strategy (product). Proposals stay in register.md only until accepted.

Use to groom an existing backlog or judge whether a breakdown is ready to commit to — reprioritise, split oversized epics or stories, re-estimate, defer misaligned items, and check sprint readiness of docs/product/backlog.md or docs/work/{epic}/tasks.md. Triggers on "groom the backlog", "refine the backlog", "is this sprint-ready", "are these stories ready", "reprioritise", "this epic is too big", "clean up the backlog". Amends in place and reports a verdict. Do NOT use to create a backlog or write new stories and tasks (tasks), plan a sprint (sprint-planning), review a finished sprint (sprint-retro), or verify an epic against its acceptance criteria (validate).

Use when the user wants to address, action, or fix findings from a code review — their own working diff reviewed by code-review, a reviewer's comments on a PR or MR, or a pasted list of issues. Triggers on "fix the review findings", "address the review feedback", "action the blocking issues", "apply the review comments". Optionally scoped to an action tier (blocking, warning, all). Makes targeted, behaviour-preserving changes, runs the project's validation suite, and commits in logical units. Do NOT use to perform a review (code-review), to implement new work or features (implement), to address UX or design-fidelity findings (ux-design-review), or to open a PR/MR (merge-request).

Use when the user wants a code review of a branch, PR, MR, or working diff against its acceptance criteria and declared scope, in whatever form they take in this repo. Triggers on "review my branch", "review this PR", "check this diff before I raise it", "is this ready to merge". Works with any language, delivery process, or issue tracker. Produces a structured verdict with blocking, warning, and suggestion findings; writes no source changes. Do NOT use to address or fix review findings (code-review-fix), to implement work (implement), to publish a review to a provider as its reviewer (merge-request-review), to sign off completion of a larger body of work (validate), or to review rendered UI (ux-design-review).

Use when the user wants epic-level technical design at docs/work/{epic}/design.md, walking-skeleton or TDD design, or design review before tasks. Pass epic slug or ID (CHK01). Cite solution.md — do not re-narrate architecture. Triggers on "design CHK01", "write the epic design", "how should we build this epic", "review the design before tasks". Do NOT use for epics or stories (tasks), task Gherkin (tasks), system-wide architecture (solution), ADR write (adr), code implementation (implement), or reviewing a set of documents for quality and consistency (docs-review).

Use when the user wants a set of documents reviewed — a docs folder, a wiki, a handbook, a repo's markdown, or any collection of written material. Checks that each document is well written and well structured, that boundaries between documents are clear with no duplication, and that the set is consistent and cohesive. Triggers on "review the docs", "are these docs any good", "is our documentation consistent", "do these docs overlap", "audit the documentation". Works on any doc set in any format or tool. Read-only: produces a report and changes nothing. Do NOT use to write or amend a document, to review code (code-review), or to review rendered UI (ux-design-review).

Use when the user wants to implement a task in code against an approved design.md and docs/work/{epic}/tasks.md. Triggers on "implement CHK01-01", "build this task", "write the code for this story". Reads the design and acceptance criteria, writes code and tests, runs the project's full validation suite, and commits in logical units. Do NOT use for code review (code-review), addressing review feedback (code-review-fix), changing how existing UI looks or behaves (ux-design-fix), writing tasks (tasks), or writing a design (design).