@starlein/paperclip-plugin-company-wizard 0.2.1

package/templates/modules/auto-assign/module.meta.json

@@ -0,0 +1,27 @@
+{
+  "name": "auto-assign",
+  "description": "Automatically assigns unowned backlog items to available agents. Keeps work flowing without manual dispatch.",
+  "permissions": [
+    "tasks:assign"
+  ],
+  "capabilities": [
+    {
+      "skill": "auto-assign",
+      "owners": [
+        "product-owner",
+        "ceo"
+      ],
+      "fallbackSkill": "auto-assign.fallback"
+    }
+  ],
+  "routines": [
+    {
+      "title": "Auto-assign unassigned issues",
+      "description": "Find unassigned todo issues and assign to the best available agent based on role and workload.",
+      "assignTo": "capability:auto-assign",
+      "schedule": "0 9,13 * * 1-5",
+      "priority": "medium",
+      "concurrencyPolicy": "skip_if_active"
+    }
+  ]
+}

package/templates/modules/auto-assign/skills/auto-assign.md

@@ -0,0 +1,23 @@
+# Skill: Auto-Assign
+
+You own issue assignment. Match issues to the right agents based on skills and availability.
+
+## Assignment Check
+
+Run this on every heartbeat, after handling your own assignments.
+
+1. Query idle agents: `GET /api/companies/{companyId}/agents?status=idle`
+2. Query unassigned todo issues: `GET /api/companies/{companyId}/issues?status=todo&unassigned=true`
+3. For each idle agent that matches the issue requirements:
+   - Pick the highest-priority unassigned issue
+   - Assign it: `PATCH /api/issues/{id}` with `assigneeAgentId`
+   - The agent will wake on the assignment trigger
+4. Record assignments in your daily notes.
+
+## Rules
+
+- Match issues to agents by role/capabilities. Don't assign code tasks to non-engineering agents.
+- Assign one issue at a time per agent. Don't overload.
+- If no suitable match exists, leave the issue unassigned and note it.
+- Respect agent budget. Don't assign to agents near their budget limit.
+- Prioritize unblocking over optimization — a good-enough assignment now beats a perfect one later.

package/templates/modules/backlog/README.md

@@ -0,0 +1,26 @@
+# Module: backlog
+
+Owns the product backlog lifecycle — from goal decomposition to a steady pipeline of actionable issues.
+
+## What it adds
+
+- **Backlog health skill**: Monitors unassigned issue count and generates new issues from the roadmap when the pipeline runs low.
+- **Process doc**: `backlog-process.md` — shared workflow guide for how issues flow from goals to agents.
+
+## How it works
+
+On every heartbeat, the backlog owner checks the issue pipeline:
+1. Count unassigned issues with status `todo`
+2. If count < threshold (default: 3), decompose the next chunk of work from the goal/roadmap into concrete issues
+3. New issues are created with proper `projectId`, `goalId`, priority, and acceptance criteria. For top-level backlog issues, never omit `projectId`.
+4. Issues are left unassigned for the auto-assign module (or manual assignment)
+
+## Ownership
+
+- **Primary**: Product Owner — owns backlog health, prioritization, and issue quality
+- **Fallback**: CEO — creates minimal issues to keep engineers unblocked when PO is absent
+
+## Best for
+
+- Any company that wants a steady pipeline of work without manual issue creation
+- Keeps engineers fed with work continuously

package/templates/modules/backlog/agents/ceo/heartbeat-section.md

@@ -0,0 +1,10 @@
+## Backlog Health Check (Fallback)
+
+Only if the Product Owner is absent or stalled:
+
+1. Query unassigned issues: `GET /api/companies/{companyId}/issues?status=todo&unassigned=true`
+2. If fewer than 1 unassigned issue AND PO hasn't acted recently:
+   - Create 1-2 high-priority issues from the roadmap to keep engineers unblocked.
+   - Attach `labelIds` — fetch via `GET /api/companies/{companyId}/labels`. If none exist, create defaults first (see `backlog-health` skill).
+   - Tag the PO to take over backlog grooming.
+3. If the PO is active and backlog has 1+ issues, skip this step.

package/templates/modules/backlog/agents/ceo/skills/backlog-health.fallback.md

