harness-everything 0.2.1 → 0.2.2
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 +1 -1
- package/build-multi-agent-system/SKILL.md +68 -68
- package/create-agent-launcher/SKILL.md +48 -48
- package/docs/architecture.md +2 -2
- package/docs/workflows/build-multi-agent-system.md +62 -62
- package/docs/workflows/create-agent-launcher.md +62 -62
- package/docs/workflows/environment-detection.md +63 -63
- package/docs/workflows/eval-harness.md +57 -57
- package/docs/workflows/fable-discipline.md +59 -59
- package/docs/workflows/fable-mode.md +32 -32
- package/docs/workflows/git-commit.md +62 -62
- package/docs/workflows/grill-me.md +62 -62
- package/docs/workflows/grill-with-docs.md +62 -62
- package/docs/workflows/improve-codebase-architecture.md +60 -60
- package/docs/workflows/repo-docs.md +59 -59
- package/docs/workflows/rewrite-commits.md +60 -60
- package/docs/workflows/security-review.md +58 -58
- package/docs/workflows/self-evolve.md +59 -59
- package/docs/workflows/tdd.md +39 -39
- package/docs/workflows/todo-driven-workflow.md +36 -36
- package/docs/workflows/using-git-worktrees.md +63 -63
- package/docs/workflows/verification-loop.md +69 -69
- package/docs/workflows/verify-before-claim.md +60 -60
- package/docs/workflows/zoom-out.md +62 -62
- package/environment-detection/SKILL.md +77 -77
- package/eval-framework/behavioral-test.js +105 -105
- package/eval-framework/mechanism-test.js +251 -251
- package/eval-harness/SKILL.md +59 -59
- package/fable-discipline/SKILL.md +38 -38
- package/fable-mode/SKILL.md +51 -51
- package/git-commit/SKILL.md +55 -55
- package/grill-me/SKILL.md +36 -36
- package/grill-with-docs/SKILL.md +99 -99
- package/harness-everything/SKILL.md +141 -141
- package/harness-everything/examples/README.md +9 -9
- package/harness-everything/examples/todo-workflow.md +22 -22
- package/harness-everything/scripts/todo-cli.js +157 -157
- package/harness-everything/scripts/verify-gate.js +31 -31
- package/hooks/scripts/atomic-commit-check.js +68 -68
- package/hooks/scripts/context-compact.js +114 -114
- package/hooks/scripts/lib/platforms/claude.js +132 -42
- package/hooks/scripts/lib/platforms/codex.js +96 -46
- package/hooks/scripts/lib/platforms/continue.js +73 -41
- package/hooks/scripts/lib/platforms/copilot.js +91 -41
- package/hooks/scripts/lib/platforms/cursor.js +71 -41
- package/hooks/scripts/lib/platforms/hermes.js +25 -0
- package/hooks/scripts/rule-of-3.js +176 -176
- package/improve-codebase-architecture/SKILL.md +44 -44
- package/install-cognitive-os/SKILL.md +95 -95
- package/package.json +1 -1
- package/repo-docs/SKILL.md +45 -45
- package/rewrite-commits/SKILL.md +32 -32
- package/scripts/installer.js +57 -200
- package/scripts/lib/advisory-text.js +163 -163
- package/scripts/lib/claude-hooks.js +71 -71
- package/scripts/lib/manifest.js +82 -82
- package/scripts/lib/prompts.js +241 -241
- package/scripts/lib/skills.js +174 -172
- package/scripts/lib/workspace.js +28 -28
- package/security-review/SKILL.md +510 -510
- package/self-evolve/SKILL.md +54 -54
- package/skill-creator/SKILL.md +91 -91
- package/skill-creator/references/testing-workflow.md +32 -32
- package/skill-style/SKILL.md +48 -48
- package/tdd/SKILL.md +53 -53
- package/todo-driven-workflow/SKILL.md +54 -54
- package/using-git-worktrees/SKILL.md +161 -161
- package/verification-loop/SKILL.md +138 -138
- package/verify-before-claim/SKILL.md +86 -86
- package/zoom-out/SKILL.md +90 -90
|
@@ -1,58 +1,58 @@
|
|
|
1
|
-
# Workflow: Security Review
|
|
2
|
-
|
|
3
|
-
> Automated security scanning, threat modeling, and input-validation reviews to identify potential security holes and enforce robust safety guardrails.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Skill Behavior Workflow
|
|
8
|
-
|
|
9
|
-
This section visualizes how the `security-review` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
-
|
|
11
|
-
```mermaid
|
|
12
|
-
graph TD
|
|
13
|
-
Start([Code Refactoring / Feature Done]) --> ScanInputs["Locate all user input and API boundary points"]
|
|
14
|
-
ScanInputs --> ThreatModeling["Perform threat modeling on data flow"]
|
|
15
|
-
ThreatModeling --> CheckCommonVulnerabilities["Check for SQL Injection, XSS, CSRF, and broken access controls"]
|
|
16
|
-
CheckCommonVulnerabilities --> AuditDependencies["Scan package dependencies for known CVE vulnerabilities"]
|
|
17
|
-
AuditDependencies --> FlagSinks["Flag insecure coding patterns, hardcoded secrets, or raw exec commands"]
|
|
18
|
-
FlagSinks --> CompileSecurityReport["Compile actionable security hardening proposal"]
|
|
19
|
-
CompileSecurityReport --> End([Codebase hardened and verified secure])
|
|
20
|
-
```
|
|
21
|
-
|
|
22
|
-
---
|
|
23
|
-
|
|
24
|
-
## 2. Triggering and Routing Path
|
|
25
|
-
|
|
26
|
-
This diagram illustrates how the `security-review` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
|
|
27
|
-
|
|
28
|
-
```mermaid
|
|
29
|
-
graph LR
|
|
30
|
-
Router["harness-everything / tier-router.js"] -->|Pre-flight / Quality PR reviews| SecReview["security-review / SKILL.md"]
|
|
31
|
-
SecReview -->|Informs security tests written in| TDD["tdd / SKILL.md"]
|
|
32
|
-
SecReview -->|Integrated as mandatory PR gate in| VerLoop["verification-loop / SKILL.md"]
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
---
|
|
36
|
-
|
|
37
|
-
## 3. Real-World Use Case Flowchart
|
|
38
|
-
|
|
39
|
-
Here we model concrete real-world scenarios and use cases of the `security-review` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
40
|
-
|
|
41
|
-
```mermaid
|
|
42
|
-
graph TD
|
|
43
|
-
Start["New search feature: executes system shell query using raw user input string"] --> Trigger["security-review skill runs"]
|
|
44
|
-
Trigger --> Scan["Flags potential command injection vulnerability in search.js"]
|
|
45
|
-
Scan --> Propose["Propose input sanitization and switching to child_process.execFile with argument array"]
|
|
46
|
-
Propose --> Implement["Refactor code to use safe argument arrays instead of raw string shell execution"]
|
|
47
|
-
Implement --> Done([Critical remote code execution vulnerability resolved])
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
---
|
|
51
|
-
|
|
52
|
-
## 4. Verification Check
|
|
53
|
-
|
|
54
|
-
To ensure that the `security-review` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
55
|
-
|
|
56
|
-
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
57
|
-
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
58
|
-
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
1
|
+
# Workflow: Security Review
|
|
2
|
+
|
|
3
|
+
> Automated security scanning, threat modeling, and input-validation reviews to identify potential security holes and enforce robust safety guardrails.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `security-review` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Code Refactoring / Feature Done]) --> ScanInputs["Locate all user input and API boundary points"]
|
|
14
|
+
ScanInputs --> ThreatModeling["Perform threat modeling on data flow"]
|
|
15
|
+
ThreatModeling --> CheckCommonVulnerabilities["Check for SQL Injection, XSS, CSRF, and broken access controls"]
|
|
16
|
+
CheckCommonVulnerabilities --> AuditDependencies["Scan package dependencies for known CVE vulnerabilities"]
|
|
17
|
+
AuditDependencies --> FlagSinks["Flag insecure coding patterns, hardcoded secrets, or raw exec commands"]
|
|
18
|
+
FlagSinks --> CompileSecurityReport["Compile actionable security hardening proposal"]
|
|
19
|
+
CompileSecurityReport --> End([Codebase hardened and verified secure])
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## 2. Triggering and Routing Path
|
|
25
|
+
|
|
26
|
+
This diagram illustrates how the `security-review` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
|
|
27
|
+
|
|
28
|
+
```mermaid
|
|
29
|
+
graph LR
|
|
30
|
+
Router["harness-everything / tier-router.js"] -->|Pre-flight / Quality PR reviews| SecReview["security-review / SKILL.md"]
|
|
31
|
+
SecReview -->|Informs security tests written in| TDD["tdd / SKILL.md"]
|
|
32
|
+
SecReview -->|Integrated as mandatory PR gate in| VerLoop["verification-loop / SKILL.md"]
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## 3. Real-World Use Case Flowchart
|
|
38
|
+
|
|
39
|
+
Here we model concrete real-world scenarios and use cases of the `security-review` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
40
|
+
|
|
41
|
+
```mermaid
|
|
42
|
+
graph TD
|
|
43
|
+
Start["New search feature: executes system shell query using raw user input string"] --> Trigger["security-review skill runs"]
|
|
44
|
+
Trigger --> Scan["Flags potential command injection vulnerability in search.js"]
|
|
45
|
+
Scan --> Propose["Propose input sanitization and switching to child_process.execFile with argument array"]
|
|
46
|
+
Propose --> Implement["Refactor code to use safe argument arrays instead of raw string shell execution"]
|
|
47
|
+
Implement --> Done([Critical remote code execution vulnerability resolved])
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
---
|
|
51
|
+
|
|
52
|
+
## 4. Verification Check
|
|
53
|
+
|
|
54
|
+
To ensure that the `security-review` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
55
|
+
|
|
56
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
57
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
58
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
@@ -1,59 +1,59 @@
|
|
|
1
|
-
# Workflow: Self-Evolve
|
|
2
|
-
|
|
3
|
-
> Analyzes execution logs and session memories to extract underlying root causes, defining new error boundaries and compressing them into cognitive guardrails.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Skill Behavior Workflow
|
|
8
|
-
|
|
9
|
-
This section visualizes how the `self-evolve` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
-
|
|
11
|
-
```mermaid
|
|
12
|
-
graph TD
|
|
13
|
-
Start([Task Completed / Error Loop Triggered]) --> ReadSessionLogs["Read active debugging logs & session history"]
|
|
14
|
-
ReadSessionLogs --> IdentifyRootCauses["Isolate and extract system failures or bottlenecks"]
|
|
15
|
-
IdentifyRootCauses --> SynthesizeGuardrails["Formulate actionable high-level cognitive guardrails"]
|
|
16
|
-
SynthesizeGuardrails --> CompressMemories["Compress repetitive events into compact markdown files in /memories/"]
|
|
17
|
-
CompressMemories --> UpdateUserMemory["Commit lessons learned to user memory space"]
|
|
18
|
-
UpdateUserMemory --> End([Agent cognitive defense expanded for future sessions])
|
|
19
|
-
```
|
|
20
|
-
|
|
21
|
-
---
|
|
22
|
-
|
|
23
|
-
## 2. Triggering and Routing Path
|
|
24
|
-
|
|
25
|
-
This diagram illustrates how the `self-evolve` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
|
|
26
|
-
|
|
27
|
-
```mermaid
|
|
28
|
-
graph LR
|
|
29
|
-
SessionEnd["Task Completed / Session Closed"] --> Evolve["self-evolve / SKILL.md"]
|
|
30
|
-
Evolve -->|Reads from| HistoryLog["VS Code Debug logs & memory directories"]
|
|
31
|
-
Evolve -->|Writes permanent updates to| UserMemory["/memories/ / user-memory files"]
|
|
32
|
-
Evolve -->|Informs future task triage in| Router["harness-everything / tier-router.js"]
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
---
|
|
36
|
-
|
|
37
|
-
## 3. Real-World Use Case Flowchart
|
|
38
|
-
|
|
39
|
-
Here we model concrete real-world scenarios and use cases of the `self-evolve` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
40
|
-
|
|
41
|
-
```mermaid
|
|
42
|
-
graph TD
|
|
43
|
-
Start["Session ends after solving a recurring, messy Windows path-slashes bug"] --> Trigger["self-evolve skill runs automatically"]
|
|
44
|
-
Trigger --> Analyze["Reads last 5 execution logs"]
|
|
45
|
-
Analyze --> DetectPattern["Finds 3 consecutive terminal command failures caused by path backslashes in PowerShell"]
|
|
46
|
-
DetectPattern --> Formulate["Formulate new guardrail: 'When on Windows, convert backslashes to forward slashes for cross-shell command lines'"]
|
|
47
|
-
Formulate --> Write["Write bullet point to /memories/debugging.md"]
|
|
48
|
-
Write --> Done([Memory recorded: future sessions will automatically avoid Windows path errors])
|
|
49
|
-
```
|
|
50
|
-
|
|
51
|
-
---
|
|
52
|
-
|
|
53
|
-
## 4. Verification Check
|
|
54
|
-
|
|
55
|
-
To ensure that the `self-evolve` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
56
|
-
|
|
57
|
-
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
58
|
-
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
59
|
-
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
1
|
+
# Workflow: Self-Evolve
|
|
2
|
+
|
|
3
|
+
> Analyzes execution logs and session memories to extract underlying root causes, defining new error boundaries and compressing them into cognitive guardrails.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `self-evolve` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Task Completed / Error Loop Triggered]) --> ReadSessionLogs["Read active debugging logs & session history"]
|
|
14
|
+
ReadSessionLogs --> IdentifyRootCauses["Isolate and extract system failures or bottlenecks"]
|
|
15
|
+
IdentifyRootCauses --> SynthesizeGuardrails["Formulate actionable high-level cognitive guardrails"]
|
|
16
|
+
SynthesizeGuardrails --> CompressMemories["Compress repetitive events into compact markdown files in /memories/"]
|
|
17
|
+
CompressMemories --> UpdateUserMemory["Commit lessons learned to user memory space"]
|
|
18
|
+
UpdateUserMemory --> End([Agent cognitive defense expanded for future sessions])
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## 2. Triggering and Routing Path
|
|
24
|
+
|
|
25
|
+
This diagram illustrates how the `self-evolve` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
|
|
26
|
+
|
|
27
|
+
```mermaid
|
|
28
|
+
graph LR
|
|
29
|
+
SessionEnd["Task Completed / Session Closed"] --> Evolve["self-evolve / SKILL.md"]
|
|
30
|
+
Evolve -->|Reads from| HistoryLog["VS Code Debug logs & memory directories"]
|
|
31
|
+
Evolve -->|Writes permanent updates to| UserMemory["/memories/ / user-memory files"]
|
|
32
|
+
Evolve -->|Informs future task triage in| Router["harness-everything / tier-router.js"]
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## 3. Real-World Use Case Flowchart
|
|
38
|
+
|
|
39
|
+
Here we model concrete real-world scenarios and use cases of the `self-evolve` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
40
|
+
|
|
41
|
+
```mermaid
|
|
42
|
+
graph TD
|
|
43
|
+
Start["Session ends after solving a recurring, messy Windows path-slashes bug"] --> Trigger["self-evolve skill runs automatically"]
|
|
44
|
+
Trigger --> Analyze["Reads last 5 execution logs"]
|
|
45
|
+
Analyze --> DetectPattern["Finds 3 consecutive terminal command failures caused by path backslashes in PowerShell"]
|
|
46
|
+
DetectPattern --> Formulate["Formulate new guardrail: 'When on Windows, convert backslashes to forward slashes for cross-shell command lines'"]
|
|
47
|
+
Formulate --> Write["Write bullet point to /memories/debugging.md"]
|
|
48
|
+
Write --> Done([Memory recorded: future sessions will automatically avoid Windows path errors])
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## 4. Verification Check
|
|
54
|
+
|
|
55
|
+
To ensure that the `self-evolve` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
56
|
+
|
|
57
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
58
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
59
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
package/docs/workflows/tdd.md
CHANGED
|
@@ -1,39 +1,39 @@
|
|
|
1
|
-
# Workflow: Test-Driven Development (TDD)
|
|
2
|
-
|
|
3
|
-
> Enforces the classic Red-Green-Refactor development cycle. Crucially, this is NOT a linear process. It is a loop driven by terminal exit codes.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Skill Behavior Workflow
|
|
8
|
-
|
|
9
|
-
This section visualizes the script-gated reality of TDD. The AI cannot progress to the next phase until the terminal script explicitly confirms the state.
|
|
10
|
-
|
|
11
|
-
```mermaid
|
|
12
|
-
graph TD
|
|
13
|
-
Start([Identify Feature / Bug]) --> DesignInterface["Design interface & contract"]
|
|
14
|
-
DesignInterface --> WriteTest["Write unit/integration tests first"]
|
|
15
|
-
|
|
16
|
-
WriteTest --> RunRed["Try: Run tests (EXPECT FAILURE)"]
|
|
17
|
-
RunRed --> VerifyRed{Gate: Exit Code 1?}
|
|
18
|
-
VerifyRed -->|Exit 0: Fake Test| FixTest["Reflect: Test is broken/fake. Fix it."]
|
|
19
|
-
FixTest --> RunRed
|
|
20
|
-
|
|
21
|
-
VerifyRed -->|Exit 1: True Red| WriteCode["Write minimal code to pass test"]
|
|
22
|
-
|
|
23
|
-
WriteCode --> RunGreen["Try: Run tests (EXPECT SUCCESS)"]
|
|
24
|
-
RunGreen --> VerifyGreen{Gate: verify-gate.js}
|
|
25
|
-
|
|
26
|
-
VerifyGreen -->|Exit 1: Still Broken| DebugCode["Reflect: Read logs, fix code"]
|
|
27
|
-
DebugCode --> RunGreen
|
|
28
|
-
VerifyGreen -->|Exit 1: 3x Failures| CircuitBreaker["Trigger rule-of-3.js: ZOOM OUT"]
|
|
29
|
-
CircuitBreaker --> DebugCode
|
|
30
|
-
|
|
31
|
-
VerifyGreen -->|Exit 0: Green| Refactor["Refactor code for readability"]
|
|
32
|
-
|
|
33
|
-
Refactor --> RunVerify["Try: Run tests again"]
|
|
34
|
-
RunVerify --> VerifyRefactor{Gate: verify-gate.js}
|
|
35
|
-
VerifyRefactor -->|Exit 1| Revert["Revert refactor / Fix"]
|
|
36
|
-
Revert --> RunVerify
|
|
37
|
-
|
|
38
|
-
VerifyRefactor -->|Exit 0| End([Feature verified & completed])
|
|
39
|
-
```
|
|
1
|
+
# Workflow: Test-Driven Development (TDD)
|
|
2
|
+
|
|
3
|
+
> Enforces the classic Red-Green-Refactor development cycle. Crucially, this is NOT a linear process. It is a loop driven by terminal exit codes.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes the script-gated reality of TDD. The AI cannot progress to the next phase until the terminal script explicitly confirms the state.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Identify Feature / Bug]) --> DesignInterface["Design interface & contract"]
|
|
14
|
+
DesignInterface --> WriteTest["Write unit/integration tests first"]
|
|
15
|
+
|
|
16
|
+
WriteTest --> RunRed["Try: Run tests (EXPECT FAILURE)"]
|
|
17
|
+
RunRed --> VerifyRed{Gate: Exit Code 1?}
|
|
18
|
+
VerifyRed -->|Exit 0: Fake Test| FixTest["Reflect: Test is broken/fake. Fix it."]
|
|
19
|
+
FixTest --> RunRed
|
|
20
|
+
|
|
21
|
+
VerifyRed -->|Exit 1: True Red| WriteCode["Write minimal code to pass test"]
|
|
22
|
+
|
|
23
|
+
WriteCode --> RunGreen["Try: Run tests (EXPECT SUCCESS)"]
|
|
24
|
+
RunGreen --> VerifyGreen{Gate: verify-gate.js}
|
|
25
|
+
|
|
26
|
+
VerifyGreen -->|Exit 1: Still Broken| DebugCode["Reflect: Read logs, fix code"]
|
|
27
|
+
DebugCode --> RunGreen
|
|
28
|
+
VerifyGreen -->|Exit 1: 3x Failures| CircuitBreaker["Trigger rule-of-3.js: ZOOM OUT"]
|
|
29
|
+
CircuitBreaker --> DebugCode
|
|
30
|
+
|
|
31
|
+
VerifyGreen -->|Exit 0: Green| Refactor["Refactor code for readability"]
|
|
32
|
+
|
|
33
|
+
Refactor --> RunVerify["Try: Run tests again"]
|
|
34
|
+
RunVerify --> VerifyRefactor{Gate: verify-gate.js}
|
|
35
|
+
VerifyRefactor -->|Exit 1| Revert["Revert refactor / Fix"]
|
|
36
|
+
Revert --> RunVerify
|
|
37
|
+
|
|
38
|
+
VerifyRefactor -->|Exit 0| End([Feature verified & completed])
|
|
39
|
+
```
|
|
@@ -1,36 +1,36 @@
|
|
|
1
|
-
# Workflow: Todo-Driven Workflow
|
|
2
|
-
|
|
3
|
-
> The fundamental execution loop. Driven entirely by terminal state machines (`todo-cli.js`).
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Skill Behavior Workflow
|
|
8
|
-
|
|
9
|
-
This section visualizes the rigid state constraints. Transitioning state is blocked unless verification gates pass.
|
|
10
|
-
|
|
11
|
-
```mermaid
|
|
12
|
-
graph TD
|
|
13
|
-
Start([Initialize Checklist]) --> Plan["Define 3-7 Verifiable Sub-tasks"]
|
|
14
|
-
Plan --> SaveTodo["Try: node todo-cli.js init ..."]
|
|
15
|
-
|
|
16
|
-
SaveTodo --> ChooseTask["Choose ONE pending task"]
|
|
17
|
-
ChooseTask --> MarkInProgress["Try: node todo-cli.js start <id>"]
|
|
18
|
-
|
|
19
|
-
MarkInProgress --> CheckStart{Gate: Exit Code?}
|
|
20
|
-
CheckStart -->|Exit 1: Multitasking Blocked| ReflectStart["Reflect: Must complete previous task first"]
|
|
21
|
-
ReflectStart --> Execute
|
|
22
|
-
|
|
23
|
-
CheckStart -->|Exit 0| Execute["Execute code changes"]
|
|
24
|
-
|
|
25
|
-
Execute --> GatherEvidence["Try: node verify-gate.js"]
|
|
26
|
-
GatherEvidence --> VerifySuccess{Gate: Exit Code?}
|
|
27
|
-
|
|
28
|
-
VerifySuccess -->|Exit 1: Code is broken| ReflectCode["Reflect: Read Error Log & Fix"]
|
|
29
|
-
ReflectCode --> Execute
|
|
30
|
-
|
|
31
|
-
VerifySuccess -->|Exit 0: Code works| MarkCompleted["Try: node todo-cli.js complete <id>"]
|
|
32
|
-
|
|
33
|
-
MarkCompleted --> CheckRemaining{All tasks completed?}
|
|
34
|
-
CheckRemaining -->|No| ChooseTask
|
|
35
|
-
CheckRemaining -->|Yes| Finish([Signal Task Completion])
|
|
36
|
-
```
|
|
1
|
+
# Workflow: Todo-Driven Workflow
|
|
2
|
+
|
|
3
|
+
> The fundamental execution loop. Driven entirely by terminal state machines (`todo-cli.js`).
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes the rigid state constraints. Transitioning state is blocked unless verification gates pass.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Initialize Checklist]) --> Plan["Define 3-7 Verifiable Sub-tasks"]
|
|
14
|
+
Plan --> SaveTodo["Try: node todo-cli.js init ..."]
|
|
15
|
+
|
|
16
|
+
SaveTodo --> ChooseTask["Choose ONE pending task"]
|
|
17
|
+
ChooseTask --> MarkInProgress["Try: node todo-cli.js start <id>"]
|
|
18
|
+
|
|
19
|
+
MarkInProgress --> CheckStart{Gate: Exit Code?}
|
|
20
|
+
CheckStart -->|Exit 1: Multitasking Blocked| ReflectStart["Reflect: Must complete previous task first"]
|
|
21
|
+
ReflectStart --> Execute
|
|
22
|
+
|
|
23
|
+
CheckStart -->|Exit 0| Execute["Execute code changes"]
|
|
24
|
+
|
|
25
|
+
Execute --> GatherEvidence["Try: node verify-gate.js"]
|
|
26
|
+
GatherEvidence --> VerifySuccess{Gate: Exit Code?}
|
|
27
|
+
|
|
28
|
+
VerifySuccess -->|Exit 1: Code is broken| ReflectCode["Reflect: Read Error Log & Fix"]
|
|
29
|
+
ReflectCode --> Execute
|
|
30
|
+
|
|
31
|
+
VerifySuccess -->|Exit 0: Code works| MarkCompleted["Try: node todo-cli.js complete <id>"]
|
|
32
|
+
|
|
33
|
+
MarkCompleted --> CheckRemaining{All tasks completed?}
|
|
34
|
+
CheckRemaining -->|No| ChooseTask
|
|
35
|
+
CheckRemaining -->|Yes| Finish([Signal Task Completion])
|
|
36
|
+
```
|
|
@@ -1,63 +1,63 @@
|
|
|
1
|
-
# Workflow: Using Git Worktrees
|
|
2
|
-
|
|
3
|
-
> Manages isolated workspace environments in parallel using native Git Worktrees, enabling developers to switch contexts safely without stashing or losing unsaved progress.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Skill Behavior Workflow
|
|
8
|
-
|
|
9
|
-
This section visualizes how the `using-git-worktrees` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
-
|
|
11
|
-
```mermaid
|
|
12
|
-
graph TD
|
|
13
|
-
Start([Switch Context Needed]) --> CheckClean["Assess if main branch has uncommitted changes"]
|
|
14
|
-
CheckClean --> CreateWorktree["Run git worktree add to a sibling directory"]
|
|
15
|
-
CreateWorktree --> CheckoutTarget["Checkout target branch or create a hotfix branch"]
|
|
16
|
-
CheckoutTarget --> OpenWorkspace["Open the sibling directory as a separate isolated workspace"]
|
|
17
|
-
OpenWorkspace --> RunDev["Perform isolated edits, tests, and debugging"]
|
|
18
|
-
RunDev --> CommitIsolated["Commit changes in the isolated workspace"]
|
|
19
|
-
CommitIsolated --> RemoveWorktree["Prune and clean up the worktree path"]
|
|
20
|
-
RemoveWorktree --> Return([Return to original workspace with pristine unsaved state intact])
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
---
|
|
24
|
-
|
|
25
|
-
## 2. Triggering and Routing Path
|
|
26
|
-
|
|
27
|
-
This diagram illustrates how the `using-git-worktrees` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
|
|
28
|
-
|
|
29
|
-
```mermaid
|
|
30
|
-
graph LR
|
|
31
|
-
Router["harness-everything / tier-router.js"] -->|Keyword: worktree / isolate / checkout| WT["using-git-worktrees / SKILL.md"]
|
|
32
|
-
WT -->|Maintains isolation before running tests in| TDDSkill["tdd / SKILL.md"]
|
|
33
|
-
WT -->|Protects terminal environment testing in| EnvSkill["environment-detection / SKILL.md"]
|
|
34
|
-
```
|
|
35
|
-
|
|
36
|
-
---
|
|
37
|
-
|
|
38
|
-
## 3. Real-World Use Case Flowchart
|
|
39
|
-
|
|
40
|
-
Here we model concrete real-world scenarios and use cases of the `using-git-worktrees` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
41
|
-
|
|
42
|
-
```mermaid
|
|
43
|
-
graph TD
|
|
44
|
-
Start["Working on deep feature 'feat-billing' (unstaged edits)"] --> Interrupt["Urgent production hotfix required!"]
|
|
45
|
-
Interrupt --> Trigger["using-git-worktrees skill invoked"]
|
|
46
|
-
Trigger --> CreateWT["Add worktree: 'git worktree add ../hotfix-auth hotfix-branch'"]
|
|
47
|
-
CreateWT --> OpenWT["Open separate workspace editor in ../hotfix-auth"]
|
|
48
|
-
OpenWT --> FixBug["Fix auth bug & run verification test"]
|
|
49
|
-
FixBug --> CommitWT["Commit fix and push branch"]
|
|
50
|
-
CommitWT --> CloseWT["Close editor, run 'git worktree prune'"]
|
|
51
|
-
CloseWT --> Resume["Return to original billing workspace with all unsaved files exactly where they were"]
|
|
52
|
-
Resume --> Done([Context switched safely with zero stashing friction])
|
|
53
|
-
```
|
|
54
|
-
|
|
55
|
-
---
|
|
56
|
-
|
|
57
|
-
## 4. Verification Check
|
|
58
|
-
|
|
59
|
-
To ensure that the `using-git-worktrees` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
60
|
-
|
|
61
|
-
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
62
|
-
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
63
|
-
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
1
|
+
# Workflow: Using Git Worktrees
|
|
2
|
+
|
|
3
|
+
> Manages isolated workspace environments in parallel using native Git Worktrees, enabling developers to switch contexts safely without stashing or losing unsaved progress.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `using-git-worktrees` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Switch Context Needed]) --> CheckClean["Assess if main branch has uncommitted changes"]
|
|
14
|
+
CheckClean --> CreateWorktree["Run git worktree add to a sibling directory"]
|
|
15
|
+
CreateWorktree --> CheckoutTarget["Checkout target branch or create a hotfix branch"]
|
|
16
|
+
CheckoutTarget --> OpenWorkspace["Open the sibling directory as a separate isolated workspace"]
|
|
17
|
+
OpenWorkspace --> RunDev["Perform isolated edits, tests, and debugging"]
|
|
18
|
+
RunDev --> CommitIsolated["Commit changes in the isolated workspace"]
|
|
19
|
+
CommitIsolated --> RemoveWorktree["Prune and clean up the worktree path"]
|
|
20
|
+
RemoveWorktree --> Return([Return to original workspace with pristine unsaved state intact])
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 2. Triggering and Routing Path
|
|
26
|
+
|
|
27
|
+
This diagram illustrates how the `using-git-worktrees` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
|
|
28
|
+
|
|
29
|
+
```mermaid
|
|
30
|
+
graph LR
|
|
31
|
+
Router["harness-everything / tier-router.js"] -->|Keyword: worktree / isolate / checkout| WT["using-git-worktrees / SKILL.md"]
|
|
32
|
+
WT -->|Maintains isolation before running tests in| TDDSkill["tdd / SKILL.md"]
|
|
33
|
+
WT -->|Protects terminal environment testing in| EnvSkill["environment-detection / SKILL.md"]
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## 3. Real-World Use Case Flowchart
|
|
39
|
+
|
|
40
|
+
Here we model concrete real-world scenarios and use cases of the `using-git-worktrees` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
41
|
+
|
|
42
|
+
```mermaid
|
|
43
|
+
graph TD
|
|
44
|
+
Start["Working on deep feature 'feat-billing' (unstaged edits)"] --> Interrupt["Urgent production hotfix required!"]
|
|
45
|
+
Interrupt --> Trigger["using-git-worktrees skill invoked"]
|
|
46
|
+
Trigger --> CreateWT["Add worktree: 'git worktree add ../hotfix-auth hotfix-branch'"]
|
|
47
|
+
CreateWT --> OpenWT["Open separate workspace editor in ../hotfix-auth"]
|
|
48
|
+
OpenWT --> FixBug["Fix auth bug & run verification test"]
|
|
49
|
+
FixBug --> CommitWT["Commit fix and push branch"]
|
|
50
|
+
CommitWT --> CloseWT["Close editor, run 'git worktree prune'"]
|
|
51
|
+
CloseWT --> Resume["Return to original billing workspace with all unsaved files exactly where they were"]
|
|
52
|
+
Resume --> Done([Context switched safely with zero stashing friction])
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## 4. Verification Check
|
|
58
|
+
|
|
59
|
+
To ensure that the `using-git-worktrees` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
60
|
+
|
|
61
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
62
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
63
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|