@starlein/paperclip-plugin-company-wizard 0.2.1

package/templates/modules/pr-review/docs/pr-conventions.md

@@ -0,0 +1,78 @@
+# PR Conventions
+
+## Branch Naming
+
+```
+<prefix>-<N>/<short-description>
+```
+
+Where `<prefix>` is the company issue prefix (lowercase) and `<N>` is the issue number.
+
+Examples: `yes-6/add-auth-endpoint`, `yes-12/fix-game-loop`
+
+## PR Title
+
+Use Conventional Commits format:
+
+```
+<type>: <short description>
+```
+
+Types: `feat`, `fix`, `docs`, `chore`, `refactor`, `test`, `perf`
+
+Rules: lowercase after colon, no period, under 72 chars.
+
+## PR Body Template
+
+```markdown
+## What changed
+<Brief description of the changes>
+
+## Why
+<Motivation and context>
+
+## How to test
+<Steps to verify the changes>
+
+## Related
+Closes [PREFIX-N]
+```
+
+## Labels
+
+Apply one primary label: `feature`, `bug`, `docs`, `chore`, `infra`, `agent`.
+
+## Review Workflow
+
+Two-role review via @-mention on the originating issue:
+
+1. **Engineer** opens PR on GitHub
+2. **Engineer** sets originating issue to `in_review`
+3. **Engineer** @-mentions @Code Reviewer and @Product Owner on the issue with PR link
+4. **Code Reviewer** reviews for correctness, security, code style, simplicity
+5. **Product Owner** reviews for intent match, scope discipline, acceptance criteria, roadmap alignment
+6. Both reviewers post their verdict on the issue
+7. **Engineer** merges when both approve, sets issue to `done`
+
+## Review Roles
+
+- **Code Reviewer**: Correctness, security, style, simplicity. Uses `gh pr review`.
+- **Product Owner**: Intent alignment, scope discipline, acceptance criteria. Posts review as PR comment.
+- **UI Designer** *(when present)*: Visual consistency, brand compliance, accessibility, design token usage.
+- **UX Researcher** *(when present)*: Usability, user flow integrity, cognitive load, error handling UX.
+- **QA Engineer** *(when present)*: Test coverage, edge cases, regression risk, boundary conditions.
+- **DevOps Engineer** *(when present)*: Infrastructure impact, security, performance, rollback safety.
+
+## Merge Rules
+
+- Code Reviewer and Product Owner must approve (required)
+- Other reviewers provide advisory feedback — blocking only for their domain-critical issues (e.g., security for DevOps, accessibility for UI Designer)
+- CI must pass
+- No force pushes
+- Merge using `gh pr merge <number> --merge`
+- Engineer is the merge owner — reviewers never merge
+
+## Dev Cycle Rules
+
+**Requires PR**: code logic, APIs, DB schema, agent configs, infrastructure
+**Direct-to-main OK**: typos, comment-only changes, minor doc fixes (must reference issue)

package/templates/modules/pr-review/module.meta.json

@@ -0,0 +1,24 @@
+{
+  "name": "pr-review",
+  "description": "Enforces pull request reviews through branch protection. Activates additional reviewers based on the roles present in the team.",
+  "requires": [
+    "github-repo"
+  ],
+  "activatesWithRoles": [
+    "engineer",
+    "code-reviewer",
+    "product-owner",
+    "ui-designer",
+    "ux-researcher",
+    "qa",
+    "devops"
+  ],
+  "capabilities": [],
+  "issues": [
+    {
+      "title": "Set up branch protection and PR requirements",
+      "assignTo": "engineer",
+      "description": "Configure the GitHub repository with branch protection on main: require PR reviews, disable direct pushes. Verify the PR workflow works with a test branch."
+    }
+  ]
+}

package/templates/modules/release-management/agents/engineer/skills/release-process.fallback.md