@@ -0,0 +1,20 @@
+# Skill: Backlog Health (Fallback)
+
+The Product Owner primarily manages the backlog pipeline. You are the fallback — step in only if the PO is absent, stalled, or the backlog is critically empty.
+
+## Backlog Health Check (Fallback)
+
+On your heartbeat, after handling assignments:
+
+1. Query unassigned issues: `GET /api/companies/{companyId}/issues?status=todo&unassigned=true`
+2. If fewer than 1 unassigned issue remains AND the Product Owner hasn't acted recently:
+   - Create 1-2 high-priority issues from the roadmap to keep engineers unblocked
+   - Attach `labelIds` — fetch available labels via `GET /api/companies/{companyId}/labels`. If no labels exist yet, create the defaults (see `backlog-health` skill for the label table) before creating issues.
+   - Comment on the issue tagging the Product Owner to take over backlog grooming
+3. If the Product Owner is active and the backlog has 1+ issues, skip this step.
+
+## Rules
+
+- This is a safety net, not your primary job. Let the PO own it.
+- Only create issues when engineers would otherwise have nothing to work on.
+- Keep it minimal — just enough to unblock, not a full grooming session.

package/templates/modules/backlog/agents/product-owner/heartbeat-section.md

@@ -0,0 +1,15 @@
+## Backlog Health Check
+
+After handling your own assignments:
+
+1. Query unassigned issues: `GET /api/companies/{companyId}/issues?status=todo&unassigned=true`
+2. If fewer than 3 unassigned issues remain:
+   - Review the company goal and current progress.
+   - Identify the next logical chunk of work from the roadmap.
+   - Create 3-5 new issues via `POST /api/companies/{companyId}/issues`, making sure each payload includes the correct `projectId`.
+   - Each issue needs: `title`, `description`, `priority`, `projectId`, `goalId`, `labelIds`.
+   - Use the active roadmap project's `projectId`. Do not leave top-level backlog issues projectless.
+   - Fetch labels once per session: `GET /api/companies/{companyId}/labels`. If none exist, create them first (see `backlog-health` skill).
+   - Write clear acceptance criteria. Leave issues unassigned.
+   - Only create subissues for independently deliverable slices. Do not split tightly coupled implementation across sibling subissues.
+3. Record what you generated in daily notes.

package/templates/modules/backlog/docs/backlog-process.md

@@ -0,0 +1,62 @@
+# Backlog Process
+
+The product backlog is the single source of work for all agents. This document defines how issues flow from company goals to agent assignments.
+
+## Lifecycle
+
+```
+Goal → Roadmap → Issues → Assignment → Execution → Done
+```
+
+1. **Goal decomposition** — The backlog owner breaks the company goal into milestones, then milestones into actionable issues.
+2. **Issue creation** — New issues enter the backlog via `POST /api/companies/{companyId}/issues` with `title`, `description`, `priority`, `projectId`, `goalId`, and `labelIds`. Top-level backlog issues must always include the active roadmap `projectId`.
+3. **Pipeline health** — The backlog owner monitors unassigned issue count. When fewer than 3 remain, the next batch is generated from the roadmap.
+4. **Assignment** — Issues are left unassigned at creation. Assignment happens separately (auto-assign module or manual).
+5. **Execution** — Agents check out assigned issues, work them, and mark done.
+
+## Issue Quality
+
+Every issue should be:
+
+- **Small** — completable in a single agent session
+- **Actionable** — clear what "done" looks like
+- **Independent** — minimal blocking dependencies on other issues
+- **Prioritized** — `priority` field reflects roadmap order and urgency
+- **Labeled** — at least one label from the company's label set via `labelIds`
+
+### Acceptance Criteria
+
+Write acceptance criteria in the issue description. Engineers use these to validate their work before marking done. Keep them concrete and testable.
+
+## Sources of Issues
+
+Issues can enter the backlog from multiple sources:
+
+- **Backlog owner** — primary source, decomposes roadmap into issues
+- **Other modules** — architecture-plan, user-testing, market-analysis, etc. may create follow-up issues from their workflows
+- **Engineers** — may create sub-issues or bug reports during execution
+- **CEO** — fallback issue creation when backlog owner is absent
+
+All sources use the same API and issue format. The backlog owner is responsible for overall health and prioritization, not for being the only creator.
+
+## Prioritization
+
+- **P0** — Blocking other work or critical path. Do first.
+- **P1** — Important for current milestone. Do soon.
+- **P2** — Valuable but not urgent. Do when capacity allows.
+- **P3** — Nice to have. Backlog buffer.
+
+Re-prioritize when milestones shift or new information arrives. Don't let low-priority issues accumulate indefinitely — archive or cancel stale ones.
+
+## Backlog Health Indicators
+
+- **Healthy**: 3+ unassigned issues in `todo`, covering the next logical chunk of work
+- **Thin**: 1-2 unassigned issues — generate more soon
+- **Empty**: 0 unassigned issues — engineers will idle. Generate immediately.
+- **Bloated**: 20+ unassigned issues — stop creating, focus on prioritization and cleanup
+
+## Coordination
+
+- The backlog owner coordinates with the CEO on strategic priorities when unclear.
+- If the goal is fully decomposed and all issues are done or in progress, report completion to the CEO rather than inventing new work.
+- When multiple agents create issues (e.g., from user-testing findings), the backlog owner reviews and re-prioritizes as needed.

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

