@jakkrichm/create-nexus-devflow 2.0.19 → 2.0.21

package/template/.agents/skills/type-design/SKILL.md

@@ -1,84 +0,0 @@
----
-name: type-design
-description: "[Devflow] Analyzes type and interface design for encapsulation, invariant expression, usefulness, and enforcement. Use when introducing new types, reviewing PRs with type changes, or refactoring domain models."
----
-
-# Type Design
-
-Use this skill to evaluate whether types make invalid states hard or impossible to represent without over-engineering the codebase.
-
-## Core Rule
-
-Make illegal states unrepresentable when it prevents real bugs, but do not make simple things complex.
-
-## When To Use
-
-- New type, interface, schema, model, DTO, or value object is introduced.
-- A PR changes type relationships, constructors, factories, or public API contracts.
-- A refactor moves validation, mutation, or domain rules across module boundaries.
-- A reviewer needs a pragmatic quality rating for type design.
-
-## Analysis Scope
-
-Review:
-
-- Type/interface definitions.
-- Constructors, factories, parsers, and validators.
-- Setter methods and mutation points.
-- Public API surface and exported types.
-- Relationships between fields that must remain consistent.
-
-## Evaluation Dimensions
-
-| Dimension | Ask |
-|---|---|
-| Encapsulation | Can callers violate invariants from outside the type boundary? |
-| Invariant Expression | Are the important constraints obvious from the type shape? |
-| Invariant Usefulness | Do the constraints prevent real bugs or only add ceremony? |
-| Invariant Enforcement | Are invalid instances impossible or at least rejected at boundaries? |
-
-Rate each dimension from 1 to 10. Scores below 5 require concrete findings.
-
-## Anti-Patterns
-
-| Anti-pattern | Risk |
-|---|---|
-| Exposed mutable internals | Callers can break invariants after construction. |
-| Doc-only invariants | The rule exists only in comments and is easy to bypass. |
-| No constructor or parser validation | Invalid instances can enter the system. |
-| Anemic domain model | Rules are scattered across callers. |
-| God type | Too many responsibilities make the type hard to use correctly. |
-| Over-modeled simple data | Complexity exceeds the bug-prevention value. |
-
-## Output Format
-
-```markdown
-## Type Design Review: [Scope]
-
-### Types Reviewed
-| Type | File | Purpose |
-|---|---|---|
-| `TypeName` | `path/file.ts:10` | Represents ... |
-
-### Ratings
-| Type | Encapsulation | Expression | Usefulness | Enforcement | Overall |
-|---|---:|---:|---:|---:|---:|
-| `TypeName` | 8 | 7 | 8 | 6 | 7.25 |
-
-### Findings
-#### [Severity] [Title]
-**Location**: `path/file.ts:23`
-**Problem**: [What invariant can fail]
-**Impact**: [Concrete bug or maintenance risk]
-**Recommendation**: [Smallest useful improvement]
-
-### Verdict
-[Well-designed / Adequate / Needs improvement / Significant issues]
-```
-
-## Verification
-
-- Findings cite concrete files and lines.
-- Recommendations fit the project's existing type style.
-- Suggestions include trade-offs when they add ceremony.
-- No recommendation depends on speculative future requirements.

package/template/.agents/skills/ui-ux-pro-max/SKILL.md

