harness-everything 0.2.0
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/AGENTS.md +2 -0
- package/BENCHMARK_SOP.md +62 -0
- package/CHANGELOG.md +107 -0
- package/Dockerfile +18 -0
- package/LICENSE +201 -0
- package/README.md +197 -0
- package/VERIFICATION.md +347 -0
- package/bin/cli.js +97 -0
- package/build-multi-agent-system/AGENTS.md +50 -0
- package/build-multi-agent-system/README.md +63 -0
- package/build-multi-agent-system/SKILL.md +68 -0
- package/create-agent-launcher/SKILL.md +48 -0
- package/create-agent-launcher/examples/csharp-monorepo.md +123 -0
- package/create-agent-launcher/examples/typescript-cli.md +126 -0
- package/create-agent-launcher/guidelines/platform-claude.md +77 -0
- package/create-agent-launcher/guidelines/platform-codex.md +146 -0
- package/create-agent-launcher/guidelines/platform-copilot.md +74 -0
- package/create-agent-launcher/guidelines/platform-gemini.md +101 -0
- package/create-agent-launcher/guidelines/role-capabilities.md +108 -0
- package/create-agent-launcher/templates/README.md +17 -0
- package/create-agent-launcher/templates/agent-launcher.md +68 -0
- package/create-agent-launcher/templates/backend-developer-csharp.md +56 -0
- package/create-agent-launcher/templates/backend-developer-polyglot.md +62 -0
- package/create-agent-launcher/templates/backend-developer-ts.md +57 -0
- package/create-agent-launcher/templates/memory-keeper.md +37 -0
- package/create-agent-launcher/templates/requirement-analyzer.md +66 -0
- package/create-agent-launcher/templates/specialist-agent.md +34 -0
- package/create-agent-launcher/templates/task-verifier.md +56 -0
- package/create-agent-launcher/templates/tool-maker.md +33 -0
- package/create-agent-launcher/workflows/01-init.md +22 -0
- package/create-agent-launcher/workflows/02-analysis.md +26 -0
- package/create-agent-launcher/workflows/03-generation.md +29 -0
- package/create-agent-launcher/workflows/04-launcher.md +20 -0
- package/docker-verify.sh +266 -0
- package/docs/architecture.md +95 -0
- package/docs/philosophy.md +45 -0
- package/docs/reflection.md +34 -0
- package/docs/routing.md +45 -0
- package/docs/workflows/build-multi-agent-system.md +62 -0
- package/docs/workflows/create-agent-launcher.md +62 -0
- package/docs/workflows/environment-detection.md +63 -0
- package/docs/workflows/eval-harness.md +57 -0
- package/docs/workflows/fable-discipline.md +59 -0
- package/docs/workflows/fable-mode.md +32 -0
- package/docs/workflows/git-commit.md +62 -0
- package/docs/workflows/grill-me.md +62 -0
- package/docs/workflows/grill-with-docs.md +62 -0
- package/docs/workflows/harness-everything.md +92 -0
- package/docs/workflows/improve-codebase-architecture.md +60 -0
- package/docs/workflows/install-cognitive-os.md +60 -0
- package/docs/workflows/repo-docs.md +59 -0
- package/docs/workflows/rewrite-commits.md +60 -0
- package/docs/workflows/security-review.md +58 -0
- package/docs/workflows/self-evolve.md +59 -0
- package/docs/workflows/skill-creator.md +75 -0
- package/docs/workflows/skill-style.md +64 -0
- package/docs/workflows/tdd.md +39 -0
- package/docs/workflows/todo-driven-workflow.md +36 -0
- package/docs/workflows/using-git-worktrees.md +63 -0
- package/docs/workflows/verification-loop.md +69 -0
- package/docs/workflows/verify-before-claim.md +60 -0
- package/docs/workflows/zoom-out.md +62 -0
- package/environment-detection/SKILL.md +77 -0
- package/environment-detection/scripts/preflight.js +93 -0
- package/eval-framework/behavioral-test.js +105 -0
- package/eval-framework/cases/case1.json +5 -0
- package/eval-framework/cases/case2.json +5 -0
- package/eval-framework/cases/case3.json +5 -0
- package/eval-framework/cases/case4-zh-tier2.json +5 -0
- package/eval-framework/cases/case5-zh-tier3.json +5 -0
- package/eval-framework/mechanism-test.js +251 -0
- package/eval-framework/runner.js +56 -0
- package/eval-harness/SKILL.md +59 -0
- package/eval-harness/scripts/evaluate.js +61 -0
- package/fable-discipline/SKILL.md +38 -0
- package/fable-mode/CONTRACT-FORMAT.md +51 -0
- package/fable-mode/SKILL.md +51 -0
- package/fable-mode/agents/fable-orchestrator.md +92 -0
- package/fable-mode/agents/fable-verifier.md +32 -0
- package/fable-mode/agents/fable-worker-haiku.md +48 -0
- package/fable-mode/agents/fable-worker-sonnet.md +49 -0
- package/fable-mode/execution-guardrails/SKILL.md +87 -0
- package/fable-mode/fable-haiku/SKILL.md +48 -0
- package/git-commit/SKILL.md +55 -0
- package/git-commit/guides/ANGULAR_STYLE.md +61 -0
- package/git-commit/guides/COMMIT_GENERATION.md +24 -0
- package/git-commit/guides/LANGUAGE_DETECTION.md +16 -0
- package/git-commit/guides/MAIN_REPO.md +15 -0
- package/git-commit/guides/SUBMODULES.md +27 -0
- package/grill-me/SKILL.md +36 -0
- package/grill-with-docs/ADR-FORMAT.md +47 -0
- package/grill-with-docs/CONTEXT-FORMAT.md +63 -0
- package/grill-with-docs/SKILL.md +99 -0
- package/harness-everything/SKILL.md +141 -0
- package/harness-everything/examples/README.md +9 -0
- package/harness-everything/examples/todo-workflow.md +22 -0
- package/harness-everything/scripts/bootstrap.js +140 -0
- package/harness-everything/scripts/self-heal.js +189 -0
- package/harness-everything/scripts/tier-router.js +219 -0
- package/harness-everything/scripts/todo-cli.js +157 -0
- package/harness-everything/scripts/verify-gate.js +31 -0
- package/hooks/hooks.json +155 -0
- package/hooks/scripts/atomic-commit-check.js +68 -0
- package/hooks/scripts/boundary-guard.js +55 -0
- package/hooks/scripts/context-compact.js +114 -0
- package/hooks/scripts/contract-test.js +79 -0
- package/hooks/scripts/depth-guard.js +65 -0
- package/hooks/scripts/lib/harness-state.js +202 -0
- package/hooks/scripts/lib/platforms/claude.js +42 -0
- package/hooks/scripts/lib/platforms/codex.js +46 -0
- package/hooks/scripts/lib/platforms/continue.js +41 -0
- package/hooks/scripts/lib/platforms/copilot.js +41 -0
- package/hooks/scripts/lib/platforms/cursor.js +41 -0
- package/hooks/scripts/lib/platforms/hermes.js +32 -0
- package/hooks/scripts/lib/platforms/index.js +17 -0
- package/hooks/scripts/lib/platforms/worktrees.js +20 -0
- package/hooks/scripts/reset-circuit-breaker.js +30 -0
- package/hooks/scripts/rule-of-3-tracker.js +91 -0
- package/hooks/scripts/rule-of-3.js +176 -0
- package/hooks/scripts/state-persist.js +99 -0
- package/hooks/scripts/stop-gate.js +80 -0
- package/hooks/scripts/subagent-scope-guard.js +88 -0
- package/improve-codebase-architecture/SKILL.md +44 -0
- package/improve-codebase-architecture/guides/DEEPENING.md +37 -0
- package/improve-codebase-architecture/guides/HTML-REPORT.md +123 -0
- package/improve-codebase-architecture/guides/INTERFACE-DESIGN.md +44 -0
- package/improve-codebase-architecture/guides/LANGUAGE.md +53 -0
- package/install-cognitive-os/SKILL.md +95 -0
- package/package.json +22 -0
- package/repo-docs/SKILL.md +45 -0
- package/repo-docs/templates/agents-template.md +264 -0
- package/repo-docs/templates/knowledge-agents-template.md +50 -0
- package/repo-docs/templates/knowledge-readme-template.md +83 -0
- package/repo-docs/templates/manual-recon.md +117 -0
- package/repo-docs/templates/multi-skills-readme-template.md +72 -0
- package/repo-docs/templates/product-agents-template.md +78 -0
- package/repo-docs/templates/product-readme-template.md +95 -0
- package/repo-docs/templates/readme-template.md +136 -0
- package/repo-docs/templates/single-skill-readme-template.md +70 -0
- package/repo-docs/templates/skills-agents-template.md +60 -0
- package/rewrite-commits/SKILL.md +32 -0
- package/scripts/installer.js +649 -0
- package/scripts/lib/advisory-text.js +163 -0
- package/scripts/lib/claude-hooks.js +71 -0
- package/scripts/lib/gitignore.js +58 -0
- package/scripts/lib/manifest.js +82 -0
- package/scripts/lib/prompts.js +241 -0
- package/scripts/lib/skills.js +172 -0
- package/scripts/lib/workspace.js +28 -0
- package/security-review/SKILL.md +511 -0
- package/self-evolve/SKILL.md +54 -0
- package/self-evolve/scripts/persist-memory.js +40 -0
- package/self-evolve/scripts/self-regression.js +113 -0
- package/skill-creator/SKILL.md +91 -0
- package/skill-creator/references/quality-principles.md +81 -0
- package/skill-creator/references/testing-workflow.md +32 -0
- package/skill-style/SKILL.md +48 -0
- package/skill-style/STYLE.md +37 -0
- package/tdd/SKILL.md +53 -0
- package/tdd/guides/deep-modules.md +33 -0
- package/tdd/guides/interface-design.md +31 -0
- package/tdd/guides/mocking.md +59 -0
- package/tdd/guides/refactoring.md +10 -0
- package/tdd/guides/tests.md +61 -0
- package/todo-driven-workflow/SKILL.md +54 -0
- package/using-git-worktrees/SKILL.md +161 -0
- package/verification-loop/SKILL.md +138 -0
- package/verify-before-claim/SKILL.md +86 -0
- package/zoom-out/SKILL.md +90 -0
package/docs/routing.md
ADDED
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Harness Routing & Task Triage
|
|
2
|
+
|
|
3
|
+
To prevent both over-engineering and under-planning, Harness classifies every user request into one of three execution tiers. This ensures that trivial tasks are executed instantly without unnecessary bloat, while complex architectural refactoring is strictly designed and verified.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## The Three-Tier Routing System
|
|
8
|
+
|
|
9
|
+
Upon receiving a request, the `tier-router.js` script analyzes the scope, affected files, and instruction patterns to route the task:
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
[ User Request ]
|
|
13
|
+
|
|
|
14
|
+
v
|
|
15
|
+
[ Triage Analysis ]
|
|
16
|
+
/ | \
|
|
17
|
+
/ | \
|
|
18
|
+
(Trivial) (Standard) (Macro)
|
|
19
|
+
/ | \
|
|
20
|
+
v v v
|
|
21
|
+
[ Tier 1 ] [ Tier 2 ] [ Tier 3 ]
|
|
22
|
+
Direct Edit Test-Driven (TDD) Multi-Agent Flow
|
|
23
|
+
(No plans) (Red-Green-Refactor) (Fable-Mode)
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
### Tier 1: Trivial Tasks (Direct Execution)
|
|
27
|
+
* **Trigger criteria:** Single-file edits, typos, simple styling fixes, readme corrections, or clean-up tasks.
|
|
28
|
+
* **Behavior:** Harness bypasses plans, code-reviews, and sub-agents. The model is directed to make the edit directly and complete the task, consuming minimal tokens.
|
|
29
|
+
* **Verification:** Basic syntax checks or a quick compile verify success.
|
|
30
|
+
|
|
31
|
+
### Tier 2: Standard Tasks (Test-Driven Development)
|
|
32
|
+
* **Trigger criteria:** Normal feature requests, bug fixes, algorithm additions, API endpoint creations, or any task affecting multiple files with logical risk.
|
|
33
|
+
* **Behavior:** Harness enforces the `todo-driven-workflow` base execution loop (initialize a 3-7 item verifiable checklist before editing, one item in-progress at a time) and the `tdd` skill. The model is strictly guided through the Red-Green-Refactor loop:
|
|
34
|
+
1. **Red:** Write an automated test first that reproduces the issue or covers the feature, then run it to verify failure.
|
|
35
|
+
2. **Green:** Implement the minimal amount of code to make the test pass.
|
|
36
|
+
3. **Refactor:** Polish the code, clean up duplicates, and ensure coverage targets (minimum 80%) are met.
|
|
37
|
+
* **Verification:** Strict execution of the test suite.
|
|
38
|
+
|
|
39
|
+
### Tier 3: Macro Tasks (Multi-Agent/Fable-Mode)
|
|
40
|
+
* **Trigger criteria:** High-level design changes, migration of modules, large-scale refactoring, or major capability additions affecting multiple domains.
|
|
41
|
+
* **Behavior:** Harness automatically spawns the multi-agent orchestration engine (`fable-mode` and `create-agent-launcher`), with the macro plan materialized as the `todo-driven-workflow` checklist.
|
|
42
|
+
1. **Planning:** An agent constructs a rigorous, phase-based implementation plan.
|
|
43
|
+
2. **Delegation:** Specialized sub-agents (e.g., `security-reviewer`, `database-reviewer`, `code-reviewer`) are created to handle specific work streams or audits.
|
|
44
|
+
3. **Handoffs:** Session handoffs are saved periodically to ensure that if a session limits out or restarts, the progress is seamlessly restored.
|
|
45
|
+
* **Verification:** Multi-layer unit, integration, and E2E verification loops.
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Workflow: Build Multi-Agent System
|
|
2
|
+
|
|
3
|
+
> Deploys an industrial-grade, self-adapting Multi-Agent Workspace architecture, scaffolding physical boundaries and relational SQLite context indexes.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `build-multi-agent-system` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Workspace Scaffolding Requested]) --> DiscoverStack["Analyze project package.json/runtimes"]
|
|
14
|
+
DiscoverStack --> DeduceRoles["Deduce required specialist roles & PM / Challenger"]
|
|
15
|
+
DeduceRoles --> ScaffoldZones["Scaffold '6 Functional Zones' directories: State, Decisions, Logs, etc."]
|
|
16
|
+
ScaffoldZones --> GenMemoryIndexer["Generate language-appropriate index_memory script"]
|
|
17
|
+
GenMemoryIndexer --> GenAgentsRouter["Generate AGENTS.md routing brain"]
|
|
18
|
+
GenAgentsRouter --> RunIndexer["Execute memory indexer to initialize local memory.db SQLite index"]
|
|
19
|
+
RunIndexer --> VerifyExecution["Verify schema, tables, and execution status"]
|
|
20
|
+
VerifyExecution --> End([Scaffolding and hybrid relational memory initialized])
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 2. Triggering and Routing Path
|
|
26
|
+
|
|
27
|
+
This diagram illustrates how the `build-multi-agent-system` 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: agent / workspace / multi-agent| BMAS["build-multi-agent-system / SKILL.md"]
|
|
32
|
+
BMAS -->|Works hand-in-hand with spawning tool| CAL["create-agent-launcher / SKILL.md"]
|
|
33
|
+
BMAS -->|Stores architectural contracts in| GWD["grill-with-docs / SKILL.md"]
|
|
34
|
+
BMAS -->|Initializes memory rules via| Evolve["self-evolve / SKILL.md"]
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
## 3. Real-World Use Case Flowchart
|
|
40
|
+
|
|
41
|
+
Here we model concrete real-world scenarios and use cases of the `build-multi-agent-system` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
42
|
+
|
|
43
|
+
```mermaid
|
|
44
|
+
graph TD
|
|
45
|
+
Start["User asks to set up an AI developer workspace for a Python backend"] --> Trigger["Invoke build-multi-agent-system"]
|
|
46
|
+
Trigger --> DetectStack["Identifies Python/Django stack"]
|
|
47
|
+
DetectStack --> BuildDirs["Creates .agents/, docs/decisions/, docs/architecture/, state/ folders"]
|
|
48
|
+
BuildDirs --> WriteIndexer["Creates python indexer script parsing markdown frontmatter"]
|
|
49
|
+
WriteIndexer --> CreateDB["Runs indexer, generating SQLite memory.db schema"]
|
|
50
|
+
CreateDB --> WriteAgentsRouter["Generates AGENTS.md with routing matrix"]
|
|
51
|
+
WriteAgentsRouter --> Done([Professional Multi-Agent Workspace deployed and indexed])
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## 4. Verification Check
|
|
57
|
+
|
|
58
|
+
To ensure that the `build-multi-agent-system` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
59
|
+
|
|
60
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
61
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
62
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Workflow: Create Agent Launcher
|
|
2
|
+
|
|
3
|
+
> Sub-agent generator for orchestrating multi-domain specialized agents to avoid token context waste and preserve developer focus.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `create-agent-launcher` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Complex Task Demands Division of Labor]) --> AssessComplexity{Too complex for 1 context?}
|
|
14
|
+
AssessComplexity -->|No| Reject["Reject creation, resolve in current context via TDD"]
|
|
15
|
+
AssessComplexity -->|Yes| DefinePersona["Define highly restrictive specialized sub-agent persona"]
|
|
16
|
+
DefinePersona --> IsolateResources["Map exact, minimum file paths needed for sub-task"]
|
|
17
|
+
IsolateResources --> SelectModel["Select cost-effective model based on task weight"]
|
|
18
|
+
SelectModel --> WriteHandoff["Define strict input/output contract for sub-agent return report"]
|
|
19
|
+
WriteHandoff --> LaunchAgent["Launch specialized sub-agent under isolated sandbox"]
|
|
20
|
+
LaunchAgent --> MergeReport["Validate and merge sub-agent findings into main orchestrator"]
|
|
21
|
+
MergeReport --> End([Sub-agent work verified and closed])
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 2. Triggering and Routing Path
|
|
27
|
+
|
|
28
|
+
This diagram illustrates how the `create-agent-launcher` 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.
|
|
29
|
+
|
|
30
|
+
```mermaid
|
|
31
|
+
graph LR
|
|
32
|
+
Router["harness-everything / tier-router.js"] -->|Requires agent specialization| CAL["create-agent-launcher / SKILL.md"]
|
|
33
|
+
CAL -->|Spawns agent on scaffolding provided by| BMAS["build-multi-agent-system / SKILL.md"]
|
|
34
|
+
CAL -->|Plans agent tasks using macro planner| Fable["fable-mode / SKILL.md"]
|
|
35
|
+
CAL -->|Limits child memory to prevent bloat via| FD["fable-discipline / SKILL.md"]
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## 3. Real-World Use Case Flowchart
|
|
41
|
+
|
|
42
|
+
Here we model concrete real-world scenarios and use cases of the `create-agent-launcher` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
43
|
+
|
|
44
|
+
```mermaid
|
|
45
|
+
graph TD
|
|
46
|
+
Start["Refactoring task involves SQL Schema migrations, Node endpoints, and React forms"] --> Trigger["create-agent-launcher skill executed"]
|
|
47
|
+
Trigger --> SpawnDB["Spawn 'Database Architect': Only views 'schema.sql' and outputs raw SQL migration"]
|
|
48
|
+
Trigger --> SpawnFE["Spawn 'Frontend Specialist': Only views 'Login.tsx' and outputs validated form code"]
|
|
49
|
+
SpawnDB & SpawnFE --> Collect["Main orchestrator receives isolated, highly focused diff reports from both"]
|
|
50
|
+
Collect --> Merge["Integrate changes and run integration testing"]
|
|
51
|
+
Merge --> Done([Complex task completed with 70% lower token cost and zero context confusion])
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## 4. Verification Check
|
|
57
|
+
|
|
58
|
+
To ensure that the `create-agent-launcher` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
59
|
+
|
|
60
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
61
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
62
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# Workflow: Environment Detection
|
|
2
|
+
|
|
3
|
+
> Active shell, operating system, and toolset environment detection, providing safety guardrails and running preflight syntactic verification.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `environment-detection` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Before Command Execution]) --> DetectOS["Detect Operating System: Windows, macOS, Linux"]
|
|
14
|
+
DetectOS --> DetectShell["Detect Shell: Bash, PowerShell, CMD, Zsh"]
|
|
15
|
+
DetectShell --> ScanCapabilities["Scan available runtimes: Node, Python, .NET, Docker"]
|
|
16
|
+
ScanCapabilities --> CheckSyntax["Inspect command for active shell compatibilities"]
|
|
17
|
+
CheckSyntax --> SyntaxGuard{Syntax safe for shell?}
|
|
18
|
+
SyntaxGuard -->|No| RewriteCmd["Transform/Rewrite command syntax to match active shell"]
|
|
19
|
+
SyntaxGuard -->|Yes| Execute["Run command in persistent terminal"]
|
|
20
|
+
RewriteCmd --> Execute
|
|
21
|
+
Execute --> CaptureOutput["Interleave output and exit code correctly"]
|
|
22
|
+
CaptureOutput --> End([Secure terminal result returned])
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## 2. Triggering and Routing Path
|
|
28
|
+
|
|
29
|
+
This diagram illustrates how the `environment-detection` 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.
|
|
30
|
+
|
|
31
|
+
```mermaid
|
|
32
|
+
graph LR
|
|
33
|
+
Router["harness-everything / tier-router.js"] -->|Pre-flight command execution| Env["environment-detection / SKILL.md"]
|
|
34
|
+
Env -->|Guards runner execution commands in| TDD["tdd / SKILL.md"]
|
|
35
|
+
Env -->|Guards script installations in| InstallOS["install-cognitive-os / SKILL.md"]
|
|
36
|
+
Env -->|Guards PR quality checks in| VerLoop["verification-loop / SKILL.md"]
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## 3. Real-World Use Case Flowchart
|
|
42
|
+
|
|
43
|
+
Here we model concrete real-world scenarios and use cases of the `environment-detection` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
44
|
+
|
|
45
|
+
```mermaid
|
|
46
|
+
graph TD
|
|
47
|
+
Start["Agent wants to run: 'rm -rf build && mkdir build' on Windows Powershell"] --> Trigger["Environment detection pre-flight check"]
|
|
48
|
+
Trigger --> Detect["Identifies OS: Windows, Shell: PowerShell"]
|
|
49
|
+
Detect --> AnalyzeSyntax["Identifies that 'rm -rf' will fail or behave unexpectedly in PowerShell"]
|
|
50
|
+
AnalyzeSyntax --> Rewrite["Rewrites command to PowerShell equivalent or executes using native node commands"]
|
|
51
|
+
Rewrite --> Run["Executes safely with exit code 0"]
|
|
52
|
+
Run --> Done([Syntax error and execution crash avoided])
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## 4. Verification Check
|
|
58
|
+
|
|
59
|
+
To ensure that the `environment-detection` 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.
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Workflow: Eval Harness
|
|
2
|
+
|
|
3
|
+
> Evaluates AI developer agent performance based on accuracy, resource efficiency, and anti-loop metrics.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `eval-harness` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Agent Execution Finished]) --> CollectExecutionMetrics["Gather total elapsed time, token count, and API calls"]
|
|
14
|
+
CollectExecutionMetrics --> EvaluateAccuracy["Compare completed task output against baseline correctness requirements"]
|
|
15
|
+
EvaluateAccuracy --> AnalyzeLoops["Check for repetitive tool invocations or redundant edits"]
|
|
16
|
+
AnalyzeLoops --> CalculateScores["Calculate performance and efficiency scores"]
|
|
17
|
+
CalculateScores --> GenerateEvalReport["Compile formal evaluation report and dashboard metrics"]
|
|
18
|
+
GenerateEvalReport --> End([Performance metrics indexed and logged])
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## 2. Triggering and Routing Path
|
|
24
|
+
|
|
25
|
+
This diagram illustrates how the `eval-harness` 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
|
+
Router["harness-everything / tier-router.js"] -->|Analyzes performance metrics| EH["eval-harness / SKILL.md"]
|
|
30
|
+
EH -->|Synthesizes lessons learned for| Evolve["self-evolve / SKILL.md"]
|
|
31
|
+
EH -->|Detects error loops triggering| ZoomOut["zoom-out / SKILL.md"]
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## 3. Real-World Use Case Flowchart
|
|
37
|
+
|
|
38
|
+
Here we model concrete real-world scenarios and use cases of the `eval-harness` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
39
|
+
|
|
40
|
+
```mermaid
|
|
41
|
+
graph TD
|
|
42
|
+
Start["Agent session finishes implementing a complete backend server"] --> Trigger["eval-harness skill executed"]
|
|
43
|
+
Trigger --> Gather["Collects: 15 minutes elapsed, 32 tool calls, 45,000 tokens consumed"]
|
|
44
|
+
Gather --> Score["Scores: Correctness 10/10, Resource Efficiency 9/10, Anti-loop 10/10"]
|
|
45
|
+
Score --> Output["Generates benchmark report summarizing optimal execution speed and zero looping errors"]
|
|
46
|
+
Output --> Done([Benchmark logged for project history])
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## 4. Verification Check
|
|
52
|
+
|
|
53
|
+
To ensure that the `eval-harness` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
54
|
+
|
|
55
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
56
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
57
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Workflow: Fable Discipline
|
|
2
|
+
|
|
3
|
+
> Shadow guard for fable-mode preventing context bloat, enforcing physical boundaries, and tracking token burn metrics.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `fable-discipline` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Fable Task Initiated]) --> AuditContext["Audit total file lengths in current context"]
|
|
14
|
+
AuditContext --> CheckTokenLimit{Tokens exceeding budget?}
|
|
15
|
+
CheckTokenLimit -->|Yes| TrimContext["Evict raw logs, completed tasks, and non-essential file contents"]
|
|
16
|
+
CheckTokenLimit -->|No| KeepState["Continue monitoring context state"]
|
|
17
|
+
TrimContext --> EnforceLimit["Enforce physical boundary guidelines"]
|
|
18
|
+
KeepState --> EnforceLimit
|
|
19
|
+
EnforceLimit --> LogMetrics["Track token utilization and distillation loops"]
|
|
20
|
+
LogMetrics --> End([Context maintained under safe, high-attention limits])
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 2. Triggering and Routing Path
|
|
26
|
+
|
|
27
|
+
This diagram illustrates how the `fable-discipline` 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
|
+
Fable["fable-mode / SKILL.md"] -->|Monitors context on every turn| FD["fable-discipline / SKILL.md"]
|
|
32
|
+
FD -->|Trims and prunes files from| ActiveContext["Active AI Session Context"]
|
|
33
|
+
FD -->|Triggers high-level reflection when overloaded| ZoomOut["zoom-out / 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 `fable-discipline` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
41
|
+
|
|
42
|
+
```mermaid
|
|
43
|
+
graph TD
|
|
44
|
+
Start["Fable-mode is editing a large monorepo (context approaching 120k tokens)"] --> Monitor["Fable-discipline analyzes context size"]
|
|
45
|
+
Monitor --> TriggerPruning["Identifies 80k tokens of raw test execution logs & completed sub-task details"]
|
|
46
|
+
TriggerPruning --> Clean["Evicts completed step details and logs from immediate active context"]
|
|
47
|
+
Clean --> Compress["Summarizes historical state into a 50-line relational state.json"]
|
|
48
|
+
Compress --> Done([Active context drops back to 40k tokens, preserving model's reasoning precision])
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## 4. Verification Check
|
|
54
|
+
|
|
55
|
+
To ensure that the `fable-discipline` 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.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Workflow: Fable Mode
|
|
2
|
+
|
|
3
|
+
> Macro-task planning and execution engine. Like all Harness workflows, this is not a straight line to success. It requires continuous verification and course correction.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how `fable-mode` handles macro tasks. Subagent failure or integration crashes are expected realities, not edge cases.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Tier 3 Macro Task Triggered]) --> InitFable["Initialize Fable Execution Context"]
|
|
14
|
+
InitFable --> AnalyzeScope["Map system dependencies & files"]
|
|
15
|
+
AnalyzeScope --> GenerateContract["Generate Contract & Todo List"]
|
|
16
|
+
|
|
17
|
+
GenerateContract --> RunStep["Try: Execute Step / Sub-agent"]
|
|
18
|
+
RunStep --> VerifyStep["Try: Run verify-gate.js for Integration"]
|
|
19
|
+
|
|
20
|
+
VerifyStep --> Check{Gate: Exit Code?}
|
|
21
|
+
Check -->|Exit 1: Sub-agent Failed| Diagnose["Reflect: Why did sub-agent fail?"]
|
|
22
|
+
Diagnose --> InsertBlocker["Insert Blocker Todo: Fix Integration"]
|
|
23
|
+
InsertBlocker --> RunStep
|
|
24
|
+
|
|
25
|
+
Check -->|Exit 0: Success| CheckAllSteps{All steps done?}
|
|
26
|
+
CheckAllSteps -->|No| RunStep
|
|
27
|
+
CheckAllSteps -->|Yes| FinalAudit["Perform system-wide verification loop"]
|
|
28
|
+
|
|
29
|
+
FinalAudit --> FinalCheck{Gate: Exit Code?}
|
|
30
|
+
FinalCheck -->|Exit 1| Diagnose
|
|
31
|
+
FinalCheck -->|Exit 0| End([Macro rewrite successfully deployed])
|
|
32
|
+
```
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Workflow: Git Commit
|
|
2
|
+
|
|
3
|
+
> Generates semantic, Angular-style conventional commits after verifying the workspace, staged files, and active language contexts.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `git-commit` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Trigger Commit Hook / Command]) --> DetectRepo["Detect main repo vs submodule"]
|
|
14
|
+
DetectRepo --> PreCheck["Verify unstaged changes & staged files"]
|
|
15
|
+
PreCheck --> StageCheck{Staged files present?}
|
|
16
|
+
StageCheck -->|No| Warning["Warn developer & exit"]
|
|
17
|
+
StageCheck -->|Yes| DetectLang["Analyze file extensions for active languages"]
|
|
18
|
+
DetectLang --> GenMessage["Analyze changes and generate Angular-style commit message"]
|
|
19
|
+
GenMessage --> FormatCheck["Format check: type, scope, subject, body, footer"]
|
|
20
|
+
FormatCheck --> WriteCommit["Commit staged files with formatted message"]
|
|
21
|
+
WriteCommit --> End([Staging clean and committed])
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 2. Triggering and Routing Path
|
|
27
|
+
|
|
28
|
+
This diagram illustrates how the `git-commit` 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.
|
|
29
|
+
|
|
30
|
+
```mermaid
|
|
31
|
+
graph LR
|
|
32
|
+
Router["harness-everything / tier-router.js"] -->|Keyword: commit / git / save| GitCommit["git-commit / SKILL.md"]
|
|
33
|
+
GitCommit -->|Formats according to| Guide["git-commit / guides / ANGULAR_STYLE.md"]
|
|
34
|
+
GitCommit -->|Integrates with pre-commit gates| VerLoop["verification-loop / SKILL.md"]
|
|
35
|
+
GitCommit -->|Composed after history squashes| Rewrite["rewrite-commits / SKILL.md"]
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## 3. Real-World Use Case Flowchart
|
|
41
|
+
|
|
42
|
+
Here we model concrete real-world scenarios and use cases of the `git-commit` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
43
|
+
|
|
44
|
+
```mermaid
|
|
45
|
+
graph TD
|
|
46
|
+
Start["Developer completes feature & runs 'git add .'"] --> Trigger["Invoke git-commit skill"]
|
|
47
|
+
Trigger --> Analyze["Skill parses staged diff: 'src/auth.js (+15,-2)'"]
|
|
48
|
+
Analyze --> DetectScope["Deduce scope: 'auth' and type: 'feat'"]
|
|
49
|
+
DetectScope --> BuildMessage["Build message: 'feat(auth): add JWT token expiration check'"]
|
|
50
|
+
BuildMessage --> Commit["Execute git commit -m 'feat(auth): add JWT token expiration check'"]
|
|
51
|
+
Commit --> Done(["Repository index updated cleanly"])
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## 4. Verification Check
|
|
57
|
+
|
|
58
|
+
To ensure that the `git-commit` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
59
|
+
|
|
60
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
61
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
62
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Workflow: Grill Me
|
|
2
|
+
|
|
3
|
+
> Relentless Challenger interview process that stress-tests architectural plans, highlights hidden assumptions, and demands explicit edge-case handling.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `grill-me` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Developer Proposes Plan]) --> IntroduceChallenger["Introduce 'Challenger' adversarial persona"]
|
|
14
|
+
IntroduceChallenger --> ProbeAssumptions["Analyze proposal and probe soft/mocked points"]
|
|
15
|
+
ProbeAssumptions --> AskHardQuestions["Ask 3-5 aggressive, non-trivial stress-testing questions"]
|
|
16
|
+
AskHardQuestions --> ReceiveAnswers["Developer provides details & arguments"]
|
|
17
|
+
ReceiveAnswers --> ValidateResilience{Answers robust & handle failures?}
|
|
18
|
+
ValidateResilience -->|No| GrillDeeper["Grill deeper on specific vulnerabilities"]
|
|
19
|
+
ValidateResilience -->|Yes| DistillDecisions["Distill final agreed design decisions"]
|
|
20
|
+
GrillDeeper --> ReceiveAnswers
|
|
21
|
+
DistillDecisions --> End([Proposal approved and hardened against failures])
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 2. Triggering and Routing Path
|
|
27
|
+
|
|
28
|
+
This diagram illustrates how the `grill-me` 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.
|
|
29
|
+
|
|
30
|
+
```mermaid
|
|
31
|
+
graph LR
|
|
32
|
+
Router["harness-everything / tier-router.js"] -->|Keyword: grill / debate / plan| GrillMe["grill-me / SKILL.md"]
|
|
33
|
+
GrillMe -->|Writes final hardened agreements into| GWD["grill-with-docs / SKILL.md"]
|
|
34
|
+
GrillMe -->|Directs macro execution strategies of| Fable["fable-mode / SKILL.md"]
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
## 3. Real-World Use Case Flowchart
|
|
40
|
+
|
|
41
|
+
Here we model concrete real-world scenarios and use cases of the `grill-me` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
42
|
+
|
|
43
|
+
```mermaid
|
|
44
|
+
graph TD
|
|
45
|
+
Start["Proposal: 'I will write a fast cron job to sync database tables directly'"] --> Trigger["grill-me skill activated"]
|
|
46
|
+
Trigger --> Challenger["Challenger SRE: 'What happens if the cron script fails mid-sync? Will there be database lock contention? How do we prevent partial/corrupt states?'"]
|
|
47
|
+
Challenger --> Answer1["Dev: 'I'll add database transaction wraps and skip locks'"]
|
|
48
|
+
Answer1 --> Challenger2["Challenger: 'How will we monitor and alert if locks are skipped repeatedly?'"]
|
|
49
|
+
Challenger2 --> Answer2["Dev: 'I'll add structured logging and trigger a standard Slack web-hook alerting'"]
|
|
50
|
+
Answer2 --> Approve["Challenger: 'Excellent. Let's record these lock-skip alerts as mandatory requirements.'"]
|
|
51
|
+
Approve --> Done([Plan hardened and logged])
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## 4. Verification Check
|
|
57
|
+
|
|
58
|
+
To ensure that the `grill-me` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
59
|
+
|
|
60
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
61
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
62
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Workflow: Grill with Docs
|
|
2
|
+
|
|
3
|
+
> Decision tracking, Glossary alignment, and ADR-driven (Architecture Decision Record) grilling to eliminate technical drift between code and documentation.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Skill Behavior Workflow
|
|
8
|
+
|
|
9
|
+
This section visualizes how the `grill-with-docs` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
|
|
10
|
+
|
|
11
|
+
```mermaid
|
|
12
|
+
graph TD
|
|
13
|
+
Start([Plan Proposed against Domain]) --> ReadDomainModel["Read CONTEXT.md and existing ADRs"]
|
|
14
|
+
ReadDomainModel --> ChallengeDrift["Examine plan for term drift or architectural violations"]
|
|
15
|
+
ChallengeDrift --> UpdateGlossary["Refine and match terminology with current Glossary"]
|
|
16
|
+
UpdateGlossary --> DraftADR["Draft formal Architecture Decision Record in ADR format"]
|
|
17
|
+
DraftADR --> StressTestADR["Stress-test ADR against error boundaries and fail-safes"]
|
|
18
|
+
StressTestADR --> WriteDocs["Commit ADR to docs/adr/ and update CONTEXT.md"]
|
|
19
|
+
WriteDocs --> InjectTodos["Inject critical TODO: [CRITICAL BUG FIX] tags into corresponding code"]
|
|
20
|
+
InjectTodos --> End([Code and documentation are perfectly aligned])
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 2. Triggering and Routing Path
|
|
26
|
+
|
|
27
|
+
This diagram illustrates how the `grill-with-docs` 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: adr / decision / glossary| GWD["grill-with-docs / SKILL.md"]
|
|
32
|
+
GWD -->|Coordinates stress-tests using| GrillMe["grill-me / SKILL.md"]
|
|
33
|
+
GWD -->|Aligns documentation during macro work in| Fable["fable-mode / SKILL.md"]
|
|
34
|
+
GWD -->|Triggers todo tasks tracked by| Todo["todo-driven-workflow / SKILL.md"]
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
## 3. Real-World Use Case Flowchart
|
|
40
|
+
|
|
41
|
+
Here we model concrete real-world scenarios and use cases of the `grill-with-docs` skill, illustrating standard success paths, error handling, or recovery loops.
|
|
42
|
+
|
|
43
|
+
```mermaid
|
|
44
|
+
graph TD
|
|
45
|
+
Start["Requirement: Change notification retry rate limits"] --> Trigger["grill-with-docs skill invoked"]
|
|
46
|
+
Trigger --> ReadDocs["Analyzes docs/adr/003-rate-limiting.md"]
|
|
47
|
+
ReadDocs --> CheckDrift["Finds that proposed change violates the maximum overload protection limit"]
|
|
48
|
+
CheckDrift --> RefinePlan["Plan updated to stay within the 003-rate-limiting contract"]
|
|
49
|
+
RefinePlan --> CreateADR["Create docs/adr/008-notification-retries.md"]
|
|
50
|
+
CreateADR --> SyncCode["Modify code and inject aligned TODO tags directly in code to maintain truth"]
|
|
51
|
+
SyncCode --> Done([Zero architectural drift achieved])
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## 4. Verification Check
|
|
57
|
+
|
|
58
|
+
To ensure that the `grill-with-docs` skill is operating in strict compliance with Harness OS design laws, verify the following:
|
|
59
|
+
|
|
60
|
+
- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
|
|
61
|
+
- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
|
|
62
|
+
- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
|