@@ -0,0 +1,53 @@
+# Product Backlog
+
+_This is the living backlog for the company. The backlog owner maintains this document alongside the issue tracker._
+
+## Current Milestone
+
+**Milestone:** _(name of the current milestone from the roadmap)_
+**Status:** _(on track / at risk / blocked)_
+**Target:** _(what "done" looks like for this milestone)_
+
+## Roadmap
+
+Break the company goal into milestones. Each milestone is a coherent chunk of value that can be delivered and validated.
+
+| # | Milestone | Status | Key Deliverables |
+|:--|:----------|:-------|:-----------------|
+| 1 | _(name)_ | _(planned / active / done)_ | _(what ships)_ |
+| 2 | | | |
+| 3 | | | |
+
+## Issue Labels
+
+These categories must exist as Paperclip labels. Create them via `POST /api/companies/{companyId}/labels` with `{ "name": "...", "color": "..." }` before creating your first issues. Attach labels to every issue via `labelIds`.
+
+| Label | Color | Use for |
+|:------|:------|:--------|
+| feature | `0075ca` | New user-facing capability |
+| bug | `d73a4a` | Defect or regression |
+| chore | `7057ff` | Refactoring, cleanup, dependency updates |
+| spike | `006b75` | Research or investigation with a time-box |
+| blocked | `e4e669` | Cannot proceed, needs unblocking |
+
+Add more labels as the project evolves (e.g., `docs`, `design`, `security`). Pick distinct hex colors. Fetch existing labels: `GET /api/companies/{companyId}/labels`.
+
+## Backlog Snapshot
+
+_Summary of current backlog health. Update on each heartbeat cycle._
+
+- **Unassigned todo issues:** _(count)_
+- **In-progress issues:** _(count)_
+- **Health:** _(healthy / thin / empty / bloated — see backlog-process.md)_
+
+## Decisions Log
+
+Record significant backlog decisions so context isn't lost:
+
+| Date | Decision | Rationale |
+|:-----|:---------|:----------|
+| | | |
+
+## Notes
+
+_(Anything relevant to backlog strategy: deferred items, external dependencies, scope changes, feedback from other agents.)_

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

@@ -0,0 +1,31 @@
+{
+  "name": "backlog",
+  "description": "Monitors and maintains backlog health. Surfaces stale issues and blocked work so the queue stays actionable.",
+  "capabilities": [
+    {
+      "skill": "backlog-health",
+      "owners": [
+        "product-owner",
+        "ceo"
+      ],
+      "fallbackSkill": "backlog-health.fallback"
+    }
+  ],
+  "issues": [
+    {
+      "title": "Create roadmap and generate initial backlog",
+      "assignTo": "capability:backlog-health",
+      "description": "Review the company goal, create a ROADMAP.md with milestones, then generate the first batch of actionable issues from it."
+    }
+  ],
+  "routines": [
+    {
+      "title": "Backlog grooming",
+      "description": "Ensure backlog has at least 3 actionable unassigned issues. If running low, generate new issues from the roadmap.",
+      "assignTo": "capability:backlog-health",
+      "schedule": "0 10 * * 1,3,5",
+      "priority": "medium",
+      "concurrencyPolicy": "skip_if_active"
+    }
+  ]
+}

