owflow 0.1.5 → 0.1.6

package/README.md

@@ -10,7 +10,7 @@ Started as a simple OpenCode fork of [Maister Claude Code plugin](https://github
 
 ## What You Get
 
-- **Guided workflows** for features, bug fixes, enhancements, performance, migrations, research, and product design
+- **Guided workflows** for features, bug fixes, enhancements, performance, migrations and research
 - **Auto-discovered standards** from your codebase - config files, source patterns, and documentation are analyzed and enforced throughout every workflow
 - **Test-driven implementation** with automated planning, incremental verification, and full test suite runs before completion
 - **Pause and resume** any workflow - state is preserved across sessions
@@ -25,17 +25,29 @@ Started as a simple OpenCode fork of [Maister Claude Code plugin](https://github
 
 ### Installation
 
-#### Install the plugin
+#### Add owflow to the `plugin` array in your `opencode.json` ([global or project-level](https://opencode.ai/docs/plugins/#load-order)):
 
-```bash
-npm install owflow
+To use it across multiple repos it is advised to use the global level:
+
+Linux/MacOS:
+
+```sh
+~/.config/opencode/opencode.json
 ```
 
-#### Add owflow to the `plugin` array in your `opencode.json` ([global or project-level](https://opencode.ai/docs/plugins/#load-order)):
+Windows:
+
+```powershell
+\Users\YourUsername\.config\opencode\opencode.json
+```
+
+In `opencode.json`:
 
 ```json
 {
-  "plugin": ["owflow"]
+  ...
+  "plugin": ["owflow@latest"]
+  ...
 }
 ```
 
@@ -98,13 +110,12 @@ You can always be explicit when you prefer - arguments and flags simply override
 
 ## Supported Workflows
 
-| Command           | Use When                                    |
-| ----------------- | ------------------------------------------- |
-| `/development`    | Features, bug fixes, enhancements           |
-| `/research`       | Research with synthesis and solution design |
-| `/performance`    | Optimizing speed or resource usage          |
-| `/migration`      | Changing technologies or patterns           |
-| `/product-design` | Product and feature design                  |
+| Command        | Use When                                    |
+| -------------- | ------------------------------------------- |
+| `/development` | Features, bug fixes, enhancements           |
+| `/research`    | Research with synthesis and solution design |
+| `/performance` | Optimizing speed or resource usage          |
+| `/migration`   | Changing technologies or patterns           |
 
 Task type (feature/bug/enhancement) is auto-detected from context. Override with `--type=feature|bug|enhancement` if needed. Or use `/work` as a single entry point that routes to the right workflow.
 
@@ -112,11 +123,13 @@ Task type (feature/bug/enhancement) is auto-detected from context. Override with
 
 For smaller tasks that don't need a full workflow:
 
-| Command         | Use When                                                    |
-| --------------- | ----------------------------------------------------------- |
-| `/quick-plan`   | You want a plan with standards awareness before coding      |
-| `/quick-dev`    | You know what to do - just implement with standards applied |
-| `/quick-bugfix` | Quick TDD-driven bug fix — write failing test, fix, verify  |
+| Command         | Use When                                                    | Artifacts                               |
+| --------------- | ----------------------------------------------------------- | --------------------------------------- |
+| `/quick-plan`   | You want a plan with standards awareness before coding      | `task.yml`, `findings.md`               |
+| `/quick-dev`    | You know what to do - just implement with standards applied | `task.yml`, `summary.md`                |
+| `/quick-bugfix` | Quick TDD-driven bug fix — write failing test, fix, verify  | `task.yml`, `findings.md`, `summary.md` |
+
+All quick commands create lightweight task directories under `.owflow/tasks/quick-{type}/` with a `task.yml` for traceability.
 
 ## Standards-Aware Development
 
@@ -141,9 +154,9 @@ TBD
 
 **Don't use plan mode when starting a workflow.** Planning is a built-in part of every workflow — the orchestrator creates specs, plans, and other files as it goes. OpenCode's plan mode restricts file creation, which conflicts with this. Let the workflow handle planning on its own.
 
-**Start workflows in a fresh session.** This is especially useful when chaining workflows (e.g., research → development). Research and product-design artifacts already contain all the context needed, so a clean session avoids noise from prior conversation.
+**Start workflows in a fresh session.** This is especially useful when chaining workflows (e.g., research → development). Research artifacts already contain all the context needed, so a clean session avoids noise from prior conversation.
 
-**Chain workflows by passing a task folder.** If you've completed a research or product-design workflow and want to build on those results, pass the task folder directly:
+**Chain workflows by passing a task folder.** If you've completed a research workflow and want to build on those results, pass the task folder directly:
 
 ```bash
 /development .owflow/tasks/research/2026-01-12-oauth-research
@@ -152,7 +165,7 @@ TBD
 You can also append additional instructions to narrow scope or guide the workflow:
 
 ```bash
-/development .owflow/tasks/product-design/2026-03-10-dashboard-redesign Implement only phase 1
+/development .owflow/tasks/research/2026-01-12-oauth-research Implement only phase 1
 ```
 
 ## Known Issues

package/dist/__tests__/verify_template.test.js

@@ -0,0 +1,102 @@
+import { expect, test, describe, beforeAll, afterAll } from "bun:test";
+import fs from "node:fs";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+import { verify_template } from "../tools/verify_template";
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+describe("verify_template tool", () => {
+    const templatesDir = path.join(__dirname, "../templates");
+    const testDir = path.join(__dirname, "test_tmp_dir");
+    const testTemplateName = "test-template.yml";
+    const testTemplatePath = path.join(templatesDir, testTemplateName);
+    beforeAll(() => {
+        // Ensure templates dir exists
+        if (!fs.existsSync(templatesDir)) {
+            fs.mkdirSync(templatesDir, { recursive: true });
+        }
+        // Create a dummy template
+        fs.writeFileSync(testTemplatePath, `
+key1: value1
+key2:
+  subKey1: subValue1
+      `);
+        // Ensure test dir exists
+        if (!fs.existsSync(testDir)) {
+            fs.mkdirSync(testDir, { recursive: true });
+        }
+    });
+    afterAll(() => {
+        // Cleanup
+        if (fs.existsSync(testTemplatePath)) {
+            fs.rmSync(testTemplatePath);
+        }
+        if (fs.existsSync(testDir)) {
+            fs.rmSync(testDir, { recursive: true, force: true });
+        }
+    });
+    test("should return error if file not found", async () => {
+        const result = await verify_template.execute({ filePath: "nonexistent.yml", templateName: testTemplateName }, { directory: testDir });
+        expect(result.output).toContain("File not found at nonexistent.yml");
+    });
+    test("should return error if template not found", async () => {
+        const filePath = "target.yml";
+        fs.writeFileSync(path.join(testDir, filePath), "key1: value");
+        const result = await verify_template.execute({ filePath, templateName: "nonexistent-template.yml" }, { directory: testDir });
+        expect(result.output).toContain("Template 'nonexistent-template.yml' not found");
+    });
+    test("should return error if target file has invalid YAML syntax", async () => {
+        const filePath = "invalid.yml";
+        fs.writeFileSync(path.join(testDir, filePath), "key1: : value\n  invalid");
+        const result = await verify_template.execute({ filePath, templateName: testTemplateName }, { directory: testDir });
+        expect(result.output).toContain("YAML Syntax Error in invalid.yml");
+    });
+    test("should return error if target file is missing keys from template", async () => {
+        const filePath = "missing-keys.yml";
+        // Missing key2
+        fs.writeFileSync(path.join(testDir, filePath), "key1: some-value");
+        const result = await verify_template.execute({ filePath, templateName: testTemplateName }, { directory: testDir });
+        expect(result.output).toContain("YAML Structure Validation Failed");
+        expect(result.output).toContain("- Missing key: key2");
+    });
+    test("should pass if target file matches template structure", async () => {
+        const filePath = "valid.yml";
+        fs.writeFileSync(path.join(testDir, filePath), `
+key1: different_value
+key2:
+  subKey1: different_sub_value
+extraKey: this is fine
+      `);
+        const result = await verify_template.execute({ filePath, templateName: testTemplateName }, { directory: testDir });
+        expect(result.output).toBe("File exists and follows the correct YAML structure.");
+    });
+    test("should pass if template has null or non-object values and target has them too", async () => {
+        const nullTemplateName = "null-template.yml";
+        const nullTemplatePath = path.join(templatesDir, nullTemplateName);
+        fs.writeFileSync(nullTemplatePath, "key: null\nother: 123");
+        const filePath = "valid-null.yml";
+        fs.writeFileSync(path.join(testDir, filePath), "key: something\nother: 456");
+        const result = await verify_template.execute({ filePath, templateName: nullTemplateName }, { directory: testDir });
+        expect(result.output).toBe("File exists and follows the correct YAML structure.");
+        fs.rmSync(nullTemplatePath);
+    });
+    describe("real templates validation", () => {
+        let templateFiles = [];
+        try {
+            const files = fs.readdirSync(templatesDir);
+            templateFiles = files.filter(f => f.endsWith('.yml') || f.endsWith('.yaml') || f.endsWith('.md'));
+            // Filter out our dummy test template
+            templateFiles = templateFiles.filter(f => f !== "test-template.yml" && f !== "null-template.yml");
+        }
+        catch (e) {
+            // templates dir might not exist or be readable in some contexts, though beforeAll ensures it exists
+        }
+        for (const templateName of templateFiles) {
+            test(`should successfully validate a valid instance of ${templateName}`, async () => {
+                // We use the templates directory as the working directory 
+                // and the template name as the filePath, effectively comparing the template to itself to ensure it's structurally valid.
+                const result = await verify_template.execute({ filePath: templateName, templateName }, { directory: templatesDir });
+                expect(result.output).toBe("File exists and follows the correct YAML structure.");
+            });
+        }
+    });
+});

package/dist/agents/task-classifier.md

@@ -44,18 +44,15 @@ You are a specialized task classification agent that analyzes task descriptions
 
 ## Supported Workflow Types
 
-| Type               | Purpose                                                                             | Primary Keywords                                                                            |
-| ------------------ | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
-| **development**    | Any code change: bug fixes, enhancements, new features, refactoring, security fixes | fix, bug, error, improve, enhance, add, new, create, refactor, vulnerability                |
-| **performance**    | Optimize speed/efficiency                                                           | slow, optimize, faster, bottleneck, latency                                                 |
-| **migration**      | Change tech/patterns/versions                                                       | migrate, move from X to Y, upgrade to, transition                                           |
-| **research**       | Investigate, document, explore options                                              | research, investigate, explore, document, spike, compare                                    |
-| **product-design** | Design features/products before building                                            | design, product design, feature design, wireframe, prototype, mockup, user journey, persona |
+| Type            | Purpose                                                                             | Primary Keywords                                                             |
+| --------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
+| **development** | Any code change: bug fixes, enhancements, new features, refactoring, security fixes | fix, bug, error, improve, enhance, add, new, create, refactor, vulnerability |
+| **performance** | Optimize speed/efficiency                                                           | slow, optimize, faster, bottleneck, latency                                  |
+| **migration**   | Change tech/patterns/versions                                                       | migrate, move from X to Y, upgrade to, transition                            |
+| **research**    | Investigate, document, explore options                                              | research, investigate, explore, document, spike, compare                     |
 
 **Note**: Security fixes, refactoring, and documentation of code are all routed through `development` or `research` — they are characteristics of the work, not separate workflow types.
 
-**Key distinction**: `product-design` is for defining WHAT to build before any code is written. If the user already knows what to build and wants to implement it, that's `development`.
-
 ---
 
 ## Classification Workflow
@@ -159,13 +156,6 @@ If description contains error messages or stack traces:
 - Discovery: spike, proof of concept, prototype, feasibility
 - Documentation: document findings, write guide, create documentation
 
-**Product Design**:
-
-- Primary: design, product design, feature design, wireframe, prototype, mockup
-- Exploration: user journey, persona, user story, product brief, user flow
-- Planning: scope definition, requirements gathering, feature spec (before code)
-- **Key distinction**: Designing what to build before building it — if implementation is implied, route to development instead
-
 **Calculate Confidence Score**:
 
 ```
@@ -236,7 +226,6 @@ Please choose the workflow type that best fits:
 2. Performance - Optimize speed/efficiency
 3. Migration - Move to new tech/pattern
 4. Research - Investigate, document, explore options
-5. Product Design - Design features or products before building them
 
 Which type best describes your task?
 ```
@@ -260,7 +249,7 @@ Return structured YAML format:
 
 ```yaml
 classification:
-  task_type: [development|performance|migration|research|product-design]
+  task_type: [development|performance|migration|research]
   confidence: [percentage as integer]
   keywords_matched: [list of matched keywords]
 
@@ -394,7 +383,6 @@ Use question with relevant options
 - **performance** → performance orchestrator
 - **migration** → migration orchestrator
 - **research** → research orchestrator
-- **product-design** → product-design orchestrator
 
 **External Systems** (tries MCP → CLI → WebFetch → prompt user):
 

package/dist/commands/quick-dev.md

@@ -53,6 +53,18 @@ Implement a task directly without entering planning mode, while still applying p
   "What would you like to implement? Please describe the task."
   ```
 
+### Step 1b: Create Task Directory
+
+**Create a lightweight task directory for artifact anchoring.**
+
+1. Generate a task name from the task description:
+   - Extract 3–5 key words, convert to lowercase kebab-case
+   - Prepend today's date: `YYYY-MM-DD-kebab-name`
+   - Examples: "Add a logout button to the navbar" → `2026-05-28-add-navbar-logout-button`, "Update the API endpoint to accept JSON" → `2026-05-28-update-api-accept-json`
+2. Create directory: `.owflow/tasks/quick-dev/YYYY-MM-DD-task-name/`
+3. Write `task.yml` with initial state using the template [src/templates/quick-dev-task.yml](../templates/quick-dev-task.yml).
+4. **CRITICAL**: Use the `verify_template` tool immediately after creation to check YAML validity against `quick-dev-task.yml`.
+
 ### Step 2: Discover Standards
 
 **Check if `.owflow/docs/INDEX.md` exists:**
@@ -65,6 +77,7 @@ Implement a task directly without entering planning mode, while still applying p
    - The nature of the task
    - Keywords in the task description
 3. **READ the applicable standard files** (see Standards Reading Enforcement below)
+4. **Update `task.yml`**: Add paths of standards read to `standards_applied` list
 
 **If not exists:**
 
@@ -110,7 +123,34 @@ Implement a task directly without entering planning mode, while still applying p
 
 ### Step 5: Summary
 
-**Provide completion summary:**
+**Write `summary.md`** in the task directory:
+
+```markdown
+# Task Summary
+
+**Command**: quick-dev
+**Date**: YYYY-MM-DD
+**Status**: completed
+
+## What Was Done
+[What was implemented]
+
+## Files Modified
+- `path/to/file`
+
+## Standards Applied
+- [standard]: [guideline]
+
+## Tests
+- [test file] — [result]
+
+## Commit Suggestion
+[conventional commit message]
+```
+
+**Update `task.yml`**: set `status: completed`, `updated: [now]`.
+
+**Provide completion summary to user:**
 
 - What was implemented
 - Which standards from INDEX.md were applied
@@ -122,11 +162,13 @@ Implement a task directly without entering planning mode, while still applying p
 ## What This Does
 
 1. **Parses** task description from user input
-2. **Discovers** applicable standards from `.owflow/docs/INDEX.md`
-3. **READS** actual standard files (MANDATORY - not just INDEX.md)
-4. **Implements** directly without planning mode approval
-5. **Verifies** standards were followed
-6. **Summarizes** what was done and which standards were read and applied
+2. **Creates** lightweight task directory with `task.yml` for artifact anchoring
+3. **Discovers** applicable standards from `.owflow/docs/INDEX.md`
+4. **READS** actual standard files (MANDATORY - not just INDEX.md)
+5. **Implements** directly without planning mode approval
+6. **Verifies** standards were followed
+7. **Writes** `summary.md` in task directory and updates `task.yml` to `completed`
+8. **Summarizes** what was done and which standards were read and applied
 
 ## Graceful Fallback
 

package/dist/commands/quick-plan.md

@@ -35,6 +35,19 @@ Enter OpenCode's planning mode for a task, with automatic discovery of project s
   "What would you like to plan? Please describe the task or feature."
   ```
 
+### Step 1b: Create Task Directory
+
+**Create a lightweight task directory for artifact anchoring.**
+
+1. Generate a task name from the task description:
+   - Extract 3–5 key words, convert to lowercase kebab-case
+   - Prepend today's date: `YYYY-MM-DD-kebab-name`
+   - Examples: "Add retry logic to API client" → `2026-05-28-add-api-retry-logic`, "Refactor the payment processing module" → `2026-05-28-refactor-payment-module`
+2. Create directory: `.owflow/tasks/quick-plan/YYYY-MM-DD-task-name/`
+3. Create `analysis/` subdirectory inside it
+4. Write `task.yml` with initial state using the template [src/templates/quick-plan-task.yml](../templates/quick-plan-task.yml).
+5. **CRITICAL**: Use the `verify_template` tool immediately after creation to check YAML validity against `quick-plan-task.yml`.
+
 ### Step 2: Discover and Read Standards (BEFORE Plan Mode)
 
 **CRITICAL: This step MUST complete before calling Plan Agent.**
@@ -53,6 +66,24 @@ Enter OpenCode's planning mode for a task, with automatic discovery of project s
 4. **READ the actual standard files** using the Read tool — reading INDEX.md alone is NOT sufficient
 
 5. **Summarize key guidelines** from each standard file read — these will carry into plan mode as context
+6. **Update `task.yml`**: Add paths of standards read to `standards_applied` list
+
+### Step 2b: Write Findings
+
+**After standards discovery, write `analysis/findings.md`** in the task directory:
+
+```markdown
+# Task Analysis
+
+## Context
+[What was analyzed to inform the plan — codebase areas explored, existing patterns found]
+
+## Key Decisions
+[Architectural or implementation decisions made during planning]
+
+## Standards Referenced
+- [standard file]: [key guideline applied]
+```
 
 ### Step 3: Enter Planning Mode
 
@@ -101,10 +132,13 @@ project documentation and coding standards for better consistency.
 ## What This Does
 
 1. **Parses** task description from user input
-2. **Discovers and READS** applicable standard files from `.owflow/docs/` (BEFORE plan mode)
-3. **Enters** OpenCode's builtin planning mode via delegating to `Plan Agent` with standards already loaded
-4. **Produces** a plan file with implementation approach, applicable standards, and compliance checklist
-5. **Gates** Approval question on mandatory standards sections in the plan file
+2. **Creates** lightweight task directory with `task.yml` for artifact anchoring
+3. **Discovers and READS** applicable standard files from `.owflow/docs/` (BEFORE plan mode)
+4. **Writes** `analysis/findings.md` with task context and key decisions
+5. **Enters** OpenCode's builtin planning mode via delegating to `Plan Agent` with standards already loaded
+6. **Produces** a plan file with implementation approach, applicable standards, and compliance checklist
+7. **Gates** Approval question on mandatory standards sections in the plan file
+8. **Updates** `task.yml` with `status: completed` and `plan_path` after plan approval
 
 ## Benefits Over Manual Planning
 
@@ -117,6 +151,7 @@ project documentation and coding standards for better consistency.
 
 Once the plan is approved:
 
+- **Update `task.yml`**: set `status: completed`, `plan_path: [path to plan file]`, `updated: [now]`
 - Implementation begins based on the plan
 - Standards are applied during coding
 

package/dist/commands/work.md

@@ -59,7 +59,6 @@ Auto-classifies tasks and routes to the appropriate workflow orchestrator. Suppo
 | performance    | `performance`     |
 | migration      | `migration`       |
 | research       | `research`        |
-| product-design | `product-design`  |
 
 ---
 
@@ -93,13 +92,12 @@ Auto-classifies tasks and routes to the appropriate workflow orchestrator. Suppo
 1. Read `orchestrator-state.yml` from task folder
 2. Determine workflow type from folder path:
 
-| Folder            | Workflow Type  |
-| ----------------- | -------------- |
-| `development/`    | development    |
-| `performance/`    | performance    |
-| `migrations/`     | migration      |
-| `research/`       | research       |
-| `product-design/` | product-design |
+| Folder         | Workflow Type |
+| -------------- | ------------- |
+| `development/` | development   |
+| `performance/` | performance   |
+| `migrations/`  | migration     |
+| `research/`    | research      |
 
 3. Extract status from state file:
    - `completed`: null = in-progress, timestamp = finished
@@ -177,7 +175,7 @@ The subagent will:
 
 ```yaml
 classification:
-  task_type: [development|performance|migration|research|product-design]
+  task_type: [development|performance|migration|research]
   confidence: [percentage]
   reasoning: [explanation]
 ```
@@ -217,7 +215,6 @@ Use question with options:
 2. Performance - Optimize speed/efficiency
 3. Migration - Move to new tech/pattern
 4. Research - Investigate and document findings
-5. Product Design - Design features or products before building them
 
 Then route to selected workflow using Skill tool.
 ```
@@ -236,13 +233,12 @@ Display:
 
 ## Resume Skill Reference
 
-| Workflow Type  | Skill            | Args                                                |
-| -------------- | ---------------- | --------------------------------------------------- |
-| development    | `development`    | `--resume [path] [--from=PHASE] [--reset-attempts]` |
-| performance    | `performance`    | `--resume [path] [--from=PHASE]`                    |
-| migration      | `migration`      | `--resume [path] [--from=PHASE]`                    |
-| research       | `research`       | `--resume [path] [--from=PHASE]`                    |
-| product-design | `product-design` | `--resume [path] [--from=PHASE]`                    |
+| Workflow Type | Skill         | Args                                                |
+| ------------- | ------------- | --------------------------------------------------- |
+| development   | `development` | `--resume [path] [--from=PHASE] [--reset-attempts]` |
+| performance   | `performance` | `--resume [path] [--from=PHASE]`                    |
+| migration     | `migration`   | `--resume [path] [--from=PHASE]`                    |
+| research      | `research`    | `--resume [path] [--from=PHASE]`                    |
 
 ---
 

package/dist/index.js

@@ -6,6 +6,7 @@ import path from "node:path";
 import fs from "node:fs";
 import { fileURLToPath } from "url";
 import matter from "gray-matter";
+import { verify_template } from "./tools/verify_template";
 const __dirname = path.dirname(fileURLToPath(import.meta.url));
 const PLUGIN_ROOT = __dirname; // Points to dist/ where skills/commands/agents are copied
 /**
@@ -72,6 +73,9 @@ const prepareAgent = ({ data, content }, smallModel) => {
 const OwflowPlugin = async ({ $, directory }) => {
     const agentBySession = new Map();
     return {
+        tool: {
+            verify_template,
+        },
         /**
          * Register owflow's skills, commands, and agents so OpenCode discovers
          * them without requiring manual config file edits.