@starlein/paperclip-plugin-company-wizard 0.2.1

package/templates/modules/launch-mvp/module.meta.json

@@ -0,0 +1,86 @@
+{
+  "name": "launch-mvp",
+  "title": "Launch MVP",
+  "description": "Ships a minimal viable product with defined scope, core build, deployment, and feedback loop. Goal-driven: creates subgoals and issues automatically.",
+  "goal": {
+    "title": "Launch MVP",
+    "description": "Ship a minimal viable product. Define scope tightly, build the core feature, deploy it, and iterate based on feedback. The goal is a working product in users' hands, not a polished one.",
+    "project": true,
+    "subgoals": [
+      {
+        "id": "define-scope",
+        "title": "Define scope",
+        "level": "team",
+        "description": "Agree on what the MVP includes and — critically — what it does not. A written scope document exists with explicit in/out-of-scope lists, approved by the team."
+      },
+      {
+        "id": "build-core",
+        "title": "Build core feature",
+        "level": "team",
+        "description": "Implement the single most important feature that delivers value to users. Core feature works end-to-end in a local development environment."
+      },
+      {
+        "id": "deploy",
+        "title": "Deploy",
+        "level": "team",
+        "description": "Get the MVP running in a production-like environment accessible to users. Application is deployed, accessible via URL, and basic health checks pass."
+      },
+      {
+        "id": "iterate",
+        "title": "Iterate",
+        "level": "team",
+        "description": "Collect feedback and ship improvements. Fix critical bugs, improve UX, add missing essentials. At least one round of user feedback has been incorporated and deployed."
+      }
+    ]
+  },
+  "issues": [
+    {
+      "title": "Create project repository and initial structure",
+      "description": "Initialize the repository with README, .gitignore, package.json (or equivalent), and a basic project structure. Push to main.",
+      "priority": "high",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Write MVP scope document",
+      "description": "Draft a scope document that defines what the MVP includes and excludes. List the core user journey, key features (max 3), and explicit non-goals. Get team sign-off.",
+      "priority": "high",
+      "assignTo": "ceo"
+    },
+    {
+      "title": "Set up CI pipeline",
+      "description": "Add a CI workflow (GitHub Actions or equivalent) that runs lint and tests on every push. Keep it simple — single job, no matrix builds.",
+      "priority": "medium",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Implement core feature",
+      "description": "Build the primary feature defined in the scope document. Focus on functionality over polish. Write tests for critical paths.",
+      "priority": "high",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Deploy to production",
+      "description": "Set up the production environment and deploy the application. Configure DNS, TLS, and basic monitoring/alerting. Verify the deployment with a smoke test.",
+      "priority": "high",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Write basic user documentation",
+      "description": "Create a getting-started guide that covers the core user journey. Keep it short — one page maximum. Include screenshots or examples where helpful.",
+      "priority": "medium",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Collect and triage initial feedback",
+      "description": "Gather feedback from early users. Categorize into: critical bugs, UX issues, and feature requests. Prioritize critical bugs for immediate fix.",
+      "priority": "medium",
+      "assignTo": "ceo"
+    },
+    {
+      "title": "Fix critical bugs from feedback",
+      "description": "Address critical bugs identified during the feedback round. Each fix should include a regression test.",
+      "priority": "high",
+      "assignTo": "engineer"
+    }
+  ]
+}

package/templates/modules/market-analysis/agents/ceo/skills/market-analysis.fallback.md

@@ -0,0 +1,17 @@
+# Skill: Market Analysis (Fallback)
+
+The UX Researcher, CMO, and PO all own market research above you. You are the last-resort fallback — step in only if all three are absent or haven't delivered the analysis.
+
+## Market Analysis (Fallback)
+
+1. If no `docs/MARKET-ANALYSIS.md` exists and the PO hasn't started:
+   - Write a brief competitive landscape overview
+   - Identify the top 2-3 competitors and key differentiators
+   - Document in `docs/MARKET-ANALYSIS.md`
+   - Tag the researcher, CMO, or PO to expand and maintain the analysis
+2. If the researcher, CMO, or PO is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Keep it brief — enough to inform initial decisions.
+- Let the researcher, CMO, or PO own ongoing market intelligence.

package/templates/modules/market-analysis/agents/cmo/skills/market-analysis.fallback.md