package/templates/modules/backlog/skills/backlog-health.md

@@ -0,0 +1,47 @@
+# Skill: Backlog Health
+
+You own the product backlog pipeline.
+
+## Label Setup
+
+Before creating your first batch of issues, set up labels for the company:
+
+1. Check existing labels: `GET /api/companies/{companyId}/labels`
+2. If no labels exist, create them via `POST /api/companies/{companyId}/labels` with `{ "name": "...", "color": "..." }`:
+
+| Label | Color | Use for |
+|:------|:------|:--------|
+| feature | `0075ca` | New user-facing capability |
+| bug | `d73a4a` | Defects and regressions |
+| chore | `7057ff` | Refactoring, cleanup, dependency updates |
+| spike | `006b75` | Research or investigation with a time-box |
+| blocked | `e4e669` | Cannot proceed, needs unblocking |
+
+Add additional labels if the roadmap calls for them (e.g., `docs`, `design`, `security`). Pick distinct hex colors.
+
+## Backlog Health Check
+
+Run this on every heartbeat, after handling your own assignments.
+
+1. Query unassigned issues: `GET /api/companies/{companyId}/issues?status=todo&unassigned=true`
+2. If fewer than 3 unassigned issues remain:
+   - Review the company goal and current progress
+   - Identify the next logical chunk of work from the roadmap
+   - Create 3-5 new issues via `POST /api/companies/{companyId}/issues`, making sure each payload includes the correct `projectId`
+   - Each issue must have: `title`, `description`, `priority`, `projectId`, `goalId`, `labelIds`
+   - Use the current roadmap project's `projectId`; never create top-level backlog issues with `projectId: null`
+   - Fetch label IDs once per session: `GET /api/companies/{companyId}/labels`
+   - Write clear acceptance criteria in the description
+   - Leave issues unassigned — assignment happens separately
+3. Record what you generated in your daily notes.
+
+## Rules
+
+- Don't create duplicate issues. Check existing issues before creating new ones.
+- Keep issues small and actionable. Each should be completable in a single agent session.
+- Split into subissues only when each child can be completed, tested, and merged independently in its own isolated workspace.
+- Do not split tightly coupled implementation work across sibling subissues (same core code path/file cluster changed together). Keep coupled work in one issue, or sequence it explicitly so later work starts only after the prerequisite issue is done.
+- Set priority based on roadmap order and dependencies.
+- Always attach at least one label to every issue you create.
+- If the goal is fully decomposed into issues, don't create more. Report to the CEO instead.
+- Coordinate with the CEO on strategic priorities when unclear.

package/templates/modules/brand-identity/agents/ceo/skills/brand-identity.fallback.md

@@ -0,0 +1,19 @@
+# Skill: Brand Identity (Fallback)
+
+The UI Designer and CMO both own brand identity above you. You are the last-resort fallback — step in only if neither has addressed brand guidelines.
+
+## Brand Identity (Fallback)
+
+1. If no `docs/BRAND-IDENTITY.md` exists and no designer has started:
+   - Set up a minimal brand placeholder with basic defaults
+   - Choose a neutral color palette (1 primary, 1 accent, 1 neutral)
+   - Pick a safe, widely available font pairing (e.g., Inter + system serif)
+   - Document in `docs/BRAND-IDENTITY.md` and mark all choices as **provisional**
+   - Create an issue for the designer or CMO to review and expand the brand guidelines
+2. If a designer or CMO is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Choose sensible defaults, not optimal solutions.
+- Mark everything as provisional — the designer owns the final brand.
+- Let the designer or CMO refine and expand the actual brand identity.

package/templates/modules/brand-identity/agents/cmo/skills/brand-identity.fallback.md