@@ -1,75 +0,0 @@
----
-name: ui-ux-pro-max
-description: "[Devflow] AI-powered design intelligence with 50+ styles, 95+ color palettes, and automated design system generation. Use when designing, building, or reviewing UI/UX."
----
-
-# UI/UX Pro Max (Design Intelligence)
-
-Comprehensive design guide for web and mobile applications. Contains 50+ styles, 97 color palettes, 57 font pairings, 99 UX guidelines, and 25 chart types across 9 technology stacks. Searchable database with priority-based recommendations.
-
-## Prerequisites
-
-Python is required for the design system search tool.
-
-## How to Use This Skill
-
-When you need to perform UI/UX work (design, build, create, implement, review, fix, improve), follow this process:
-
-### 1. Analyze User Requirements
-Extract key information:
-- **Product type**: SaaS, e-commerce, dashboard, etc.
-- **Style keywords**: minimal, playful, professional, dark mode, etc.
-- **Industry**: healthcare, fintech, gaming, etc.
-- **Stack**: React, Vue, Next.js, or default to `html-tailwind`.
-
-### 2. Generate Design System (REQUIRED)
-**Always start by generating a design system** to get comprehensive recommendations:
-
-```bash
-python3 .claude/.shared/ui-ux-pro-max/scripts/search.py "<product_type> <industry> <keywords>" --design-system [-p "Project Name"]
-```
-
-### 3. Persist Design System
-To save the design system for hierarchical retrieval:
-
-```bash
-python3 .claude/.shared/ui-ux-pro-max/scripts/search.py "<query>" --design-system --persist -p "Project Name" [--page "name"]
-```
-
-### 4. Detailed Domain Searches
-Supplement with specific details as needed:
-- `style`: `--domain style "keywords"`
-- `chart`: `--domain chart "keywords"`
-- `ux`: `--domain ux "keywords"`
-- `typography`: `--domain typography "keywords"`
-
----
-
-## Design Guidelines & Standards
-
-### Professional UI Rules
-- **No emoji icons**: Use SVG icons (Heroicons, Lucide).
-- **Stable hover states**: Use color/opacity transitions, avoid layout shifts.
-- **Consistent icon sizing**: Use fixed viewBox (24x24) with w-6 h-6.
-- **Cursor pointer**: Add `cursor-pointer` to all interactive elements.
-
-### Contrast & Visibility
-- **Light Mode Glass**: Use `bg-white/80` or higher.
-- **Text Contrast**: Use high-contrast slates (e.g., slate-900 for body).
-- **Border visibility**: Ensure borders are visible in both light/dark modes.
-
-### Layout
-- **Floating navbar**: Add `top-4 left-4 right-4` spacing.
-- **Responsive**: Test at 375px, 768px, 1024px, 1440px.
-
-## Pre-Delivery Checklist
-
-- [ ] No emojis used as icons (use SVG instead).
-- [ ] Hover states don't cause layout shift.
-- [ ] All clickable elements have `cursor-pointer`.
-- [ ] Transitions are smooth (150-300ms).
-- [ ] Responsive at all major breakpoints.
-- [ ] No horizontal scroll on mobile.
-
----
-*Powered by UI-UX Pro Max Engine*

package/template/.claude/skills/agent/SKILL.md