@@ -0,0 +1,18 @@
+# Skill: Release Process (Fallback)
+
+DevOps primarily owns the release process. You are the fallback — step in only if DevOps is absent.
+
+## Release Process (Fallback)
+
+1. If no `docs/RELEASE-PROCESS.md` exists and DevOps hasn't started:
+   - Check the project for existing versioning (git tags, package.json version)
+   - Document the current state in `docs/RELEASE-PROCESS.md`
+   - If no process exists, set up basic semver + CHANGELOG.md
+   - Mark the document as **provisional** — it needs DevOps review for CI integration and rollback procedures
+2. If DevOps is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Document what exists and set up the basics.
+- Skip CI/CD release automation — that requires DevOps expertise.
+- Don't configure deployment targets or rollback infrastructure — leave that to DevOps.

package/templates/modules/release-management/module.meta.json

@@ -0,0 +1,25 @@
+{
+  "name": "release-management",
+  "description": "Defines and tracks the release process: versioning, changelogs, and deployment checklists.",
+  "requires": [
+    "github-repo"
+  ],
+  "capabilities": [
+    {
+      "skill": "release-process",
+      "owners": [
+        "devops",
+        "engineer",
+        "ceo"
+      ],
+      "fallbackSkill": "release-process.fallback"
+    }
+  ],
+  "issues": [
+    {
+      "title": "Document or establish release process",
+      "assignTo": "capability:release-process",
+      "description": "Review the current release workflow. If one exists, document it in docs/RELEASE-PROCESS.md. If not, establish a semver + changelog workflow with tagging conventions."
+    }
+  ]
+}

package/templates/modules/release-management/skills/release-process.md

@@ -0,0 +1,45 @@
+# Skill: Release Process
+
+You are responsible for managing the release lifecycle — versioning, changelogs, tagging, and rollback procedures.
+
+## Steps
+
+1. **Assess current state** — Check if the project already has:
+   - A versioning scheme (package.json version, git tags, etc.)
+   - A CHANGELOG.md or release notes history
+   - A release branch strategy or tag-based releases
+   - CI/CD release automation (GitHub Actions release workflow, etc.)
+
+2. **Establish or document the release process** in `docs/RELEASE-PROCESS.md`:
+   - **Versioning** — Semantic Versioning (MAJOR.MINOR.PATCH). Document what constitutes each level.
+   - **Changelog** — Keep a CHANGELOG.md following Keep a Changelog format. Update it with every release.
+   - **Tagging** — Tag releases as `vX.Y.Z`. Tags trigger release workflows if CI is configured.
+   - **Release workflow:**
+     1. Ensure all PRs for the release are merged
+     2. Update version in package manifest
+     3. Update CHANGELOG.md with release notes
+     4. Commit: `chore: release vX.Y.Z`
+     5. Tag: `git tag vX.Y.Z`
+     6. Push: `git push origin main --tags`
+   - **Rollback** — Document how to revert a bad release (revert commit + patch release, or redeploy previous tag).
+
+3. **Execute releases** when the codebase reaches a release-worthy state:
+   - Compile changelog entries from merged PRs and closed issues since last release
+   - Bump version according to the nature of changes
+   - Create the release commit and tag
+   - Create a GitHub Release with notes: `gh release create vX.Y.Z --notes "..."`
+
+## Ongoing
+
+On each heartbeat:
+1. Check if unreleased changes have accumulated — review commits since last tag.
+2. If significant changes exist without a release, flag it or initiate a release.
+3. Ensure CHANGELOG.md stays up to date with merged work.
+
+## Rules
+
+- Never release with failing tests or CI. Verify the build passes before tagging.
+- One version bump per release. Don't skip versions.
+- Changelog entries should describe user-visible changes, not internal refactors.
+- Rollback procedures must be tested — don't document a rollback you haven't verified.
+- Coordinate with the team before major version bumps — breaking changes need communication.

package/templates/modules/security-audit/agents/devops/skills/security-review.fallback.md

