owflow 0.1.3 → 0.1.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +169 -169
- package/dist/agents/e2e-test-verifier.md +1 -1
- package/dist/commands/diagrams-mermaid.md +37 -0
- package/dist/commands/html-renderer.md +37 -0
- package/dist/commands/quick-plan.md +9 -9
- package/dist/skills/development/SKILL.md +15 -0
- package/dist/skills/diagrams-mermaid/SKILL.md +156 -0
- package/dist/skills/diagrams-mermaid/references/reference.md +148 -0
- package/dist/skills/docs-manager/SKILL.md +10 -10
- package/dist/skills/flow-init/SKILL.md +15 -0
- package/dist/skills/html-renderer/SKILL.md +159 -0
- package/dist/skills/html-renderer/references/index.html +318 -0
- package/dist/skills/html-renderer/references/styles.css +388 -0
- package/dist/skills/html-renderer/references/tokens.json +104 -0
- package/dist/skills/migration/SKILL.md +12 -0
- package/dist/skills/migration/references/migration-strategies.md +65 -32
- package/dist/skills/migration/references/migration-types.md +80 -27
- package/dist/skills/performance/SKILL.md +12 -0
- package/dist/skills/quick-bugfix/SKILL.md +4 -4
- package/dist/skills/research/SKILL.md +8 -0
- package/dist/skills/standards-discover/references/docs-extractor-prompt.md +1 -1
- package/package.json +1 -1
- /package/dist/skills/docs-manager/references/{claude-md-template.md → agents-md-template.md} +0 -0
package/README.md
CHANGED
|
@@ -1,169 +1,169 @@
|
|
|
1
|
-