@@ -1,165 +0,0 @@
----name: agent
-
-description: "[Devflow] Invoke specialist persona or role-based agent on a target file, folder, stage artifact, or concern."
----
-# Phase 90: Invoke Agent
-
-Run a specialist agent persona for targeted expertise while preserving the DevFlow 2.0 stage-first contract.
-
-Primary behavior now lives in the `specialist-agent-routing` skill. Keep this workflow as the compatibility wrapper and advanced user-facing agent entry point.
-
-## Usage
-
-```text
-Agent {AGENT_NAME} {TARGET}
-```
-
-Examples:
-
-```text
-Agent requirements-engineer devflow/runs/007-auth-refactor20-spec.md
-Agent codebase-explorer src/services/
-Agent code-reviewer devflow/runs/007-auth-refactor
-```
-
-## Available Agents
-
-Agent definitions live in `../agents/`.
-
-Planning and requirements:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `prp-core-planner` | Create implementation plans from specs and codebase patterns. |
-| `requirements-engineer` | Refine `10-define.md` and `20-spec.md` before planning. |
-| `prp-core-prd-architect` | Draft PRD documents from early ideas. |
-| `orchestrator` | Coordinate complex work and recommend next specialist steps. |
-| `prp-core-boss` | Route `/goal` requests, decompose work, enforce turn budgets, and validate worker output. |
-
-Research and exploration:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `codebase-explorer` | Find files and patterns; analyze architecture, data flow, and module relationships. |
-| `web-researcher` | Research external APIs, docs, and best practices. |
-
-Implementation:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `prp-core-coder` | Implement planned subtasks. |
-| `prp-core-worker` | Execute focused Boss-assigned `/goal` subtasks and report validation status. |
-| `backend-specialist` | Backend, APIs, database, server logic. |
-| `frontend-specialist` | UI/UX and frontend implementation. |
-| `database-architect` | Schema, indexing, and query design. |
-
-Quality and debugging:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `test-engineer` | Unit and integration tests. |
-| `prp-core-debugger` | Root cause analysis. |
-| `code-reviewer` | Code review, risk, regressions. |
-| `security-auditor` | Security and logic risk. |
-| `performance-engineer` | Performance bottlenecks. |
-
-Git and docs:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `prp-core-git-committer` | Commit preparation and message quality. |
-| `prp-core-git-pr-maker` | Pull request summary and preparation. |
-| `documentation-maintainer` | Documentation impact analysis. |
-
-Maintenance and infrastructure:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `ob-loop-engineer` | Overnight infrastructure maintenance, code debt pruning, and variant branch testing loops. |
-
-
-## Reusable Skills
-
-The following former narrow agents are now skills. Invoke them through the responsible agent or workflow instead of `Agent`:
-
-| Skill | Apply Through |
-| :--- | :--- |
-| `code-simplification` | `prp-core-coder`, `code-reviewer`, or `Simplify` |
-| `type-design` | `backend-specialist`, `frontend-specialist`, `database-architect`, or `code-reviewer` |
-| `silent-failure-audit` | `code-reviewer`, `test-engineer`, `backend-specialist`, or `security-auditor` |
-
-## Artifact Contract
-
-Specialist agents must use the DevFlow 2.0 stage-first contract:
-
-- Prefer `00-discover.md`, `10-define.md`, `20-spec.md`, `30-plan.md`, `40-execute.md`, `50-verify.md`, `70-release.md`, and `60-report.md` as the primary artifacts.
-- Do not silently rewrite legacy JSON artifacts.
-- If migration work still requires JSON, prefer CLI-backed minimal updates instead of full-file rewrites.
-- If the specialist is only reviewing, recommend exact commands instead of mutating artifacts.
-- Keep reports readable without requiring a dashboard or JSON viewer.
-
-## 9arm-Skills Discipline Routing
-
-When the target task matches one of these review or communication modes, apply the credited local pack under `.agents/skills/9arm-skills/` while preserving the normal specialist output contract:
-
-| Situation | Apply |
-| :--- | :--- |
-| `code-reviewer`, PR review, plan critique, or change risk review | `9arm-skills/scrutinize` |
-| debug or RCA specialist work | `9arm-skills/debug-mantra` |
-| completed bug or regression lesson extraction | `9arm-skills/post-mortem` |
-| stakeholder-readable summary, PR body, release note, standup, or status update | `9arm-skills/management-talk` |
-
-Reports that use the pack should include a short `Source Discipline` note with credit to `thananon/9arm-skills`.
-
-## Process
-
-1. Load the persona from `../agents/{AGENT_NAME}.md`.
-2. Read the target file, folder, stage directory, or recent changes.
-3. Apply the persona's specialist logic.
-4. If artifact changes are needed, prefer stage markdown updates first.
-5. Record lightweight context usage in the report when the agent loads notable context.
-6. Produce either a concise report or a focused set of changes.
-
-## Output
-
-If a report is substantial, save it to:
-
-```text
-devflow/reports/{date}-{agent-name}-{timestamp}.md
-```
-
-Before saving a substantial agent report, inspect `.agent/resources/schemas/agent_report.template.md` and use its required headings unless the target workflow provides a more specific template.
-
-Before reporting completion, run:
-
-Review `{report_path}` against `agent_report.template.md`, keep the required headings, and remove placeholder text before completion.
-
-Replace any placeholder or template text with concrete files reviewed, findings, recommendations, and validation needs.
-
-For substantial reports, add a short `Context Usage Notes` subsection under the context reviewed area with files or artifacts loaded, any known token counts, and one practical optimization note for future runs.
-
-Short reports can be returned directly in chat.
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Specialist invocation command, not a numbered stage
-- Typical entry points: any stage that needs focused specialist judgment
-- Typical handoff targets: return to the owning workflow such as `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/agents/README.md`
-- `.agent/resources/schemas/agent_report.template.md`
-- Related commands: `Research`, `PR-Review`, `Debug`, `Help`, all mainline stages
-
-## Next Workflow Recommendation
-
-- **Primary**: the workflow that owns the target's lifecycle, such as `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`, or `PR-Review`.
-- **Why**: `Agent` supplies specialist judgment; the owning workflow should execute the next lifecycle step.
-- **Alternatives**:
-  - `Research` when the specialist work uncovered unresolved external uncertainty
-  - `Wiki` when the specialist report contains reusable project knowledge
-  - `Help {target}` when the correct next route is unclear
-