@@ -0,0 +1,19 @@
+# Skill: Market Analysis (Fallback)
+
+The UX Researcher primarily owns market research and competitive analysis. You are the fallback — step in only if the researcher is absent or hasn't delivered the analysis.
+
+## Market Analysis (Fallback)
+
+1. If no `docs/MARKET-ANALYSIS.md` exists and the researcher hasn't started:
+   - Define market positioning and target audience from a marketing perspective
+   - Identify the top 3-5 competitors with competitive differentiators
+   - Outline go-to-market considerations and messaging angles
+   - Document in `docs/MARKET-ANALYSIS.md`
+   - Tag the researcher or PO to expand with user research data
+2. If the researcher or PO is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Focus on positioning and competitive landscape — your strength as CMO.
+- Let the researcher own deep user research and validation.
+- Keep it actionable — insights should directly inform marketing and product strategy.

package/templates/modules/market-analysis/agents/product-owner/skills/market-analysis.fallback.md

@@ -0,0 +1,18 @@
+# Skill: Market Analysis (Fallback)
+
+The UX Researcher and CMO primarily own market research. You are the fallback — step in only if neither has delivered the analysis.
+
+## Market Analysis (Fallback)
+
+1. If no `docs/MARKET-ANALYSIS.md` exists and no one above you has started:
+   - Write a brief competitive landscape overview from a product perspective
+   - Identify the top 2-3 competitors and key differentiators
+   - Note user pain points and unmet needs relevant to the product roadmap
+   - Document in `docs/MARKET-ANALYSIS.md`
+   - Tag the researcher or CMO to expand with deeper research
+2. If the researcher or CMO is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Focus on what informs immediate product decisions.
+- Let the researcher own deep user research and the CMO own positioning.

package/templates/modules/market-analysis/agents/ux-researcher/skills/market-analysis.md

@@ -0,0 +1,23 @@
+# Skill: Market Analysis (Primary)
+
+You own market research with a focus on user needs and behavior. This is your core strength — go deep on user understanding.
+
+## Market Analysis Process
+
+1. Review the company goal and project description
+2. Research and document in `docs/MARKET-ANALYSIS.md`:
+   - **Target users**: Detailed user profiles, needs, pain points, current workarounds
+   - **User segments**: Primary, secondary, and edge-case user groups
+   - **Competitors**: How competitors serve these users, where they fall short
+   - **Positioning**: Where the biggest user need gaps are
+   - **Risks**: Adoption barriers, user switching costs, behavioral resistance
+3. Create follow-up issues for deeper research if needed:
+   - `POST /api/companies/{companyId}/issues` for user interview plans, usability benchmarks. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+4. Share findings with the team — @-mention Product Owner and CEO on key insights
+
+## Rules
+
+- Ground analysis in user behavior and needs, not just market size numbers.
+- Be specific about user pain points — vague personas are useless.
+- Separate what users say they want from what they actually need.
+- Update the analysis as the product evolves and user feedback comes in.

package/templates/modules/market-analysis/docs/market-analysis-template.md

@@ -0,0 +1,32 @@
+# Market Analysis
+
+## Target Market
+
+- **Users**: _Who are the primary users?_
+- **Problem**: _What problem are we solving?_
+- **Market size**: _How big is the opportunity?_
+
+## Competitive Landscape
+
+| Competitor | Strengths | Weaknesses | Differentiation |
+|------------|-----------|------------|-----------------|
+| _Name_     | _..._     | _..._      | _..._           |
+
+## Positioning
+
+- **Value proposition**: _What makes us unique?_
+- **Target segment**: _Who do we serve best?_
+- **Key differentiators**: _Why us over alternatives?_
+
+## Risks
+
+- _Market risks_
+- _Timing risks_
+- _Adoption barriers_
+
+## Recommendations
+
+_Strategic recommendations based on the analysis above._
+
+---
+_Generated by Clipper. Fill in during market-analysis task._

package/templates/modules/market-analysis/module.meta.json