|
|
2
|
-
|
|
3
|
-
# Owflow
|
|
4
|
-
|
|
5
|
-
**Structured, standards-aware development workflows for OpenCode**
|
|
6
|
-
|
|
7
|
-
Describe what you want to build, and the plugin handles the rest - from specification through implementation to verification - while enforcing your project's coding standards at every step.
|
|
8
|
-
|
|
9
|
-
Started as a simple OpenCode fork of [Maister Claude Code plugin](https://github.com/SkillPanel/maister), Owflow aims to deliver production ready workflows using the full [Opencode](https://opencode.ai/) plugin support.
|
|
10
|
-
|
|
11
|
-
## What You Get
|
|
12
|
-
|
|
13
|
-
- **Guided workflows** for features, bug fixes, enhancements, performance, migrations, research, and product design
|
|
14
|
-
- **Auto-discovered standards** from your codebase - config files, source patterns, and documentation are analyzed and enforced throughout every workflow
|
|
15
|
-
- **Test-driven implementation** with automated planning, incremental verification, and full test suite runs before completion
|
|
16
|
-
- **Pause and resume** any workflow - state is preserved across sessions
|
|
17
|
-
- **Production readiness checks** including code review, reality assessment, and pragmatic over-engineering detection
|
|
18
|
-
|
|
19
|
-
## Getting Started
|
|
20
|
-
|
|
21
|
-
### Prerequisites
|
|
22
|
-
|
|
23
|
-
- [Opencode](https://opencode.ai/) CLI installed and configured
|
|
24
|
-
- [Node.js](https://nodejs.org/) >= 25
|
|
25
|
-
|
|
26
|
-
### Installation
|
|
27
|
-
|
|
28
|
-
#### Install the plugin
|
|
29
|
-
|
|
30
|
-
```bash
|
|
31
|
-
npm install owflow
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
#### Add owflow to the `plugin` array in your `opencode.json` ([global or project-level](https://opencode.ai/docs/plugins/#load-order)):
|
|
35
|
-
|
|
36
|
-
```json
|
|
37
|
-
{
|
|
38
|
-
"plugin": ["owflow"]
|
|
39
|
-
}
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
### Initial project setup
|
|
43
|
-
|
|
44
|
-
Initialize your project to auto-detect coding standards and generate project documentation:
|
|
45
|
-
|
|
46
|
-
```bash
|
|
47
|
-
/flow-init
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
This scans your codebase and creates `.owflow/` with standards, docs, and task folders. May take a few minutes on larger projects.
|
|
51
|
-
|
|
52
|
-
If you have another project already using Owflow, you can reuse its standards as a starting point:
|
|
53
|
-
|
|
54
|
-
```bash
|
|
55
|
-
/flow-init --standards-from=/path/to/other-project
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
### First Workflow
|
|
59
|
-
|
|
60
|
-
```bash
|
|
61
|
-
/development Add user profile page with avatar upload
|
|
62
|
-
```
|
|
63
|
-
|
|
64
|
-
Or just discuss your task with
|
|
65
|
-
|
|
66
|
-
```bash
|
|
67
|
-
/development
|
|
68
|
-
```
|
|
69
|
-
|
|
70
|
-
The plugin picks up context from your conversation - no arguments needed.
|
|
71
|
-
|
|
72
|
-
## How It Works
|
|
73
|
-
|
|
74
|
-
1. You describe a task - either as an argument or just in conversation
|
|
75
|
-
2. The plugin classifies it (feature, bug, enhancement, etc.) and proposes a workflow
|
|
76
|
-
3. You confirm, and it guides you through phases: **requirements → spec → plan → implement → verify**
|
|
77
|
-
4. At each phase, it asks for your input and decisions
|
|
78
|
-
5. You get tested, verified code with a detailed work log
|
|
79
|
-
|
|
80
|
-
All artifacts are saved in `.owflow/tasks/` organized by type and date.
|
|
81
|
-
|
|
82
|
-
### Context-Aware Commands
|
|
83
|
-
|
|
84
|
-
Every workflow command works without arguments. The plugin reads your current conversation to extract the task description and auto-detect the task type:
|
|
85
|
-
|
|
86
|
-
```
|
|
87
|
-
You: "The login page throws a 500 error when the session expires"
|
|
88
|
-
You: /development
|
|
89
|
-
→ Auto-detects: bug fix, extracts description from conversation
|
|
90
|
-
```
|
|
91
|
-
|
|
92
|
-
```
|
|
93
|
-
You: /standards-update
|
|
94
|
-
→ Scans conversation for patterns like "we always use..." or "prefer X over Y"
|
|
95
|
-
```
|
|
96
|
-
|
|
97
|
-
You can always be explicit when you prefer - arguments and flags simply override the auto-detection.
|
|
98
|
-
|
|
99
|
-
## Supported Workflows
|
|
100
|
-
|
|
101
|
-
| Command | Use When |
|
|
102
|
-
| ----------------- | ------------------------------------------- |
|
|
103
|
-
| `/development` | Features, bug fixes, enhancements |
|
|
104
|
-
| `/research` | Research with synthesis and solution design |
|
|
105
|
-
| `/performance` | Optimizing speed or resource usage |
|
|
106
|
-
| `/migration` | Changing technologies or patterns |
|
|
107
|
-
| `/product-design` | Product and feature design |
|
|
108
|
-
|
|
109
|
-
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.
|
|
110
|
-
|
|
111
|
-
### Quick Commands
|
|
112
|
-
|
|
113
|
-
For smaller tasks that don't need a full workflow:
|
|
114
|
-
|
|
115
|
-
| Command | Use When |
|
|
116
|
-
| --------------- | ----------------------------------------------------------- |
|
|
117
|
-
| `/quick-plan` | You want a plan with standards awareness before coding |
|
|
118
|
-
| `/quick-dev` | You know what to do - just implement with standards applied |
|
|
119
|
-
| `/quick-bugfix` | Quick TDD-driven bug fix — write failing test, fix, verify |
|
|
120
|
-
|
|
121
|
-
## Standards-Aware Development
|
|
122
|
-
|
|
123
|
-
This is the key differentiator. Owflow doesn't just run workflows - it learns your project's conventions and enforces them:
|
|
124
|
-
|
|
125
|
-
- **`flow-init`** scans config files, source code, and documentation to auto-detect your coding standards
|
|
126
|
-
- **Continuous checking** - standards are consulted before specification, during planning, and while coding (not just at the start)
|
|
127
|
-
- **`/standards-discover`** refreshes standards from your evolving codebase
|
|
128
|
-
- **`/standards-update`** lets you add or refine standards manually, or sync from another project with `--from=PATH`
|
|
129
|
-
|
|
130
|
-
Standards live in `.owflow/docs/standards/` and are indexed in `.owflow/docs/INDEX.md`.
|
|
131
|
-
|
|
132
|
-
**Important**: Do not use plan mode with workflows (see [Best Practices](#best-practices) below).
|
|
133
|
-
|
|
134
|
-
## Beta Channel
|
|
135
|
-
|
|
136
|
-
Want to try experimental features before they hit stable? Install from the beta channel:
|
|
137
|
-
|
|
138
|
-
TBD
|
|
139
|
-
|
|
140
|
-
## Best Practices
|
|
141
|
-
|
|
142
|
-
**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.
|
|
143
|
-
|
|
144
|
-
**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.
|
|
145
|
-
|
|
146
|
-
**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:
|
|
147
|
-
|
|
148
|
-
```bash
|
|
149
|
-
/development .owflow/tasks/research/2026-01-12-oauth-research
|
|
150
|
-
```
|
|
151
|
-
|
|
152
|
-
You can also append additional instructions to narrow scope or guide the workflow:
|
|
153
|
-
|
|
154
|
-
```bash
|
|
155
|
-
/development .owflow/tasks/product-design/2026-03-10-dashboard-redesign Implement only phase 1
|
|
156
|
-
```
|
|
157
|
-
|
|
158
|
-
## Known Issues
|
|
159
|
-
|
|
160
|
-
**Orchestrator may stall after long phases.** After context compaction (which typically happens after lengthy phases like implementation), the main agent may stop progressing automatically. If you notice it's idle, just type something like "continue" or "proceed" — it will pick up where it left off. You can also re-invoke the workflow in resume mode to reload the orchestrator state:
|
|
161
|
-
|
|
162
|
-
```bash
|
|
163
|
-
/development .owflow/tasks/development/2026-03-24-my-feature
|
|
164
|
-
```
|
|
165
|
-
|
|
166
|
-
## Learn More
|
|
167
|
-
|
|
168
|
-
- [Workflow Details](docs/workflows.md) - phases, examples, and task structure for each workflow type
|
|
169
|
-
- [Full Command Reference](docs/commands.md) - all workflow, review, utility, and quick commands
|
|
1
|
+

|
|
2
|
+
|
|
3
|
+
# Owflow
|
|
4
|
+
|
|
5
|
+
**Structured, standards-aware development workflows for OpenCode**
|
|
6
|
+
|
|
7
|
+
Describe what you want to build, and the plugin handles the rest - from specification through implementation to verification - while enforcing your project's coding standards at every step.
|
|
8
|
+
|
|
9
|
+
Started as a simple OpenCode fork of [Maister Claude Code plugin](https://github.com/SkillPanel/maister), Owflow aims to deliver production ready workflows using the full [Opencode](https://opencode.ai/) plugin support.
|
|
10
|
+
|
|
11
|
+
## What You Get
|
|
12
|
+
|
|
13
|
+
- **Guided workflows** for features, bug fixes, enhancements, performance, migrations, research, and product design
|
|
14
|
+
- **Auto-discovered standards** from your codebase - config files, source patterns, and documentation are analyzed and enforced throughout every workflow
|
|
15
|
+
- **Test-driven implementation** with automated planning, incremental verification, and full test suite runs before completion
|
|
16
|
+
- **Pause and resume** any workflow - state is preserved across sessions
|
|
17
|
+
- **Production readiness checks** including code review, reality assessment, and pragmatic over-engineering detection
|
|
18
|
+
|
|
19
|
+
## Getting Started
|
|
20
|
+
|
|
21
|
+
### Prerequisites
|
|
22
|
+
|
|
23
|
+
- [Opencode](https://opencode.ai/) CLI installed and configured
|
|
24
|
+
- [Node.js](https://nodejs.org/) >= 25
|
|
25
|
+
|
|
26
|
+
### Installation
|
|
27
|
+
|
|
28
|
+
#### Install the plugin
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
npm install owflow
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
#### Add owflow to the `plugin` array in your `opencode.json` ([global or project-level](https://opencode.ai/docs/plugins/#load-order)):
|
|
35
|
+
|
|
36
|
+
```json
|
|
37
|
+
{
|
|
38
|
+
"plugin": ["owflow"]
|
|
39
|
+
}
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### Initial project setup
|
|
43
|
+
|
|
44
|
+
Initialize your project to auto-detect coding standards and generate project documentation:
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
/flow-init
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
This scans your codebase and creates `.owflow/` with standards, docs, and task folders. May take a few minutes on larger projects.
|
|
51
|
+
|
|
52
|
+
If you have another project already using Owflow, you can reuse its standards as a starting point:
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
/flow-init --standards-from=/path/to/other-project
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
### First Workflow
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
/development Add user profile page with avatar upload
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
Or just discuss your task with Agent and then run:
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
/development
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
The plugin picks up context from your conversation - no arguments needed.
|
|
71
|
+
|
|
72
|
+
## How It Works
|
|
73
|
+
|
|
74
|
+
1. You describe a task - either as an argument or just in conversation
|
|
75
|
+
2. The plugin classifies it (feature, bug, enhancement, etc.) and proposes a workflow
|
|
76
|
+
3. You confirm, and it guides you through phases: **requirements → spec → plan → implement → verify**
|
|
77
|
+
4. At each phase, it asks for your input and decisions
|
|
78
|
+
5. You get tested, verified code with a detailed work log
|
|
79
|
+
|
|
80
|
+
All artifacts are saved in `.owflow/tasks/` organized by type and date.
|
|
81
|
+
|
|
82
|
+
### Context-Aware Commands
|
|
83
|
+
|
|
84
|
+
Every workflow command works without arguments. The plugin reads your current conversation to extract the task description and auto-detect the task type:
|
|
85
|
+
|
|
86
|
+
```
|
|
87
|
+
You: "The login page throws a 500 error when the session expires"
|
|
88
|
+
You: /development
|
|
89
|
+
→ Auto-detects: bug fix, extracts description from conversation
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
```
|
|
93
|
+
You: /standards-update
|
|
94
|
+
→ Scans conversation for patterns like "we always use..." or "prefer X over Y"
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
You can always be explicit when you prefer - arguments and flags simply override the auto-detection.
|
|
98
|
+
|
|
99
|
+
## Supported Workflows
|
|
100
|
+
|
|
101
|
+
| Command | Use When |
|
|
102
|
+
| ----------------- | ------------------------------------------- |
|
|
103
|
+
| `/development` | Features, bug fixes, enhancements |
|
|
104
|
+
| `/research` | Research with synthesis and solution design |
|
|
105
|
+
| `/performance` | Optimizing speed or resource usage |
|
|
106
|
+
| `/migration` | Changing technologies or patterns |
|
|
107
|
+
| `/product-design` | Product and feature design |
|
|
108
|
+
|
|
109
|
+
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.
|
|
110
|
+
|
|
111
|
+
### Quick Commands
|
|
112
|
+
|
|
113
|
+
For smaller tasks that don't need a full workflow:
|
|
114
|
+
|
|
115
|
+
| Command | Use When |
|
|
116
|
+
| --------------- | ----------------------------------------------------------- |
|
|
117
|
+
| `/quick-plan` | You want a plan with standards awareness before coding |
|
|
118
|
+
| `/quick-dev` | You know what to do - just implement with standards applied |
|
|
119
|
+
| `/quick-bugfix` | Quick TDD-driven bug fix — write failing test, fix, verify |
|
|
120
|
+
|
|
121
|
+
## Standards-Aware Development
|
|
122
|
+
|
|
123
|
+
This is the key differentiator. Owflow doesn't just run workflows - it learns your project's conventions and enforces them:
|
|
124
|
+
|
|
125
|
+
- **`flow-init`** scans config files, source code, and documentation to auto-detect your coding standards
|
|
126
|
+
- **Continuous checking** - standards are consulted before specification, during planning, and while coding (not just at the start)
|
|
127
|
+
- **`/standards-discover`** refreshes standards from your evolving codebase
|
|
128
|
+
- **`/standards-update`** lets you add or refine standards manually, or sync from another project with `--from=PATH`
|
|
129
|
+
|
|
130
|
+
Standards live in `.owflow/docs/standards/` and are indexed in `.owflow/docs/INDEX.md`.
|
|
131
|
+
|
|
132
|
+
**Important**: Do not use plan mode with workflows (see [Best Practices](#best-practices) below).
|
|
133
|
+
|
|
134
|
+
## Beta Channel
|
|
135
|
+
|
|
136
|
+
Want to try experimental features before they hit stable? Install from the beta channel:
|
|
137
|
+
|
|
138
|
+
TBD
|
|
139
|
+
|
|
140
|
+
## Best Practices
|
|
141
|
+
|
|
142
|
+
**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.
|
|
143
|
+
|
|
144
|
+
**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.
|
|
145
|
+
|
|
146
|
+
**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:
|
|
147
|
+
|
|
148
|
+
```bash
|
|
149
|
+
/development .owflow/tasks/research/2026-01-12-oauth-research
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
You can also append additional instructions to narrow scope or guide the workflow:
|
|
153
|
+
|
|
154
|
+
```bash
|
|
155
|
+
/development .owflow/tasks/product-design/2026-03-10-dashboard-redesign Implement only phase 1
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
## Known Issues
|
|
159
|
+
|
|
160
|
+
**Orchestrator may stall after long phases.** After context compaction (which typically happens after lengthy phases like implementation), the main agent may stop progressing automatically. If you notice it's idle, just type something like "continue" or "proceed" — it will pick up where it left off. You can also re-invoke the workflow in resume mode to reload the orchestrator state:
|
|
161
|
+
|
|
162
|
+
```bash
|
|
163
|
+
/development .owflow/tasks/development/2026-03-24-my-feature
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
## Learn More
|
|
167
|
+
|
|
168
|
+
- [Workflow Details](docs/workflows.md) - phases, examples, and task structure for each workflow type
|
|
169
|
+
- [Full Command Reference](docs/commands.md) - all workflow, review, utility, and quick commands
|
|
@@ -299,7 +299,7 @@ Categorized by severity (Critical/Major/Minor/Cosmetic):
|
|
|
299
299
|
Detect unavailable tools and provide setup instructions:
|
|
300
300
|
|
|
301
301
|
- Install playwright-mcp
|
|
302
|
-
- Configure MCP server in
|
|
302
|
+
- Configure MCP server in OpenCode
|
|
303
303
|
- Restart and retry
|
|
304
304
|
|
|
305
305
|
### Application Not Running
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: diagrams-mermaid
|
|
3
|
+
description: Generate Mermaid diagrams from natural language descriptions. Creates diagrams in markdown format with mermaid code fences. Supports flowcharts, sequence diagrams, class diagrams, state diagrams, ER diagrams, user journeys, Gantt charts, pie charts, and C4 diagrams.
|
|
4
|
+
argument-hint: [diagram description]
|
|
5
|
+
generated-from-skill: true
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
CRITICAL INSTRUCTION: You MUST invoke the diagrams-mermaid skill immediately as your FIRST action.
|
|
9
|
+
|
|
10
|
+
Use the Skill tool with these exact parameters:
|
|
11
|
+
name: "diagrams-mermaid"
|
|
12
|
+
prompt: "$ARGUMENTS"
|
|
13
|
+
|
|
14
|
+
DO NOT:
|
|
15
|
+
|
|
16
|
+
- Analyze the task before invoking the skill
|
|
17
|
+
- Decide the task is "straightforward" and skip the skill
|
|
18
|
+
- Substitute your own approach or workflow
|
|
19
|
+
- Execute any part of the workflow yourself
|
|
20
|
+
|
|
21
|
+
WHY: The user explicitly chose this workflow by using /diagrams-mermaid.
|
|
22
|
+
Invoke the skill now and let it orchestrate the complete workflow.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## About This Skill
|
|
27
|
+
|
|
28
|
+
Generate Mermaid diagrams from natural language descriptions. Creates diagrams in markdown format with mermaid code fences. Supports flowcharts, sequence diagrams, class diagrams, state diagrams, ER diagrams, user journeys, Gantt charts, pie charts, and C4 diagrams.
|
|
29
|
+
|
|
30
|
+
The skill handles:
|
|
31
|
+
|
|
32
|
+
- Diagram type selection based on description
|
|
33
|
+
- Mermaid syntax generation with proper formatting
|
|
34
|
+
- Best practices and anti-patterns enforcement
|
|
35
|
+
- Output in markdown format with mermaid code fences
|
|
36
|
+
|
|
37
|
+
See `skills/diagrams-mermaid/SKILL.md` for complete documentation.
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: html-renderer
|
|
3
|
+
description: Render a markdown plan, idea, RFC, or design note into a self-contained, share-ready HTML file using the warm editorial visual system. Output is a single .html file with all CSS inlined, written next to the source markdown file.
|
|
4
|
+
argument-hint: [path to markdown file]
|
|
5
|
+
generated-from-skill: true
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
CRITICAL INSTRUCTION: You MUST invoke the html-renderer skill immediately as your FIRST action.
|
|
9
|
+
|
|
10
|
+
Use the Skill tool with these exact parameters:
|
|
11
|
+
name: "html-renderer"
|
|
12
|
+
prompt: "$ARGUMENTS"
|
|
13
|
+
|
|
14
|
+
DO NOT:
|
|
15
|
+
|
|
16
|
+
- Analyze the task before invoking the skill
|
|
17
|
+
- Decide the task is "straightforward" and skip the skill
|
|
18
|
+
- Substitute your own approach or workflow
|
|
19
|
+
- Execute any part of the workflow yourself
|
|
20
|
+
|
|
21
|
+
WHY: The user explicitly chose this workflow by using /html-renderer.
|
|
22
|
+
Invoke the skill now and let it orchestrate the complete workflow.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## About This Skill
|
|
27
|
+
|
|
28
|
+
Render a markdown plan, idea, RFC, or design note into a self-contained, share-ready HTML file using the warm editorial visual system. Output is a single .html file with all CSS inlined, written next to the source markdown file.
|
|
29
|
+
|
|
30
|
+
The skill handles:
|
|
31
|
+
|
|
32
|
+
- Markdown parsing and semantic HTML generation
|
|
33
|
+
- Design system application with warm editorial styling
|
|
34
|
+
- Mermaid diagram rendering via CDN (when present)
|
|
35
|
+
- Self-contained output with inlined CSS
|
|
36
|
+
|
|
37
|
+
See `skills/html-renderer/SKILL.md` for complete documentation.
|
|
@@ -5,7 +5,7 @@ description: Enter planning mode with AI SDLC standards awareness
|
|
|
5
5
|
|
|
6
6
|
# Planning Mode with Standards Awareness
|
|
7
7
|
|
|
8
|
-
Enter
|
|
8
|
+
Enter OpenCode's planning mode for a task, with automatic discovery of project standards from `.owflow/docs/`.
|
|
9
9
|
|
|
10
10
|
## Usage
|
|
11
11
|
|
|
@@ -37,7 +37,7 @@ Enter Claude Code's planning mode for a task, with automatic discovery of projec
|
|
|
37
37
|
|
|
38
38
|
### Step 2: Discover and Read Standards (BEFORE Plan Mode)
|
|
39
39
|
|
|
40
|
-
**CRITICAL: This step MUST complete before calling
|
|
40
|
+
**CRITICAL: This step MUST complete before calling Plan Agent.**
|
|
41
41
|
|
|
42
42
|
1. **Check if `.owflow/docs/INDEX.md` exists**
|
|
43
43
|
- **If not exists**: Note that no standards are available, skip to Step 3
|
|
@@ -56,7 +56,7 @@ Enter Claude Code's planning mode for a task, with automatic discovery of projec
|
|
|
56
56
|
|
|
57
57
|
### Step 3: Enter Planning Mode
|
|
58
58
|
|
|
59
|
-
**Use the `
|
|
59
|
+
**Use the `Plan agent` to trigger OpenCode's builtin planning mode.**
|
|
60
60
|
|
|
61
61
|
**Standards context from Step 2 MUST actively inform all plan mode phases:**
|
|
62
62
|
|
|
@@ -70,11 +70,11 @@ The planning mode will:
|
|
|
70
70
|
2. Launch Plan agents to design implementation approach (with standards constraints)
|
|
71
71
|
3. Review and verify alignment with user intent
|
|
72
72
|
4. Write final plan to plan file (with standards woven into steps)
|
|
73
|
-
5.
|
|
73
|
+
5. Ask for user approval (gated on mandatory standards sections)
|
|
74
74
|
|
|
75
|
-
###
|
|
75
|
+
### Approval question gate: Mandatory Standards Sections
|
|
76
76
|
|
|
77
|
-
**BLOCKING: Do NOT call
|
|
77
|
+
**BLOCKING: Do NOT call ask user for approval until the plan file contains these sections:**
|
|
78
78
|
|
|
79
79
|
1. **"## Applicable Standards"** — list each standard file that was read, with key guidelines extracted from each. If no standards exist, state: "No AI SDLC standards found. Consider running `/flow-init`."
|
|
80
80
|
|
|
@@ -85,7 +85,7 @@ The planning mode will:
|
|
|
85
85
|
- [ ] New components use TypeScript strict mode (from `standards/frontend/components.md`)
|
|
86
86
|
```
|
|
87
87
|
|
|
88
|
-
If these sections are missing from the plan file, add them before
|
|
88
|
+
If these sections are missing from the plan file, add them before asking user for approval.
|
|
89
89
|
|
|
90
90
|
### Graceful Fallback
|
|
91
91
|
|
|
@@ -102,9 +102,9 @@ project documentation and coding standards for better consistency.
|
|
|
102
102
|
|
|
103
103
|
1. **Parses** task description from user input
|
|
104
104
|
2. **Discovers and READS** applicable standard files from `.owflow/docs/` (BEFORE plan mode)
|
|
105
|
-
3. **Enters**
|
|
105
|
+
3. **Enters** OpenCode's builtin planning mode via delegating to `Plan Agent` with standards already loaded
|
|
106
106
|
4. **Produces** a plan file with implementation approach, applicable standards, and compliance checklist
|
|
107
|
-
5. **Gates**
|
|
107
|
+
5. **Gates** Approval question on mandatory standards sections in the plan file
|
|
108
108
|
|
|
109
109
|
## Benefits Over Manual Planning
|
|
110
110
|
|
|
@@ -235,6 +235,15 @@ question - "UI mockups complete. Continue to Phase 5?"
|
|
|
235
235
|
|
|
236
236
|
**SELF-CHECK**: Did you just invoke the Task tool with `specification-creator`? Or did you start writing spec.md yourself? If the latter, STOP immediately and invoke the Task tool instead.
|
|
237
237
|
|
|
238
|
+
**Part D — Diagram Refinement (Skill, content-preserving)**:
|
|
239
|
+
|
|
240
|
+
7. Invoke Skill tool: `diagrams-mermaid` to refine `implementation/spec.md`
|
|
241
|
+
8. Add diagrams that clarify scope and communication (without replacing prose):
|
|
242
|
+
- `flowchart` for primary functional path,
|
|
243
|
+
- `sequenceDiagram` for key component interaction,
|
|
244
|
+
- optionally `C4Component` if internal module structure is required by scope.
|
|
245
|
+
9. If required context is missing, add explicit open questions/assumptions section instead of inventing entities.
|
|
246
|
+
|
|
238
247
|
**Output**: `analysis/technical-clarifications.md` (conditional), `analysis/requirements.md`, `implementation/spec.md`
|
|
239
248
|
**State**: Update `task_context.tech_clarified`, `task_context.architecture_decision`, `phase_summaries.specification`
|
|
240
249
|
|
|
@@ -285,6 +294,12 @@ question - Display executive summary before asking. Read `verification/spec-audi
|
|
|
285
294
|
|
|
286
295
|
**SELF-CHECK**: Did you just invoke the Task tool with `implementation-planner`? Or did you start writing implementation-plan.md yourself? If the latter, STOP immediately and invoke the Task tool instead.
|
|
287
296
|
|
|
297
|
+
**Post-plan diagram refinement (Skill, content-preserving)**:
|
|
298
|
+
|
|
299
|
+
- Invoke Skill tool: `diagrams-mermaid` for `implementation/implementation-plan.md`
|
|
300
|
+
- Add a compact execution diagram (task-group dependency flow or phase/state view).
|
|
301
|
+
- Keep implementation steps authoritative; diagrams are explanatory, not a replacement for task descriptions.
|
|
302
|
+
|
|
288
303
|
→ Pause
|
|
289
304
|
|
|
290
305
|
question - Display executive summary before asking. Read `implementation/implementation-plan.md` and extract: number of task groups, total implementation steps, key dependencies between groups, estimated complexity. Format as brief overview then "Continue to implementation?"
|