@compilr-dev/sdk 0.7.6 → 0.7.8

package/dist/skills/platform-skills.js

@@ -1,1761 +1,30 @@
 /**
- * Platform Skills
+ * Platform Skills — Aggregate
  *
- * Skills that depend on platform-specific tools (backlog, workitems, documents, projects).
- * These were originally in @compilr-dev/agents and @compilr-dev/agents-coding-core
- * but belong in the SDK since they reference platform tools.
- *
- * Skills: design, sketch, prd, refine, refine-item, architecture, session-notes, build, scaffold
+ * Re-exports all domain-specific skills and provides the combined platformSkills array.
+ * Individual skill files: software-skills.ts, research-skills.ts, business-skills.ts, content-skills.ts
  */
-import { defineSkill } from '@compilr-dev/agents';
-// =============================================================================
-// From @compilr-dev/agents (7 skills)
-// =============================================================================
-export const designSkill = defineSkill({
-    name: 'design',
-    description: 'Guide user through project design and requirements gathering',
-    prompt: `You are in DESIGN MODE. Your goal is to gather enough information to populate the project backlog with 5-15 actionable items.
-
-## When to Use
-- Starting a new project from scratch
-- User has an idea but no clear requirements
-- Need to create initial backlog
-
-## When NOT to Use
-- Project already has requirements → use refine skill
-- Quick project outline needed → use sketch skill
-- Just need to update PRD → use prd skill
-
-## PHASES
-
-### Phase 1: Vision (3-5 questions)
-Understand the big picture:
-- What problem does this solve?
-- Who is the target user/customer?
-- What's the one-sentence pitch?
-- What makes this different from alternatives?
-
-After gathering answers, summarize the vision and confirm with user.
-
-### Phase 2: Core Features (3-5 questions)
-Define MVP scope:
-- What are the 3-5 must-have features for v1?
-- What explicitly can wait for v2?
-- Are there any non-negotiable technical requirements?
-
-Use the ask_user tool to present feature options when helpful.
-
-### Phase 3: Technical Context (2-3 questions)
-Understand constraints:
-- Any existing systems to integrate with?
-- Performance/scale requirements?
-- Compliance/security requirements?
-
-### Phase 4: Output
-When you have enough information:
-1. Summarize the design in a concise format
-2. Check if project needs foundation:
-   - Use detect_project tool to check current state
-   - If no src/, package.json, or code files exist → this is a fresh project
-3. Use backlog_write to create 5-15 items:
-   - **For fresh projects, ALWAYS add first:**
-     | CHORE-001 | chore | 📋 | critical | Project scaffolding | Create project structure, dependencies, and build config based on tech stack |
-   - Core features (type: feature, priority: high)
-   - Nice-to-haves (type: feature, priority: medium/low)
-   - Technical setup tasks (type: chore, priority: high)
-   - Known risks/unknowns (type: tech-debt, priority: medium)
-4. Update the PRD.md file with gathered requirements:
-   - Use the edit tool to update PRD.md (located in .compilr/requirements/PRD.md or {project}-docs/00-requirements/PRD.md)
-   - Fill in: Problem Statement, Goals, User Stories, Functional Requirements
-   - Keep the existing structure, just replace placeholder text
-5. Present the backlog and PRD summary to user for confirmation
-   - If CHORE-001 was added, mention: "Run /scaffold to create the project foundation"
-6. If the project involves managing entities (CRUD operations on things like users, orders, products):
-   - Mention: "This looks like an entity-based app — /scaffold can auto-generate a full working MVP with CRUD pages, API, routing, and seed data."
-   - Do NOT build the Application Model during /design — /scaffold handles that
-
-## RULES
-- Ask questions in batches of 2-4 using ask_user tool when possible
-- Always offer a "Type something custom" option
-- Summarize after each phase before moving on
-- If user says "skip" or "later", move to next phase
-- Stop asking when you have enough for a meaningful backlog
-- Total interaction should be 10-20 questions max
-
-## COMPLETION CRITERIA
-✓ Vision is clear and confirmed
-✓ MVP features are defined
-✓ Backlog has 5-15 items
-✓ For fresh projects: CHORE-001 scaffolding item is first (critical priority)
-✓ PRD.md is populated with requirements
-✓ If entity-based: user informed about /scaffold auto-generation
-✓ User has approved the backlog`,
-    tags: ['planning', 'requirements'],
-});
-export const refineSkill = defineSkill({
-    name: 'refine',
-    description: 'Iteratively refine and expand project requirements',
-    prompt: `You are in REFINE MODE. Your goal is to deepen and expand existing requirements based on user feedback.
-
-## When to Use
-- Backlog items are too vague
-- Need to add acceptance criteria
-- Reprioritizing existing items
-- Adding missing items to backlog
-
-## When NOT to Use
-- No backlog exists yet → use design skill
-- Quick outline needed → use sketch skill
-- Refining single item → use refine-item skill
-
-## STARTUP
-
-1. Use todo_write to create a task list:
-   - "Get backlog overview"
-   - "Ask user what to refine"
-   - "Refine selected items"
-   - "Update backlog"
-
-2. Use backlog_read with limit:10 to get overview (NOT all items!)
-   - Note the total count and what types/priorities exist
-   - If total > 10, mention there are more items available
-
-3. Use ask_user_simple to ask what the user wants to focus on:
-   - Question: "What would you like to refine?"
-   - Options based on what you found (e.g., "High priority features", "Technical debt items", "A specific item by ID")
-
-## REFINEMENT APPROACHES
-
-### 1. Expand Existing Items
-For items that are too vague:
-- Break down into sub-tasks
-- Add acceptance criteria
-- Clarify scope boundaries
-
-### 2. Add Missing Items
-Identify gaps:
-- Edge cases not covered
-- Error handling scenarios
-- Integration points
-
-### 3. Reprioritize
-Based on new understanding:
-- Promote blockers, demote nice-to-haves
-- Identify dependencies
-
-### 4. Technical Deep-Dive
-For complex features:
-- Architecture decisions
-- Technology choices
-
-## TOOLS TO USE
-
-- **ask_user_simple**: For single-choice questions (preferred for most interactions)
-- **ask_user**: For multi-question batches (when gathering related info)
-- **backlog_read**: Use id param to get specific item, use search/filters otherwise
-- **backlog_write**: Update items after refinement decisions
-- **todo_write**: Track your progress through refinement
-
-## RULES
-
-1. ALWAYS use ask_user_simple or ask_user for decisions - NEVER ask questions in plain text
-2. Keep backlog reads efficient - use filters and limits
-3. One refinement focus at a time
-4. Update backlog with backlog_write after each decision
-5. Summarize changes at the end
-
-## COMPLETION CRITERIA
-✓ User's refinement goals are addressed
-✓ Backlog is updated with changes
-✓ No open questions remain`,
-    tags: ['planning', 'requirements'],
-});
-export const sketchSkill = defineSkill({
-    name: 'sketch',
-    description: 'Quick project outline with simple questions',
-    prompt: `You are in SKETCH MODE. Ask 6 quick questions, then create backlog items.
-
-## When to Use
-- Quick project kickoff
-- User wants fast outline without deep dive
-- Initial brainstorming session
-
-## When NOT to Use
-- Detailed requirements needed → use design skill
-- Project already has backlog → use refine skill
-- Single item focus → use refine-item skill
-
-STEPS:
-1. Use todo_write with 6 tasks (one per question)
-2. Ask each question using ask_user_simple tool
-3. After each answer, mark that todo complete
-4. After all questions, check if this is a fresh project:
-   - Use detect_project to check if src/, package.json, or code files exist
-   - If fresh project → add CHORE-001 scaffolding item first (critical priority)
-5. Use backlog_write to create 3-8 items
-6. Summarize and suggest /design for more detail (or /build to start scaffolding)
-
-QUESTIONS (ask one at a time):
-1. App type? Options: Web app, Mobile app, CLI tool, API service
-2. Target users? Options: Developers, Business users, Consumers, Internal team
-3. Main problem it solves? (free text, no options)
-4. Must-have features? (free text, no options)
-5. Tech needs? Options: Database, Authentication, External APIs, None
-6. Timeline? Options: Quick prototype, MVP in weeks, Full product
-
-RULES:
-- One ask_user_simple call per question
-- Keep it simple and fast
-- For fresh projects, ALWAYS add CHORE-001 scaffolding as first item`,
-    tags: ['planning', 'requirements'],
-});
-export const refineItemSkill = defineSkill({
-    name: 'refine-item',
-    description: 'Focused refinement of a specific backlog item',
-    prompt: `You are in FOCUSED REFINE MODE. Your goal is to refine a specific backlog item.
-
-## When to Use
-- User wants to work on a specific backlog item
-- Item needs more detail or breakdown
-- Changing priority of specific item
-
-## When NOT to Use
-- Multiple items need refinement → use refine skill
-- No items exist yet → use design or sketch skill
-- Ready to implement → use build skill
-
-## STARTUP
-
-1. Use backlog_read with id parameter to get the specific item
-2. Use todo_write to track progress:
-   - "Review current item"
-   - "Gather refinement details"
-   - "Update backlog"
-
-3. Present the item and ask what to refine using ask_user_simple:
-   - Question: "How would you like to refine this item?"
-   - Options: "Break into subtasks", "Add details/criteria", "Change priority", "Technical deep-dive"
-
-## REFINEMENT FLOW
-
-Based on user's choice:
-
-### Break into subtasks
-- Use ask_user_simple to ask how many subtasks (2-5)
-- For each subtask, use ask_user_simple to get title
-- Use backlog_write to add new items
-- Optionally update original item status
-
-### Add details/criteria
-- Use ask_user to gather:
-  - Acceptance criteria
-  - Edge cases
-  - Dependencies
-- Use backlog_write to update description
-
-### Change priority
-- Use ask_user_simple with priority options
-- Use backlog_write to update
-
-### Technical deep-dive
-- Use ask_user to gather:
-  - Architecture approach
-  - Technology choices
-  - Risks/concerns
-- Add as new tech-debt item or update description
-
-## RULES
-
-1. ALWAYS use ask_user_simple for single choices
-2. Use ask_user for multi-field input
-3. Update backlog after each decision
-4. Summarize what was changed at the end
-
-## COMPLETION
-✓ Item is refined per user's request
-✓ Backlog is updated
-✓ Changes are summarized`,
-    tags: ['planning', 'requirements'],
-});
-export const architectureSkill = defineSkill({
-    name: 'architecture',
-    description: 'Create architecture documentation (ADRs, diagrams, data models, API designs)',
-    prompt: `You are in ARCHITECTURE MODE. Your goal is to create architecture documentation.
-
-## When to Use
-- Creating ADRs (Architecture Decision Records)
-- Documenting system diagrams
-- Designing data models or API specs
-- Recording technical decisions
-
-## When NOT to Use
-- Need product requirements → use design or prd skill
-- Need to implement features → use build skill
-- Just want to understand existing code → use explain skill
-
-## DOCUMENT TYPE: {{doc_type}}
-{{#if custom_topic}}Custom Topic: {{custom_topic}}{{/if}}
-
-## STARTUP
-
-1. Use todo_write to track your progress:
-   - "Read project context"
-   - "Gather requirements"
-   - "Create document"
-   - "Confirm with user"
-
-2. Read project context:
-   - Check for PRD.md (project vision and requirements)
-   - Use backlog_read with limit:10 for feature overview
-   - Check existing architecture docs to avoid duplicates
-
-## DOCUMENT TEMPLATES
-
-### For ADR (Architecture Decision Record)
-Location: .compilr/architecture/decisions/ADR-NNN-{{slug}}.md or {project}-docs/02-architecture/decisions/ADR-NNN-{{slug}}.md
-
-Use ask_user to gather:
-1. What decision is being documented?
-2. What problem or need prompted this decision?
-3. What alternatives were considered?
-4. What are the trade-offs of the chosen approach?
-
-Template:
-\`\`\`markdown
-# ADR-NNN: {{title}}
-
-**Status:** Proposed | Accepted | Deprecated | Superseded
-**Date:** {{YYYY-MM-DD}}
-**Deciders:** {{who made this decision}}
-
----
-
-## Context
-
-{{What is the issue that we're seeing that is motivating this decision?}}
-
-## Decision
-
-{{What is the change that we're proposing and/or doing?}}
-
-## Consequences
-
-### Positive
-- {{benefit 1}}
-- {{benefit 2}}
-
-### Negative
-- {{trade-off 1}}
-- {{trade-off 2}}
-
-### Risks
-- {{risk 1}}
-
----
-
-## Alternatives Considered
-
-### {{Alternative 1}}
-{{description}}
-**Rejected because:** {{reason}}
-
----
-
-*Generated by /arch*
-\`\`\`
-
-### For System Diagram
-Location: .compilr/architecture/diagrams/{{slug}}.md or {project}-docs/02-architecture/diagrams/{{slug}}.md
-
-Use ask_user to gather:
-1. What are the main components/services?
-2. How do they communicate?
-3. What external integrations exist?
-4. What data flows between components?
-
-Generate a Mermaid diagram with explanation.
-
-### For Data Model
-Location: .compilr/architecture/data-model.md or {project}-docs/02-architecture/data-model.md
-
-Use ask_user to gather:
-1. What are the main entities?
-2. What are the relationships between them?
-3. What are the key fields and constraints?
-
-Generate entity descriptions and a Mermaid ER diagram.
-
-### For API Design
-Location: .compilr/architecture/api-design.md or {project}-docs/02-architecture/api-design.md
-
-Use ask_user to gather:
-1. What resources/endpoints are needed?
-2. What authentication approach?
-3. What are the main request/response formats?
-
-Generate OpenAPI-style documentation.
-
-### For Custom Topic
-Location: .compilr/architecture/{{slug}}.md or {project}-docs/02-architecture/{{slug}}.md
-
-Use ask_user to understand:
-1. What aspect of architecture to document?
-2. What level of detail is needed?
-3. Who is the audience?
-
-Generate appropriate documentation.
-
-## RULES
-
-1. Use ask_user or ask_user_simple for structured input
-2. Read existing docs first to avoid duplicates
-3. For ADRs, auto-number based on existing ADRs in the directory
-4. Create directories if they don't exist
-5. Follow the appropriate template for the document type
-6. Include Mermaid diagrams where helpful
-7. Summarize what was created at the end
-
-## COMPLETION CRITERIA
-✓ Document is created in correct location
-✓ All sections are properly filled in
-✓ Diagrams render correctly (valid Mermaid syntax)
-✓ User has reviewed the output`,
-    tags: ['architecture', 'documentation'],
-});
-export const prdSkill = defineSkill({
-    name: 'prd',
-    description: 'Amend or enhance the Product Requirements Document',
-    prompt: `You are in PRD MODE. Your goal is to update or enhance the existing Product Requirements Document.
-
-## When to Use
-- Updating existing PRD sections
-- Adding new requirements to PRD
-- Refining vision or scope
-
-## When NOT to Use
-- No PRD exists yet → use design skill first
-- Need architecture docs → use architecture skill
-- Need session summary → use session-notes skill
-
-## STARTUP
-
-1. Use todo_write to track your progress:
-   - "Read current PRD"
-   - "Identify section to update"
-   - "Gather updates"
-   - "Write updated PRD"
-
-2. Read the existing PRD.md:
-   - Location: .compilr/requirements/PRD.md or {project}-docs/00-requirements/PRD.md
-   - If no PRD exists, inform the user to run /design first
-
-3. Present current PRD sections to user using ask_user_simple:
-   - Question: "Which section would you like to update?"
-   - Options based on PRD structure (Vision, Scope, Technical, Success Criteria)
-
-## PRD STRUCTURE
-
-The PRD has these sections that can be updated:
-
-### 1. Vision
-- Problem Statement
-- Target Users
-- Value Proposition
-- Differentiation
-
-### 2. Scope
-- MVP Features (v1)
-- Future Features (v2+)
-- Out of Scope
-
-### 3. Technical Context
-- Integrations
-- Constraints (Performance, Scale, Compliance)
-- Tech Stack
-
-### 4. Success Criteria
-- How do we know when this is done?
-
-## UPDATE FLOW
-
-Based on section selected:
-
-1. Show current content of that section
-2. Use ask_user to gather:
-   - What to add/change
-   - What to remove
-   - Any clarifications
-3. Use the edit tool to update PRD.md
-4. Show the updated section for confirmation
-
-## RULES
-
-1. ALWAYS read the existing PRD first
-2. Use ask_user_simple for section selection
-3. Use ask_user for gathering detailed updates
-4. Preserve sections you're not updating
-5. Use edit tool (not write_file) to update specific sections
-6. Keep formatting consistent with existing document
-7. If scope changes affect backlog, suggest running /refine
-
-## COMPLETION CRITERIA
-✓ PRD.md is updated with changes
-✓ User has reviewed the updates
-✓ Related backlog updates are suggested if needed`,
-    tags: ['planning', 'requirements'],
-});
-export const sessionNotesSkill = defineSkill({
-    name: 'session-notes',
-    description: 'Create structured session notes capturing work done and decisions made',
-    prompt: `You are in SESSION NOTES MODE. Your goal is to create a structured summary of the current session.
-
-## When to Use
-- End of a work session
-- User asks to document what was done
-- Need to capture decisions for future reference
-
-## When NOT to Use
-- Need product requirements → use prd skill
-- Need architecture docs → use architecture skill
-- In the middle of active work
-
-## STARTUP
-
-1. Use todo_write to track your progress:
-   - "Gather session context"
-   - "Write session note"
-   - "Confirm with user"
-
-2. Review recent conversation to understand:
-   - What was accomplished
-   - What files were changed
-   - What decisions were made
-   - What blockers were encountered
-   - What should be done next
-
-## SESSION NOTE STRUCTURE
-
-Create a markdown file with this structure:
-
-\`\`\`markdown
-# Session Note - {{title}}
-
-**Date:** {{YYYY-MM-DD}}
-**Project:** {{project_name}}
-
----
-
-## Summary
-
-{{2-3 sentence summary of what was accomplished}}
-
-## Changes Made
-
-- {{list of files created/modified}}
-- {{features implemented}}
-- {{bugs fixed}}
-
-## Decisions Made
-
-- {{architectural decisions}}
-- {{technology choices}}
-- {{scope changes}}
-
-## Blockers / Issues
-
-- {{problems encountered}}
-- {{unresolved questions}}
-
-## Next Steps
-
-- [ ] {{actionable next task}}
-- [ ] {{follow-up item}}
-
----
-
-*Generated by /note*
-\`\`\`
-
-## FILE LOCATION
-
-Save the note to:
-- Single repo: \`.compilr/sessions/{{YYYY-MM-DD}}-{{slug}}.md\`
-- Two repo: \`{{project}}-docs/04-session-notes/{{YYYY-MM-DD}}-{{slug}}.md\`
-
-Create the directory if it doesn't exist.
-
-## RULES
-
-1. Use ask_user_simple to ask for a title if not provided
-2. Keep summary concise (2-3 sentences max)
-3. List concrete changes, not vague descriptions
-4. Decisions should explain the "why"
-5. Next steps should be actionable
-6. If user provides a title, use it; otherwise generate one from the summary
-
-## COMPLETION CRITERIA
-✓ Session note file is created
-✓ All sections are filled in
-✓ User has reviewed the note`,
-    tags: ['documentation', 'session'],
-});
-// =============================================================================
-// From @compilr-dev/agents-coding-core (2 skills)
-// =============================================================================
-export const buildSkill = defineSkill({
-    name: 'build',
-    description: 'Implement a backlog item end-to-end',
-    tags: ['implementation', 'coding'],
-    prompt: `You are in BUILD MODE. Implement the specified backlog item.
-
-## When to Use
-- Implementing a specific backlog item
-- User says "build FEAT-001" or similar
-- Ready to write code for a feature
-
-## When NOT to Use
-- Item is too vague → use refine-item skill first
-- No backlog exists → use design or sketch skill
-- Just exploring code → use code-navigation skill
-- Need to fix a bug → use debug skill
-
-## CRITICAL: PROJECT DIRECTORY
-
-**All files MUST be created/modified in: {{projectPath}}**
-
-Use ABSOLUTE paths for ALL file operations. Example:
-- write_file({ path: "{{projectPath}}/src/feature.ts", ... })
-- edit({ path: "{{projectPath}}/src/index.ts", ... })
-
-NEVER use relative paths. NEVER use process.cwd().
-
-## ITEM TO IMPLEMENT
-- **ID:** {{item_id}}
-- **Title:** {{item_title}}
-- **Type:** {{item_type}}
-- **Priority:** {{item_priority}}
-- **Description:** {{item_description}}
-
-## BEFORE STARTING
-
-1. Show the item details to the user in a clear format
-2. Use ask_user_simple to confirm: "Proceed with implementation?"
-   - Options: "Yes, let's build it", "No, pick a different item", "Cancel"
-3. If there are dependency warnings, mention them and ask if user wants to proceed anyway
-
-## CONTEXT TO READ
-
-Before implementing, read these files for context:
-- **PRD.md** (if exists): Project vision and requirements
-- **CLAUDE.md**: Coding standards and conventions
-- **Existing code**: Understand patterns already in use
-
-## IMPLEMENTATION WORKFLOW
-
-### Phase 1: Plan
-1. Use todo_write to create implementation checklist:
-   - Break down the item into concrete tasks
-   - Identify files to create or modify
-   - Note any edge cases to handle
-2. Update backlog status to 🚧 using backlog_write
-
-### Phase 2: Implement
-1. Write code following project conventions from CLAUDE.md
-2. Add tests if the project has a test framework
-3. Keep changes focused on the backlog item scope
-4. Use todo_write to track progress through tasks
-
-### Phase 3: Verify
-1. Run tests with run_tests tool
-2. Run lint with run_lint tool
-3. If tests or lint fail:
-   - Analyze the error message
-   - Fix the issue
-   - Re-run verification
-   - Repeat up to 3 times
-4. If still failing after 3 attempts:
-   - Report the issue to user
-   - Keep status as 🚧
-   - Ask for guidance
-
-### Phase 4: Complete
-1. Update backlog status to ✅ using backlog_write
-2. Create git commit with message format:
-   - feat({{item_id}}): {{item_title}} - for features
-   - fix({{item_id}}): {{item_title}} - for bugs
-   - chore({{item_id}}): {{item_title}} - for chores
-3. Update backlog with the commit SHA
-4. Clear todos with todo_write
-5. Summarize what was implemented
-
-## RULES
-
-- Follow coding standards from CLAUDE.md strictly
-- Keep commits atomic - one backlog item per commit
-- Ask user via ask_user_simple if you hit blockers
-- Don't over-engineer - implement exactly what the item describes
-- Don't add features beyond what was requested
-- Use todo_write throughout to show progress
-- Always run tests before marking complete`,
-    version: '1.0.0',
-});
-export const scaffoldSkill = defineSkill({
-    name: 'scaffold',
-    description: 'Create project foundation based on tech stack',
-    tags: ['setup', 'foundation', 'scaffolding'],
-    prompt: `You are creating the PROJECT SCAFFOLD (foundation).
-
-## When to Use
-- Starting a new project from scratch
-- CHORE-001 scaffolding item in backlog
-- Need basic project structure
-
-## When NOT to Use
-- Project already has structure → use build skill
-- Need requirements first → use design skill
-- Modifying existing project → use appropriate skill
-
-## FACTORY CHECK (TRY THIS FIRST)
-
-Before manual scaffolding, check if the factory can auto-generate the project:
-
-1. Call \`app_model_get\` with \`{ "scope": "summary" }\` to check for an existing Application Model.
-   - If model exists with entities → use factory path: preview with \`factory_scaffold({ "dry_run": true })\`, confirm with user, then generate with \`factory_scaffold({ "output_dir": "{{projectPath}}" })\`.
-   - Skip the manual scaffold below entirely.
-
-2. If NO model exists, check project documents for entity patterns:
-   - Read PRD with \`project_document_get({ "doc_type": "prd" })\`
-   - If PRD mentions managing/tracking things (entities, CRUD, data types) → ask user:
-     "Your project involves managing [entities]. I can auto-generate a working app. Want me to use the factory? (Yes = build model + generate / No = manual scaffold)"
-   - If Yes → call \`factory_list_toolkits\` to show options, then build the model with \`app_model_update\` operations (set identity, techStack, add entities with fields, add relationships, set features/theme/layout), validate with \`app_model_validate\`, generate with \`factory_scaffold({ "output_dir": "{{projectPath}}" })\`.
-
-3. If no entities detected or user declines factory → proceed with MANUAL SCAFFOLD below.
-
----
-
-## MANUAL SCAFFOLD (if factory not applicable)
-
-## CRITICAL: PROJECT DIRECTORY
-
-**All files MUST be created in: {{projectPath}}**
-
-Use ABSOLUTE paths for ALL file operations. Example:
-- write_file({ path: "{{projectPath}}/package.json", ... })
-- write_file({ path: "{{projectPath}}/src/index.ts", ... })
-
-NEVER use relative paths. NEVER use process.cwd().
-
-## PURPOSE
-
-Create the base project structure that features will be built on top of.
-This is the skeleton that makes feature implementation possible.
-
-## CONTEXT TO READ
-
-Use project_document_get to read project documents from the database:
-- PRD document for project vision and requirements
-- Architecture documents if they exist
-
-## BEFORE STARTING
-
-1. Summarize the detected/specified tech stack
-2. Use ask_user_simple to confirm: "Create project scaffold with this stack?"
-   - Options: "Yes, create it", "No, let me specify", "Cancel"
-3. If user wants to specify, ask about tech stack preferences
-
-## SCAFFOLD BY PROJECT TYPE
-
-### Web Application (React/Vue/Svelte)
-
-Create:
-- \`src/\` folder structure:
-  - \`src/components/\` - Reusable components
-  - \`src/pages/\` or \`src/routes/\` - Page components
-  - \`src/lib/\` or \`src/utils/\` - Utility functions
-  - \`src/styles/\` - Global styles
-- \`package.json\` with dependencies
-- Build config (\`vite.config.ts\`, \`next.config.js\`, etc.)
-- \`index.html\` entry point (if applicable)
-- Basic App component with routing setup
-- CSS/Tailwind configuration
-- \`.gitignore\`
-- \`README.md\` with setup instructions
-
-### API / Backend (Node/Python/Go)
-
-Create:
-- \`src/\` folder structure:
-  - \`src/routes/\` or \`src/api/\` - API endpoints
-  - \`src/services/\` - Business logic
-  - \`src/models/\` - Data models
-  - \`src/utils/\` - Utilities
-- \`package.json\` / \`requirements.txt\` / \`go.mod\`
-- Entry point (\`src/index.ts\`, \`main.py\`, \`main.go\`)
-- Basic server setup (Express, FastAPI, Gin, etc.)
-- Health check endpoint (\`GET /health\`)
-- Environment config (\`.env.example\`)
-- \`.gitignore\`
-- \`README.md\` with setup instructions
-
-### CLI Tool (Node/Python/Rust)
-
-Create:
-- \`src/\` folder structure:
-  - \`src/commands/\` - Command handlers
-  - \`src/utils/\` - Utilities
-- \`package.json\` with \`bin\` entry / \`setup.py\` / \`Cargo.toml\`
-- Entry point with argument parsing
-- Basic command structure (help, version)
-- \`.gitignore\`
-- \`README.md\` with usage instructions
-
-### Full-Stack Application
-
-Create both frontend and backend structures:
-- \`frontend/\` or \`client/\` - Web app scaffold
-- \`backend/\` or \`server/\` - API scaffold
-- Root \`package.json\` with workspace config (if monorepo)
-- \`docker-compose.yml\` (optional)
-- \`.gitignore\`
-- \`README.md\` with setup instructions
-
-## POST-SCAFFOLD STEPS
-
-1. Install dependencies:
-   - \`npm install\` / \`pip install -r requirements.txt\` / etc.
-2. Run build to verify:
-   - \`npm run build\` / equivalent
-3. Run lint to verify:
-   - \`npm run lint\` / equivalent
-4. Create initial git commit:
-   - \`chore: initial project scaffold\`
-5. Update backlog:
-   - Mark scaffold CHORE as ✅ (if exists)
-
-## RULES
-
-- Follow conventions from CLAUDE.md
-- Use modern, widely-adopted patterns
-- Keep it minimal - only what's needed to start
-- Don't add features - just structure
-- Ensure the project builds and lints clean
-- Add helpful comments in config files
-- Include TypeScript/type hints where applicable`,
-    version: '1.0.0',
-});
-// =============================================================================
-// Research Skills
-// =============================================================================
-export const outlineSkill = defineSkill({
-    name: 'outline',
-    description: 'Build or refine the research paper structure — sections, claims, source mapping',
-    prompt: `You are in OUTLINE MODE. Your goal is to help the user build or refine a structured outline for their research paper using the Research Model.
-
-## When to Use
-- Starting a new research paper — no outline exists yet
-- Restructuring an existing paper — user wants to reorganize sections
-- Evolving a paper — new sources or insights change the direction
-- Importing structure — user has an existing paper and wants to model it
-
-## Step 1: Assess Current State
-
-Start by reading the current state:
-1. Use \`research_model_get\` with scope: "overview" to check if a model exists
-2. If it exists, review sections, questions, and sources already defined
-3. Check the Knowledge Base (read pinned content) for available sources
-4. Check existing work items with \`workitem_query\`
-
-Tell the user what you found:
-- "You have X sections, Y sources, Z research questions defined" (if model exists)
-- "No research model found yet — let's build one from scratch" (if new)
-
-## Step 2: Gather Context (only ask what you don't already know)
-
-Ask in batches of 2-3 questions:
-- **Research topic:** What is the main topic or research question?
-- **Scope:** What type of paper? (journal article, thesis chapter, full thesis, literature review, lab report)
-- **Citation style:** APA, MLA, Chicago, IEEE, Harvard?
-- **Audience:** Who is this for? (academic journal, conference, class assignment)
-- **Constraints:** Any required sections or structure mandated by the target venue?
-
-If the model already has a title and citation style set, skip those questions.
-
-After gathering answers, save the metadata:
-- \`research_model_update\` with op: "set_title"
-- \`research_model_update\` with op: "set_citation_style"
-- \`research_model_update\` with op: "set_authors" (if provided)
-- \`research_model_update\` with op: "set_keywords" (if provided)
-
-## Step 3: Propose Research Questions
-
-Based on the topic and available sources, propose:
-- One main research question
-- 2-4 sub-questions the paper will address
-
-Present them to the user for review. After confirmation, save each:
-- \`research_model_update\` with op: "question_add", question: { question: "..." }
-
-## Step 4: Propose Section Structure
-
-Based on the questions, scope, and sources, propose an outline. Adapt to the paper type:
-
-**Journal article (5-7 sections):**
-1. Introduction — state the problem, thesis, and contribution
-2. Literature Review / Related Work — what's known, what's the gap
-3. Methodology — research approach
-4. Results / Findings — present the evidence
-5. Discussion — interpret results, implications, limitations
-6. Conclusion — summarize contributions, future work
-
-**Thesis (chapters with subsections):**
-- Chapters as top-level sections, subsections as children
-- Include: Abstract, Acknowledgments if appropriate
-
-**Literature review (thematic):**
-- Organized by themes, not methodology/results
-- Each theme is a section with sub-themes as subsections
-
-**Lab report:**
-- Hypothesis, Method, Results, Discussion, Conclusion
-
-Present the outline to the user. For each section include:
-- Title
-- Purpose (what this section argues or establishes — not just "discusses X" but "argues that X because Y")
-- Estimated word count (if appropriate for the scope)
-
-After user confirms/adjusts, save each section:
-- \`research_model_update\` with op: "section_add", section: { title, purpose, order, parentId, targetWordCount }
-
-For subsections, use parentId referencing the parent section's ID.
-
-## Step 5: Map Sources to Sections (if sources exist in KB)
-
-If the Knowledge Base has sources:
-1. Review available source descriptions/pinned content
-2. For each section, suggest which sources might be relevant
-3. Create initial claim sketches for key arguments
-4. Link sources to claims
-
-For each claim:
-- \`research_model_update\` with op: "claim_add", sectionId: "...", claim: { statement: "..." }
-
-For each source link (only if source is already in the model):
-- \`research_model_update\` with op: "claim_link_source", sectionId: "...", claimId: "...", sourceRef: { sourceId: "..." }, relation: "supporting"
-
-If no sources exist yet, skip this step and note: "Add sources to the Knowledge Base and run /literature-review to link them."
-
-## Step 6: Generate Work Items
-
-Create one work item per section:
-- Use \`workitem_create\` for each section
-- Type: "feature" (displayed as "Section" in research projects)
-- Title: "Draft: {section title}"
-- Description: Include section purpose, key claims to address, relevant sources
-- Priority based on writing order:
-  - Methodology → high (write first, grounds the paper)
-  - Literature Review → high (needed early)
-  - Results / Findings → medium
-  - Discussion → medium
-  - Introduction → low (easier to write once you know what you're introducing)
-  - Conclusion → low (summary of everything else)
-
-## Step 7: Validate and Summarize
-
-1. Run \`research_model_validate\` to check for issues
-2. Present a summary:
-   - Paper title and scope
-   - Research questions
-   - Section outline with purposes
-   - Source mapping (if any)
-   - Work items created
-   - Any warnings from validation (unsupported claims, empty sections — expected at this stage)
-
-## Rules
-- This is INTERACTIVE. Ask questions, propose, get feedback, iterate. Do NOT generate the entire outline in one shot.
-- Respect existing model state. If sections already exist, propose modifications rather than replacing everything.
-- Each section's purpose should clearly state what it argues or establishes.
-- Claims are hypotheses at this stage — mark them as unsupported until sources are linked.
-- Use the ask_user tool to present options when choices are needed.
-- If the user says "skip" or "later", move to the next step.
-- Total interaction should be 8-15 questions max.
-
-## Completion Criteria
-✓ Paper title and citation style are set
-✓ Research questions are defined
-✓ Section structure matches the paper scope
-✓ Each section has a clear purpose
-✓ Sources mapped to sections (if available)
-✓ Work items created for each section
-✓ Model validates without structural errors
-✓ User has reviewed and approved the outline`,
-    tags: ['research', 'planning', 'outline'],
-});
-export const literatureReviewSkill = defineSkill({
-    name: 'literature-review',
-    description: 'Analyze sources from the Knowledge Base — extract findings, link to claims, identify gaps',
-    prompt: `You are in LITERATURE REVIEW MODE. Your goal is to systematically analyze the sources in the Knowledge Base and connect them to the Research Model's sections and claims.
-
-## When to Use
-- Sources have been added to the Knowledge Base but not yet analyzed
-- The Research Model has sections/claims that need source support
-- User wants to understand how sources relate to their argument
-- User wants to identify gaps in their source coverage
-
-## Prerequisites
-- A Research Model should exist (run /outline first if not)
-- Sources should be in the Knowledge Base (upload PDFs, paste text, or import URLs)
-
-## Step 1: Assess Current State
-
-1. Use \`research_model_get\` with scope: "overview" to see the current model
-2. Use \`research_model_get\` with scope: "sources" to see which sources are already registered and analyzed
-3. Review the Knowledge Base content (pinned items are in context; read non-pinned files as needed)
-
-Report to the user:
-- "You have X sources in the model, Y analyzed, Z unanalyzed"
-- "The Knowledge Base has N files available"
-- "X claims currently lack source support"
-
-## Step 2: Register New Sources
-
-For each KB document not yet in the Research Model:
-1. Read the document content (use \`read_file\` if not pinned)
-2. Extract citation information: authors, title, year, venue, type
-3. Register it: \`research_model_update\` with op: "source_add", source: { citeKey, citation: { type, title, authors, year, venue } }
-4. Note: generate a short, memorable citeKey (e.g., "smith2024", "jones-ml-2023")
-
-Ask the user to confirm the extracted citation info for each source, or batch-confirm if there are many.
-
-## Step 3: Analyze Each Source
-
-For each unanalyzed source:
-1. Read the full content from the KB
-2. Extract key findings relevant to the paper's research questions
-3. Identify the source's methodology and limitations
-4. Determine relevance: primary (directly addresses research questions), secondary (provides context), or background (general knowledge)
-5. Update the source: \`research_model_update\` with op: "source_update", sourceId: "...", updates: { keyFindings: [...], relevance: "primary|secondary|background", analyzed: true, tags: [...] }
-
-Present a summary of each source's key findings to the user.
-
-## Step 4: Link Sources to Claims
-
-For each section in the model:
-1. Read the section's existing claims (\`research_model_get\` with sectionId)
-2. For each claim, identify which analyzed sources support or contradict it
-3. Link them: \`research_model_update\` with op: "claim_link_source", sectionId, claimId, sourceRef: { sourceId, relevance: "brief note" }, relation: "supporting" or "contradicting"
-4. Update evidence strength based on the linked sources:
-   - strong: multiple supporting sources, no contradictions
-   - moderate: at least one supporting source
-   - weak: tangential support only
-   - contested: sources disagree
-   - unsupported: no sources linked
-
-If a source suggests a claim that doesn't exist yet, propose adding it:
-- \`research_model_update\` with op: "claim_add", sectionId, claim: { statement, type: "derived" }
-
-## Step 5: Identify Gaps
-
-After linking sources to claims, analyze gaps:
-1. Run \`research_model_validate\` to get warnings
-2. Report:
-   - **Unsupported claims** — claims with no source references (need more sources or should be marked as original analysis)
-   - **Orphan sources** — sources not linked to any claim (may not be relevant, or claims are missing)
-   - **Thin sections** — sections with few claims or few sources
-   - **Missing perspectives** — if all sources agree, note the lack of counter-arguments
-
-Suggest next steps:
-- "Section X needs more sources on [topic] — consider searching for..."
-- "Source Y has findings relevant to Section Z but no claim captures this yet"
-- "The paper lacks counter-arguments on [claim] — consider adding a limitations discussion"
-
-## Step 6: Synthesize Themes
-
-If multiple sources have been analyzed, provide a thematic synthesis:
-- Group sources by the themes they address
-- Note where sources agree, where they disagree, and what's novel
-- Map themes to research questions
-- Suggest how themes should be organized in the Literature Review section
-
-## Rules
-- Analyze sources ONE AT A TIME — don't rush through multiple sources
-- Ask the user to confirm citation info before saving (batch OK for many sources)
-- Always distinguish between the source's claims and the user's interpretation
-- Note methodological differences between sources when relevant
-- Use citeKeys consistently when referencing sources
-- If a source is irrelevant to the research, say so — not every KB file needs to be in the model
-- Keep evidence strength assessments conservative — "moderate" is better than over-claiming "strong"
-
-## Completion Criteria
-✓ All relevant KB sources are registered in the model
-✓ Each source has been analyzed (keyFindings, relevance, tags)
-✓ Sources are linked to relevant claims
-✓ Evidence strength updated for linked claims
-✓ Gaps identified and reported
-✓ User has reviewed the source-claim mappings`,
-    tags: ['research', 'analysis', 'sources'],
-});
-export const draftSectionSkill = defineSkill({
-    name: 'draft-section',
-    description: 'Draft a paper section using the outline, claims, and linked sources',
-    prompt: `You are in DRAFT SECTION MODE. Your goal is to write or revise a section of the research paper, guided by the Research Model's outline, claims, and linked sources.
-
-## When to Use
-- A section has status "outlined" and needs its first draft
-- A section needs revision based on reviewer feedback
-- The user wants to expand a section with more detail
-
-## Step 1: Select the Section
-
-1. Use \`research_model_get\` with scope: "sections" to see all sections and their status
-2. If the user didn't specify which section, suggest the next logical one:
-   - Methodology first (grounds the paper)
-   - Literature Review (needed early)
-   - Results / Findings (core content)
-   - Discussion (interpretation)
-   - Introduction and Conclusion last (summaries)
-3. Confirm the section choice with the user
-
-## Step 2: Gather Section Context
-
-For the chosen section:
-1. Use \`research_model_get\` with sectionId to get the section's purpose, claims, and notes
-2. Read any existing draft file (if the section has been drafted before)
-3. For each claim with linked sources, read the source content from KB to understand the evidence
-4. Check the citation style from the model: \`research_model_get\` with scope: "overview"
-
-Summarize to the user:
-- "Section: {title}"
-- "Purpose: {purpose}"
-- "Claims to address: {list}"
-- "Sources available: {list with citeKeys}"
-
-## Step 3: Draft the Section
-
-Write the section following these guidelines:
-
-**Structure:**
-- Start with a topic sentence that states the section's purpose
-- Address each claim in the section in a logical order
-- Use transitions between paragraphs
-- End with a connection to the next section (or summary for final sections)
-
-**Citations:**
-- Use the project's citation style for in-text citations
-- APA: (Author, Year) or Author (Year)
-- MLA: (Author Page) or Author (Page)
-- IEEE: [citeKey] or [N]
-- Chicago: (Author Year) or Author (Year)
-- Harvard: (Author Year) or Author (Year)
-- Cite sources for every non-original claim
-- When multiple sources support a claim, cite them together
-
-**Academic Tone:**
-- Formal but clear — avoid jargon without definition
-- Use hedging language where appropriate ("suggests", "indicates", "appears to")
-- Distinguish between established facts and interpretations
-- Use active voice for the author's contributions, passive for general findings
-
-**Length:**
-- Respect the section's targetWordCount if set
-- If not set, aim for appropriate length based on scope:
-  - Journal article section: 500-1500 words
-  - Thesis chapter: 2000-5000 words
-  - Literature review section: 800-2000 words
-
-## Step 4: Write the File
-
-1. Determine the file path: \`{project_path}/sections/{section_order}-{section_slug}.md\`
-   - e.g., \`sections/01-introduction.md\`, \`sections/03-methodology.md\`
-2. Write the draft using \`write_file\` or \`edit_file\` (if revising)
-3. Include a header comment: \`<!-- Section: {title} | Status: drafted | Rev: {model revision} -->\`
-
-## Step 5: Update the Model
-
-After writing:
-1. Update section status: \`research_model_update\` with op: "section_update", sectionId, updates: { status: "drafted", actualWordCount: N }
-2. If new claims emerged during writing, add them: \`research_model_update\` with op: "claim_add"
-3. If evidence strength changed based on closer reading, update claims
-
-## Step 6: Generate Bibliography (if needed)
-
-If this is the first section being drafted or the user requests it:
-1. Use \`bibliography_generate\` with format: "markdown" to produce the references list
-2. Write it to \`{project_path}/sections/references.md\`
-
-## Step 7: Summary
-
-Report to the user:
-- Section drafted: title, word count, file path
-- Claims addressed: list with evidence strength
-- Citations used: list of citeKeys
-- Suggestions: any gaps noticed, claims that need more support
-
-## Rules
-- NEVER fabricate citations — only cite sources that exist in the Research Model
-- If a claim lacks source support, note it explicitly rather than inventing a reference
-- Maintain consistency with previously drafted sections (terminology, tense, voice)
-- If the section has subsections in the model, draft them as ## subheadings
-- Read existing drafted sections first to maintain consistent style
-- Ask the user about tone preferences if this is the first section being drafted
-
-## Completion Criteria
-✓ Section file written with proper citations
-✓ Model updated (status: drafted, actualWordCount)
-✓ All claims in the section are addressed in the text
-✓ In-text citations match the project's citation style
-✓ User has reviewed the draft`,
-    tags: ['research', 'writing', 'drafting'],
-});
-export const peerReviewSkill = defineSkill({
-    name: 'peer-review',
-    description: 'Validate argument structure, find logical gaps, check consistency across sections',
-    prompt: `You are in PEER REVIEW MODE. Your goal is to critically evaluate the research paper's argument structure, identify gaps, and check consistency — like an academic peer reviewer.
-
-## When to Use
-- One or more sections have been drafted
-- The user wants feedback before submitting/finalizing
-- After significant revisions to check nothing was broken
-- To identify areas that need more work
-
-## Step 1: Assess What's Available
-
-1. Use \`research_model_get\` with scope: "overview" for the big picture
-2. Use \`research_model_get\` with scope: "sections" to see status of each section
-3. Run \`research_model_validate\` for structural issues and warnings
-
-Report to the user:
-- "X sections drafted, Y still outlined, Z sources linked"
-- Any structural errors from validation
-- Which sections are ready for review
-
-If no sections are drafted yet, tell the user: "There's nothing to review yet — run /draft-section first."
-
-## Step 2: Argument Structure Review
-
-Read each drafted section (use \`read_file\` on the section files) and evaluate:
-
-**Thesis & Research Questions:**
-- Is the main thesis clearly stated in the Introduction?
-- Does each section contribute to answering the research questions?
-- Are the research questions actually addressed by the paper's content?
-
-**Logical Flow:**
-- Does the argument progress logically from Introduction → Literature Review → Methodology → Results → Discussion → Conclusion?
-- Does each section build on what came before?
-- Are there logical jumps or non-sequiturs between sections?
-
-**Claim Validation:**
-For each claim in the Research Model:
-- Is it actually stated in the draft text?
-- Is it supported by the cited sources?
-- Is the evidence strength rating accurate given the sources?
-- Are there unsupported assertions presented as established facts?
-
-Rate each issue found:
-- **Critical** — breaks the argument (e.g., unsupported central claim, circular reasoning)
-- **Major** — weakens the argument significantly (e.g., missing counter-arguments, logical gap)
-- **Minor** — should be fixed but doesn't break the argument (e.g., vague language, minor inconsistency)
-
-## Step 3: Gap Detection
-
-Check for missing elements:
-
-**Source Gaps:**
-- Claims that should have citations but don't
-- Sections that rely on very few sources
-- Important counter-arguments not addressed
-- Methodology claims without justification
-
-**Structural Gaps:**
-- Research questions not addressed by any section
-- Sections that don't connect to the overall argument
-- Missing limitations discussion
-- Missing future work section (if appropriate)
-
-**Content Gaps:**
-- Definitions used but never introduced
-- Acronyms used without expansion
-- Figures/tables referenced but not present
-- Promises made in the Introduction but not delivered
-
-## Step 4: Consistency Check
-
-Across all drafted sections, check:
-
-**Terminology:**
-- Is the same concept referred to consistently? (e.g., not "users" in one place and "participants" in another without reason)
-- Are technical terms used with consistent meaning?
-
-**Tense:**
-- Literature review: past tense for completed studies
-- Methodology: past tense for what was done, present for general statements
-- Results: past tense for findings
-- Discussion: present tense for interpretations
-
-**Voice & Tone:**
-- Is the level of formality consistent?
-- Is the author's voice consistent (not shifting between confident and hedging without reason)?
-
-**Numbers & Data:**
-- Do statistics match between text and any tables/figures?
-- Are numbers formatted consistently?
-
-## Step 5: Cross-Reference Check
-
-- "As discussed in Section X" — does Section X actually discuss that?
-- "See Table N" / "See Figure N" — do they exist?
-- Citations in text match sources in the Research Model
-- Consistent use of citation style throughout
-
-## Step 6: Generate Review Report
-
-Structure the report as:
-
-### Strengths
-- What the paper does well (2-3 points)
-
-### Critical Issues
-- Issues that must be addressed (with specific locations)
-
-### Major Issues
-- Significant improvements needed
-
-### Minor Issues
-- Small fixes and suggestions
-
-### Recommendations
-- Prioritized list of what to fix first
-- Suggested order of revisions
-
-Write the report to \`{project_path}/reviews/peer-review-{date}.md\`
-
-## Step 7: Update Model
-
-For issues that affect the Research Model:
-1. Update claim evidence strength if ratings were inaccurate
-2. Add new claims if the review identified missing arguments
-3. Create work items (type: "bug" / displayed as "Revision") for each critical and major issue:
-   - \`workitem_create\` with type: "bug", title: "Review: {brief issue}", description: detailed issue + suggested fix
-
-## Rules
-- Be constructive, not destructive — every critique should include a suggestion for improvement
-- Reference specific sections, claims, and sources by ID/citeKey
-- Don't rewrite the paper — point out issues and let the author fix them
-- Distinguish between opinion ("I would suggest...") and errors ("This claim is unsupported")
-- If the argument is sound, say so — don't manufacture problems
-- Focus on the argument, not the writing style (that's the Editor's job)
-
-## Completion Criteria
-✓ All drafted sections reviewed
-✓ Argument structure evaluated (thesis, logical flow, claim support)
-✓ Gaps identified (source, structural, content)
-✓ Consistency checked (terminology, tense, cross-references)
-✓ Review report written to file
-✓ Revision work items created for critical/major issues
-✓ User has received the review summary`,
-    tags: ['research', 'review', 'quality'],
-});
-export const researchScaffoldSkill = defineSkill({
-    name: 'research-scaffold',
-    description: 'Scaffold a research paper project from a template (APA, IEEE, Thesis, Literature Review, Lab Report)',
-    prompt: `You are in RESEARCH SCAFFOLD MODE. Your goal is to help the user set up a new research paper project using a template.
-
-## Available Templates
-
-| Template | ID | Best For |
-|----------|-----|----------|
-| APA Research Paper | \`apa-paper\` | Social sciences, psychology, education |
-| IEEE Conference Paper | \`ieee-paper\` | Engineering, computer science |
-| Thesis / Dissertation | \`thesis\` | Graduate work, multi-chapter |
-| Literature Review | \`literature-review\` | Standalone review papers |
-| Lab Report | \`lab-report\` | Scientific experiments |
-
-## Step 1: Gather Info
-
-Ask the user (if not already provided):
-1. What is the paper topic / title?
-2. Which template best fits their needs? (describe the options briefly)
-3. What citation style? (default depends on template — APA for most, IEEE for engineering)
-
-## Step 2: Scaffold
-
-Call the \`research_scaffold\` tool with:
-- \`template\`: the template ID
-- \`title\`: the paper title
-- \`citation_style\`: if different from template default
-- \`output_dir\`: the project path
-
-This creates:
-- A Research Model with pre-defined sections
-- Folder structure (sections/, figures/, references/, knowledge/)
-- Section stub files (one per section)
-- COMPILR.md with project context
-- Bibliography file (.bib)
-- Work items for each section (type: "Section")
-
-## Step 3: Confirm and Guide
-
-After scaffolding, tell the user:
-- What was created (sections, files, work items)
-- Suggested next steps:
-  1. "Add your source material to the Knowledge Base"
-  2. "Run /outline to customize the section structure"
-  3. "Run /literature-review to analyze your sources"
-  4. "Run /draft-section to start writing"
-
-## Rules
-- If a Research Model already exists, warn the user and don't overwrite
-- Use dry_run first if the user seems uncertain
-- The scaffold is a starting point — the user can customize everything after`,
-    tags: ['research', 'scaffold', 'setup'],
-});
-// =============================================================================
-// Business Plan Skills
-// =============================================================================
-export const businessVisionSkill = defineSkill({
-    name: 'business-vision',
-    description: 'Define the business identity, problem, solution, and value proposition',
-    prompt: `You are in BUSINESS VISION MODE. Help the user define and articulate their business idea.
-
-## Step 1: Assess Current State
-1. Use \`business_model_get\` with scope: "identity" to check if a model exists
-2. Report what's already defined
-
-## Step 2: Gather Core Information
-Ask in batches (only what's not already defined):
-- **Business name** and tagline
-- **Problem**: What specific pain point do your target customers experience?
-- **Solution**: How does your product/service solve this?
-- **Unique value**: Why you instead of alternatives? What's the unfair advantage?
-- **Target customer**: Who specifically are you building for?
-- **Stage**: idea, pre-seed, seed, series-a, growth, or established?
-- **Industry/sector**
-
-## Step 3: Craft the Value Proposition
-Help refine the problem-solution-uniqueValue into a compelling narrative:
-- Problem should be specific and relatable
-- Solution should directly address the problem
-- Unique value should differentiate from ALL alternatives (including doing nothing)
-
-## Step 4: Save to Model
-- \`business_model_update\` with op: "set_identity" for name, tagline, mission, stage, industry, sector
-- \`business_model_update\` with op: "set_value_proposition" for problem, solution, uniqueValue, targetCustomer
-
-## Step 5: Suggest Next Steps
-After saving, suggest:
-- "Run /market-analysis to size your market and define customer segments"
-- "Run /competitor-analysis to map the competitive landscape"
-
-## Rules
-- Interactive — ask questions, don't assume
-- Push back on vague answers ("everyone" is not a target customer)
-- A good value proposition is specific, measurable, and defensible`,
-    tags: ['business', 'planning', 'vision'],
-});
-export const marketAnalysisSkill = defineSkill({
-    name: 'market-analysis',
-    description: 'Analyze market size, trends, and customer segments',
-    prompt: `You are in MARKET ANALYSIS MODE. Help the user understand their market.
-
-## Step 1: Assess Current State
-1. Use \`business_model_get\` with scope: "overview" for context
-2. Use \`business_model_get\` with scope: "market" for existing market data
-3. Check Knowledge Base for market research sources
-
-## Step 2: Define Customer Segments
-For each segment:
-- Name and description
-- Estimated size (number of potential customers or revenue opportunity)
-- Key pain points (what problems they face)
-- Willingness to pay
-
-Save each: \`business_model_update\` with op: "segment_add", segment: { name, description, size, painPoints, willingness }
-
-## Step 3: Market Sizing
-Guide through TAM/SAM/SOM:
-- **TAM** (Total Addressable Market): If everyone who could use your product did, how big is the market?
-- **SAM** (Serviceable Addressable Market): Realistically, which portion can you reach?
-- **SOM** (Serviceable Obtainable Market): In the first 1-3 years, what share can you capture?
-
-Each should have a value (e.g., "$4.2B"), description, and source.
-Save: \`business_model_update\` with op: "set_market_size", market_size: { tam: {...}, sam: {...}, som: {...} }
-
-## Step 4: Trends and Growth
-- Identify 3-5 market trends relevant to the business
-- Estimate market growth rate
-Save: \`business_model_update\` with op: "set_market_size", market_size: { trends: [...], growthRate: "..." }
-
-## Step 5: Generate Work Items
-Create Milestone work items for:
-- "Validate segment: [name]" for each segment (priority: high)
-- "Source market data" if TAM/SAM/SOM need better sources (priority: medium)
-
-## Rules
-- Always ask for sources — investors will ask "where did you get that number?"
-- Challenge unrealistic sizing (a $100B TAM for a niche SaaS is suspicious)
-- Bottom-up sizing is more credible than top-down
-- Distinguish between potential customers and paying customers`,
-    tags: ['business', 'analysis', 'market'],
-});
-export const competitorAnalysisSkill = defineSkill({
-    name: 'competitor-analysis',
-    description: 'Map the competitive landscape — identify competitors, strengths, weaknesses, positioning',
-    prompt: `You are in COMPETITOR ANALYSIS MODE. Help the user understand their competition.
-
-## Step 1: Assess Current State
-1. Use \`business_model_get\` with scope: "competitors" for existing data
-2. Read Knowledge Base for competitor research, reports, articles
-3. Use \`business_model_get\` with scope: "identity" for context on the business
-
-## Step 2: Identify Competitors
-For each competitor (guide user to list 3-8):
-- Direct competitors (same product, same market)
-- Indirect competitors (different product, same problem)
-- Potential competitors (could enter the market)
-
-## Step 3: Analyze Each Competitor
-For each, gather:
-- **Name** and brief description
-- **Strengths** (2-4): what they do well
-- **Weaknesses** (2-4): where they fall short
-- **Market position**: leader, challenger, niche, or emerging
-- **Pricing** model/range
-- **URL** (if applicable)
-
-Save each: \`business_model_update\` with op: "competitor_add", competitor: { name, description, strengths, weaknesses, marketPosition, pricing, url }
-
-## Step 4: Define Competitive Advantages
-Based on the competitor analysis, what are YOUR advantages?
-- What do you do that no competitor does?
-- Where are the gaps in the market?
-- What would be hard for competitors to replicate?
-
-Save: \`business_model_update\` with op: "set_competitive_advantages", advantages: [...]
-
-## Step 5: Positioning Matrix
-Help the user define a 2D positioning matrix:
-- Ask: "What are the two most important dimensions in your market?" (e.g., price vs. features, simplicity vs. power, general vs. specialized)
-- Define axes with labels
-- Score each competitor (0-100) on both axes
-- Score the user's business position
-
-Save positioning: \`business_model_update\` op: "set_positioning", positioning: { xAxis: "Domain Specialization", yAxis: "Multi-Agent Capability", xLow: "General", xHigh: "Specialized", yLow: "Single", yHigh: "Multi-Agent", selfX: 85, selfY: 90 }
-
-Then update each competitor with position: \`business_model_update\` op: "competitor_update", competitor_id: "...", updates: { positionX: 30, positionY: 70 }
-
-This generates a visual positioning chart in the Business Model Viewer.
-
-## Step 6: Generate Work Items
-Create work items for:
-- "Deep-dive: [competitor name]" for competitors needing more research (type: Research)
-- "Validate advantage: [advantage]" for unproven competitive claims (type: Research)
-
-## Rules
-- "We have no competitors" is always wrong — there's always an alternative (even doing nothing)
-- Be honest about competitor strengths — investors will know
-- Focus on defensible advantages, not features that can be copied
-- Include both current competitors and potential future entrants`,
-    tags: ['business', 'analysis', 'competition'],
-});
-export const financialModelSkill = defineSkill({
-    name: 'financial-model',
-    description: 'Build revenue forecasts, cost structure, and break-even analysis',
-    prompt: `You are in FINANCIAL MODEL MODE. Help the user build financial projections.
-
-## Step 1: Assess Current State
-1. Use \`business_model_get\` with scope: "financials" for existing projections
-2. Use \`business_model_get\` with scope: "canvas" for revenue streams and cost structure
-3. Use \`business_model_get\` with scope: "overview" for business context
-
-## Step 2: Define Revenue Streams
-For each revenue stream (if not already defined):
-- Name, type (subscription, one-time, usage, etc.)
-- Projected revenue
-Save: \`business_model_update\` op: "revenue_stream_add"
-
-## Step 3: Build Revenue Forecasts
-For each revenue stream, guide through assumptions:
-- Number of customers per period
-- Average revenue per customer
-- Growth rate
-- Seasonality or ramp-up time
-
-Save forecasts: \`business_model_update\` op: "forecast_add", financials_field: { type: "revenue", period, category, amount }
-
-Use realistic time horizons:
-- Startup: monthly for Year 1, quarterly for Years 2-3
-- Growth stage: quarterly for 3 years
-- Established: yearly for 5 years
-
-## Step 4: Define Cost Structure
-Guide through expense categories:
-- **Fixed costs**: salaries, rent, subscriptions, insurance
-- **Variable costs**: hosting, transaction fees, marketing spend (scales with revenue)
-
-Save each: \`business_model_update\` op: "cost_item_add"
-Save forecasts: \`business_model_update\` op: "forecast_add", financials_field: { type: "expense", period, category, amount }
-
-## Step 5: Break-Even Analysis
-Calculate:
-- Monthly burn rate (total fixed + variable costs)
-- Monthly revenue at steady state
-- Break-even point (when cumulative revenue > cumulative costs)
-
-Save: \`business_model_update\` op: "set_financials_fields", financials_field: { breakEvenPoint: "Month 18", fundingNeeds: "$2M", useOfFunds: "70% product, 20% marketing, 10% ops" }
-
-## Step 6: Document Assumptions
-List all key assumptions made:
-- Customer acquisition rate
-- Churn rate
-- Pricing changes
-- Hiring timeline
-
-Save: \`business_model_update\` op: "set_financials_fields", financials_field: { assumptions: [...] }
-
-## Rules
-- Always state assumptions explicitly — hidden assumptions kill credibility
-- Use conservative estimates (investors multiply your timeline by 2x)
-- Revenue should be bottoms-up (customers × price), not top-down (% of TAM)
-- Include a "what if" scenario: what happens if growth is 50% slower?
-- Round to meaningful numbers — $1.2M not $1,237,849`,
-    tags: ['business', 'analysis', 'financial'],
-});
-export const pitchOutlineSkill = defineSkill({
-    name: 'pitch-outline',
-    description: 'Structure an investor pitch or executive summary from the Business Model',
-    prompt: `You are in PITCH OUTLINE MODE. Help the user create a compelling pitch from their Business Model.
-
-## Step 1: Assess Readiness
-1. Use \`business_model_get\` with scope: "full" to review the complete model
-2. Check completeness: identity, value prop, market, competitors, financials
-3. If major gaps exist, note them and suggest which skills to run first
-
-## Step 2: Choose Format
-Ask the user:
-- **Elevator pitch** (30 seconds — 3 sentences)
-- **Executive summary** (1 page — for email/document)
-- **Pitch deck narrative** (10-12 slides — investor presentation)
-
-## Step 3: Structure the Pitch
-For a pitch deck (adapt for other formats):
-
-1. **Problem** — The pain point (from valueProposition.problem)
-2. **Solution** — Your approach (from valueProposition.solution)
-3. **Market** — Size and opportunity (from market TAM/SAM/SOM)
-4. **Product** — What you've built / will build
-5. **Business Model** — How you make money (from canvas.revenueStreams)
-6. **Traction** — What you've achieved so far (milestones, users, revenue)
-7. **Competition** — Why you win (from competitors + competitiveAdvantages)
-8. **Team** — Why this team (from team)
-9. **Financials** — Projections and key metrics (from financials)
-10. **The Ask** — What you need (from financials.fundingNeeds + useOfFunds)
-
-## Step 4: Draft the Narrative
-For each section:
-- Write 2-3 sentences that tell a story
-- Lead with the strongest point
-- Use specific numbers, not vague claims
-- Save as a project document
-
-## Step 5: Generate Work Items
-Create Milestone work items:
-- "Draft: [section name]" for each pitch section
-- "Prepare: supporting data" for claims that need evidence
-
-## Rules
-- The pitch tells a STORY, not a list of facts
-- Start with emotion (the problem), end with opportunity (the ask)
-- Every claim should be backed by data from the Business Model
-- If financials are weak, lead with market size and traction instead
-- The ask should be specific: "$X for Y months to achieve Z"`,
-    tags: ['business', 'writing', 'pitch'],
-});
-export const businessReviewSkill = defineSkill({
-    name: 'business-review',
-    description: 'Validate the business plan — find gaps, weak assumptions, and missing elements',
-    prompt: `You are in BUSINESS REVIEW MODE. Critically evaluate the business plan like an investor would.
-
-## Step 1: Load and Assess
-1. Use \`business_model_get\` with scope: "full" to read everything
-2. Run \`business_model_validate\` for structural issues
-
-## Step 2: Completeness Check
-Score each section (Complete / Partial / Missing):
-- Identity & Value Proposition
-- Market Analysis (TAM/SAM/SOM, segments)
-- Competitive Analysis (competitors, advantages)
-- Business Model Canvas (revenue, costs, channels, partnerships)
-- Financial Projections (revenue, expenses, break-even)
-- Go-to-Market (phases, strategy)
-- Team
-
-Present a scorecard: "7/7 complete" or "5/7 — missing Financials and GTM"
-
-## Step 3: Assumption Audit
-For each key assumption:
-- Is it stated explicitly?
-- Is there evidence supporting it?
-- What happens if it's wrong?
-
-Flag assumptions that are:
-- **Optimistic** — "We'll capture 10% of the market in Year 1" (unlikely for most startups)
-- **Unvalidated** — claims without data or customer evidence
-- **Risky** — single points of failure
-
-## Step 4: Competitive Blind Spots
-- Are there competitors missing from the analysis?
-- Are competitive advantages truly defensible?
-- What would a well-funded competitor do to beat you?
-- Is the pricing competitive given the alternatives?
-
-## Step 5: Financial Reality Check
-- Do revenue projections match the market sizing? (can't project $100M revenue in a $50M SAM)
-- Is the cost structure realistic? (engineering salaries, cloud costs, marketing spend)
-- Is the break-even timeline achievable with the stated funding?
-- What's the burn rate, and how long does the funding last?
-
-## Step 6: Generate Review Report
-Structure as:
-
-### Scorecard
-Section-by-section completeness
-
-### Strengths (what's compelling)
-2-3 strongest elements
-
-### Critical Issues (must fix)
-Problems that would stop an investor
-
-### Major Issues (should fix)
-Significant weaknesses
-
-### Recommendations
-Prioritized action items
-
-Write report to a project document.
-
-## Step 7: Create Work Items
-- Type "Issue" (bug) for critical and major issues
-- Type "Research" (tech-debt) for unvalidated assumptions
-- Type "Milestone" (feature) for missing sections
-
-## Rules
-- Be constructive but honest — sugar-coating helps nobody
-- Think like an investor: "Would I put money into this?"
-- Every issue should have a specific recommendation
-- Acknowledge what's strong — it builds credibility for the critique
-- Focus on the 3-5 things that matter most, not a list of 20 nitpicks`,
-    tags: ['business', 'review', 'validation'],
-});
-// =============================================================================
-// Aggregate export
-// =============================================================================
+// Software Development
+export { designSkill, sketchSkill, prdSkill, refineSkill, refineItemSkill, architectureSkill, sessionNotesSkill, buildSkill, scaffoldSkill, } from './software-skills.js';
+// Research Paper
+export { outlineSkill, literatureReviewSkill, draftSectionSkill, peerReviewSkill, researchScaffoldSkill, } from './research-skills.js';
+// Business Plan
+export { businessVisionSkill, marketAnalysisSkill, competitorAnalysisSkill, financialModelSkill, pitchOutlineSkill, businessReviewSkill, } from './business-skills.js';
+// Content & Marketing
+export { brandSetupSkill, contentStrategySkill, contentCalendarSkill, createContentSkill, contentReviewSkill, } from './content-skills.js';
+// Course / Training
+export { curriculumDesignSkill, lessonPlanSkill, assessmentDesignSkill, courseReviewSkill, } from './course-skills.js';
+// Import all for the aggregate array
+import { designSkill, sketchSkill, prdSkill, refineSkill, refineItemSkill, architectureSkill, sessionNotesSkill, buildSkill, scaffoldSkill, } from './software-skills.js';
+import { outlineSkill, literatureReviewSkill, draftSectionSkill, peerReviewSkill, researchScaffoldSkill, } from './research-skills.js';
+import { businessVisionSkill, marketAnalysisSkill, competitorAnalysisSkill, financialModelSkill, pitchOutlineSkill, businessReviewSkill, } from './business-skills.js';
+import { brandSetupSkill, contentStrategySkill, contentCalendarSkill, createContentSkill, contentReviewSkill, } from './content-skills.js';
+import { curriculumDesignSkill, lessonPlanSkill, assessmentDesignSkill, courseReviewSkill, } from './course-skills.js';
 /**
- * All platform-specific skills (20 total).
- * These skills reference platform tools (backlog, workitems, documents, projects)
- * and belong in the SDK rather than in generic agent/coding libraries.
+ * All platform-specific skills (29 total).
  */
 export const platformSkills = [
+    // Software (9)
     designSkill,
     sketchSkill,
     prdSkill,
@@ -1765,15 +34,28 @@ export const platformSkills = [
     sessionNotesSkill,
     buildSkill,
     scaffoldSkill,
+    // Research (5)
     outlineSkill,
     literatureReviewSkill,
     draftSectionSkill,
     peerReviewSkill,
     researchScaffoldSkill,
+    // Business (6)
     businessVisionSkill,
     marketAnalysisSkill,
     competitorAnalysisSkill,
     financialModelSkill,
     pitchOutlineSkill,
     businessReviewSkill,
+    // Content (5)
+    brandSetupSkill,
+    contentStrategySkill,
+    contentCalendarSkill,
+    createContentSkill,
+    contentReviewSkill,
+    // Course (4)
+    curriculumDesignSkill,
+    lessonPlanSkill,
+    assessmentDesignSkill,
+    courseReviewSkill,
 ];