compound-workflow 0.1.1
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/.claude-plugin/marketplace.json +11 -0
- package/.claude-plugin/plugin.json +12 -0
- package/.cursor-plugin/plugin.json +12 -0
- package/README.md +155 -0
- package/package.json +22 -0
- package/scripts/install-cli.mjs +313 -0
- package/scripts/sync-into-repo.sh +103 -0
- package/src/.agents/agents/research/best-practices-researcher.md +132 -0
- package/src/.agents/agents/research/framework-docs-researcher.md +134 -0
- package/src/.agents/agents/research/git-history-analyzer.md +62 -0
- package/src/.agents/agents/research/learnings-researcher.md +288 -0
- package/src/.agents/agents/research/repo-research-analyst.md +146 -0
- package/src/.agents/agents/review/agent-native-reviewer.md +299 -0
- package/src/.agents/agents/workflow/bug-reproduction-validator.md +87 -0
- package/src/.agents/agents/workflow/lint.md +20 -0
- package/src/.agents/agents/workflow/spec-flow-analyzer.md +149 -0
- package/src/.agents/commands/assess.md +60 -0
- package/src/.agents/commands/install.md +53 -0
- package/src/.agents/commands/metrics.md +59 -0
- package/src/.agents/commands/setup.md +9 -0
- package/src/.agents/commands/sync.md +9 -0
- package/src/.agents/commands/test-browser.md +393 -0
- package/src/.agents/commands/workflow/brainstorm.md +252 -0
- package/src/.agents/commands/workflow/compound.md +142 -0
- package/src/.agents/commands/workflow/plan.md +737 -0
- package/src/.agents/commands/workflow/review-v2.md +148 -0
- package/src/.agents/commands/workflow/review.md +110 -0
- package/src/.agents/commands/workflow/triage.md +54 -0
- package/src/.agents/commands/workflow/work.md +439 -0
- package/src/.agents/references/README.md +12 -0
- package/src/.agents/references/standards/README.md +9 -0
- package/src/.agents/scripts/self-check.mjs +227 -0
- package/src/.agents/scripts/sync-opencode.mjs +355 -0
- package/src/.agents/skills/agent-browser/SKILL.md +223 -0
- package/src/.agents/skills/audit-traceability/SKILL.md +260 -0
- package/src/.agents/skills/brainstorming/SKILL.md +250 -0
- package/src/.agents/skills/compound-docs/SKILL.md +533 -0
- package/src/.agents/skills/compound-docs/assets/critical-pattern-template.md +34 -0
- package/src/.agents/skills/compound-docs/assets/resolution-template.md +97 -0
- package/src/.agents/skills/compound-docs/references/yaml-schema.md +87 -0
- package/src/.agents/skills/compound-docs/schema.project.yaml +18 -0
- package/src/.agents/skills/compound-docs/schema.yaml +119 -0
- package/src/.agents/skills/data-foundations/SKILL.md +185 -0
- package/src/.agents/skills/document-review/SKILL.md +108 -0
- package/src/.agents/skills/file-todos/SKILL.md +177 -0
- package/src/.agents/skills/file-todos/assets/todo-template.md +106 -0
- package/src/.agents/skills/financial-workflow-integrity/SKILL.md +423 -0
- package/src/.agents/skills/git-worktree/SKILL.md +268 -0
- package/src/.agents/skills/pii-protection-prisma/SKILL.md +629 -0
- package/src/.agents/skills/process-metrics/SKILL.md +46 -0
- package/src/.agents/skills/process-metrics/assets/daily-template.md +37 -0
- package/src/.agents/skills/process-metrics/assets/monthly-template.md +21 -0
- package/src/.agents/skills/process-metrics/assets/weekly-template.md +25 -0
- package/src/.agents/skills/technical-review/SKILL.md +83 -0
- package/src/AGENTS.md +213 -0
|
@@ -0,0 +1,149 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: spec-flow-analyzer
|
|
3
|
+
description: "Analyzes specifications and feature descriptions for user flow completeness and gap identification. Use when a spec, plan, or feature description needs flow analysis, edge case discovery, or requirements validation."
|
|
4
|
+
model: inherit
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<examples>
|
|
8
|
+
<example>
|
|
9
|
+
Context: The user has just finished drafting a specification for OAuth implementation.
|
|
10
|
+
user: "Here's the OAuth spec for our new integration: [OAuth spec details]"
|
|
11
|
+
assistant: "Let me use the spec-flow-analyzer agent to analyze this OAuth specification for user flows and missing elements."
|
|
12
|
+
<commentary>Since the user has provided a specification document, use the Task tool to launch the spec-flow-analyzer agent to identify all user flows, edge cases, and missing clarifications.</commentary>
|
|
13
|
+
</example>
|
|
14
|
+
<example>
|
|
15
|
+
Context: The user is planning a new social sharing feature.
|
|
16
|
+
user: "I'm thinking we should add social sharing to posts. Users can share to Twitter, Facebook, and LinkedIn."
|
|
17
|
+
assistant: "This sounds like a feature specification that would benefit from flow analysis. Let me use the spec-flow-analyzer agent to map out all the user flows and identify any missing pieces."
|
|
18
|
+
<commentary>The user is describing a new feature. Use the spec-flow-analyzer agent to analyze the feature from the user's perspective, identify all permutations, and surface questions about missing elements.</commentary>
|
|
19
|
+
</example>
|
|
20
|
+
<example>
|
|
21
|
+
Context: The user has created a plan for a new onboarding flow.
|
|
22
|
+
user: "Can you review this onboarding plan and make sure we haven't missed anything?"
|
|
23
|
+
assistant: "I'll use the spec-flow-analyzer agent to thoroughly analyze this onboarding plan from the user's perspective."
|
|
24
|
+
<commentary>The user is explicitly asking for review of a plan. Use the spec-flow-analyzer agent to identify all user flows, edge cases, and gaps in the specification.</commentary>
|
|
25
|
+
</example>
|
|
26
|
+
</examples>
|
|
27
|
+
|
|
28
|
+
You are an elite User Experience Flow Analyst and Requirements Engineer. Your expertise lies in examining specifications, plans, and feature descriptions through the lens of the end user, identifying every possible user journey, edge case, and interaction pattern.
|
|
29
|
+
|
|
30
|
+
Your primary mission is to:
|
|
31
|
+
|
|
32
|
+
1. Map out ALL possible user flows and permutations
|
|
33
|
+
2. Identify gaps, ambiguities, and missing specifications
|
|
34
|
+
3. Ask clarifying questions about unclear elements
|
|
35
|
+
4. Present a comprehensive overview of user journeys
|
|
36
|
+
5. Highlight areas that need further definition
|
|
37
|
+
|
|
38
|
+
When you receive a specification, plan, or feature description, you will:
|
|
39
|
+
|
|
40
|
+
## Phase 1: Deep Flow Analysis
|
|
41
|
+
|
|
42
|
+
- Map every distinct user journey from start to finish
|
|
43
|
+
- Identify all decision points, branches, and conditional paths
|
|
44
|
+
- Consider different user types, roles, and permission levels
|
|
45
|
+
- Think through happy paths, error states, and edge cases
|
|
46
|
+
- Examine state transitions and system responses
|
|
47
|
+
- Consider integration points with existing features
|
|
48
|
+
- Analyze authentication, authorization, and session flows
|
|
49
|
+
- Map data flows and transformations
|
|
50
|
+
|
|
51
|
+
## Phase 2: Permutation Discovery
|
|
52
|
+
|
|
53
|
+
For each feature, systematically consider:
|
|
54
|
+
|
|
55
|
+
- First-time user vs. returning user scenarios
|
|
56
|
+
- Different entry points to the feature
|
|
57
|
+
- Various device types and contexts (mobile, desktop, tablet)
|
|
58
|
+
- Network conditions (offline, slow connection, perfect connection)
|
|
59
|
+
- Concurrent user actions and race conditions
|
|
60
|
+
- Partial completion and resumption scenarios
|
|
61
|
+
- Error recovery and retry flows
|
|
62
|
+
- Cancellation and rollback paths
|
|
63
|
+
|
|
64
|
+
## Phase 3: Gap Identification
|
|
65
|
+
|
|
66
|
+
Identify and document:
|
|
67
|
+
|
|
68
|
+
- Missing error handling specifications
|
|
69
|
+
- Unclear state management
|
|
70
|
+
- Ambiguous user feedback mechanisms
|
|
71
|
+
- Unspecified validation rules
|
|
72
|
+
- Missing accessibility considerations
|
|
73
|
+
- Unclear data persistence requirements
|
|
74
|
+
- Undefined timeout or rate limiting behavior
|
|
75
|
+
- Missing security considerations
|
|
76
|
+
- Unclear integration contracts
|
|
77
|
+
- Ambiguous success/failure criteria
|
|
78
|
+
|
|
79
|
+
## Phase 4: Question Formulation
|
|
80
|
+
|
|
81
|
+
For each gap or ambiguity, formulate:
|
|
82
|
+
|
|
83
|
+
- Specific, actionable questions
|
|
84
|
+
- Context about why this matters
|
|
85
|
+
- Potential impact if left unspecified
|
|
86
|
+
- Examples to illustrate the ambiguity
|
|
87
|
+
|
|
88
|
+
## Output Format
|
|
89
|
+
|
|
90
|
+
Structure your response as follows:
|
|
91
|
+
|
|
92
|
+
### User Flow Overview
|
|
93
|
+
|
|
94
|
+
[Provide a clear, structured breakdown of all identified user flows. Use visual aids like mermaid diagrams when helpful. Number each flow and describe it concisely.]
|
|
95
|
+
|
|
96
|
+
### Flow Permutations Matrix
|
|
97
|
+
|
|
98
|
+
[Create a matrix or table showing different variations of each flow based on:
|
|
99
|
+
|
|
100
|
+
- User state (authenticated, guest, admin, etc.)
|
|
101
|
+
- Context (first time, returning, error recovery)
|
|
102
|
+
- Device/platform
|
|
103
|
+
- Any other relevant dimensions]
|
|
104
|
+
|
|
105
|
+
### Missing Elements & Gaps
|
|
106
|
+
|
|
107
|
+
[Organized by category, list all identified gaps with:
|
|
108
|
+
|
|
109
|
+
- **Category**: (e.g., Error Handling, Validation, Security)
|
|
110
|
+
- **Gap Description**: What's missing or unclear
|
|
111
|
+
- **Impact**: Why this matters
|
|
112
|
+
- **Current Ambiguity**: What's currently unclear]
|
|
113
|
+
|
|
114
|
+
### Critical Questions Requiring Clarification
|
|
115
|
+
|
|
116
|
+
[Numbered list of specific questions, prioritized by:
|
|
117
|
+
|
|
118
|
+
1. **Critical** (blocks implementation or creates security/data risks)
|
|
119
|
+
2. **Important** (significantly affects UX or maintainability)
|
|
120
|
+
3. **Nice-to-have** (improves clarity but has reasonable defaults)]
|
|
121
|
+
|
|
122
|
+
For each question, include:
|
|
123
|
+
|
|
124
|
+
- The question itself
|
|
125
|
+
- Why it matters
|
|
126
|
+
- What assumptions you'd make if it's not answered
|
|
127
|
+
- Examples illustrating the ambiguity
|
|
128
|
+
|
|
129
|
+
### Assumptions (If Unanswered)
|
|
130
|
+
|
|
131
|
+
[List the defaults you would apply if the user does not answer some questions. Keep these explicit and testable.]
|
|
132
|
+
|
|
133
|
+
### Recommended Next Steps
|
|
134
|
+
|
|
135
|
+
[Concrete actions to resolve the gaps and questions]
|
|
136
|
+
|
|
137
|
+
Key principles:
|
|
138
|
+
|
|
139
|
+
- **Be exhaustively thorough** - assume the spec will be implemented exactly as written, so every gap matters
|
|
140
|
+
- **Think like a user** - walk through flows as if you're actually using the feature
|
|
141
|
+
- **Consider the unhappy paths** - errors, failures, and edge cases are where most gaps hide
|
|
142
|
+
- **Be specific in questions** - avoid "what about errors?" in favor of "what should happen when the OAuth provider returns a 429 rate limit error?"
|
|
143
|
+
- **Prioritize ruthlessly** - distinguish between critical blockers and nice-to-have clarifications
|
|
144
|
+
- **Use examples liberally** - concrete scenarios make ambiguities clear
|
|
145
|
+
- **Reference existing patterns** - when available, reference how similar flows work in the codebase
|
|
146
|
+
|
|
147
|
+
Your goal is to ensure that when implementation begins, developers have a crystal-clear understanding of every user journey, every edge case is accounted for, and no critical questions remain unanswered. Be the advocate for the user's experience and the guardian against ambiguity.
|
|
148
|
+
|
|
149
|
+
If invoked from `/workflow:plan`, ensure recommendations align with the selected plan fidelity (Low/Medium/High).
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: assess
|
|
3
|
+
description: Review recent metrics entries to identify failures/trends and propose concrete improvements to commands/skills/agents
|
|
4
|
+
argument-hint: "[daily|weekly|monthly] [optional: count]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# /assess
|
|
8
|
+
|
|
9
|
+
Summarize what failed, what caused friction, and what to change next.
|
|
10
|
+
|
|
11
|
+
This command is the feedback loop that improves the `.agents` system over time.
|
|
12
|
+
|
|
13
|
+
## Inputs
|
|
14
|
+
|
|
15
|
+
- Default: `weekly 7`
|
|
16
|
+
- Examples:
|
|
17
|
+
- `/assess daily 1`
|
|
18
|
+
- `/assess weekly 7`
|
|
19
|
+
- `/assess monthly 30`
|
|
20
|
+
|
|
21
|
+
## Workflow
|
|
22
|
+
|
|
23
|
+
1. Determine window:
|
|
24
|
+
- daily: last N daily entries
|
|
25
|
+
- weekly: last 7 days (or N)
|
|
26
|
+
- monthly: last 30 days (or N)
|
|
27
|
+
2. Read metrics files from:
|
|
28
|
+
- `docs/metrics/daily/`
|
|
29
|
+
3. Produce:
|
|
30
|
+
- Top failure modes (ranked)
|
|
31
|
+
- Repeat blockers (ranked)
|
|
32
|
+
- Leading indicators (e.g., many partials, many pending todos, frequent lint failures)
|
|
33
|
+
- Positive signals (what improved)
|
|
34
|
+
- Trend call: quality up/down and speed up/down (simple narrative)
|
|
35
|
+
4. Propose actions:
|
|
36
|
+
- Each action should target a component:
|
|
37
|
+
- command (`.agents/commands/*.md`)
|
|
38
|
+
- skill (`.agents/skills/**/SKILL.md`)
|
|
39
|
+
- agent (`.agents/agents/**/*.md`)
|
|
40
|
+
- repo config (`AGENTS.md` keys)
|
|
41
|
+
- Provide the smallest change that would move the metric.
|
|
42
|
+
5. Materialize actions:
|
|
43
|
+
- Create `todos/` items (pending by default) for each approved action using `file-todos`.
|
|
44
|
+
6. Optional aggregation:
|
|
45
|
+
- Write a weekly or monthly summary file under:
|
|
46
|
+
- `docs/metrics/weekly/YYYY-WW.md`
|
|
47
|
+
- `docs/metrics/monthly/YYYY-MM.md`
|
|
48
|
+
|
|
49
|
+
## Output Format
|
|
50
|
+
|
|
51
|
+
- Window reviewed
|
|
52
|
+
- Metrics summary (counts)
|
|
53
|
+
- Top issues
|
|
54
|
+
- Proposed actions (with owners and expected metric movement)
|
|
55
|
+
- Todos created (paths)
|
|
56
|
+
|
|
57
|
+
## Guardrails
|
|
58
|
+
|
|
59
|
+
- Do not modify code or `.agents` components automatically.
|
|
60
|
+
- Only create todos and summary docs.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: install
|
|
3
|
+
invocation: install
|
|
4
|
+
description: Install compound-workflow in this project (one action)—opencode.json, AGENTS.md, dirs, and Repo Config Block.
|
|
5
|
+
argument-hint: "[--dry-run] [--root <path>] [--no-config]"
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# /install
|
|
9
|
+
|
|
10
|
+
Install or update compound-workflow in this project with **one action**. Writes opencode.json (OpenCode loads from the package), merges AGENTS.md (template + preserved Repo Config Block), creates standard dirs, and reminds you to set the Repo Config Block if needed.
|
|
11
|
+
|
|
12
|
+
## When to use
|
|
13
|
+
|
|
14
|
+
- First time adding compound-workflow to this repo (OpenCode users).
|
|
15
|
+
- After updating the compound-workflow package and you want the latest AGENTS.md template and opencode.json entries.
|
|
16
|
+
|
|
17
|
+
## Prerequisites
|
|
18
|
+
|
|
19
|
+
- The project must have `compound-workflow` installed: `npm install compound-workflow` (or add to dependencies and run `npm install`).
|
|
20
|
+
|
|
21
|
+
## Instructions for the agent
|
|
22
|
+
|
|
23
|
+
Run in the **workspace root** (or the directory the user specifies):
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
npx compound-workflow@latest install
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
Or with a specific root and flags:
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
npx compound-workflow install --root /path/to/project
|
|
33
|
+
npx compound-workflow install --dry-run
|
|
34
|
+
npx compound-workflow install --no-config
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
- **--dry-run**: Print planned changes only; no writes.
|
|
38
|
+
- **--root <path>**: Target project directory (default: current directory).
|
|
39
|
+
- **--no-config**: Skip Repo Config Block reminder; only write opencode.json, AGENTS.md merge, and dirs.
|
|
40
|
+
|
|
41
|
+
Do not copy files from a compound-workflow clone; the Install CLI uses the package from `node_modules/compound-workflow`.
|
|
42
|
+
|
|
43
|
+
After running, suggest the user run `opencode debug config` in the project to verify OpenCode sees the commands and agents.
|
|
44
|
+
|
|
45
|
+
## What Install does (one run)
|
|
46
|
+
|
|
47
|
+
1. Ensures `compound-workflow` is in the project (exits with instructions if not).
|
|
48
|
+
2. Writes/merges **opencode.json** so OpenCode loads commands, agents, and skills from `node_modules/compound-workflow` (no copy into the project).
|
|
49
|
+
3. Creates/merges **AGENTS.md** (template content; preserves existing Repo Config Block).
|
|
50
|
+
4. Creates **docs/brainstorms/**, **docs/plans/**, **docs/solutions/**, **docs/metrics/daily|weekly|monthly/**, **todos/** if missing.
|
|
51
|
+
5. Reminds the user to edit AGENTS.md for the Repo Config Block (default_branch, test_command, lint_command, dev_server_url, etc.) unless `--no-config` was used.
|
|
52
|
+
|
|
53
|
+
No separate Sync or Setup step; this single command replaces both.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: metrics
|
|
3
|
+
description: Log a metrics entry for the current workflow run so process performance can be reviewed daily/weekly/monthly
|
|
4
|
+
argument-hint: "[optional: context path (plan/todo/PR/solution) or short label]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# /metrics
|
|
8
|
+
|
|
9
|
+
Log a single metrics entry capturing outcome, quality, and friction for a unit of work.
|
|
10
|
+
|
|
11
|
+
This command logs AND assesses the session in one step.
|
|
12
|
+
|
|
13
|
+
It creates or appends to one file under `docs/metrics/daily/`.
|
|
14
|
+
|
|
15
|
+
## Inputs
|
|
16
|
+
|
|
17
|
+
- Optional context: `$ARGUMENTS`
|
|
18
|
+
- plan path (preferred)
|
|
19
|
+
- todo path / issue id
|
|
20
|
+
- PR number / URL
|
|
21
|
+
- solution doc path
|
|
22
|
+
- short label
|
|
23
|
+
|
|
24
|
+
## Workflow
|
|
25
|
+
|
|
26
|
+
1. Determine today's date (YYYY-MM-DD).
|
|
27
|
+
2. Ensure directories exist:
|
|
28
|
+
- `docs/metrics/daily/`
|
|
29
|
+
- `docs/metrics/weekly/`
|
|
30
|
+
- `docs/metrics/monthly/`
|
|
31
|
+
3. Create the daily entry:
|
|
32
|
+
- file: `docs/metrics/daily/YYYY-MM-DD.md`
|
|
33
|
+
- if it exists, append a new "Session" block
|
|
34
|
+
4. Use the template from `process-metrics` skill:
|
|
35
|
+
- `.agents/skills/process-metrics/assets/daily-template.md`
|
|
36
|
+
5. Ask for the minimum missing fields:
|
|
37
|
+
- workflow (`brainstorm|plan|work|triage|review|compound|test-browser|other`)
|
|
38
|
+
- outcome (`success|partial|failed`)
|
|
39
|
+
- time spent (minutes)
|
|
40
|
+
- biggest blocker (one sentence)
|
|
41
|
+
- quality signal (tests/lint ran? pass/fail)
|
|
42
|
+
6. Assess the session (REQUIRED):
|
|
43
|
+
- what failed (if anything)
|
|
44
|
+
- why it failed (root cause)
|
|
45
|
+
- what to change next time (1-3 actions)
|
|
46
|
+
- target each action to: command|skill|agent|config|todo
|
|
47
|
+
7. Materialize improvements (optional):
|
|
48
|
+
- if an action needs follow-up work, create a `pending` todo via `file-todos`
|
|
49
|
+
- otherwise keep it as a simple note in the metrics entry
|
|
50
|
+
|
|
51
|
+
## Guardrails
|
|
52
|
+
|
|
53
|
+
- Keep metrics brief and structured.
|
|
54
|
+
- Do not change code.
|
|
55
|
+
- Do not create commits/PRs.
|
|
56
|
+
|
|
57
|
+
## After /metrics
|
|
58
|
+
|
|
59
|
+
- Use `/assess weekly 7` to see aggregate performance and trends.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: setup
|
|
3
|
+
description: "(Deprecated) Repo Config Block is now part of /install. Use /install once; then edit AGENTS.md to set default_branch, test_command, lint_command, dev_server_url."
|
|
4
|
+
argument-hint: "Use /install instead; then edit AGENTS.md for Repo Config Block."
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# /setup (deprecated)
|
|
8
|
+
|
|
9
|
+
**Use `/install` instead.** The Install command (one action) writes opencode.json, merges AGENTS.md, creates dirs, and preserves your Repo Config Block. After running Install, edit `AGENTS.md` to set `default_branch`, `test_command`, `lint_command`, `dev_server_url`, and other repo defaults in the Repo Config Block YAML section.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sync
|
|
3
|
+
description: "(Deprecated) Use /install instead. Install compound-workflow in the project with one action (npx compound-workflow install)."
|
|
4
|
+
argument-hint: "Use /install instead."
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# /sync (deprecated)
|
|
8
|
+
|
|
9
|
+
**Use `/install` instead.** Run `npx compound-workflow install` in the project—one action that configures opencode.json, AGENTS.md, dirs, and Repo Config Block. No copy from a clone; the package is loaded from `node_modules/compound-workflow`.
|