package/template/.claude/skills/api-and-interface-design/SKILL.md

@@ -1,294 +0,0 @@
----
-name: api-and-interface-design
-description: "[Devflow] Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend."
----
-
-# API and Interface Design
-
-## Overview
-
-Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.
-
-## When to Use
-
-- Designing new API endpoints
-- Defining module boundaries or contracts between teams
-- Creating component prop interfaces
-- Establishing database schema that informs API shape
-- Changing existing public interfaces
-
-## Core Principles
-
-### Hyrum's Law
-
-> With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract.
-
-This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications:
-
-- **Be intentional about what you expose.** Every observable behavior is a potential commitment.
-- **Don't leak implementation details.** If users can observe it, they will depend on it.
-- **Plan for deprecation at design time.** See `deprecation-and-migration` for how to safely remove things users depend on.
-- **Tests are not enough.** Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.
-
-### The One-Version Rule
-
-Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.
-
-### 1. Contract First
-
-Define the interface before implementing it. The contract is the spec — implementation follows.
-
-```typescript
-// Define the contract first
-interface TaskAPI {
-  // Creates a task and returns the created task with server-generated fields
-  createTask(input: CreateTaskInput): Promise<Task>;
-
-  // Returns paginated tasks matching filters
-  listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;
-
-  // Returns a single task or throws NotFoundError
-  getTask(id: string): Promise<Task>;
-
-  // Partial update — only provided fields change
-  updateTask(id: string, input: UpdateTaskInput): Promise<Task>;
-
-  // Idempotent delete — succeeds even if already deleted
-  deleteTask(id: string): Promise<void>;
-}
-```
-
-### 2. Consistent Error Semantics
-
-Pick one error strategy and use it everywhere:
-
-```typescript
-// REST: HTTP status codes + structured error body
-// Every error response follows the same shape
-interface APIError {
-  error: {
-    code: string;        // Machine-readable: "VALIDATION_ERROR"
-    message: string;     // Human-readable: "Email is required"
-    details?: unknown;   // Additional context when helpful
-  };
-}
-
-// Status code mapping
-// 400 → Client sent invalid data
-// 401 → Not authenticated
-// 403 → Authenticated but not authorized
-// 404 → Resource not found
-// 409 → Conflict (duplicate, version mismatch)
-// 422 → Validation failed (semantically invalid)
-// 500 → Server error (never expose internal details)
-```
-
-**Don't mix patterns.** If some endpoints throw, others return null, and others return `{ error }` — the consumer can't predict behavior.
-
-### 3. Validate at Boundaries
-
-Trust internal code. Validate at system edges where external input enters:
-
-```typescript
-// Validate at the API boundary
-app.post('/api/tasks', async (req, res) => {
-  const result = CreateTaskSchema.safeParse(req.body);
-  if (!result.success) {
-    return res.status(422).json({
-      error: {
-        code: 'VALIDATION_ERROR',
-        message: 'Invalid task data',
-        details: result.error.flatten(),
-      },
-    });
-  }
-
-  // After validation, internal code trusts the types
-  const task = await taskService.create(result.data);
-  return res.status(201).json(task);
-});
-```
-
-Where validation belongs:
-- API route handlers (user input)
-- Form submission handlers (user input)
-- External service response parsing (third-party data -- **always treat as untrusted**)
-- Environment variable loading (configuration)
-
-> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.
-
-Where validation does NOT belong:
-- Between internal functions that share type contracts
-- In utility functions called by already-validated code
-- On data that just came from your own database
-
-### 4. Prefer Addition Over Modification
-
-Extend interfaces without breaking existing consumers:
-
-```typescript
-// Good: Add optional fields
-interface CreateTaskInput {
-  title: string;
-  description?: string;
-  priority?: 'low' | 'medium' | 'high';  // Added later, optional
-  labels?: string[];                       // Added later, optional
-}
-
-// Bad: Change existing field types or remove fields
-interface CreateTaskInput {
-  title: string;
-  // description: string;  // Removed — breaks existing consumers
-  priority: number;         // Changed from string — breaks existing consumers
-}
-```
-
-### 5. Predictable Naming
-
-| Pattern | Convention | Example |
-|---------|-----------|---------|
-| REST endpoints | Plural nouns, no verbs | `GET /api/tasks`, `POST /api/tasks` |
-| Query params | camelCase | `?sortBy=createdAt&pageSize=20` |
-| Response fields | camelCase | `{ createdAt, updatedAt, taskId }` |
-| Boolean fields | is/has/can prefix | `isComplete`, `hasAttachments` |
-| Enum values | UPPER_SNAKE | `"IN_PROGRESS"`, `"COMPLETED"` |
-
-## REST API Patterns
-
-### Resource Design
-
-```
-GET    /api/tasks              → List tasks (with query params for filtering)
-POST   /api/tasks              → Create a task
-GET    /api/tasks/:id          → Get a single task
-PATCH  /api/tasks/:id          → Update a task (partial)
-DELETE /api/tasks/:id          → Delete a task
-
-GET    /api/tasks/:id/comments → List comments for a task (sub-resource)
-POST   /api/tasks/:id/comments → Add a comment to a task
-```
-
-### Pagination
-
-Paginate list endpoints:
-
-```typescript
-// Request
-GET /api/tasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc
-
-// Response
-{
-  "data": [...],
-  "pagination": {
-    "page": 1,
-    "pageSize": 20,
-    "totalItems": 142,
-    "totalPages": 8
-  }
-}
-```
-
-### Filtering
-
-Use query parameters for filters:
-
-```
-GET /api/tasks?status=in_progress&assignee=user123&createdAfter=2025-01-01
-```
-
-### Partial Updates (PATCH)
-
-Accept partial objects — only update what's provided:
-
-```typescript
-// Only title changes, everything else preserved
-PATCH /api/tasks/123
-{ "title": "Updated title" }
-```
-
-## TypeScript Interface Patterns
-
-### Use Discriminated Unions for Variants
-
-```typescript
-// Good: Each variant is explicit
-type TaskStatus =
-  | { type: 'pending' }
-  | { type: 'in_progress'; assignee: string; startedAt: Date }
-  | { type: 'completed'; completedAt: Date; completedBy: string }
-  | { type: 'cancelled'; reason: string; cancelledAt: Date };
-
-// Consumer gets type narrowing
-function getStatusLabel(status: TaskStatus): string {
-  switch (status.type) {
-    case 'pending': return 'Pending';
-    case 'in_progress': return `In progress (${status.assignee})`;
-    case 'completed': return `Done on ${status.completedAt}`;
-    case 'cancelled': return `Cancelled: ${status.reason}`;
-  }
-}
-```
-
-### Input/Output Separation
-
-```typescript
-// Input: what the caller provides
-interface CreateTaskInput {
-  title: string;
-  description?: string;
-}
-
-// Output: what the system returns (includes server-generated fields)
-interface Task {
-  id: string;
-  title: string;
-  description: string | null;
-  createdAt: Date;
-  updatedAt: Date;
-  createdBy: string;
-}
-```
-
-### Use Branded Types for IDs
-
-```typescript
-type TaskId = string & { readonly __brand: 'TaskId' };
-type UserId = string & { readonly __brand: 'UserId' };
-
-// Prevents accidentally passing a UserId where a TaskId is expected
-function getTask(id: TaskId): Promise<Task> { ... }
-```
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "We'll document the API later" | The types ARE the documentation. Define them first. |
-| "We don't need pagination for now" | You will the moment someone has 100+ items. Add it from the start. |
-| "PATCH is complicated, let's just use PUT" | PUT requires the full object every time. PATCH is what clients actually want. |
-| "We'll version the API when we need to" | Breaking changes without versioning break consumers. Design for extension from the start. |
-| "Nobody uses that undocumented behavior" | Hyrum's Law: if it's observable, somebody depends on it. Treat every public behavior as a commitment. |
-| "We can just maintain two versions" | Multiple versions multiply maintenance cost and create diamond dependency problems. Prefer the One-Version Rule. |
-| "Internal APIs don't need contracts" | Internal consumers are still consumers. Contracts prevent coupling and enable parallel work. |
-
-## Red Flags
-
-- Endpoints that return different shapes depending on conditions
-- Inconsistent error formats across endpoints
-- Validation scattered throughout internal code instead of at boundaries
-- Breaking changes to existing fields (type changes, removals)
-- List endpoints without pagination
-- Verbs in REST URLs (`/api/createTask`, `/api/getUsers`)
-- Third-party API responses used without validation or sanitization
-
-## Verification
-
-After designing an API:
-
-- [ ] Every endpoint has typed input and output schemas
-- [ ] Error responses follow a single consistent format
-- [ ] Validation happens at system boundaries only
-- [ ] List endpoints support pagination
-- [ ] New fields are additive and optional (backward compatible)
-- [ ] Naming follows consistent conventions across all endpoints
-- [ ] API documentation or types are committed alongside the implementation