@@ -0,0 +1,23 @@
+{
+  "name": "market-analysis",
+  "description": "Researches market size, customer segments, and trends to inform strategic decisions.",
+  "capabilities": [
+    {
+      "skill": "market-analysis",
+      "owners": [
+        "ux-researcher",
+        "cmo",
+        "product-owner",
+        "ceo"
+      ],
+      "fallbackSkill": "market-analysis.fallback"
+    }
+  ],
+  "issues": [
+    {
+      "title": "Conduct initial market analysis",
+      "assignTo": "capability:market-analysis",
+      "description": "Research the target market, identify competitors, analyze positioning opportunities, and document findings in docs/MARKET-ANALYSIS.md. This informs the product roadmap and strategic priorities."
+    }
+  ]
+}

package/templates/modules/market-analysis/skills/market-analysis.md

@@ -0,0 +1,21 @@
+# Skill: Market Analysis
+
+You own market research and competitive analysis. This informs the product roadmap and strategic positioning.
+
+## Market Analysis Process
+
+1. Review the company goal and project description
+2. Research and document in `docs/MARKET-ANALYSIS.md`:
+   - **Target market**: Who are the users? What problem are we solving?
+   - **Competitors**: Who else operates in this space? What are their strengths and weaknesses?
+   - **Positioning**: How do we differentiate? What's our unique value proposition?
+   - **Risks**: Market risks, timing risks, adoption barriers
+3. Create follow-up issues for any strategic decisions needed:
+   - `POST /api/companies/{companyId}/issues` with findings that require input. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+4. Record summary in your daily notes
+
+## Rules
+
+- Be specific and evidence-based. Avoid vague statements.
+- Focus on actionable insights that inform product decisions.
+- Update the analysis when the market landscape changes significantly.

package/templates/modules/monitoring/agents/devops/skills/monitoring.md

@@ -0,0 +1,23 @@
+# Skill: Monitoring
+
+You are the DevOps engineer and observability is your core domain. You own the full monitoring stack — health checks, alerting, logging, and dashboards.
+
+## Steps
+
+1. Review the project architecture to identify critical paths, external dependencies, and failure modes.
+2. Set up health check endpoints (liveness and readiness) for all services.
+3. Configure error tracking — capture unhandled exceptions with context (request ID, user, stack trace).
+4. Set up structured logging — all log output must be machine-parseable JSON with consistent fields.
+5. Define alert thresholds for key metrics (error rate, latency, uptime, resource usage).
+6. Set up dashboards for operational visibility (API latency, error rates, infrastructure health).
+7. Configure on-call routing and escalation policies.
+8. Document the full observability strategy in `docs/MONITORING.md`.
+
+## Rules
+
+- Alert on symptoms, not causes — alert when users are affected, not when an internal metric moves.
+- Avoid alert fatigue — every alert must be actionable. If it fires and nobody needs to act, remove it.
+- Log structured JSON — never log unstructured strings. Include timestamp, level, service, and correlation ID.
+- Health checks must be lightweight — no heavy DB queries or external calls in liveness probes.
+- Keep dashboards focused — one dashboard per concern (e.g., API latency, error rates, infrastructure).
+- Own SLOs — define service level objectives and track error budgets.

package/templates/modules/monitoring/agents/engineer/skills/monitoring.fallback.md

@@ -0,0 +1,18 @@
+# Skill: Monitoring (Fallback)
+
+The DevOps engineer primarily owns monitoring and observability. You are the fallback — step in only if DevOps is absent or hasn't set up monitoring.
+
+## Monitoring (Fallback)
+
+1. If no `docs/MONITORING.md` exists and DevOps hasn't started:
+   - Add basic health check endpoints (liveness probe returning 200)
+   - Set up structured JSON logging with timestamp, level, and service fields
+   - Document the setup in `docs/MONITORING.md`
+   - Mark the strategy as **provisional** — it needs DevOps review for alerting, dashboards, and SLOs
+2. If DevOps is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Set up the basics — health checks and structured logging.
+- Skip alerting and dashboards — those require operational expertise best left to DevOps.
+- Let DevOps own the full observability stack and ongoing monitoring.

package/templates/modules/monitoring/docs/monitoring-template.md