@@ -0,0 +1,19 @@
+# Skill: Brand Identity (Fallback)
+
+The UI Designer primarily owns brand identity and visual guidelines. You are the fallback — step in only if no designer has addressed brand guidelines.
+
+## Brand Identity (Fallback)
+
+1. If no `docs/BRAND-IDENTITY.md` exists and no designer has started:
+   - Define brand positioning: mission statement, target audience, key differentiators
+   - Establish tone of voice and communication guidelines
+   - Set up a minimal color palette and typography recommendation
+   - Document in `docs/BRAND-IDENTITY.md` and mark visual choices as **provisional**
+   - Create an issue for the designer to refine visual identity
+2. If a designer is active, skip this entirely.
+
+## Rules
+
+- This is a safety net. Focus on brand strategy and messaging — your strength as CMO.
+- Visual design choices (colors, typography, logo) are provisional — the designer owns the final visual identity.
+- Let the designer lead on visual execution; you lead on positioning and messaging.

package/templates/modules/brand-identity/docs/brand-identity-template.md

@@ -0,0 +1,43 @@
+# Brand Identity
+
+## Brand Vision
+
+_What the brand stands for, its mission, and the emotional response it should evoke._
+
+## Color Palette
+
+| Role      | Name  | Hex     | RGB           | Usage            |
+|-----------|-------|---------|---------------|------------------|
+| Primary   | _..._ | _..._   | _..._         | _..._            |
+| Secondary | _..._ | _..._   | _..._         | _..._            |
+| Accent    | _..._ | _..._   | _..._         | _..._            |
+| Neutral   | _..._ | _..._   | _..._         | _..._            |
+| Error     | _..._ | _..._   | _..._         | _..._            |
+| Success   | _..._ | _..._   | _..._         | _..._            |
+
+## Typography
+
+| Role     | Typeface | Weight  | Size  | Usage            |
+|----------|----------|---------|-------|------------------|
+| Heading  | _..._    | _..._   | _..._ | _..._            |
+| Body     | _..._    | _..._   | _..._ | _..._            |
+| Mono     | _..._    | _..._   | _..._ | _..._            |
+
+## Logo Usage
+
+_Logo variants, clear space requirements, minimum size, and usage guidelines._
+
+_Do's and don'ts for logo placement and modification._
+
+## Iconography
+
+_Icon style (outline, filled, duotone), stroke weight, grid size, and alignment rules._
+
+## Tone of Voice
+
+_Communication style, vocabulary preferences, and brand personality traits._
+
+_Examples of on-brand vs. off-brand language._
+
+---
+_Generated by Clipper. Fill in during brand-identity task._

package/templates/modules/brand-identity/module.meta.json

@@ -0,0 +1,22 @@
+{
+  "name": "brand-identity",
+  "description": "Establishes brand identity: naming, visual language, messaging, and tone of voice.",
+  "capabilities": [
+    {
+      "skill": "brand-identity",
+      "owners": [
+        "ui-designer",
+        "cmo",
+        "ceo"
+      ],
+      "fallbackSkill": "brand-identity.fallback"
+    }
+  ],
+  "issues": [
+    {
+      "title": "Define brand identity and visual guidelines",
+      "assignTo": "capability:brand-identity",
+      "description": "Create the brand book: logo usage, color palette, typography, iconography, and tone-of-voice guidelines. Document everything in docs/BRAND-IDENTITY.md."
+    }
+  ]
+}

package/templates/modules/brand-identity/skills/brand-identity.md

@@ -0,0 +1,30 @@
+# Skill: Brand Identity
+
+You own the company's visual identity and brand guidelines. Define a cohesive brand that reflects the company's mission and resonates with its audience.
+
+## Brand Identity Process
+
+1. Audit the company goal and vision for brand direction:
+   - Review the company goal, target audience, and market positioning
+   - Identify key brand attributes (e.g., professional, playful, minimal, bold)
+   - Note any existing brand assets or constraints
+2. Define the core brand elements:
+   - **Color palette**: Primary, secondary, and accent colors with hex/RGB values
+   - **Typography**: Heading and body typefaces, size scale, weight usage
+   - **Logo usage**: Clear space, minimum size, do's and don'ts
+   - **Iconography**: Style, stroke weight, grid alignment
+   - **Tone of voice**: Communication style, vocabulary, personality
+3. Document everything in `docs/BRAND-IDENTITY.md`:
+   - Use the brand-identity-template as a starting point
+   - Fill in all sections with concrete values and rationale
+   - Include visual examples or references where possible
+4. Create initial design tokens if a tech stack exists:
+   - If `docs/TECH-STACK.md` is present, produce a tokens file (CSS custom properties or JSON) matching the chosen stack
+   - Reference the design-system module if the architecture-plan module exists
+
+## Rules
+
+- Consistency over novelty — a cohesive system beats clever one-offs.
+- Document rationale for every choice (why this color, why this typeface).
+- Ensure accessibility: color contrast must meet WCAG AA at minimum.
+- If a decision requires board input (e.g., paid font licensing), create an approval request.

