codex-workflows 0.1.0

package/.agents/skills/subagents-orchestration-guide/SKILL.md

@@ -0,0 +1,354 @@
+---
+name: subagents-orchestration-guide
+description: "Guides subagent coordination through implementation workflows. Use when: orchestrating multiple agents, managing workflow phases, determining autonomous execution mode, or coordinating recipe execution."
+---
+
+# Subagents Orchestration Guide
+
+## Role: The Orchestrator
+
+**The orchestrator coordinates subagents like a conductor -- directing the musicians without playing the instruments.**
+
+All investigation, analysis, and implementation work flows through specialized subagents.
+
+### Automatic Responses
+
+| Trigger | Action |
+|---------|--------|
+| New task | Spawn **requirement-analyzer** |
+| Flow in progress | Check scale determination table for next subagent |
+| Phase completion | Spawn the appropriate agent |
+| Stop point reached | Wait for user approval |
+
+### First Action Rule [MANDATORY]
+
+To accurately analyze user requirements, pass them directly to requirement-analyzer and determine the workflow based on its analysis results.
+
+**ENFORCEMENT**: MUST spawn requirement-analyzer as first action for every new task
+
+## Decision Flow When Receiving Tasks
+
+```
+Receive New Task -> Analyze requirements with requirement-analyzer
+                 -> Scale assessment
+                 -> Execute flow based on scale
+```
+
+**During flow execution, determine next subagent according to scale determination table**
+
+### Requirement Change Detection During Flow [MANDATORY]
+
+**During flow execution**, if detecting the following in user response, MUST stop flow and go to requirement-analyzer:
+- Mentions of new features/behaviors (additional operation methods, display on different screens, etc.)
+- Additions of constraints/conditions (data volume limits, permission controls, etc.)
+- Changes in technical requirements (processing methods, output format changes, etc.)
+
+**ENFORCEMENT**: If any one applies — MUST restart from requirement-analyzer with integrated requirements
+
+## Available Subagents
+
+The following subagents are available:
+
+### Implementation Support Agents
+1. **quality-fixer**: Self-contained processing for overall quality assurance and fixes until completion
+2. **task-decomposer**: Appropriate task decomposition of work plans
+3. **task-executor**: Individual task execution and structured response
+4. **integration-test-reviewer**: Review integration/E2E tests for skeleton compliance and quality
+
+### Document Creation Agents
+5. **requirement-analyzer**: Requirement analysis and work scale determination
+6. **prd-creator**: Product Requirements Document creation
+7. **ui-spec-designer**: UI Specification creation from PRD and optional prototype code (frontend/fullstack features)
+8. **technical-designer**: ADR/Design Doc creation
+9. **work-planner**: Work plan creation from Design Doc and test skeletons
+10. **document-reviewer**: Single document quality and rule compliance check
+11. **design-sync**: Design Doc consistency verification across multiple documents
+12. **acceptance-test-generator**: Generate integration and E2E test skeletons from Design Doc ACs
+
+## Orchestration Principles
+
+### Task Assignment with Responsibility Separation [MANDATORY]
+
+Assign work based on each subagent's responsibilities:
+
+**What to spawn task-executor for**:
+- Implementation work and test addition
+- Confirmation of added tests passing (existing tests are not covered)
+- Spawn quality-fixer exclusively for quality assurance
+
+**What to spawn quality-fixer for**:
+- Overall quality assurance (static analysis, style check, all test execution, etc.)
+- Complete execution of quality error fixes
+- Self-contained processing until fix completion
+- Final approved judgment (only after fixes are complete)
+
+## Constraints Between Subagents [MANDATORY]
+
+Subagents CANNOT directly call other subagents — all coordination MUST flow through the orchestrator.
+
+**ENFORCEMENT**: Direct subagent-to-subagent communication is PROHIBITED
+
+## How to Spawn Agents
+
+Spawn agents using natural language prompts. Provide clear context about what the agent should accomplish.
+
+### Spawn Examples
+
+**requirement-analyzer**:
+> "Analyze the following requirements and determine the work scale: [user requirements]. Perform requirement analysis and scale determination."
+
+**task-executor**:
+> "Execute the implementation task defined in docs/plans/tasks/[filename].md. Complete the implementation following TDD Red-Green-Refactor."
+
+**quality-fixer**:
+> "Run quality checks on the codebase: static analysis, style check, all test execution. Fix any issues found and report when all checks pass."
+
+**document-reviewer**:
+> "Review the document at [path] for quality and rule compliance. Check against documentation-criteria standards."
+
+**design-sync**:
+> "Verify consistency between Design Docs in docs/design/. Use [path] as the source document for comparison."
+
+## Explicit Stop Points [MANDATORY]
+
+Autonomous execution MUST stop and wait for user input at these points.
+
+| Phase | Stop Point | User Action Required |
+|-------|------------|---------------------|
+| Requirements | After requirement-analyzer completes | Confirm requirements / Answer questions |
+| PRD | After document-reviewer completes PRD review | Approve PRD |
+| UI Spec | After document-reviewer completes UI Spec review (frontend/fullstack) | Approve UI Spec |
+| ADR | After document-reviewer completes ADR review (if ADR created) | Approve ADR |
+| Design | After design-sync completes consistency verification | Approve Design Doc |
+| Work Plan | After work-planner creates plan | Batch approval for implementation phase |
+
+**ENFORCEMENT**: After batch approval, autonomous execution proceeds without stops until completion or escalation. Skipping stop points is a CRITICAL VIOLATION.
+
+### Approval Status Vocabulary [MANDATORY]
+
+All agents MUST use this vocabulary consistently:
+
+| Status | Meaning | Next Action |
+|--------|---------|-------------|
+| `approved` | All criteria met | Proceed to next phase |
+| `approved_with_conditions` | Criteria met with minor open items | Proceed — carry conditions as input to next phase |
+| `needs_revision` | Significant issues found | Return to author agent for revision (max 2 iterations) |
+| `rejected` | Fundamental problems | Halt workflow, escalate to user |
+| `skipped` | Preconditions not met for this step | Report reason, proceed |
+
+**approved_with_conditions handling**:
+- Conditions MUST be listed explicitly in the agent's output
+- Orchestrator MUST append conditions to the document's "Undetermined Items" or "Open Items" section before proceeding
+- Orchestrator MUST pass conditions to the next phase's agent as context
+- Conditions do not block progression but MUST be resolved before implementation phase
+
+**ENFORCEMENT**: Using any status value outside this vocabulary is a VIOLATION.
+
+## Scale Determination and Document Requirements
+
+| Scale | File Count | PRD | ADR | Design Doc | Work Plan |
+|-------|------------|-----|-----|------------|-----------|
+| Small | 1-2 | Update* | Not needed | Not needed | Simplified |
+| Medium | 3-5 | Update* | Conditional** | **Required** | **Required** |
+| Large | 6+ | **Required*** | Conditional** | **Required** | **Required** |
+
+\* Update if PRD exists for the relevant feature
+\*\* When there are architecture changes, new technology introduction, or data flow changes
+\*\*\* New creation/update existing/reverse PRD (when no existing PRD)
+
+## Structured Response Specification
+
+Subagents respond in JSON format. Key fields for orchestrator decisions:
+- **requirement-analyzer**: scale, confidence, affectedLayers, adrRequired, scopeDependencies, questions
+- **task-executor**: status (escalation_needed/blocked/completed), testsAdded
+- **quality-fixer**: approved (true/false)
+- **document-reviewer**: verdict.decision (approved/approved_with_conditions/needs_revision/rejected)
+- **design-sync**: sync_status (CONFLICTS_FOUND/NO_CONFLICTS) — text format with [SUMMARY] block
+- **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
+- **acceptance-test-generator**: status, generatedFiles
+
+## Handling Requirement Changes
+
+### Handling Requirement Changes in requirement-analyzer
+requirement-analyzer follows the "completely self-contained" principle and processes requirement changes as new input.
+
+#### How to Integrate Requirements
+
+**Important**: To maximize accuracy, integrate requirements as complete sentences, including all contextual information communicated by the user.
+
+```yaml
+Integration example:
+  Initial: "I want to create user management functionality"
+  Addition: "Permission management is also needed"
+  Result: "I want to create user management functionality. Permission management is also needed.
+
+          Initial requirement: I want to create user management functionality
+          Additional requirement: Permission management is also needed"
+```
+
+### Update Mode for Document Generation Agents
+Document generation agents (work-planner, technical-designer, prd-creator) can update existing documents in `update` mode.
+
+- **Initial creation**: Create new document in create (default) mode
+- **On requirement change**: Edit existing document and add history in update mode
+
+## Basic Flow for Work Planning
+
+When receiving new features or change requests, start with requirement-analyzer.
+
+### Large Scale (6+ Files) - 11 Steps (backend) / 13 Steps (frontend/fullstack)
+
+1. requirement-analyzer: Requirement analysis + Check existing PRD **[Stop]**
+2. prd-creator: PRD creation
+3. document-reviewer: PRD review **[Stop: PRD Approval]**
+4. **(frontend/fullstack only)** Ask user for prototype code; ui-spec-designer: UI Spec creation
+5. **(frontend/fullstack only)** document-reviewer: UI Spec review **[Stop: UI Spec Approval]**
+6. technical-designer: ADR creation (if architecture/technology/data flow changes)
+7. document-reviewer: ADR review (if ADR created) **[Stop: ADR Approval]**
+8. technical-designer: Design Doc creation
+9. document-reviewer: Design Doc review
+10. design-sync: Consistency verification **[Stop: Design Doc Approval]**
+11. acceptance-test-generator: Test skeleton generation, pass to work-planner
+12. work-planner: Work plan creation **[Stop: Batch approval]**
+13. task-decomposer: Autonomous execution to Completion report
+
+### Medium Scale (3-5 Files) - 7 Steps (backend) / 9 Steps (frontend/fullstack)
+
+1. requirement-analyzer: Requirement analysis **[Stop]**
+2. **(frontend/fullstack only)** Ask user for prototype code; ui-spec-designer: UI Spec creation
+3. **(frontend/fullstack only)** document-reviewer: UI Spec review **[Stop: UI Spec Approval]**
+4. technical-designer: Design Doc creation
+5. document-reviewer: Design Doc review
+6. design-sync: Consistency verification **[Stop: Design Doc Approval]**
+7. acceptance-test-generator: Test skeleton generation, pass to work-planner
+8. work-planner: Work plan creation **[Stop: Batch approval]**
+9. task-decomposer: Autonomous execution to Completion report
+
+### Small Scale (1-2 Files) - 2 Steps
+
+1. Create simplified plan **[Stop: Batch approval]**
+2. Direct implementation to Completion report
+
+## Autonomous Execution Mode
+
+### Pre-Execution Environment Check
+
+**Principle**: Verify subagents can complete their responsibilities
+
+**Required environments**:
+- Commit capability (for per-task commit cycle)
+- Quality check tools (quality-fixer will detect and escalate if missing)
+- Test runner (task-executor will detect and escalate if missing)
+
+**If critical environment unavailable**: Escalate with specific missing component before entering autonomous mode
+
+### Authority Grant
+
+**After environment check passes**:
+- Batch approval for entire implementation phase grants authority to agents
+- task-executor: Implementation authority
+- quality-fixer: Fix authority (automatic quality error fixes)
+
+### Definition of Autonomous Execution Mode
+
+After "batch approval for entire implementation phase" with work-planner, autonomously execute the following processes without human approval:
+
+```
+Batch approval -> Start autonomous execution mode
+  -> task-decomposer: Task decomposition
+  -> Task execution loop:
+      -> task-executor: Implementation
+      -> Escalation judgment:
+          - escalation_needed/blocked -> Escalate to user
+          - testsAdded has int/e2e -> integration-test-reviewer
+              - needs_revision -> back to task-executor
+              - approved -> quality-fixer
+          - No issues -> quality-fixer
+      -> quality-fixer: Quality check and fixes
+      -> Orchestrator: Execute git commit
+      -> Check remaining tasks:
+          - Yes -> next task
+          - No -> Completion report
+```
+
+### Conditions for Stopping Autonomous Execution
+
+Stop autonomous execution and escalate to user in the following cases:
+
+1. **Escalation from subagent**: When receiving `status: "escalation_needed"` or `status: "blocked"`
+2. **Requirement change detected**: Any match in requirement change detection checklist
+3. **Work-planner update restriction violated**: Requirement changes after task-decomposer starts require overall redesign
+4. **User explicitly stops**: Direct stop instruction or interruption
+
+### Task Management: 4-Step Cycle
+
+**Per-task cycle**:
+1. task-executor: Implementation
+2. Check task-executor response:
+   - `escalation_needed` or `blocked`: Escalate to user
+   - `testsAdded` contains integration/e2e tests: Execute integration-test-reviewer
+     - `needs_revision`: Return to step 1 with requiredFixes
+     - `approved`: Proceed to step 3
+   - Otherwise: Proceed to step 3
+3. quality-fixer: Quality check and fixes
+4. git commit (on `approved: true`)
+
+## Main Orchestrator Roles
+
+1. **State Management**: Track current phase, each subagent's state, and next action
+2. **Information Bridging**: Data conversion and transmission between subagents
+   - Convert each subagent's output to next subagent's input format
+   - **Always pass deliverables from previous process to next agent**
+   - Extract necessary information from structured responses
+   - Compose commit messages from changeSummary
+   - Explicitly integrate initial and additional requirements when requirements change
+3. **Quality Assurance and Commit Execution**: Execute git commit per the 4-step task cycle
+4. **Autonomous Execution Mode Management**: Start/stop autonomous execution after approval, escalation decisions
+5. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
+
+### acceptance-test-generator to work-planner Bridge
+
+**Pass to acceptance-test-generator**:
+- Design Doc: [path]
+- UI Spec: [path] (if exists)
+
+**Orchestrator verification items**:
+- Verify integration test file path retrieval and existence
+- Verify E2E test file path retrieval and existence
+
+**Pass to work-planner**:
+- Integration test file: [path] (create and execute simultaneously with each phase implementation)
+- E2E test file: [path] (execute only in final phase)
+
+**On error**: Escalate to user if files are not generated
+
+## Important Constraints [MANDATORY]
+
+- **Quality check is REQUIRED**: quality-fixer approval MUST be obtained before commit
+- **Structured response REQUIRED**: Information transmission between subagents MUST use JSON format
+- **Approval management**: Document creation -> Execute document-reviewer -> Get user approval before proceeding
+- **Flow confirmation**: After getting approval, MUST check next step with work planning flow (large/medium/small scale)
+- **Consistency verification**: If subagent determinations contradict, MUST prioritize guidelines
+
+**ENFORCEMENT**: Violating ANY constraint requires immediate correction
+
+## Required Dialogue Points with Humans [MANDATORY]
+
+### Basic Principles
+- **Stopping is REQUIRED**: MUST wait for human response at stop points
+- **Confirmation then Agreement cycle**: After document generation, proceed to next step after agreement or fix instructions in update mode
+- **Specific questions**: Make decisions easy with options (A/B/C) or comparison tables
+
+## Action Checklist
+
+When receiving a task, check the following:
+
+- [ ] Confirmed if there is an orchestrator instruction
+- [ ] Determined task type (new feature/fix/research, etc.)
+- [ ] Considered appropriate subagent utilization
+- [ ] Decided next action according to decision flow
+- [ ] Monitored requirement changes and errors during autonomous execution mode
+
+## References
+
+- `references/monorepo-flow.md`: Fullstack (monorepo) orchestration flow