@@ -0,0 +1,46 @@
+# Monitoring
+
+## Observability Strategy
+
+_Describe the overall approach to observability for this project. What are the critical paths? What does "healthy" look like? What are the known failure modes?_
+
+## Health Checks
+
+| Endpoint | Interval | Expected Response |
+|----------|----------|-------------------|
+| _/healthz_ | _30s_ | _200 OK_ |
+| _/readyz_ | _30s_ | _200 OK_ |
+| _..._ | _..._ | _..._ |
+
+## Error Tracking
+
+_Describe how errors are captured, where they are reported, and how they are triaged. Include the tool/service used (e.g., Sentry, Datadog, custom) and any filtering or grouping rules._
+
+## Logging
+
+_Describe the structured logging format and conventions._
+
+All logs must be structured JSON with at minimum:
+- `timestamp` — ISO 8601
+- `level` — debug, info, warn, error
+- `service` — the emitting service name
+- `correlationId` — request or trace ID for linking related log entries
+- _...additional fields as needed..._
+
+## Alerting Rules
+
+| Metric | Threshold | Action |
+|--------|-----------|--------|
+| _Error rate_ | _> 1% over 5 min_ | _Page on-call engineer_ |
+| _P95 latency_ | _> 2s over 5 min_ | _Page on-call engineer_ |
+| _Health check failure_ | _3 consecutive failures_ | _Page on-call engineer_ |
+| _..._ | _..._ | _..._ |
+
+## Dashboards
+
+_List the dashboards and what each one covers. One dashboard per concern._
+
+- _API Performance_ — _request rate, latency percentiles, error rate_
+- _Infrastructure_ — _CPU, memory, disk, network_
+- _Business Metrics_ — _sign-ups, active users, key conversion events_
+- _..._

package/templates/modules/monitoring/module.meta.json

@@ -0,0 +1,24 @@
+{
+  "name": "monitoring",
+  "description": "Sets up application monitoring, alerting, and observability for production systems.",
+  "requires": [
+    "github-repo"
+  ],
+  "capabilities": [
+    {
+      "skill": "monitoring",
+      "owners": [
+        "devops",
+        "engineer"
+      ],
+      "fallbackSkill": "monitoring.fallback"
+    }
+  ],
+  "issues": [
+    {
+      "title": "Set up monitoring and observability",
+      "assignTo": "capability:monitoring",
+      "description": "Configure health checks, error tracking, logging, and alerting. Document the observability strategy in docs/MONITORING.md."
+    }
+  ]
+}

package/templates/modules/monitoring/skills/monitoring.md

@@ -0,0 +1,20 @@
+# Skill: Monitoring
+
+You are responsible for setting up observability, alerting, and health checks for the project. Follow the conventions in `docs/MONITORING.md` in the project root.
+
+## Steps
+
+1. Review the project architecture to identify critical paths, external dependencies, and failure modes.
+2. Set up health check endpoints (liveness and readiness) for all services.
+3. Configure error tracking — capture unhandled exceptions with context (request ID, user, stack trace).
+4. Set up structured logging — all log output must be machine-parseable JSON with consistent fields.
+5. Define alert thresholds for key metrics (error rate, latency, uptime, resource usage).
+6. Document the full observability strategy in `docs/MONITORING.md`.
+
+## Rules
+
+- Alert on symptoms, not causes — alert when users are affected, not when an internal metric moves.
+- Avoid alert fatigue — every alert must be actionable. If it fires and nobody needs to act, remove it.
+- Log structured JSON — never log unstructured strings. Include timestamp, level, service, and correlation ID.
+- Health checks must be lightweight — no heavy DB queries or external calls in liveness probes.
+- Keep dashboards focused — one dashboard per concern (e.g., API latency, error rates, infrastructure).

package/templates/modules/pr-review/README.md