package/template/.claude/skills/app-builder/SKILL.md

@@ -1,75 +0,0 @@
----
-name: app-builder
-description: "[Devflow] Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents."
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent
----
-
-# App Builder - Application Building Orchestrator
-
-> Analyzes user's requests, determines tech stack, plans structure, and coordinates agents.
-
-## 🎯 Selective Reading Rule
-
-**Read ONLY files relevant to the request!** Check the content map, find what you need.
-
-| File | Description | When to Read |
-|------|-------------|--------------|
-| `project-detection.md` | Keyword matrix, project type detection | Starting new project |
-| `tech-stack.md` | 2026 default stack, alternatives | Choosing technologies |
-| `agent-coordination.md` | Agent pipeline, execution order | Coordinating multi-agent work |
-| `scaffolding.md` | Directory structure, core files | Creating project structure |
-| `feature-building.md` | Feature analysis, error handling | Adding features to existing project |
-| `templates/SKILL.md` | **Project templates** | Scaffolding new project |
-
----
-
-## 📦 Templates (13)
-
-Quick-start scaffolding for new projects. **Read the matching template only!**
-
-| Template | Tech Stack | When to Use |
-|----------|------------|-------------|
-| [nextjs-fullstack](templates/nextjs-fullstack/TEMPLATE.md) | Next.js + Prisma | Full-stack web app |
-| [nextjs-saas](templates/nextjs-saas/TEMPLATE.md) | Next.js + Stripe | SaaS product |
-| [nextjs-static](templates/nextjs-static/TEMPLATE.md) | Next.js + Framer | Landing page |
-| [nuxt-app](templates/nuxt-app/TEMPLATE.md) | Nuxt 3 + Pinia | Vue full-stack app |
-| [express-api](templates/express-api/TEMPLATE.md) | Express + JWT | REST API |
-| [python-fastapi](templates/python-fastapi/TEMPLATE.md) | FastAPI | Python API |
-| [react-native-app](templates/react-native-app/TEMPLATE.md) | Expo + Zustand | Mobile app |
-| [flutter-app](templates/flutter-app/TEMPLATE.md) | Flutter + Riverpod | Cross-platform mobile |
-| [electron-desktop](templates/electron-desktop/TEMPLATE.md) | Electron + React | Desktop app |
-| [chrome-extension](templates/chrome-extension/TEMPLATE.md) | Chrome MV3 | Browser extension |
-| [cli-tool](templates/cli-tool/TEMPLATE.md) | Node.js + Commander | CLI app |
-| [monorepo-turborepo](templates/monorepo-turborepo/TEMPLATE.md) | Turborepo + pnpm | Monorepo |
-
----
-
-## 🔗 Related Agents
-
-| Agent | Role |
-|-------|------|
-| `prp-core-planner` | Task breakdown, dependency graph |
-| `frontend-specialist` | UI components, pages |
-| `backend-specialist` | API, business logic |
-| `database-architect` | Schema, migrations |
-| `devops-engineer` | Deployment, preview |
-
----
-
-## Usage Example
-
-```
-User: "Make an Instagram clone with photo sharing and likes"
-
-App Builder Process:
-1. Project type: Social Media App
-2. Tech stack: Next.js + Prisma + Cloudinary + Clerk
-3. Create plan:
-   ├─ Database schema (users, posts, likes, follows)
-   ├─ API routes (12 endpoints)
-   ├─ Pages (feed, profile, upload)
-   └─ Components (PostCard, Feed, LikeButton)
-4. Coordinate agents
-5. Report progress
-6. Start preview
-```