package/.agents/skills/subagents-orchestration-guide/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Subagents Orchestration"
+  short_description: "Agent coordination guide"
+  default_prompt: "Use $subagents-orchestration-guide to coordinate workflow agents."
+
+policy:
+  allow_implicit_invocation: true

package/.agents/skills/subagents-orchestration-guide/references/monorepo-flow.md

@@ -0,0 +1,124 @@
+# Fullstack (Monorepo) Flow
+
+This reference defines the orchestration flow for projects spanning multiple layers (backend + frontend). It extends the standard orchestration guide without modifying it.
+
+## When This Flow Applies
+
+- Multiple Design Docs exist targeting different layers (backend, frontend)
+- A single feature requires implementation across both backend and frontend
+- The orchestrator is invoked for fullstack implementation
+
+## Design Phase
+
+### Large Scale Fullstack (6+ Files) - 12 Steps
+
+| Step | Agent | Purpose | Output |
+|------|-------|---------|--------|
+| 1 | requirement-analyzer | Requirement analysis + scale determination **[Stop]** | Requirements + scale |
+| 2 | prd-creator | PRD covering entire feature (all layers) | Single PRD |
+| 3 | document-reviewer | PRD review **[Stop]** | Approval |
+| 4 | (orchestrator) | Ask user for prototype code **[Stop]** | Prototype path or none |
+| 5 | ui-spec-designer | UI Spec from PRD + optional prototype | UI Spec |
+| 6 | document-reviewer | UI Spec review **[Stop]** | Approval |
+| 7 | technical-designer | **Backend** Design Doc | Backend Design Doc |
+| 8 | technical-designer-frontend | **Frontend** Design Doc (references backend Integration Points + UI Spec) | Frontend Design Doc |
+| 9 | document-reviewer x2 | Review each Design Doc (one invocation per doc) | Reviews |
+| 10 | design-sync | Cross-layer consistency verification (source: frontend Design Doc) **[Stop]** | Sync status |
+| 11 | acceptance-test-generator | Integration/E2E test skeleton from cross-layer contracts | Test skeletons |
+| 12 | work-planner | Work plan from all Design Docs **[Stop: Batch approval]** | Work plan |
+
+### Medium Scale Fullstack (3-5 Files) - 10 Steps
+
+| Step | Agent | Purpose | Output |
+|------|-------|---------|--------|
+| 1 | requirement-analyzer | Requirement analysis + scale determination **[Stop]** | Requirements + scale |
+| 2 | (orchestrator) | Ask user for prototype code **[Stop]** | Prototype path or none |
+| 3 | ui-spec-designer | UI Spec from requirements + optional prototype | UI Spec |
+| 4 | document-reviewer | UI Spec review **[Stop]** | Approval |
+| 5 | technical-designer | **Backend** Design Doc | Backend Design Doc |
+| 6 | technical-designer-frontend | **Frontend** Design Doc (references backend Integration Points + UI Spec) | Frontend Design Doc |
+| 7 | document-reviewer x2 | Review each Design Doc (one invocation per doc) | Reviews |
+| 8 | design-sync | Cross-layer consistency verification (source: frontend Design Doc) **[Stop]** | Sync status |
+| 9 | acceptance-test-generator | Integration/E2E test skeleton from cross-layer contracts | Test skeletons |
+| 10 | work-planner | Work plan from all Design Docs **[Stop: Batch approval]** | Work plan |
+
+### Layer Context in Design Doc Creation
+
+When spawning Design Doc creation for each layer, pass explicit context:
+
+**Large Scale (PRD available) -- Backend Design Doc**:
+**Agent**: Spawn technical-designer
+> "Create a backend Design Doc from PRD at [path]. Focus on: API contracts, data layer, business logic, service architecture."
+
+**Large Scale (PRD available) -- Frontend Design Doc**:
+**Agent**: Spawn technical-designer-frontend
+> "Create a frontend Design Doc from PRD at [path]. Reference backend Design Doc at [path] for API contracts and Integration Points. Reference UI Spec at [path] for component structure and state design. Focus on: component hierarchy, state management, UI interactions, data fetching."
+
+**Medium Scale (no PRD) -- Backend Design Doc**:
+**Agent**: Spawn technical-designer
+> "Create a backend Design Doc based on the following requirements: [requirement-analyzer output]. Focus on: API contracts, data layer, business logic, service architecture."
+
+**Medium Scale (no PRD) -- Frontend Design Doc**:
+**Agent**: Spawn technical-designer-frontend
+> "Create a frontend Design Doc based on the following requirements: [requirement-analyzer output]. Reference backend Design Doc at [path] for API contracts and Integration Points. Reference UI Spec at [path] for component structure and state design. Focus on: component hierarchy, state management, UI interactions, data fetching."
+
+### design-sync for Cross-Layer Verification
+
+Spawn design-sync with `source_design` = frontend Design Doc (created last, referencing backend's Integration Points). design-sync auto-discovers other Design Docs in `docs/design/` for comparison.
+
+## Test Skeleton Generation Phase
+
+Spawn acceptance-test-generator with all Design Docs and UI Spec:
+
+> "Generate test skeletons from the following documents: Design Doc (backend): [path], Design Doc (frontend): [path], UI Spec: [path] (if exists)"
+
+## Work Planning Phase
+
+Spawn work-planner with all Design Docs:
+
+> "Create a work plan from the following documents: PRD: [path] (Large Scale only), Design Doc (backend): [path], Design Doc (frontend): [path]. Compose phases as vertical feature slices where possible -- each phase should contain both backend and frontend work for the same feature area, enabling early integration verification per phase."
+
+work-planner's existing Integration Complete criteria naturally covers cross-layer verification when given multiple Design Docs.
+
+## Task Decomposition Phase
+
+task-decomposer follows standard decomposition from the work plan. The key addition is the **layer-aware naming convention**:
+
+| Filename Pattern | Meaning |
+|-----------------|---------|
+| `{plan}-backend-task-{n}.md` | Backend only |
+| `{plan}-frontend-task-{n}.md` | Frontend only |
+
+Layer is determined from the task's **Target files** paths -- this is a factual determination, not inference.
+
+## Task Cycle
+
+Each task uses the standard 4-step cycle with layer-appropriate agents:
+
+### backend-task
+1. task-executor: Implementation
+2. Escalation check
+3. quality-fixer: Quality check and fixes
+4. git commit (on approved: true)
+
+### frontend-task
+1. task-executor-frontend: Implementation
+2. Escalation check
+3. quality-fixer-frontend: Quality check and fixes
+4. git commit (on approved: true)
+
+### integration-test-reviewer Placement
+
+When `testsAdded` contains integration or E2E tests:
+- Standard flow (integration-test-reviewer after task-executor, before quality-fixer)
+
+## Agent Routing Summary
+
+The orchestrator selects agents by **filename pattern matching** -- no conditional inference required:
+
+```
+*-backend-task-*   -> task-executor + quality-fixer
+*-frontend-task-*  -> task-executor-frontend + quality-fixer-frontend
+```
+
+All other orchestration rules (stop points, structured responses, escalation handling, task management) follow the standard subagents-orchestration-guide.

package/.agents/skills/task-analyzer/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: task-analyzer
+description: "Performs task analysis and skill selection. Use when: determining task complexity, selecting appropriate skills, or estimating work scale."
+---
+
+# Task Analyzer
+
+Provides task analysis and skill selection guidance.
+
+## Skills Index
+
+See **[skills-index.yaml](references/skills-index.yaml)** for available skills metadata.
+
+## Task Analysis Process
+
+### 1. Understand Task Essence [MANDATORY]
+
+Identify the fundamental purpose beyond surface-level work:
+
+| Surface Work | Fundamental Purpose |
+|--------------|---------------------|
+| "Fix this bug" | Problem solving, root cause analysis |
+| "Implement this feature" | Feature addition, value delivery |
+| "Refactor this code" | Quality improvement, maintainability |
+| "Update this file" | Change management, consistency |
+
+**Key Questions** [MUST answer before proceeding]:
+- What problem are we really solving?
+- What is the expected outcome?
+- What could go wrong if we approach this superficially?
+
+### 2. Estimate Task Scale
+
+| Scale | File Count | Indicators |
+|-------|------------|------------|
+| Small | 1-2 | Single function/component change |
+| Medium | 3-5 | Multiple related components |
+| Large | 6+ | Cross-cutting concerns, architecture impact |
+
+**Scale affects skill priority:**
+- Larger scale: process/documentation skills more important
+- Smaller scale: implementation skills more focused
+
+### 3. Identify Task Type
+
+| Type | Characteristics | Key Skills |
+|------|-----------------|------------|
+| Implementation | New code, features | coding-rules, testing |
+| Fix | Bug resolution | ai-development-guide, testing |
+| Refactoring | Structure improvement | coding-rules, ai-development-guide |
+| Design | Architecture decisions | documentation-criteria, implementation-approach |
+| Quality | Testing, review | testing, integration-e2e-testing |
+
+### 4. Tag-Based Skill Matching
+
+Extract relevant tags from task description and match against skills-index.yaml:
+
+```yaml
+Task: "Implement user authentication with tests"
+Extracted tags: [implementation, testing, security]
+Matched skills:
+  - coding-rules (implementation, security)
+  - testing (testing)
+  - ai-development-guide (implementation)
+```
+
+### 5. Implicit Relationships
+
+Consider hidden dependencies:
+
+| Task Involves | Also Include |
+|---------------|--------------|
+| Error handling | debugging, testing |
+| New features | design, implementation, documentation |
+| Performance | profiling, optimization, testing |
+| Frontend | coding-rules/references/typescript.md, testing/references/typescript.md |
+| API/Integration | integration-e2e-testing |
+
+## Skill Selection Priority
+
+1. **Essential** - Directly related to task type
+2. **Quality** - Testing and quality assurance
+3. **Process** - Workflow and documentation
+4. **Supplementary** - Reference and best practices
+
+## Output Format
+
+Return structured analysis with skill metadata from skills-index.yaml:
+
+```yaml
+taskAnalysis:
+  essence: <string>  # Fundamental purpose identified
+  type: <implementation|fix|refactoring|design|quality>
+  scale: <small|medium|large>
+  estimatedFiles: <number>
+  tags: [<string>, ...]  # Extracted from task description
+
+selectedSkills:
+  - skill: <skill-name>  # From skills-index.yaml
+    priority: <high|medium|low>
+    reason: <string>  # Why this skill was selected
+    tags: [...]
+    typical-use: <string>
+    size: <small|medium|large>
+    sections: [...]  # All sections from yaml, unfiltered
+```
+
+**Note**: Section selection (choosing which sections are relevant) is done after reading the actual SKILL.md files.
+
+## Metacognitive Question Design
+
+Generate 3-5 questions according to task nature:
+
+| Task Type | Question Focus |
+|-----------|----------------|
+| Implementation | Design validity, edge cases, performance |
+| Fix | Root cause (5 Whys), impact scope, regression testing |
+| Refactoring | Current problems, target state, phased plan |
+| Design | Requirement clarity, future extensibility, trade-offs |
+
+## Warning Patterns [MANDATORY to detect]
+
+Detect and flag these patterns IMMEDIATELY:
+
+| Pattern | Warning | REQUIRED Action |
+|---------|---------|-----------------|
+| Large change at once | High risk | MUST split into phases |
+| Implementation without tests | Quality risk | MUST follow TDD |
+| Immediate fix on error | Root cause missed | MUST pause and analyze with 5 Whys |
+| Coding without plan | Scope creep | MUST plan first |
+
+**ENFORCEMENT**: Detecting ANY warning pattern requires IMMEDIATE corrective action
+
+## Common Decision Points
+
+| Decision | Criteria |
+|----------|----------|
+| Need documentation? | Check documentation-criteria decision matrix |
+| Which implementation approach? | Check implementation-approach phases |
+| How to test? | Check testing + integration-e2e-testing |
+| Code quality concerns? | Check ai-development-guide anti-patterns |
+| Frontend specific? | Check coding-rules/references/typescript.md |

package/.agents/skills/task-analyzer/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Task Analyzer"
+  short_description: "Task analysis and skill selection"
+  default_prompt: "Use $task-analyzer to analyze this task and select skills."
+
+policy:
+  allow_implicit_invocation: true