@zcy2nn/agent-forge 1.1.1 → 1.1.3
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 +247 -247
- package/dist/agents/designer.d.ts +2 -0
- package/dist/agents/explorer.d.ts +2 -0
- package/dist/agents/fixer.d.ts +2 -0
- package/dist/agents/librarian.d.ts +2 -0
- package/dist/agents/observer.d.ts +2 -0
- package/dist/agents/oracle.d.ts +2 -0
- package/dist/cli/index.js +3 -13
- package/dist/cli/migration.d.ts +46 -0
- package/dist/hooks/filter-available-skills/index.d.ts +4 -13
- package/dist/index.js +1 -43
- package/dist/skills/systematic-debugging/condition-based-waiting-example.d.ts +51 -0
- package/package.json +104 -104
- package/src/skills/brainstorming/SKILL.md +186 -186
- package/src/skills/brainstorming/scripts/frame-template.html +214 -214
- package/src/skills/brainstorming/scripts/server.cjs +354 -354
- package/src/skills/systematic-debugging/SKILL.md +318 -318
- package/src/skills/test-driven-development/SKILL.md +392 -392
- package/src/skills/verification-before-completion/SKILL.md +153 -153
- package/src/skills/writing-skills/graphviz-conventions.dot +171 -171
|
@@ -1,153 +1,153 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: verification-before-completion
|
|
3
|
-
description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Verification Before Completion
|
|
7
|
-
|
|
8
|
-
## Overview
|
|
9
|
-
|
|
10
|
-
Claiming work is complete without verification is dishonesty, not efficiency.
|
|
11
|
-
|
|
12
|
-
**Core principle:** Evidence before claims, always.
|
|
13
|
-
|
|
14
|
-
**Violating the letter of this rule is violating the spirit of this rule.**
|
|
15
|
-
|
|
16
|
-
## The Iron Law
|
|
17
|
-
|
|
18
|
-
```
|
|
19
|
-
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
|
|
20
|
-
```
|
|
21
|
-
|
|
22
|
-
If you haven't run the verification command in this message, you cannot claim it passes.
|
|
23
|
-
|
|
24
|
-
**This applies at ALL complexity tiers.** What varies is the depth of verification:
|
|
25
|
-
- **Simple tasks:** Run the relevant verification command (tests, linter, build) and confirm it passes
|
|
26
|
-
- **Medium/Complex tasks:** Run full verification suite, check coverage, verify edge cases, review against requirements
|
|
27
|
-
|
|
28
|
-
## The Gate Function
|
|
29
|
-
|
|
30
|
-
```
|
|
31
|
-
BEFORE claiming any status or expressing satisfaction:
|
|
32
|
-
|
|
33
|
-
1. IDENTIFY: What command proves this claim?
|
|
34
|
-
2. RUN: Execute the FULL command (fresh, complete)
|
|
35
|
-
3. READ: Full output, check exit code, count failures
|
|
36
|
-
4. VERIFY: Does output confirm the claim?
|
|
37
|
-
- If NO: State actual status with evidence
|
|
38
|
-
- If YES: State claim WITH evidence
|
|
39
|
-
5. ONLY THEN: Make the claim
|
|
40
|
-
|
|
41
|
-
Skip any step = lying, not verifying
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
## Common Failures
|
|
45
|
-
|
|
46
|
-
| Claim | Requires | Not Sufficient |
|
|
47
|
-
|-------|----------|----------------|
|
|
48
|
-
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
|
|
49
|
-
| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
|
|
50
|
-
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
|
|
51
|
-
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
|
|
52
|
-
| Regression test works | Red-green cycle verified | Test passes once |
|
|
53
|
-
| Agent completed | VCS diff shows changes | Agent reports "success" |
|
|
54
|
-
| Requirements met | Line-by-line checklist | Tests passing |
|
|
55
|
-
|
|
56
|
-
## Red Flags - STOP
|
|
57
|
-
|
|
58
|
-
- Using "should", "probably", "seems to"
|
|
59
|
-
- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
|
|
60
|
-
- About to commit/push/PR without verification
|
|
61
|
-
- Trusting agent success reports
|
|
62
|
-
- Relying on partial verification
|
|
63
|
-
- Thinking "just this once"
|
|
64
|
-
- Tired and wanting work over
|
|
65
|
-
- **ANY wording implying success without having run verification**
|
|
66
|
-
|
|
67
|
-
## Rationalization Prevention
|
|
68
|
-
|
|
69
|
-
| Excuse | Reality |
|
|
70
|
-
|--------|---------|
|
|
71
|
-
| "Should work now" | RUN the verification |
|
|
72
|
-
| "I'm confident" | Confidence ≠ evidence |
|
|
73
|
-
| "Just this once" | No exceptions |
|
|
74
|
-
| "Linter passed" | Linter ≠ compiler |
|
|
75
|
-
| "Agent said success" | Verify independently |
|
|
76
|
-
| "I'm tired" | Exhaustion ≠ excuse |
|
|
77
|
-
| "Partial check is enough" | Partial proves nothing |
|
|
78
|
-
| "Different words so rule doesn't apply" | Spirit over letter |
|
|
79
|
-
|
|
80
|
-
## Key Patterns
|
|
81
|
-
|
|
82
|
-
**Tests:**
|
|
83
|
-
```
|
|
84
|
-
✅ [Run test command] [See: 34/34 pass] "All tests pass"
|
|
85
|
-
❌ "Should pass now" / "Looks correct"
|
|
86
|
-
```
|
|
87
|
-
|
|
88
|
-
**Regression tests (TDD Red-Green):**
|
|
89
|
-
```
|
|
90
|
-
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
|
|
91
|
-
❌ "I've written a regression test" (without red-green verification)
|
|
92
|
-
```
|
|
93
|
-
|
|
94
|
-
**Build:**
|
|
95
|
-
```
|
|
96
|
-
✅ [Run build] [See: exit 0] "Build passes"
|
|
97
|
-
❌ "Linter passed" (linter doesn't check compilation)
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
**Requirements:**
|
|
101
|
-
```
|
|
102
|
-
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
|
|
103
|
-
❌ "Tests pass, phase complete"
|
|
104
|
-
```
|
|
105
|
-
|
|
106
|
-
**Agent delegation:**
|
|
107
|
-
```
|
|
108
|
-
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
|
|
109
|
-
❌ Trust agent report
|
|
110
|
-
```
|
|
111
|
-
|
|
112
|
-
## Why This Matters
|
|
113
|
-
|
|
114
|
-
From 24 failure memories:
|
|
115
|
-
- your human partner said "I don't believe you" - trust broken
|
|
116
|
-
- Undefined functions shipped - would crash
|
|
117
|
-
- Missing requirements shipped - incomplete features
|
|
118
|
-
- Time wasted on false completion → redirect → rework
|
|
119
|
-
- Violates: "Honesty is a core value. If you lie, you'll be replaced."
|
|
120
|
-
|
|
121
|
-
## When To Apply
|
|
122
|
-
|
|
123
|
-
**ALWAYS before:**
|
|
124
|
-
- ANY variation of success/completion claims
|
|
125
|
-
- ANY expression of satisfaction
|
|
126
|
-
- ANY positive statement about work state
|
|
127
|
-
- Committing, PR creation, task completion
|
|
128
|
-
- Moving to next task
|
|
129
|
-
- Delegating to agents
|
|
130
|
-
|
|
131
|
-
**Rule applies to:**
|
|
132
|
-
- Exact phrases
|
|
133
|
-
- Paraphrases and synonyms
|
|
134
|
-
- Implications of success
|
|
135
|
-
- ANY communication suggesting completion/correctness
|
|
136
|
-
|
|
137
|
-
## Complexity Assessment
|
|
138
|
-
|
|
139
|
-
**Lightweight usage:**
|
|
140
|
-
- Run core tests, confirm pass
|
|
141
|
-
- Applies when session-bootstrap classifies the task as Simple
|
|
142
|
-
|
|
143
|
-
**Standard usage:**
|
|
144
|
-
- Run all tests + check coverage + verify edge cases
|
|
145
|
-
|
|
146
|
-
**Deep usage:**
|
|
147
|
-
- Standard + requirements checklist + line-by-line verification + cross-reference with design spec
|
|
148
|
-
|
|
149
|
-
## The Bottom Line
|
|
150
|
-
|
|
151
|
-
**No shortcuts for verification.** The principle is non-negotiable; the depth adapts to complexity.
|
|
152
|
-
|
|
153
|
-
Run the command. Read the output. THEN claim the result. Whether you run one test or the full suite depends on the task's complexity tier, but you must ALWAYS run something before claiming completion.
|
|
1
|
+
---
|
|
2
|
+
name: verification-before-completion
|
|
3
|
+
description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Verification Before Completion
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Claiming work is complete without verification is dishonesty, not efficiency.
|
|
11
|
+
|
|
12
|
+
**Core principle:** Evidence before claims, always.
|
|
13
|
+
|
|
14
|
+
**Violating the letter of this rule is violating the spirit of this rule.**
|
|
15
|
+
|
|
16
|
+
## The Iron Law
|
|
17
|
+
|
|
18
|
+
```
|
|
19
|
+
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
If you haven't run the verification command in this message, you cannot claim it passes.
|
|
23
|
+
|
|
24
|
+
**This applies at ALL complexity tiers.** What varies is the depth of verification:
|
|
25
|
+
- **Simple tasks:** Run the relevant verification command (tests, linter, build) and confirm it passes
|
|
26
|
+
- **Medium/Complex tasks:** Run full verification suite, check coverage, verify edge cases, review against requirements
|
|
27
|
+
|
|
28
|
+
## The Gate Function
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
BEFORE claiming any status or expressing satisfaction:
|
|
32
|
+
|
|
33
|
+
1. IDENTIFY: What command proves this claim?
|
|
34
|
+
2. RUN: Execute the FULL command (fresh, complete)
|
|
35
|
+
3. READ: Full output, check exit code, count failures
|
|
36
|
+
4. VERIFY: Does output confirm the claim?
|
|
37
|
+
- If NO: State actual status with evidence
|
|
38
|
+
- If YES: State claim WITH evidence
|
|
39
|
+
5. ONLY THEN: Make the claim
|
|
40
|
+
|
|
41
|
+
Skip any step = lying, not verifying
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## Common Failures
|
|
45
|
+
|
|
46
|
+
| Claim | Requires | Not Sufficient |
|
|
47
|
+
|-------|----------|----------------|
|
|
48
|
+
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
|
|
49
|
+
| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
|
|
50
|
+
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
|
|
51
|
+
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
|
|
52
|
+
| Regression test works | Red-green cycle verified | Test passes once |
|
|
53
|
+
| Agent completed | VCS diff shows changes | Agent reports "success" |
|
|
54
|
+
| Requirements met | Line-by-line checklist | Tests passing |
|
|
55
|
+
|
|
56
|
+
## Red Flags - STOP
|
|
57
|
+
|
|
58
|
+
- Using "should", "probably", "seems to"
|
|
59
|
+
- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
|
|
60
|
+
- About to commit/push/PR without verification
|
|
61
|
+
- Trusting agent success reports
|
|
62
|
+
- Relying on partial verification
|
|
63
|
+
- Thinking "just this once"
|
|
64
|
+
- Tired and wanting work over
|
|
65
|
+
- **ANY wording implying success without having run verification**
|
|
66
|
+
|
|
67
|
+
## Rationalization Prevention
|
|
68
|
+
|
|
69
|
+
| Excuse | Reality |
|
|
70
|
+
|--------|---------|
|
|
71
|
+
| "Should work now" | RUN the verification |
|
|
72
|
+
| "I'm confident" | Confidence ≠ evidence |
|
|
73
|
+
| "Just this once" | No exceptions |
|
|
74
|
+
| "Linter passed" | Linter ≠ compiler |
|
|
75
|
+
| "Agent said success" | Verify independently |
|
|
76
|
+
| "I'm tired" | Exhaustion ≠ excuse |
|
|
77
|
+
| "Partial check is enough" | Partial proves nothing |
|
|
78
|
+
| "Different words so rule doesn't apply" | Spirit over letter |
|
|
79
|
+
|
|
80
|
+
## Key Patterns
|
|
81
|
+
|
|
82
|
+
**Tests:**
|
|
83
|
+
```
|
|
84
|
+
✅ [Run test command] [See: 34/34 pass] "All tests pass"
|
|
85
|
+
❌ "Should pass now" / "Looks correct"
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
**Regression tests (TDD Red-Green):**
|
|
89
|
+
```
|
|
90
|
+
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
|
|
91
|
+
❌ "I've written a regression test" (without red-green verification)
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
**Build:**
|
|
95
|
+
```
|
|
96
|
+
✅ [Run build] [See: exit 0] "Build passes"
|
|
97
|
+
❌ "Linter passed" (linter doesn't check compilation)
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
**Requirements:**
|
|
101
|
+
```
|
|
102
|
+
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
|
|
103
|
+
❌ "Tests pass, phase complete"
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
**Agent delegation:**
|
|
107
|
+
```
|
|
108
|
+
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
|
|
109
|
+
❌ Trust agent report
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
## Why This Matters
|
|
113
|
+
|
|
114
|
+
From 24 failure memories:
|
|
115
|
+
- your human partner said "I don't believe you" - trust broken
|
|
116
|
+
- Undefined functions shipped - would crash
|
|
117
|
+
- Missing requirements shipped - incomplete features
|
|
118
|
+
- Time wasted on false completion → redirect → rework
|
|
119
|
+
- Violates: "Honesty is a core value. If you lie, you'll be replaced."
|
|
120
|
+
|
|
121
|
+
## When To Apply
|
|
122
|
+
|
|
123
|
+
**ALWAYS before:**
|
|
124
|
+
- ANY variation of success/completion claims
|
|
125
|
+
- ANY expression of satisfaction
|
|
126
|
+
- ANY positive statement about work state
|
|
127
|
+
- Committing, PR creation, task completion
|
|
128
|
+
- Moving to next task
|
|
129
|
+
- Delegating to agents
|
|
130
|
+
|
|
131
|
+
**Rule applies to:**
|
|
132
|
+
- Exact phrases
|
|
133
|
+
- Paraphrases and synonyms
|
|
134
|
+
- Implications of success
|
|
135
|
+
- ANY communication suggesting completion/correctness
|
|
136
|
+
|
|
137
|
+
## Complexity Assessment
|
|
138
|
+
|
|
139
|
+
**Lightweight usage:**
|
|
140
|
+
- Run core tests, confirm pass
|
|
141
|
+
- Applies when session-bootstrap classifies the task as Simple
|
|
142
|
+
|
|
143
|
+
**Standard usage:**
|
|
144
|
+
- Run all tests + check coverage + verify edge cases
|
|
145
|
+
|
|
146
|
+
**Deep usage:**
|
|
147
|
+
- Standard + requirements checklist + line-by-line verification + cross-reference with design spec
|
|
148
|
+
|
|
149
|
+
## The Bottom Line
|
|
150
|
+
|
|
151
|
+
**No shortcuts for verification.** The principle is non-negotiable; the depth adapts to complexity.
|
|
152
|
+
|
|
153
|
+
Run the command. Read the output. THEN claim the result. Whether you run one test or the full suite depends on the task's complexity tier, but you must ALWAYS run something before claiming completion.
|
|
@@ -1,172 +1,172 @@
|
|
|
1
|
-
digraph STYLE_GUIDE {
|
|
2
|
-
// The style guide for our process DSL, written in the DSL itself
|
|
3
|
-
|
|
4
|
-
// Node type examples with their shapes
|
|
5
|
-
subgraph cluster_node_types {
|
|
6
|
-
label="NODE TYPES AND SHAPES";
|
|
7
|
-
|
|
8
|
-
// Questions are diamonds
|
|
9
|
-
"Is this a question?" [shape=diamond];
|
|
10
|
-
|
|
11
|
-
// Actions are boxes (default)
|
|
12
|
-
"Take an action" [shape=box];
|
|
13
|
-
|
|
14
|
-
// Commands are plaintext
|
|
15
|
-
"git commit -m 'msg'" [shape=plaintext];
|
|
16
|
-
|
|
17
|
-
// States are ellipses
|
|
18
|
-
"Current state" [shape=ellipse];
|
|
19
|
-
|
|
20
|
-
// Warnings are octagons
|
|
21
|
-
"STOP: Critical warning" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
22
|
-
|
|
23
|
-
// Entry/exit are double circles
|
|
24
|
-
"Process starts" [shape=doublecircle];
|
|
25
|
-
"Process complete" [shape=doublecircle];
|
|
26
|
-
|
|
27
|
-
// Examples of each
|
|
28
|
-
"Is test passing?" [shape=diamond];
|
|
29
|
-
"Write test first" [shape=box];
|
|
30
|
-
"npm test" [shape=plaintext];
|
|
31
|
-
"I am stuck" [shape=ellipse];
|
|
32
|
-
"NEVER use git add -A" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
33
|
-
}
|
|
34
|
-
|
|
35
|
-
// Edge naming conventions
|
|
36
|
-
subgraph cluster_edge_types {
|
|
37
|
-
label="EDGE LABELS";
|
|
38
|
-
|
|
39
|
-
"Binary decision?" [shape=diamond];
|
|
40
|
-
"Yes path" [shape=box];
|
|
41
|
-
"No path" [shape=box];
|
|
42
|
-
|
|
43
|
-
"Binary decision?" -> "Yes path" [label="yes"];
|
|
44
|
-
"Binary decision?" -> "No path" [label="no"];
|
|
45
|
-
|
|
46
|
-
"Multiple choice?" [shape=diamond];
|
|
47
|
-
"Option A" [shape=box];
|
|
48
|
-
"Option B" [shape=box];
|
|
49
|
-
"Option C" [shape=box];
|
|
50
|
-
|
|
51
|
-
"Multiple choice?" -> "Option A" [label="condition A"];
|
|
52
|
-
"Multiple choice?" -> "Option B" [label="condition B"];
|
|
53
|
-
"Multiple choice?" -> "Option C" [label="otherwise"];
|
|
54
|
-
|
|
55
|
-
"Process A done" [shape=doublecircle];
|
|
56
|
-
"Process B starts" [shape=doublecircle];
|
|
57
|
-
|
|
58
|
-
"Process A done" -> "Process B starts" [label="triggers", style=dotted];
|
|
59
|
-
}
|
|
60
|
-
|
|
61
|
-
// Naming patterns
|
|
62
|
-
subgraph cluster_naming_patterns {
|
|
63
|
-
label="NAMING PATTERNS";
|
|
64
|
-
|
|
65
|
-
// Questions end with ?
|
|
66
|
-
"Should I do X?";
|
|
67
|
-
"Can this be Y?";
|
|
68
|
-
"Is Z true?";
|
|
69
|
-
"Have I done W?";
|
|
70
|
-
|
|
71
|
-
// Actions start with verb
|
|
72
|
-
"Write the test";
|
|
73
|
-
"Search for patterns";
|
|
74
|
-
"Commit changes";
|
|
75
|
-
"Ask for help";
|
|
76
|
-
|
|
77
|
-
// Commands are literal
|
|
78
|
-
"grep -r 'pattern' .";
|
|
79
|
-
"git status";
|
|
80
|
-
"npm run build";
|
|
81
|
-
|
|
82
|
-
// States describe situation
|
|
83
|
-
"Test is failing";
|
|
84
|
-
"Build complete";
|
|
85
|
-
"Stuck on error";
|
|
86
|
-
}
|
|
87
|
-
|
|
88
|
-
// Process structure template
|
|
89
|
-
subgraph cluster_structure {
|
|
90
|
-
label="PROCESS STRUCTURE TEMPLATE";
|
|
91
|
-
|
|
92
|
-
"Trigger: Something happens" [shape=ellipse];
|
|
93
|
-
"Initial check?" [shape=diamond];
|
|
94
|
-
"Main action" [shape=box];
|
|
95
|
-
"git status" [shape=plaintext];
|
|
96
|
-
"Another check?" [shape=diamond];
|
|
97
|
-
"Alternative action" [shape=box];
|
|
98
|
-
"STOP: Don't do this" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
99
|
-
"Process complete" [shape=doublecircle];
|
|
100
|
-
|
|
101
|
-
"Trigger: Something happens" -> "Initial check?";
|
|
102
|
-
"Initial check?" -> "Main action" [label="yes"];
|
|
103
|
-
"Initial check?" -> "Alternative action" [label="no"];
|
|
104
|
-
"Main action" -> "git status";
|
|
105
|
-
"git status" -> "Another check?";
|
|
106
|
-
"Another check?" -> "Process complete" [label="ok"];
|
|
107
|
-
"Another check?" -> "STOP: Don't do this" [label="problem"];
|
|
108
|
-
"Alternative action" -> "Process complete";
|
|
109
|
-
}
|
|
110
|
-
|
|
111
|
-
// When to use which shape
|
|
112
|
-
subgraph cluster_shape_rules {
|
|
113
|
-
label="WHEN TO USE EACH SHAPE";
|
|
114
|
-
|
|
115
|
-
"Choosing a shape" [shape=ellipse];
|
|
116
|
-
|
|
117
|
-
"Is it a decision?" [shape=diamond];
|
|
118
|
-
"Use diamond" [shape=diamond, style=filled, fillcolor=lightblue];
|
|
119
|
-
|
|
120
|
-
"Is it a command?" [shape=diamond];
|
|
121
|
-
"Use plaintext" [shape=plaintext, style=filled, fillcolor=lightgray];
|
|
122
|
-
|
|
123
|
-
"Is it a warning?" [shape=diamond];
|
|
124
|
-
"Use octagon" [shape=octagon, style=filled, fillcolor=pink];
|
|
125
|
-
|
|
126
|
-
"Is it entry/exit?" [shape=diamond];
|
|
127
|
-
"Use doublecircle" [shape=doublecircle, style=filled, fillcolor=lightgreen];
|
|
128
|
-
|
|
129
|
-
"Is it a state?" [shape=diamond];
|
|
130
|
-
"Use ellipse" [shape=ellipse, style=filled, fillcolor=lightyellow];
|
|
131
|
-
|
|
132
|
-
"Default: use box" [shape=box, style=filled, fillcolor=lightcyan];
|
|
133
|
-
|
|
134
|
-
"Choosing a shape" -> "Is it a decision?";
|
|
135
|
-
"Is it a decision?" -> "Use diamond" [label="yes"];
|
|
136
|
-
"Is it a decision?" -> "Is it a command?" [label="no"];
|
|
137
|
-
"Is it a command?" -> "Use plaintext" [label="yes"];
|
|
138
|
-
"Is it a command?" -> "Is it a warning?" [label="no"];
|
|
139
|
-
"Is it a warning?" -> "Use octagon" [label="yes"];
|
|
140
|
-
"Is it a warning?" -> "Is it entry/exit?" [label="no"];
|
|
141
|
-
"Is it entry/exit?" -> "Use doublecircle" [label="yes"];
|
|
142
|
-
"Is it entry/exit?" -> "Is it a state?" [label="no"];
|
|
143
|
-
"Is it a state?" -> "Use ellipse" [label="yes"];
|
|
144
|
-
"Is it a state?" -> "Default: use box" [label="no"];
|
|
145
|
-
}
|
|
146
|
-
|
|
147
|
-
// Good vs bad examples
|
|
148
|
-
subgraph cluster_examples {
|
|
149
|
-
label="GOOD VS BAD EXAMPLES";
|
|
150
|
-
|
|
151
|
-
// Good: specific and shaped correctly
|
|
152
|
-
"Test failed" [shape=ellipse];
|
|
153
|
-
"Read error message" [shape=box];
|
|
154
|
-
"Can reproduce?" [shape=diamond];
|
|
155
|
-
"git diff HEAD~1" [shape=plaintext];
|
|
156
|
-
"NEVER ignore errors" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
157
|
-
|
|
158
|
-
"Test failed" -> "Read error message";
|
|
159
|
-
"Read error message" -> "Can reproduce?";
|
|
160
|
-
"Can reproduce?" -> "git diff HEAD~1" [label="yes"];
|
|
161
|
-
|
|
162
|
-
// Bad: vague and wrong shapes
|
|
163
|
-
bad_1 [label="Something wrong", shape=box]; // Should be ellipse (state)
|
|
164
|
-
bad_2 [label="Fix it", shape=box]; // Too vague
|
|
165
|
-
bad_3 [label="Check", shape=box]; // Should be diamond
|
|
166
|
-
bad_4 [label="Run command", shape=box]; // Should be plaintext with actual command
|
|
167
|
-
|
|
168
|
-
bad_1 -> bad_2;
|
|
169
|
-
bad_2 -> bad_3;
|
|
170
|
-
bad_3 -> bad_4;
|
|
171
|
-
}
|
|
1
|
+
digraph STYLE_GUIDE {
|
|
2
|
+
// The style guide for our process DSL, written in the DSL itself
|
|
3
|
+
|
|
4
|
+
// Node type examples with their shapes
|
|
5
|
+
subgraph cluster_node_types {
|
|
6
|
+
label="NODE TYPES AND SHAPES";
|
|
7
|
+
|
|
8
|
+
// Questions are diamonds
|
|
9
|
+
"Is this a question?" [shape=diamond];
|
|
10
|
+
|
|
11
|
+
// Actions are boxes (default)
|
|
12
|
+
"Take an action" [shape=box];
|
|
13
|
+
|
|
14
|
+
// Commands are plaintext
|
|
15
|
+
"git commit -m 'msg'" [shape=plaintext];
|
|
16
|
+
|
|
17
|
+
// States are ellipses
|
|
18
|
+
"Current state" [shape=ellipse];
|
|
19
|
+
|
|
20
|
+
// Warnings are octagons
|
|
21
|
+
"STOP: Critical warning" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
22
|
+
|
|
23
|
+
// Entry/exit are double circles
|
|
24
|
+
"Process starts" [shape=doublecircle];
|
|
25
|
+
"Process complete" [shape=doublecircle];
|
|
26
|
+
|
|
27
|
+
// Examples of each
|
|
28
|
+
"Is test passing?" [shape=diamond];
|
|
29
|
+
"Write test first" [shape=box];
|
|
30
|
+
"npm test" [shape=plaintext];
|
|
31
|
+
"I am stuck" [shape=ellipse];
|
|
32
|
+
"NEVER use git add -A" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
33
|
+
}
|
|
34
|
+
|
|
35
|
+
// Edge naming conventions
|
|
36
|
+
subgraph cluster_edge_types {
|
|
37
|
+
label="EDGE LABELS";
|
|
38
|
+
|
|
39
|
+
"Binary decision?" [shape=diamond];
|
|
40
|
+
"Yes path" [shape=box];
|
|
41
|
+
"No path" [shape=box];
|
|
42
|
+
|
|
43
|
+
"Binary decision?" -> "Yes path" [label="yes"];
|
|
44
|
+
"Binary decision?" -> "No path" [label="no"];
|
|
45
|
+
|
|
46
|
+
"Multiple choice?" [shape=diamond];
|
|
47
|
+
"Option A" [shape=box];
|
|
48
|
+
"Option B" [shape=box];
|
|
49
|
+
"Option C" [shape=box];
|
|
50
|
+
|
|
51
|
+
"Multiple choice?" -> "Option A" [label="condition A"];
|
|
52
|
+
"Multiple choice?" -> "Option B" [label="condition B"];
|
|
53
|
+
"Multiple choice?" -> "Option C" [label="otherwise"];
|
|
54
|
+
|
|
55
|
+
"Process A done" [shape=doublecircle];
|
|
56
|
+
"Process B starts" [shape=doublecircle];
|
|
57
|
+
|
|
58
|
+
"Process A done" -> "Process B starts" [label="triggers", style=dotted];
|
|
59
|
+
}
|
|
60
|
+
|
|
61
|
+
// Naming patterns
|
|
62
|
+
subgraph cluster_naming_patterns {
|
|
63
|
+
label="NAMING PATTERNS";
|
|
64
|
+
|
|
65
|
+
// Questions end with ?
|
|
66
|
+
"Should I do X?";
|
|
67
|
+
"Can this be Y?";
|
|
68
|
+
"Is Z true?";
|
|
69
|
+
"Have I done W?";
|
|
70
|
+
|
|
71
|
+
// Actions start with verb
|
|
72
|
+
"Write the test";
|
|
73
|
+
"Search for patterns";
|
|
74
|
+
"Commit changes";
|
|
75
|
+
"Ask for help";
|
|
76
|
+
|
|
77
|
+
// Commands are literal
|
|
78
|
+
"grep -r 'pattern' .";
|
|
79
|
+
"git status";
|
|
80
|
+
"npm run build";
|
|
81
|
+
|
|
82
|
+
// States describe situation
|
|
83
|
+
"Test is failing";
|
|
84
|
+
"Build complete";
|
|
85
|
+
"Stuck on error";
|
|
86
|
+
}
|
|
87
|
+
|
|
88
|
+
// Process structure template
|
|
89
|
+
subgraph cluster_structure {
|
|
90
|
+
label="PROCESS STRUCTURE TEMPLATE";
|
|
91
|
+
|
|
92
|
+
"Trigger: Something happens" [shape=ellipse];
|
|
93
|
+
"Initial check?" [shape=diamond];
|
|
94
|
+
"Main action" [shape=box];
|
|
95
|
+
"git status" [shape=plaintext];
|
|
96
|
+
"Another check?" [shape=diamond];
|
|
97
|
+
"Alternative action" [shape=box];
|
|
98
|
+
"STOP: Don't do this" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
99
|
+
"Process complete" [shape=doublecircle];
|
|
100
|
+
|
|
101
|
+
"Trigger: Something happens" -> "Initial check?";
|
|
102
|
+
"Initial check?" -> "Main action" [label="yes"];
|
|
103
|
+
"Initial check?" -> "Alternative action" [label="no"];
|
|
104
|
+
"Main action" -> "git status";
|
|
105
|
+
"git status" -> "Another check?";
|
|
106
|
+
"Another check?" -> "Process complete" [label="ok"];
|
|
107
|
+
"Another check?" -> "STOP: Don't do this" [label="problem"];
|
|
108
|
+
"Alternative action" -> "Process complete";
|
|
109
|
+
}
|
|
110
|
+
|
|
111
|
+
// When to use which shape
|
|
112
|
+
subgraph cluster_shape_rules {
|
|
113
|
+
label="WHEN TO USE EACH SHAPE";
|
|
114
|
+
|
|
115
|
+
"Choosing a shape" [shape=ellipse];
|
|
116
|
+
|
|
117
|
+
"Is it a decision?" [shape=diamond];
|
|
118
|
+
"Use diamond" [shape=diamond, style=filled, fillcolor=lightblue];
|
|
119
|
+
|
|
120
|
+
"Is it a command?" [shape=diamond];
|
|
121
|
+
"Use plaintext" [shape=plaintext, style=filled, fillcolor=lightgray];
|
|
122
|
+
|
|
123
|
+
"Is it a warning?" [shape=diamond];
|
|
124
|
+
"Use octagon" [shape=octagon, style=filled, fillcolor=pink];
|
|
125
|
+
|
|
126
|
+
"Is it entry/exit?" [shape=diamond];
|
|
127
|
+
"Use doublecircle" [shape=doublecircle, style=filled, fillcolor=lightgreen];
|
|
128
|
+
|
|
129
|
+
"Is it a state?" [shape=diamond];
|
|
130
|
+
"Use ellipse" [shape=ellipse, style=filled, fillcolor=lightyellow];
|
|
131
|
+
|
|
132
|
+
"Default: use box" [shape=box, style=filled, fillcolor=lightcyan];
|
|
133
|
+
|
|
134
|
+
"Choosing a shape" -> "Is it a decision?";
|
|
135
|
+
"Is it a decision?" -> "Use diamond" [label="yes"];
|
|
136
|
+
"Is it a decision?" -> "Is it a command?" [label="no"];
|
|
137
|
+
"Is it a command?" -> "Use plaintext" [label="yes"];
|
|
138
|
+
"Is it a command?" -> "Is it a warning?" [label="no"];
|
|
139
|
+
"Is it a warning?" -> "Use octagon" [label="yes"];
|
|
140
|
+
"Is it a warning?" -> "Is it entry/exit?" [label="no"];
|
|
141
|
+
"Is it entry/exit?" -> "Use doublecircle" [label="yes"];
|
|
142
|
+
"Is it entry/exit?" -> "Is it a state?" [label="no"];
|
|
143
|
+
"Is it a state?" -> "Use ellipse" [label="yes"];
|
|
144
|
+
"Is it a state?" -> "Default: use box" [label="no"];
|
|
145
|
+
}
|
|
146
|
+
|
|
147
|
+
// Good vs bad examples
|
|
148
|
+
subgraph cluster_examples {
|
|
149
|
+
label="GOOD VS BAD EXAMPLES";
|
|
150
|
+
|
|
151
|
+
// Good: specific and shaped correctly
|
|
152
|
+
"Test failed" [shape=ellipse];
|
|
153
|
+
"Read error message" [shape=box];
|
|
154
|
+
"Can reproduce?" [shape=diamond];
|
|
155
|
+
"git diff HEAD~1" [shape=plaintext];
|
|
156
|
+
"NEVER ignore errors" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
157
|
+
|
|
158
|
+
"Test failed" -> "Read error message";
|
|
159
|
+
"Read error message" -> "Can reproduce?";
|
|
160
|
+
"Can reproduce?" -> "git diff HEAD~1" [label="yes"];
|
|
161
|
+
|
|
162
|
+
// Bad: vague and wrong shapes
|
|
163
|
+
bad_1 [label="Something wrong", shape=box]; // Should be ellipse (state)
|
|
164
|
+
bad_2 [label="Fix it", shape=box]; // Too vague
|
|
165
|
+
bad_3 [label="Check", shape=box]; // Should be diamond
|
|
166
|
+
bad_4 [label="Run command", shape=box]; // Should be plaintext with actual command
|
|
167
|
+
|
|
168
|
+
bad_1 -> bad_2;
|
|
169
|
+
bad_2 -> bad_3;
|
|
170
|
+
bad_3 -> bad_4;
|
|
171
|
+
}
|
|
172
172
|
}
|