@@ -0,0 +1,17 @@
+# Skill: Security Review (Fallback)
+
+The Security Engineer owns security review above you. You are the fallback — step in if the Security Engineer is absent.
+
+## Security Review (Fallback)
+
+1. If no `docs/SECURITY-REVIEW.md` exists and the Security Engineer hasn't started:
+   - Audit infrastructure config: Dockerfiles, CI/CD pipelines, cloud IAM, secrets management
+   - Check deployment security: TLS, security headers, network policies
+   - Document in `docs/SECURITY-REVIEW.md`
+   - Tag the Security Engineer to expand with application-layer review
+2. If the Security Engineer is active, skip this entirely.
+
+## Rules
+
+- Focus on infrastructure and deployment security — that's your domain.
+- Let the Security Engineer own comprehensive code-level reviews.

package/templates/modules/security-audit/agents/devops/skills/threat-model.fallback.md

@@ -0,0 +1,17 @@
+# Skill: Threat Model (Fallback)
+
+The Security Engineer owns threat modeling above you. You are the fallback — step in if the Security Engineer is absent.
+
+## Threat Model (Fallback)
+
+1. If no `docs/THREAT-MODEL.md` exists and the Security Engineer hasn't started:
+   - Map the infrastructure attack surface: exposed ports, network boundaries, cloud IAM
+   - Identify deployment-specific risks: container escapes, supply chain, CI/CD pipeline security
+   - Document in `docs/THREAT-MODEL.md`
+   - Tag the Security Engineer to expand with application-layer analysis
+2. If the Security Engineer is active, skip this entirely.
+
+## Rules
+
+- Focus on infrastructure and deployment threats — that's your domain.
+- Let the Security Engineer own the full threat model.

package/templates/modules/security-audit/agents/engineer/skills/security-review.fallback.md

@@ -0,0 +1,17 @@
+# Skill: Security Review (Fallback)
+
+The Security Engineer and DevOps own security review above you. You are the last-resort fallback — step in only if both are absent or haven't performed the review.
+
+## Security Review (Fallback)
+
+1. If no `docs/SECURITY-REVIEW.md` exists and the Security Engineer hasn't started:
+   - Run `npm audit` (or equivalent) and document critical CVEs
+   - Check for obvious issues: hardcoded secrets, missing input validation, permissive CORS
+   - Document in `docs/SECURITY-REVIEW.md`
+   - Tag the Security Engineer or DevOps to expand the review
+2. If the Security Engineer or DevOps is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Focus on the most obvious vulnerabilities.
+- Let the Security Engineer own comprehensive security reviews.

package/templates/modules/security-audit/agents/engineer/skills/threat-model.fallback.md

@@ -0,0 +1,17 @@
+# Skill: Threat Model (Fallback)
+
+The Security Engineer and DevOps own threat modeling above you. You are the last-resort fallback — step in only if both are absent or haven't delivered the analysis.
+
+## Threat Model (Fallback)
+
+1. If no `docs/THREAT-MODEL.md` exists and the Security Engineer hasn't started:
+   - Write a brief security overview: main attack surfaces, obvious risks
+   - Focus on the OWASP Top 10 most relevant to the project
+   - Document in `docs/THREAT-MODEL.md`
+   - Tag the Security Engineer or DevOps to expand and maintain the model
+2. If the Security Engineer or DevOps is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Keep it focused on the highest-impact risks.
+- Let the Security Engineer own ongoing security analysis.

package/templates/modules/security-audit/module.meta.json

@@ -0,0 +1,36 @@
+{
+  "name": "security-audit",
+  "description": "Runs a threat model and security review of the codebase. Identifies vulnerabilities before they ship.",
+  "capabilities": [
+    {
+      "skill": "threat-model",
+      "owners": [
+        "security-engineer",
+        "devops",
+        "engineer"
+      ],
+      "fallbackSkill": "threat-model.fallback"
+    },
+    {
+      "skill": "security-review",
+      "owners": [
+        "security-engineer",
+        "devops",
+        "engineer"
+      ],
+      "fallbackSkill": "security-review.fallback"
+    }
+  ],
+  "issues": [
+    {
+      "title": "Conduct initial threat model",
+      "assignTo": "capability:threat-model",
+      "description": "Identify attack surfaces, trust boundaries, and data flows using STRIDE methodology. Document the threat model in docs/THREAT-MODEL.md with risk ratings and mitigation recommendations."
+    },
+    {
+      "title": "Perform initial security review",
+      "assignTo": "capability:security-review",
+      "description": "Audit the codebase for OWASP Top 10 vulnerabilities, dependency CVEs, secrets exposure, and configuration issues. Document findings in docs/SECURITY-REVIEW.md with severity ratings."
+    }
+  ]
+}