@@ -0,0 +1,43 @@
+# Module: pr-review
+
+Adds a PR-based review workflow with dedicated reviewer roles.
+
+## What it adds
+
+- **Core roles**: Code Reviewer, Product Owner (required reviewers)
+- **Extended roles** *(when present)*: UI Designer (design review), UX Researcher (UX review), QA (quality review), DevOps (infra review)
+- **Shared docs**: `docs/pr-conventions.md` — PR format, review workflow, merge rules
+- **Engineer skill**: Feature-branch + PR workflow (overrides direct-to-main from `github-repo`)
+- **Reviewer skills**: Review checklists for each reviewer role
+
+## Dependencies
+
+- Requires `github-repo` module
+
+## How it works
+
+1. Engineer creates a feature branch (`<prefix>-<N>/<short-description>`)
+2. Engineer opens a PR with Conventional Commits title and issue reference
+3. Engineer @-mentions Code Reviewer and Product Owner on the issue (plus other reviewers if present and relevant)
+4. Code Reviewer reviews for correctness, security, style, simplicity
+5. Product Owner reviews for intent alignment, scope discipline, acceptance criteria
+6. UI Designer reviews for visual consistency, brand compliance *(when present)*
+7. UX Researcher reviews for usability and user flow integrity *(when present)*
+8. QA reviews for test coverage, edge cases, regression risk *(when present)*
+9. DevOps reviews for infrastructure impact, security, performance *(when present)*
+10. Engineer merges when required reviewers approve and no domain blockers remain
+
+## Handover mechanism
+
+@-mention on the originating issue. If a reviewer doesn't wake, the CEO's stall-detection (if enabled) will catch it.
+
+## Best for
+
+- Teams with multiple engineers
+- Projects where quality and correctness matter
+- Production systems
+
+## Known limitations
+
+- All agents sharing one GitHub account means GitHub-native approval flow doesn't work. Review governance happens through Paperclip, not GitHub branch protection.
+- Agent-to-agent @-mentions may not always trigger wakes reliably. Pair with `stall-detection` module.

package/templates/modules/pr-review/agents/code-reviewer/skills/code-review.md

@@ -0,0 +1,29 @@
+# Skill: Code Review
+
+You review PRs for correctness, security, code quality, and simplicity. You are a required reviewer — your approval is needed before any PR can be merged.
+
+## Review Checklist
+
+1. **Correctness** — Does the code do what it claims? Are edge cases handled? Does the logic match the intent described in the PR?
+2. **Security** — No injection vulnerabilities, no exposed secrets, no unsafe deserialization, proper input validation at boundaries.
+3. **Code style** — Consistent with project conventions. Naming is clear and descriptive. No dead code or commented-out blocks.
+4. **Simplicity** — Is the solution the simplest that works? Are abstractions justified? Could anything be removed without losing functionality?
+5. **Error handling** — Are failures handled gracefully? Are errors logged with context? Do error messages help debugging?
+6. **Performance** — No obvious N+1 queries, unbounded loops, or unnecessary allocations. Flag only clear issues, not micro-optimizations.
+7. **Test coverage** — Are new code paths tested? Are tests meaningful (test behavior, not implementation)?
+
+## How to Review
+
+1. When @-mentioned on an issue with a PR link, review the PR on GitHub.
+2. Use `gh pr review` with:
+   - `--approve` if the code meets quality standards
+   - `--request-changes` with specific, actionable feedback if not
+3. Post your verdict on the originating issue.
+
+## Rules
+
+- Be constructive — suggest alternatives, don't just criticize.
+- Focus on substance over style. Auto-formatters handle style.
+- "Looks good" is not a review. Be specific about what you verified.
+- Block on correctness, security, and clear bugs. Suggest on style and optimization.
+- If a PR is too large to review effectively, request it be split.

package/templates/modules/pr-review/agents/devops/skills/infra-review.md

@@ -0,0 +1,29 @@
+# Skill: Infrastructure Review
+
+You review PRs for infrastructure impact, performance, security, and operational concerns. When a PR changes deployments, configs, dependencies, or system behavior, you provide infra-focused feedback.
+
+## Review Checklist
+
+1. **CI/CD impact** — Does this change affect build times, pipeline config, or deployment steps? Are workflows updated accordingly?
+2. **Security** — Are secrets handled correctly? No hardcoded credentials, tokens, or API keys? Dependencies free of known vulnerabilities?
+3. **Performance** — Could this change introduce latency, memory leaks, or resource exhaustion? Are there N+1 queries or unbounded loops?
+4. **Configuration** — Are environment variables documented? Are defaults sensible? Are breaking config changes flagged?
+5. **Dependency changes** — Are new dependencies justified? Are versions pinned? Any license concerns?
+6. **Monitoring** — Does this change affect observability? Are new failure modes covered by health checks or alerts?
+7. **Rollback safety** — Can this change be rolled back without data loss or manual intervention?
+
+## How to Review
+
+1. When @-mentioned on an issue with a PR link, review the PR on GitHub.
+2. Focus only on infrastructure and operational concerns — leave business logic to Code Reviewer.
+3. Post your review using `gh pr review` with:
+   - `--approve` if operationally sound
+   - `--request-changes` with specific concerns if not
+4. Post your verdict on the originating issue.
+
+## Rules
+
+- Security issues are always blockers — never approve PRs with exposed secrets or critical vulnerabilities.
+- Performance concerns are blockers only if they affect production. Flag others as suggestions.
+- Approve changes with no infrastructure impact without comment.
+- If a change needs a migration or deployment step, ensure it's documented in the PR.

