@comfanion/workflow 4.1.2 → 4.3.0

package/README.md

@@ -96,8 +96,7 @@ npx @comfanion/workflow config
 ├── config.yaml          # Your configuration
 ├── FLOW.yaml            # Workflow definition (v3.0)
 ├── agents/              # Agent personas
-├── skills/              # Knowledge modules (25+)
-├── templates/           # Document templates
+├── skills/              # Knowledge modules with templates (25+)
 ├── workflows/           # Workflow instructions
 ├── checklists/          # Validation checklists
 └── commands/            # Slash commands

package/bin/cli.js

@@ -259,7 +259,7 @@ program
       // Create CHANGELOG.md if not exists
       const changelogPath = path.join(process.cwd(), 'CHANGELOG.md');
       if (!await fs.pathExists(changelogPath)) {
-        const changelogTemplate = path.join(targetDir, 'templates/CHANGELOG.md');
+        const changelogTemplate = path.join(targetDir, 'skills/changelog/template.md');
         if (await fs.pathExists(changelogTemplate)) {
           await fs.copy(changelogTemplate, changelogPath);
         }
@@ -274,8 +274,7 @@ program
   ├── config.yaml          # Your configuration
   ├── FLOW.yaml            # Workflow definition
   ├── agents/              # Agent personas (analyst, pm, architect, sm, dev)
-  ├── skills/              # Knowledge modules
-  ├── templates/           # Document templates
+  ├── skills/              # Knowledge modules (with templates)
   ├── workflows/           # Workflow instructions
   └── checklists/          # Validation checklists
   
@@ -400,7 +399,6 @@ program
       { name: 'FLOW.yaml', path: '.opencode/FLOW.yaml', required: true },
       { name: 'agents/', path: '.opencode/agents', required: true },
       { name: 'skills/', path: '.opencode/skills', required: true },
-      { name: 'templates/', path: '.opencode/templates', required: true },
       { name: 'docs/', path: 'docs', required: true },
       { name: 'docs/sprint-artifacts/', path: 'docs/sprint-artifacts', required: true },
       { name: 'docs/requirements/', path: 'docs/requirements', required: true },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@comfanion/workflow",
-  "version": "4.1.2",
+  "version": "4.3.0",
   "description": "Initialize OpenCode Workflow system for AI-assisted development",
   "type": "module",
   "bin": {

package/src/build-info.json

@@ -1,6 +1,6 @@
 {
   "version": "3.0.0",
-  "buildDate": "2026-01-23T17:53:50.018Z",
+  "buildDate": "2026-01-23T20:59:12.140Z",
   "files": [
     "config.yaml",
     "FLOW.yaml",

package/src/opencode/ARCHITECTURE.md

@@ -186,12 +186,13 @@ prd-writing:
 │   └── integration-testing/
 │       └── SKILL.md
 │
-└── templates/                   # Referenced by skills
-    ├── requirements-template.md
-    ├── prd-template.md
-    ├── architecture-template.md
-    ├── epic-template.md
-    ├── story-template.md
+└── skills/                      # Skills with co-located templates
+    ├── prd-writing/
+    │   ├── SKILL.md
+    │   └── template.md
+    ├── architecture-design/
+    │   ├── SKILL.md
+    │   └── template.md
     └── ...
 ```
 

package/src/opencode/FLOW.yaml

@@ -99,7 +99,7 @@ pipeline:
       qa:
         artifact: docs/prd-acceptance-criteria.md
         description: Acceptance criteria for all FRs
-        template: templates/prd-acceptance-criteria-template.md
+        template: skills/acceptance-criteria/template.md
         mandatory: true
       next: coding-standards
 
@@ -143,7 +143,7 @@ pipeline:
       qa:
         artifact: docs/architecture-integration-tests.md
         description: Integration test specifications
-        template: templates/integration-tests-template.md
+        template: skills/test-design/template-integration.md
         mandatory: true
       next: module-docs
 
@@ -777,41 +777,41 @@ commands:
 artifacts:
   requirements:
     path: docs/requirements/requirements.md
-    template: templates/requirements-template.md
+    template: skills/requirements-gathering/template.md
 
   prd:
     path: docs/prd.md
-    template: templates/prd-template.md
+    template: skills/prd-writing/template.md
 
   prd-qa:
     path: docs/prd-acceptance-criteria.md
-    template: templates/prd-acceptance-criteria-template.md
+    template: skills/acceptance-criteria/template.md
     mandatory: true
 
   architecture:
     path: docs/architecture.md
-    template: templates/architecture-template.md
+    template: skills/architecture-design/template.md
 
   architecture-qa:
     path: docs/architecture-integration-tests.md
-    template: templates/integration-tests-template.md
+    template: skills/test-design/template-integration.md
     mandatory: true
 
   epic:
     path: docs/sprint-artifacts/*/epic-*.md
-    template: templates/epic-template.md
+    template: skills/epic-writing/template.md
     naming: "epic-{NN}-{module}-{description}.md"
     id_format: "{MODULE}-E{NN}"
 
   story:
     path: docs/sprint-artifacts/*/stories/story-*.md
-    template: templates/story-template.md
+    template: skills/story-writing/template.md
     naming: "story-{EPIC}-{NN}-{description}.md"
     id_format: "{MODULE}-S{EPIC}-{NN}"
 
   sprint-status:
     path: docs/sprint-artifacts/sprint-status.yaml
-    template: templates/sprint-status-template.yaml
+    template: skills/sprint-planning/template.yaml
     format: yaml
 
 # =============================================================================

package/src/opencode/agents/coder.md

@@ -0,0 +1,82 @@
+---
+description: "Fast Coder - Use for: quick implementation tasks, writing code, fixing bugs. Uses claude-haiku for speed."
+mode: subagent
+model: anthropic/claude-haiku-4-20250514
+temperature: 0.1
+tools:
+  write: true
+  edit: true
+  bash: true
+  glob: true
+  grep: true
+  read: true
+permission:
+  bash:
+    "*": allow
+---
+
+<agent id="coder" name="Swift" title="Fast Coder" icon="⚡">
+
+<activation>
+  <step n="1">Receive task from parent agent or user</step>
+  <step n="2">Read relevant files mentioned in task</step>
+  <step n="3">Implement solution following project patterns</step>
+  <step n="4">Run tests if applicable</step>
+  <step n="5">Report completion</step>
+</activation>
+
+<persona>
+  <role>Fast Implementation Specialist</role>
+  <identity>Quick executor for well-defined coding tasks. No planning, no questions - just code.</identity>
+  <communication_style>Minimal. Shows code, reports results. No explanations unless errors.</communication_style>
+  <principles>
+    - Execute task as specified, no improvisation
+    - Follow existing code patterns in project
+    - Write minimal code that solves the problem
+    - Report errors immediately if blocked
+  </principles>
+</persona>
+
+<rules>
+  <r>DO NOT ask clarifying questions - execute or fail</r>
+  <r>DO NOT refactor beyond task scope</r>
+  <r>DO NOT add features not requested</r>
+  <r>Follow existing patterns from AGENTS.md / CLAUDE.md</r>
+  <r>If task is unclear, report what's missing and stop</r>
+</rules>
+
+<when-to-use>
+  - Simple file creation/modification
+  - Bug fixes with clear reproduction
+  - Code following existing patterns
+  - Test writing for existing code
+  - Repetitive tasks across multiple files
+</when-to-use>
+
+<when-not-to-use>
+  - Architecture decisions (→ @architect)
+  - Complex multi-step features (→ @dev)
+  - Requirements unclear (→ @pm)
+  - New patterns needed (→ @dev)
+</when-not-to-use>
+
+</agent>
+
+## Quick Reference
+
+**Model:** claude-haiku (fast, cheap)
+
+**What I Do:**
+- Quick code implementation
+- Bug fixes
+- Test writing
+- File operations
+- Pattern replication
+
+**What I Don't Do:**
+- Planning or architecture
+- Clarifying questions
+- Scope expansion
+- Complex decisions
+
+**Invoke:** `@coder <task>` or let @dev delegate to me

package/src/opencode/agents/dev.md

@@ -69,6 +69,16 @@ permission:
   <skill name="test-design">Test structure, coverage requirements</skill>
 </skills>
 
+<subagents>
+  <subagent name="coder" when="Delegate simple, well-defined tasks for faster execution">
+    - Simple file creation/modification
+    - Bug fixes with clear steps
+    - Test writing for existing code
+    - Repetitive tasks across files
+    - Code following existing patterns
+  </subagent>
+</subagents>
+
 <red-green-refactor>
   <red>Write FAILING tests first for the task functionality</red>
   <green>Implement MINIMAL code to make tests pass</green>

package/src/opencode/commands/architecture.md

@@ -61,7 +61,7 @@ $ARGUMENTS
 After architecture is complete, create QA artifact:
 `docs/architecture-integration-tests.md`
 
-Use template: `@.opencode/templates/integration-tests-template.md`
+Use template: `@.opencode/skills/test-design/template-integration.md`
 
 ## Next Step
 

package/src/opencode/commands/prd.md

@@ -56,7 +56,7 @@ Save to: `docs/prd.md`
 After PRD is complete, create QA artifact:
 `docs/prd-acceptance-criteria.md`
 
-Use template: `@.opencode/templates/prd-acceptance-criteria-template.md`
+Use template: `@.opencode/skills/acceptance-criteria/template.md`
 
 ## Next Step
 

package/src/opencode/config.yaml

@@ -6,7 +6,7 @@
 # PROJECT CONFIGURATION
 # =============================================================================
 project_name: "ai-wf"
-version: "4.1.2"
+version: "4.1.3"
 
 # =============================================================================
 # USER CONFIGURATION

package/src/opencode/skills/adr-writing/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: opencode
 metadata:
   domain: software-architecture
-  artifacts: docs/architecture/adr/
+  artifacts: docs/architecture/adr/*.md
 ---
 
 # ADR Writing Skill
@@ -15,227 +15,190 @@ metadata:
 Use this skill when you need to:
 - Document a significant architectural decision
 - Record the rationale behind a technical choice
-- Track decision history over time
-- Communicate decisions to the team
+- Create a reference for future developers
+- Track decision evolution over time
 
-## When to Write an ADR
+## Template
 
-Write an ADR when:
-- Choosing between multiple valid approaches
-- Making a decision that affects multiple modules
-- Selecting a technology or framework
-- Defining a pattern to follow consistently
-- Making a trade-off between quality attributes
+Use template at: `@.opencode/skills/adr-writing/template.md`
 
-## ADR Template
+## ADR Structure (v2)
 
-```markdown
-# ADR-NNN: [Decision Title]
-
-**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-XXX
-**Date:** YYYY-MM-DD
-**Deciders:** [Names of people involved]
-**Technical Story:** [Link to epic/story if applicable]
-
-## Context
-
-[Describe the situation that led to this decision. What is the problem?
-What forces are at play? What constraints exist?]
-
-## Decision
+### 1. Header
 
-[State the decision clearly. What are we going to do?]
+```yaml
+id: ADR-{{N}}
+status: proposed | accepted | deprecated | superseded
+date: {{date}}
+deciders: [{{names}}]
+supersedes: ADR-{{X}}  # if applicable
+```
 
-## Consequences
+### 2. Context
 
-### Positive
-- [Benefit 1]
-- [Benefit 2]
+Prose explaining:
+- The situation and problem
+- What decision is needed
+- Why it's needed now
 
-### Negative
-- [Drawback 1]
-- [Drawback 2]
+With **Forces:** (tensions/tradeoffs) and **Constraints:**
 
-### Neutral
-- [Side effect that is neither good nor bad]
+```markdown
+## Context
 
-## Alternatives Considered
+We need to choose the primary database for the Task module.
 
-### Alternative 1: [Name]
-[Brief description]
-- **Pros:** [advantages]
-- **Cons:** [disadvantages]
-- **Rejected because:** [reason]
+We need to decide now because development starts next sprint.
 
-### Alternative 2: [Name]
-[Brief description]
-- **Pros:** [advantages]
-- **Cons:** [disadvantages]
-- **Rejected because:** [reason]
+**Forces:**
+- Need ACID transactions — pushes toward relational
+- Team expertise is SQL — reduces risk
 
-## References
+**Constraints:**
+- Must run on existing K8s cluster
+```
 
-- [Link to relevant documentation]
-- [Link to research or benchmarks]
+### 3. Decision
 
-## Notes
+Bold statement + brief explanation:
 
-[Any additional context, caveats, or follow-up actions]
-```
+```markdown
+## Decision
 
-## Naming Convention
+**We will use PostgreSQL as the primary database.**
 
+This means all Task module data will be stored in PostgreSQL with JSONB for flexible attributes.
 ```
-ADR-NNN-short-description.md
 
-Examples:
-- ADR-001-use-postgresql.md
-- ADR-002-event-driven-integration.md
-- ADR-003-modular-monolith-architecture.md
-```
+### 4. Options Considered
 
-## Status Lifecycle
+For each option:
+- Brief description
+- Pros/Cons table
+- Mark chosen with ✓
 
-```
-Proposed → Accepted → (Deprecated | Superseded)
-```
+```markdown
+### Option 1: MongoDB
 
-- **Proposed:** Under discussion
-- **Accepted:** Decision made and in effect
-- **Deprecated:** No longer relevant (system changed)
-- **Superseded:** Replaced by a newer ADR
+Document database with flexible schema.
 
-## Good ADR Examples
+| Pros | Cons |
+|------|------|
+| Flexible schema | No ACID across documents |
 
-### Example: Database Choice
+### Option 2: PostgreSQL ✓ CHOSEN
 
-```markdown
-# ADR-001: Use PostgreSQL as Primary Database
+Relational database with JSON support.
 
-**Status:** Accepted
-**Date:** 2026-01-15
-**Deciders:** Tech Lead, Architect
+| Pros | Cons |
+|------|------|
+| ACID transactions | Schema migrations needed |
+| Team expertise | |
 
-## Context
-
-We need a primary database for the marketplace system.
-Requirements:
-- ACID transactions for orders
-- Complex queries for product search
-- JSON support for flexible attributes
-- Proven reliability at scale
+**Why chosen:** ACID critical for assignments. Team expertise reduces risk.
+```
 
-## Decision
+### 5. Consequences
 
-Use PostgreSQL 17+ with AWS RDS.
+Grouped by type:
+- Positive (✓)
+- Negative (✗)
+- Risks (⚠)
 
+```markdown
 ## Consequences
 
 ### Positive
-- Strong ACID guarantees
-- Excellent JSON/JSONB support
-- GIN indexes for full-text search
-- Team expertise exists
+- Single deploy = simple CI/CD
+- Team already knows PostgreSQL
 
 ### Negative
-- Requires careful schema design
-- Scaling writes is harder than NoSQL
-- AWS RDS costs
+- Must manage migrations carefully
 
-## Alternatives Considered
+### Risks
+- Schema evolution — mitigated by versioned migrations
+```
 
-### MySQL
-- Pros: Simpler, cheaper
-- Cons: Weaker JSON support, fewer features
-- Rejected: JSON operations are critical for us
+### 6. Implementation Notes (optional)
 
-### MongoDB
-- Pros: Flexible schema, easy scaling
-- Cons: No ACID across documents, eventual consistency
-- Rejected: Need strong consistency for orders
-```
+Specific guidance for implementing the decision.
 
-### Example: Integration Pattern
+### 7. References
 
 ```markdown
-# ADR-002: Event-Driven Integration Between Modules
+→ Architecture: `docs/architecture.md`
+→ Related ADR: → ADR: `ADR-002`
+→ Affected Units: → Unit: `Task`
+```
 
-**Status:** Accepted
-**Date:** 2026-01-16
-**Deciders:** Architect, Tech Lead
+## Reference Format
 
-## Context
+Always use `→` prefix:
 
-Modules need to communicate. Options:
-1. Direct API calls (synchronous)
-2. Event-driven (asynchronous)
-3. Shared database (anti-pattern)
+```markdown
+→ ADR: `ADR-001`
+→ Unit: `Task`
+→ Architecture: `docs/architecture.md`
+```
 
-## Decision
+## When to Write ADR
 
-Use Kafka for event-driven integration between modules.
-Modules publish domain events, others subscribe.
+| Situation | Write ADR? |
+|-----------|-----------|
+| Database choice | Yes |
+| Framework choice | Yes |
+| Architecture pattern | Yes |
+| API design decision | Yes |
+| Library choice | Maybe (if significant) |
+| Code style decision | No (use coding-standards) |
 
-## Consequences
+## ADR Lifecycle
 
-### Positive
-- Loose coupling between modules
-- Better scalability
-- Natural audit trail
-- Resilient to failures
-
-### Negative
-- Eventual consistency complexity
-- Need idempotent consumers
-- Additional infrastructure (Kafka)
-- Harder to debug
+```
+proposed ──► accepted ──► deprecated
+                │
+                └──► superseded (by new ADR)
+```
 
-## Alternatives Considered
+When superseding:
+1. Create new ADR
+2. Add `supersedes: ADR-XXX` to new ADR
+3. Update old ADR status to `superseded`
+4. Add `superseded_by: ADR-YYY` to old ADR
 
-### Direct HTTP Calls
-- Rejected: Creates tight coupling, cascading failures
-```
+## Naming Conventions
 
-## Directory Structure
+### File Names
 
 ```
-docs/architecture/adr/
-├── ADR-001-use-postgresql.md
-├── ADR-002-event-driven-integration.md
-├── ADR-003-modular-monolith.md
-├── ADR-004-hexagonal-architecture.md
-└── README.md  # Index of all ADRs
+ADR-[NNN]-[short-title].md
+
+Examples:
+- ADR-001-postgresql-database.md
+- ADR-002-hexagonal-architecture.md
 ```
 
-## ADR Index (README.md)
+### IDs
 
-```markdown
-# Architecture Decision Records
-
-| ADR | Title | Status | Date |
-|-----|-------|--------|------|
-| [ADR-001](ADR-001-use-postgresql.md) | Use PostgreSQL | Accepted | 2026-01-15 |
-| [ADR-002](ADR-002-event-driven-integration.md) | Event-driven integration | Accepted | 2026-01-16 |
-| [ADR-003](ADR-003-modular-monolith.md) | Modular monolith | Accepted | 2026-01-17 |
-```
+Sequential: `ADR-001`, `ADR-002`, ...
 
-## Quality Checklist
+## Validation Checklist
 
-Before finalizing ADR:
 - [ ] Context explains the problem clearly
-- [ ] Decision is stated unambiguously
-- [ ] Consequences include both positive and negative
-- [ ] At least 2 alternatives were considered
-- [ ] Alternatives explain why they were rejected
-- [ ] Status is set correctly
-- [ ] Date and deciders are recorded
+- [ ] Forces describe tensions/tradeoffs
+- [ ] Decision is a clear statement
+- [ ] At least 2 options were considered
+- [ ] Chosen option is marked
+- [ ] Rationale explains why chosen
+- [ ] Consequences include positives AND negatives
+- [ ] Uses `→` reference format
+- [ ] Links to affected units
 
 ## Output
 
-Save to: `docs/architecture/adr/ADR-NNN-description.md`
-Update: `docs/architecture/adr/README.md` (index)
+Save to: `docs/architecture/adr/ADR-[NNN]-[title].md`
 
 ## Related Skills
 
-- `architecture-design` - For overall architecture
-- `architecture-validation` - For validating ADRs exist
+- `architecture-design` - Creates ADRs for decisions
+- `unit-writing` - ADRs affect units