package/templates/modules/security-audit/skills/security-review.md

@@ -0,0 +1,25 @@
+# Skill: Security Review
+
+You own security code review for the project. This catches vulnerabilities in the codebase.
+
+## Security Review Process
+
+1. Review the codebase systematically, checking for:
+   - **Injection**: SQL injection, command injection, XSS, template injection
+   - **Authentication**: Weak auth flows, missing MFA, session management issues
+   - **Authorization**: Missing access controls, privilege escalation, IDOR
+   - **Data exposure**: Leaked secrets, verbose errors, unnecessary data in responses
+   - **Dependencies**: Known CVEs in dependencies (`npm audit` or equivalent)
+   - **Configuration**: Missing security headers, permissive CORS, debug mode in production
+2. Document in `docs/SECURITY-REVIEW.md`:
+   - **Findings** with severity (Critical/High/Medium/Low), location, and evidence
+   - **Recommendations** for each finding with specific fix guidance
+   - **Dependency report** with CVE details
+3. Create follow-up issues for Critical and High findings
+4. Record summary in your daily notes
+
+## Rules
+
+- Be specific. Include file paths, line numbers, and reproduction steps.
+- Always pair a finding with a recommended fix.
+- Flag secrets exposure as Critical — these need immediate action.

package/templates/modules/security-audit/skills/threat-model.md

@@ -0,0 +1,22 @@
+# Skill: Threat Model
+
+You own threat modeling for the project. This identifies security risks before they become vulnerabilities.
+
+## Threat Modeling Process
+
+1. Review the system architecture — if `docs/ARCHITECTURE.md` exists, use it as the starting point. Otherwise, analyze the codebase structure directly.
+2. Document in `docs/THREAT-MODEL.md`:
+   - **System overview**: Components, data flows, trust boundaries
+   - **Attack surfaces**: Entry points, APIs, user inputs, external integrations
+   - **Threats (STRIDE)**: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
+   - **Risk ratings**: Likelihood x Impact = Risk (Critical/High/Medium/Low)
+   - **Mitigations**: Recommended controls for each threat
+3. Create follow-up issues for Critical and High risks:
+   - `POST /api/companies/{companyId}/issues` with specific remediation tasks. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+4. Record summary in your daily notes
+
+## Rules
+
+- Focus on realistic threats, not theoretical edge cases.
+- Prioritize by risk, not by quantity. Five Critical findings beat fifty Low ones.
+- Update the threat model when architecture changes significantly.

package/templates/modules/stall-detection/README.md

@@ -0,0 +1,27 @@
+# Module: stall-detection
+
+Adds periodic stall detection to the CEO heartbeat.
+
+## What it adds
+
+- **CEO skill**: Stall check — detects issues stuck in `in_progress` or `in_review` for too long, and nudges the responsible agent or escalates.
+
+## How it works
+
+On every heartbeat, the CEO checks:
+1. Are there issues in `in_progress` or `in_review` that haven't been updated recently?
+2. If an issue appears stalled (no activity for a configurable period):
+   - Check if the assigned agent is running or idle
+   - If idle: @-mention the agent on the issue to re-trigger
+   - If the agent has been nudged before without response: escalate to the board
+3. This catches failed handovers where an @-mention didn't trigger a wake.
+
+## Best for
+
+- Any team using @-mention-based handover (which can be unreliable)
+- Multi-agent teams where work can get dropped between agents
+- Ensuring nothing falls through the cracks
+
+## Example
+
+An engineer finishes a PR and @-mentions the Code Reviewer, but the mention doesn't trigger a wake. The CEO detects the stalled issue on the next heartbeat and re-mentions the reviewer or escalates.