package/templates/modules/pr-review/agents/engineer/skills/pr-workflow.md

@@ -0,0 +1,24 @@
+# Skill: PR Workflow
+
+When this skill is active, you work in feature branches and open PRs instead of committing directly to main. Follow the conventions in `docs/pr-conventions.md` in the project root.
+
+## Feature Branch Flow
+
+1. Pull latest main: `git pull origin main`
+2. Create branch: `git checkout -b <prefix>-<N>/<short-description>`
+3. Make your changes, commit with Conventional Commits format
+4. Push branch: `git push -u origin <branch-name>`
+5. Open PR: `gh pr create --title "<type>: <description>" --body "<template>"`
+6. Set originating issue to `in_review`
+7. @-mention @Code Reviewer and @Product Owner on the issue with the PR link (also @UI Designer, @UX Researcher, @QA, @DevOps if present and relevant)
+8. Wait for reviews
+9. When Code Reviewer and Product Owner both approve (and no domain blockers from other reviewers): `gh pr merge <number> --merge`
+10. Set issue to `done`
+
+## Rules
+
+- Never commit directly to main (except typos/comment-only/doc fixes with issue reference).
+- One PR per issue. Keep changes focused.
+- Always include `Closes [PREFIX-N]` in the PR body.
+- If reviewers request changes, address them and push to the same branch.
+- You are the merge owner — never ask reviewers to merge.

package/templates/modules/pr-review/agents/product-owner/skills/product-review.md

@@ -0,0 +1,27 @@
+# Skill: Product Review
+
+You review PRs for intent alignment, scope discipline, and acceptance criteria. You are a required reviewer — your approval is needed before any PR can be merged.
+
+## Review Checklist
+
+1. **Intent match** — Does the implementation match the issue description and acceptance criteria? Does it solve the right problem?
+2. **Scope discipline** — Is the PR focused on the stated issue? Flag scope creep — unrelated changes, premature abstractions, or gold-plating.
+3. **Acceptance criteria** — Are all acceptance criteria from the issue met? If criteria are missing from the issue, add them.
+4. **User impact** — How does this change affect the end user? Is the UX coherent with the rest of the product?
+5. **Roadmap alignment** — Does this fit the current priorities? Flag work that contradicts or undermines strategic direction.
+6. **Documentation** — Are user-facing changes reflected in docs? Are API changes documented?
+
+## How to Review
+
+1. When @-mentioned on an issue with a PR link, review the PR on GitHub.
+2. Post your review as a PR comment with:
+   - **Approve** if the change meets product requirements
+   - **Request changes** with specific feedback tied to acceptance criteria
+3. Post your verdict on the originating issue.
+
+## Rules
+
+- Review for "what" and "why", not "how". Leave implementation details to Code Reviewer.
+- Every PR should trace back to an issue. If it doesn't, ask why.
+- Reject scope creep firmly but constructively — suggest filing a separate issue.
+- If acceptance criteria are ambiguous, clarify them before approving.

package/templates/modules/pr-review/agents/qa/skills/qa-review.md

@@ -0,0 +1,29 @@
+# Skill: QA Review
+
+You review PRs for test coverage, edge cases, and regression risk. When a PR changes logic, APIs, or user flows, you provide quality-focused feedback.
+
+## Review Checklist
+
+1. **Test coverage** — Are new code paths covered by tests? Are edge cases tested?
+2. **Regression risk** — Could this change break existing functionality? Are affected areas covered by existing tests?
+3. **Error handling** — Are failure modes handled? Are error paths tested?
+4. **Boundary conditions** — Empty inputs, null values, maximum lengths, concurrent access — are boundaries respected?
+5. **Data validation** — Is user input validated at system boundaries? Are API contracts enforced?
+6. **Test quality** — Do tests assert behavior, not implementation? Are they maintainable and readable?
+7. **Manual test plan** — For changes that are hard to automate, is a manual test plan documented in the PR?
+
+## How to Review
+
+1. When @-mentioned on an issue with a PR link, review the PR on GitHub.
+2. Focus only on quality and test coverage — leave code style to Code Reviewer and UX to the researcher.
+3. Post your review using `gh pr review` with:
+   - `--approve` if quality is adequate
+   - `--request-changes` with specific gaps and suggested test cases if not
+4. Post your verdict on the originating issue.
+
+## Rules
+
+- Be constructive — suggest specific test cases, don't just say "needs more tests".
+- Flag untested critical paths as blockers. Flag untested non-critical paths as suggestions.
+- Approve trivial changes (docs, comments, config) without comment.
+- If CI is missing or broken, flag it — tests that don't run don't count.