package/templates/modules/build-api/module.meta.json

@@ -0,0 +1,118 @@
+{
+  "name": "build-api",
+  "title": "Build REST API",
+  "description": "Designs and documents the API before implementation. Defines contracts, endpoints, and data shapes upfront.",
+  "requires": [
+    "github-repo"
+  ],
+  "capabilities": [
+    {
+      "skill": "api-design",
+      "owners": [
+        "engineer",
+        "ceo"
+      ],
+      "fallbackSkill": null
+    }
+  ],
+  "issues": [
+    {
+      "title": "Design API schema and scaffold project",
+      "assignTo": "engineer",
+      "description": "Define the data model for the API's primary resources. Create database migrations. Scaffold the API project with route structure, health check endpoint, and request validation."
+    },
+    {
+      "title": "Define database schema and create migrations",
+      "description": "Design the data model for the API's primary resources. Create database migration files that can set up the schema from scratch. Include indexes for common query patterns.",
+      "priority": "high",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Scaffold API project and route structure",
+      "description": "Set up the API project with the chosen framework (Express, Fastify, Django, etc.). Create the route/controller structure with placeholder endpoints that return 501. Add health check endpoint at GET /health.",
+      "priority": "high",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Implement CRUD endpoints for primary resource",
+      "description": "Build full CRUD (Create, Read, Update, Delete) for the main resource. Include input validation, proper HTTP status codes (201 for create, 404 for not found, 422 for validation errors), and pagination for list endpoints.",
+      "priority": "high",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Add request validation middleware",
+      "description": "Add middleware that validates request bodies and query parameters against defined schemas. Return clear 422 errors with field-level messages. Use a validation library (Zod, Joi, Pydantic, etc.).",
+      "priority": "medium",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Add authentication middleware",
+      "description": "Implement authentication using JWT or session tokens. Add middleware that verifies tokens on protected routes and rejects unauthenticated requests with 401. Include a login/token endpoint.",
+      "priority": "high",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Add role-based authorization",
+      "description": "Implement authorization so users can only access resources they own or are permitted to see. Add role checks where needed. Return 403 for unauthorized access attempts.",
+      "priority": "medium",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Generate API documentation",
+      "description": "Set up auto-generated API docs using OpenAPI/Swagger, or a similar tool. Annotate endpoints with descriptions, parameter types, and example responses. Serve docs at /api-docs or equivalent.",
+      "priority": "medium",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Write API integration tests",
+      "description": "Write integration tests that hit the API endpoints with real HTTP requests. Cover happy paths, validation errors, auth failures, and edge cases. Use a test database that is reset between runs.",
+      "priority": "medium",
+      "assignTo": "engineer"
+    }
+  ],
+  "routines": [
+    {
+      "title": "API health check",
+      "description": "Verify the API health endpoint responds correctly and monitor uptime.",
+      "schedule": "*/15 * * * *",
+      "assignTo": "engineer"
+    },
+    {
+      "title": "Dependency and security audit",
+      "description": "Run dependency audit to check for known vulnerabilities in API dependencies. Flag any critical or high severity issues.",
+      "schedule": "0 8 * * 1",
+      "assignTo": "engineer"
+    }
+  ],
+  "goal": {
+    "title": "Build a REST API",
+    "description": "Design and implement a REST API from schema to documentation. Cover data modeling, endpoint implementation, authentication, and auto-generated API docs.",
+    "project": true,
+    "subgoals": [
+      {
+        "id": "schema-design",
+        "title": "Schema design",
+        "level": "team",
+        "description": "Define the data model and database schema for the API. Database schema is defined, migrations exist, and the schema can be applied to a fresh database."
+      },
+      {
+        "id": "endpoints",
+        "title": "Core endpoints",
+        "level": "team",
+        "description": "Implement the CRUD endpoints for primary resources. All core resource endpoints work with proper status codes, validation, and error handling."
+      },
+      {
+        "id": "auth",
+        "title": "Authentication and authorization",
+        "level": "team",
+        "description": "Add authentication to protect endpoints and authorization to control access. Unauthenticated requests are rejected. Users can only access resources they are authorized to see."
+      },
+      {
+        "id": "docs",
+        "title": "API documentation",
+        "level": "team",
+        "description": "Generate and publish API documentation so consumers can integrate. API docs are generated from source and accessible at a known URL."
+      }
+    ]
+  }
+}