package/templates/modules/stall-detection/agents/ceo/heartbeat-section.md

@@ -0,0 +1,12 @@
+## Stall Detection Check
+
+After handling assignments and before exit:
+
+1. Query active issues: `GET /api/companies/{companyId}/issues?status=in_progress,in_review`
+2. For each issue, check the latest comment/activity timestamp.
+3. If an issue has had no activity for more than 2 heartbeat cycles:
+   - Agent is `idle` → @-mention with a nudge.
+   - Agent is `running` → skip (may be mid-work).
+   - Agent is `error` or `paused` → escalate to the board.
+4. If already nudged and still no progress → escalate to the board.
+5. Record stall findings in daily notes.

package/templates/modules/stall-detection/agents/ceo/skills/stall-detection.md

@@ -0,0 +1,21 @@
+# Skill: Stall Detection
+
+Add this check to your heartbeat, after handling assignments and before exit.
+
+## Stall Check
+
+1. Query active issues: `GET /api/companies/{companyId}/issues?status=in_progress,in_review`
+2. For each issue, check the latest comment/activity timestamp.
+3. If an issue has had no activity for more than 2 heartbeat cycles:
+   - Check the assigned agent's status via `GET /api/agents/{agentId}`
+   - If agent is `idle`: @-mention them on the issue with a nudge: "This issue appears stalled. Please check and continue or report blockers."
+   - If agent is `running`: skip — they may be working on it now.
+   - If agent is `error` or `paused`: escalate to the board with a comment.
+4. If you've already nudged an agent on the same issue in a previous heartbeat and there's still no progress: escalate to the board.
+5. Record stall findings in your daily notes.
+
+## Rules
+
+- Don't nudge agents that are currently running — they may be mid-work.
+- Only escalate after one failed nudge attempt.
+- When escalating, be specific: which issue, which agent, how long stalled, what was the last activity.

package/templates/modules/stall-detection/module.meta.json

@@ -0,0 +1,15 @@
+{
+  "name": "stall-detection",
+  "description": "Detects when issues go stale or agents get stuck. Prompts the CEO to unblock work automatically.",
+  "capabilities": [],
+  "routines": [
+    {
+      "title": "Stall detection",
+      "description": "Check all in_progress issues for signs of stalling. Nudge assigned agents, escalate if blocked for >24h.",
+      "assignTo": "ceo",
+      "schedule": "0 9,14 * * 1-5",
+      "priority": "medium",
+      "concurrencyPolicy": "skip_if_active"
+    }
+  ]
+}

package/templates/modules/tech-stack/agents/ceo/skills/tech-stack.fallback.md

@@ -0,0 +1,16 @@
+# Skill: Tech Stack Evaluation (Fallback)
+
+The Engineer primarily owns technology decisions. You are the fallback — step in only if no engineer has addressed tech stack decisions.
+
+## Tech Stack Evaluation (Fallback)
+
+1. If no `docs/TECH-STACK.md` exists and no engineer has started:
+   - Make pragmatic default choices based on the project type
+   - Document in `docs/TECH-STACK.md` with clear rationale
+   - Create an issue for the engineer to review and refine the choices
+2. If an engineer is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Choose sensible defaults, not optimal solutions.
+- Let the engineer own and refine the actual decisions.

package/templates/modules/tech-stack/docs/tech-stack-template.md

@@ -0,0 +1,28 @@
+# Tech Stack
+
+## Chosen Stack
+
+| Layer       | Technology | Version | Notes |
+|-------------|-----------|---------|-------|
+| Language    | _..._     | _..._   | _..._ |
+| Framework   | _..._     | _..._   | _..._ |
+| Database    | _..._     | _..._   | _..._ |
+| Hosting     | _..._     | _..._   | _..._ |
+| CI/CD       | _..._     | _..._   | _..._ |
+
+## Rationale
+
+_Why each choice was made._
+
+## Trade-offs
+
+_What was considered and rejected, and why._
+
+## Key Dependencies
+
+| Package | Purpose | License |
+|---------|---------|---------|
+| _..._   | _..._   | _..._   |
+
+---
+_Generated by Clipper. Fill in during tech-stack task._