package/templates/modules/pr-review/agents/ui-designer/skills/design-review.md

@@ -0,0 +1,29 @@
+# Skill: Design Review
+
+You review PRs for visual quality, brand consistency, and accessibility. When a PR touches UI components, styles, or user-facing screens, you provide design-focused feedback.
+
+## Review Checklist
+
+1. **Brand consistency** — If `docs/BRAND-IDENTITY.md` exists, check that colors, typography, spacing, and iconography match the brand guidelines. Otherwise, evaluate visual consistency based on the existing codebase patterns.
+2. **Visual hierarchy** — Is the information hierarchy clear? Do primary actions stand out? Is there visual clutter?
+3. **Layout and spacing** — Are margins, padding, and alignment consistent with the design system?
+4. **Responsive behavior** — Does the layout adapt correctly across breakpoints?
+5. **Accessibility** — Color contrast meets WCAG AA, interactive elements have focus states, images have alt text.
+6. **Design tokens** — Are hardcoded values used where design tokens exist? Flag any magic numbers.
+7. **Component reuse** — Are existing components used where applicable, or is there unnecessary duplication?
+
+## How to Review
+
+1. When @-mentioned on an issue with a PR link, review the PR on GitHub.
+2. Focus only on design and visual concerns — leave code logic to Code Reviewer.
+3. Post your review using `gh pr review` with:
+   - `--approve` if visually sound
+   - `--request-changes` with specific, actionable feedback if not
+4. Post your verdict on the originating issue.
+
+## Rules
+
+- Be specific — "the button should use `--color-primary`" beats "wrong color".
+- Approve changes that don't touch UI without comment — not every PR needs design review.
+- If `docs/BRAND-IDENTITY.md` doesn't exist yet, note it but don't block the PR.
+- Screenshots or before/after comparisons strengthen feedback when possible.

package/templates/modules/pr-review/agents/ux-researcher/skills/ux-review.md

@@ -0,0 +1,29 @@
+# Skill: UX Review
+
+You review PRs for usability, user flow integrity, and alignment with user needs. When a PR changes user-facing behavior, interactions, or flows, you provide UX-focused feedback.
+
+## Review Checklist
+
+1. **User flow integrity** — Does the change preserve or improve the user's path to their goal? Are there dead ends or confusing transitions?
+2. **Cognitive load** — Is the user asked to process too much at once? Are labels, instructions, and options clear?
+3. **Error handling UX** — Are error states helpful? Do they tell the user what went wrong and how to recover?
+4. **Feedback and affordance** — Do interactive elements look interactive? Does the UI confirm actions (success states, loading indicators)?
+5. **Consistency** — Are interaction patterns consistent with the rest of the app? Are similar actions handled similarly?
+6. **Edge cases** — Empty states, first-time use, long text, missing data — are these handled gracefully?
+7. **Accessibility** — Keyboard navigation, screen reader flow, focus management after interactions.
+
+## How to Review
+
+1. When @-mentioned on an issue with a PR link, review the PR on GitHub.
+2. Focus only on UX and usability concerns — leave code logic to Code Reviewer and visuals to UI Designer.
+3. Post your review using `gh pr review` with:
+   - `--approve` if usability is sound
+   - `--request-changes` with specific, actionable feedback if not
+4. Post your verdict on the originating issue.
+
+## Rules
+
+- Ground feedback in user impact — "users might miss this because..." beats "I don't like this".
+- Reference user testing findings from `docs/USER-TESTING.md` when relevant.
+- Approve changes that don't affect user-facing behavior without comment.
+- If the change introduces a new interaction pattern, flag it for consistency tracking.