package/templates/modules/build-api/skills/api-design.md

@@ -0,0 +1,43 @@
+# API Design
+
+You are responsible for designing and implementing a REST API. Follow these principles:
+
+## Design Principles
+
+1. **Resource-oriented URLs** — Use nouns, not verbs. `/users`, `/orders/{id}`, not `/getUser` or `/createOrder`.
+2. **Consistent HTTP methods** — GET (read), POST (create), PUT/PATCH (update), DELETE (remove). Return appropriate status codes: 200, 201, 204, 400, 401, 403, 404, 409, 422, 500.
+3. **Input validation at the boundary** — Validate all request bodies and query parameters before touching the database. Return 422 with field-level error messages.
+4. **Pagination by default** — List endpoints return paginated results. Use cursor-based or offset pagination consistently.
+5. **Predictable error format** — Every error response uses the same shape: `{ "error": { "code": "...", "message": "...", "details": [...] } }`.
+
+## Schema Design
+
+When designing the data model:
+
+- Start from the API consumer's perspective — what objects do they need to create, read, update?
+- Normalize where it prevents data inconsistency; denormalize where it prevents N+1 queries
+- Always include `id`, `createdAt`, `updatedAt` on every table
+- Add indexes for: primary keys, foreign keys, fields used in WHERE/ORDER BY, unique constraints
+- Write migrations that are reversible (up + down)
+
+## Authentication & Authorization
+
+- **Authentication** verifies identity (who are you?). Use JWT or session tokens.
+- **Authorization** verifies access (can you do this?). Check ownership and roles.
+- Protected routes return 401 (not authenticated) or 403 (not authorized) — never 404 to hide resources.
+- Store password hashes (bcrypt/argon2), never plaintext.
+
+## Documentation
+
+- Annotate every endpoint with: description, parameters (type, required, constraints), request body schema, response schema, example request/response, possible error codes.
+- Generate docs from source annotations (OpenAPI/Swagger) — not manually maintained.
+- Keep docs in sync by making them part of the build.
+
+## Output Artifacts
+
+Document your API design decisions in `docs/API-DESIGN.md`:
+- Resource model (entities and relationships)
+- Endpoint inventory (method, path, description, auth requirement)
+- Authentication strategy
+- Error handling conventions
+- Pagination approach

package/templates/modules/ci-cd/agents/devops/skills/ci-cd.md

@@ -0,0 +1,28 @@
+# Skill: CI/CD Pipeline
+
+You are the DevOps engineer and CI/CD is your core domain. You own the full pipeline lifecycle — build, test, deploy, and ongoing maintenance.
+
+## Setup Steps
+
+1. Review the tech stack to determine build, lint, and test tooling
+2. Create a CI workflow (GitHub Actions or equivalent):
+   - Lint on all PRs and pushes to main
+   - Run tests on all PRs and pushes to main
+   - Build/typecheck to verify compilation
+3. Create a CD workflow:
+   - Trigger on merge to main
+   - Deploy to the target environment
+   - Run smoke tests after deployment
+4. Add status badges to the project README
+5. Set up infrastructure-as-code for pipeline resources (runners, caches, secrets)
+6. Document the full pipeline in `docs/CI-CD.md`
+
+## Rules
+
+- Fail fast — put the quickest checks (lint, typecheck) first.
+- Keep pipelines under 5 minutes. If they exceed this, add caching or split stages.
+- Use dependency caching (e.g., `actions/cache`, `setup-node` cache) to speed up installs.
+- Pin action versions to full SHAs, not tags, for security.
+- Never store secrets in workflow files — use GitHub Secrets or equivalent.
+- If CI breaks main, fix it immediately — a red main blocks everyone.
+- Own pipeline health metrics — track build times, flake rates, deployment frequency.