package/templates/modules/tech-stack/module.meta.json

@@ -0,0 +1,21 @@
+{
+  "name": "tech-stack",
+  "description": "Documents the technology choices for the project: languages, frameworks, infrastructure, and rationale.",
+  "capabilities": [
+    {
+      "skill": "tech-stack",
+      "owners": [
+        "engineer",
+        "ceo"
+      ],
+      "fallbackSkill": "tech-stack.fallback"
+    }
+  ],
+  "issues": [
+    {
+      "title": "Evaluate and document technology choices",
+      "assignTo": "capability:tech-stack",
+      "description": "Assess technology options for the project based on goals, constraints, and team capabilities. Document decisions, trade-offs, and rationale in docs/TECH-STACK.md."
+    }
+  ]
+}

package/templates/modules/tech-stack/skills/tech-stack.md

@@ -0,0 +1,25 @@
+# Skill: Tech Stack Evaluation
+
+You own technology decisions. Evaluate options and document choices that align with the project goals and constraints.
+
+## Tech Stack Evaluation Process
+
+1. Review the company goal, project requirements, and architecture constraints
+2. For each technology layer (language, framework, database, infra, etc.):
+   - List viable options
+   - Evaluate against criteria: team familiarity, ecosystem maturity, performance, cost
+   - Document the decision and rationale
+3. Write the complete tech stack to `docs/TECH-STACK.md`:
+   - **Chosen stack**: Technology per layer with version
+   - **Rationale**: Why each choice was made
+   - **Trade-offs**: What was considered and rejected, and why
+   - **Dependencies**: Key libraries and their purposes
+4. Create setup issues if needed:
+   - `POST /api/companies/{companyId}/issues` for initial project scaffolding. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+
+## Rules
+
+- Prefer boring technology over bleeding edge unless the goal demands it.
+- Document trade-offs honestly — future team members need to understand constraints.
+- Consider the team's existing capabilities when choosing.
+- If a decision requires board input (e.g., paid services), create an approval request.

package/templates/modules/triage/agents/ceo/skills/issue-triage.fallback.md

@@ -0,0 +1,19 @@
+# Skill: Issue Triage (Fallback)
+
+The Product Owner or Engineer primarily owns issue triage. You are the fallback — step in only if they are absent or haven't triaged recently.
+
+## Issue Triage (Fallback)
+
+1. Check for untriaged GitHub issues: `gh issue list --state open --label ""`
+2. If issues are piling up without responses:
+   - Classify each as bug, feature, question, or invalid
+   - Respond with a brief acknowledgment
+   - Create Paperclip tasks for actionable items with priority set
+   - Close duplicates and invalid issues with explanation
+3. If the Product Owner or Engineer is active and triaging, skip this entirely.
+
+## Rules
+
+- This is a safety net. Keep responses brief but respectful.
+- Focus on P0/P1 issues first — lower priority can wait for the primary owner.
+- Don't make product decisions on feature requests — just acknowledge and create the task.

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

@@ -0,0 +1,25 @@
+{
+  "name": "triage",
+  "description": "Triages open GitHub issues: classifies, prioritizes, closes noise, and converts actionable items to Paperclip tasks.",
+  "requires": [
+    "github-repo"
+  ],
+  "capabilities": [
+    {
+      "skill": "issue-triage",
+      "owners": [
+        "product-owner",
+        "engineer",
+        "ceo"
+      ],
+      "fallbackSkill": "issue-triage.fallback"
+    }
+  ],
+  "issues": [
+    {
+      "title": "Triage all open GitHub issues",
+      "assignTo": "capability:issue-triage",
+      "description": "Review all currently open issues on the GitHub repository. Classify each by type and priority, respond to reporters, close duplicates and invalid issues, and convert actionable items into Paperclip tasks."
+    }
+  ]
+}

package/templates/modules/triage/skills/issue-triage.md

@@ -0,0 +1,42 @@
+# Skill: Issue Triage
+
+You are responsible for processing inbound GitHub issues — classifying, responding, and converting them into actionable work.
+
+## Triage Process
+
+Run this on every heartbeat, after handling your own assignments.
+
+1. **Fetch new issues** — `gh issue list --state open --label "" --json number,title,body,labels,createdAt` to find untriaged issues (no classification label yet).
+2. **For each untriaged issue:**
+   a. Read the full issue body and any comments.
+   b. **Classify** by type:
+      - `bug` — Something is broken or behaves unexpectedly
+      - `feature` — New functionality request
+      - `enhancement` — Improvement to existing functionality
+      - `question` — User needs help or clarification
+      - `duplicate` — Already reported (link to original)
+      - `invalid` — Not actionable, out of scope, or spam
+   c. **Set priority** (P0–P3):
+      - P0: Production broken, data loss, security vulnerability
+      - P1: Major feature broken, blocking multiple users
+      - P2: Non-critical bug or important feature request
+      - P3: Minor issue, cosmetic, nice-to-have
+   d. **Apply labels** — `gh issue edit <number> --add-label "<type>,<priority>"`
+   e. **Respond to reporter:**
+      - Acknowledge the report
+      - Ask follow-up questions if reproduction steps are unclear (bugs)
+      - Set expectations ("we'll look into this" / "this is out of scope because...")
+      - For duplicates: link to the original issue and close
+      - For invalid: explain why and close politely
+   f. **Convert to Paperclip task** — For actionable issues (bug, feature, enhancement), create a corresponding issue in Paperclip via `POST /api/companies/{companyId}/issues` with the GitHub issue number in the description for traceability. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+
+3. **Record** what you triaged in your daily notes.
+
+## Rules
+
+- Respond to every issue. No issue should sit without acknowledgment for more than one heartbeat cycle.
+- Be respectful and constructive in responses, even for invalid or duplicate issues.
+- Don't close legitimate issues without explanation. Always comment before closing.
+- Link GitHub issues to Paperclip tasks bidirectionally — include the GitHub URL in the Paperclip issue and the Paperclip task reference in a GitHub comment.
+- If you can't classify an issue (ambiguous report), ask the reporter for clarification and label as `needs-info`.
+- Escalate P0 issues immediately — create the Paperclip task with priority `urgent` and mention it in the CEO's daily notes.

package/templates/modules/user-testing/agents/ceo/skills/user-testing.fallback.md

@@ -0,0 +1,17 @@
+# Skill: User Testing (Fallback)
+
+QA, the UX Researcher, and PO all own usability evaluations above you. You are the last-resort fallback — step in only if all three are absent or haven't started testing.
+
+## User Testing (Fallback)
+
+1. If no `docs/USER-TESTING.md` exists and no one has started:
+   - Create a basic heuristic checklist covering the core user flow
+   - Identify the top 3-5 usability concerns based on product goals
+   - Document in `docs/USER-TESTING.md`
+   - Mark all findings as **provisional** — they need validation by QA, a researcher, or PO
+2. If QA, the researcher, or PO is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Keep it brief — enough to flag obvious issues.
+- Let QA, the researcher, or PO own ongoing usability evaluation.

package/templates/modules/user-testing/agents/product-owner/skills/user-testing.fallback.md

@@ -0,0 +1,17 @@
+# Skill: User Testing (Fallback)
+
+QA and the UX Researcher primarily own usability evaluation. You are the fallback — step in only if both are absent or haven't started testing.
+
+## User Testing (Fallback)
+
+1. If no `docs/USER-TESTING.md` exists and no one above you has started:
+   - Create a basic test plan covering the most critical user flows
+   - Evaluate against acceptance criteria from the product roadmap
+   - Document findings in `docs/USER-TESTING.md`
+   - Mark all findings as **provisional** — they need validation by QA or a researcher
+2. If QA or the researcher is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Focus on acceptance criteria and business-critical flows.
+- Let QA own systematic testing and the researcher own user-centered evaluation.