harness-everything 0.2.0 → 0.2.1

package/CHANGELOG.md

@@ -5,6 +5,13 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+---
+## [0.2.1] - 2026-07-24
+
+### Fixed
+- **Global skill installs landed one directory too deep**: `--global`/`-g` installs (all platforms share this one code path) copied skills to `~/.agents/harness-everything/skills/` instead of the documented `~/.agents/skills/` (see `bin/cli.js`'s own `-g, --global` help text, and the legacy-fallback scan `scripts/lib/skills.js` already expected at that path). Corrected in `scripts/installer.js` to match the same convention already used locally: `harness-everything/` holds manifest bookkeeping only, skill content lives in the native/shared `skills/` folder next to it. `~/.agents/harness-everything/manifest.json` is unchanged; uninstall's final global sweep was updated to match.
+- **Duplicate lines could accumulate in `.gitignore`**: `ensureHarnessStateIgnored` (`hooks/scripts/lib/harness-state.js`) runs once per hook-invoked subprocess with no cross-process lock around its read-then-append, so two invocations firing close together could both decide the same ignore pattern was missing and both append it. It (and the installer's own `scripts/lib/gitignore.js` writer, which shares the identical shape) now collapses exact-duplicate non-comment/non-blank lines on every write, so a duplicate from a lost race self-heals on the next invocation instead of accumulating.
+
 ---
 ## [0.2.0] - 2026-07-23
 

package/build-multi-agent-system/SKILL.md

@@ -1,68 +1,68 @@
----
-name: build-multi-agent-system
-description: 'Deploy a universal, self-adapting Multi-Agent Architecture into any project. It dynamically analyzes the tech stack to scaffold a token-efficient workspace with strict physical boundaries, hybrid SQLite memory, and isomorphic alignment protocols.'
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-# Universal Multi-Agent Workspace Installer
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | Tier 3 task requiring a multi-agent workspace to be scaffolded from scratch; explicit request to initialize a multi-agent system. |
-| **Expected Output** | A scaffolded 6-zone folder structure, a generated `index_memory` script that builds `memory.db` (SQLite relational index), and an immutable `AGENTS.md` router (< 50 lines) at the project root. |
-| **State Mutations** | Creates/rewrites `AGENTS.md`; creates the 6 functional zone directories; creates and runs the memory indexer script; writes `memory.db`. |
-| **Enforcement Gate** | MUST run the generated `index_memory` script once and verify it executes cleanly before the task is considered complete. `AGENTS.md` MUST include a directive forbidding sub-agents from modifying it. |
-
-## Core Principles
-- MUST operate using the cognitive loop: Think > Try > Summarize > Record.
-- [Think] Map the project state before altering it. The architecture must adapt to the project's native ecosystem, not force a rigid template.
-- [Try] Build the architecture incrementally. Ensure all constraints are physically enforced by the file system or explicit router rules.
-- [Summarize] Verify that the cognitive pathways (the 6 functional zones) are clearly isolated and language-appropriate.
-- [Record] Leave behind a robust memory indexer and an immutable `AGENTS.md` router as the permanent handoff.
-
-## Cognitive Foundation (The Meta-Framework)
-- `install-cognitive-os` defines *how an agent thinks*. `self-evolve` defines *how an agent learns*.
-- THIS skill defines **WHERE the agent lives**. It is the physical landing gear.
-- Without a strict folder structure and relational index, a multi-agent team will eventually drown in its own Markdown logs, leading to massive token burn and hallucination.
-- This skill enforces "Physical Isolation of Context" and "Cognitive Metabolism", but adapts its implementation dynamically based on the project's domain (Software, Research, Writing, etc.).
-
-## [State Checkpoint]
-- MUST verify the current working directory is the root of the target project.
-- MUST verify we have read/write access to create directories and scripts.
-
-## [Discovery Phase: Environment Audit]
-1. Tech Stack & Domain Analysis: MUST analyze the project (e.g., read `package.json`, `pyproject.toml`, or general file extensions) to determine the primary language and domain.
-2. Dynamic Role Deduction: MUST deduce the required sub-agent roles from a standard Archetype Pool (e.g., Frontend, Backend, Data, Writer).
-   - *Mandatory Roles:* PM (Coordinator) and Challenger (Alignment Enforcer) MUST always be included.
-
-## [Execution Phase: Structural Scaffolding]
-3. Isomorphic Zone Mapping: MUST implement the "6 Functional Zones", adapting the folder names/paths to the project's ecosystem if necessary (e.g., `docs/`, `.agents/`, `.cursor/`), while preserving their strict semantic purpose:
-   - `[State]`: High-frequency, volatile working state (Max 100 lines).
-   - `[Logs]`: Raw dialogue and verification outputs (Strictly excluded from default PM context).
-   - `[Decisions]`: Distilled Project Memory (ADRs, Read-on-demand via Index).
-   - `[Domain]`: Immutable product vision / core rules.
-   - `[Architecture]`: Immutable technical contracts / style guides.
-   - `[Roles]`: Individual sub-agent system prompts.
-
-## [Execution Phase: Hybrid Memory Implementation]
-4. Polyglot Indexer Generation: MUST generate an `index_memory` script in the project's primary language (e.g., Python, Node.js, Bash) or provide a pure CLI fallback.
-   - The script MUST parse YAML frontmatter/Markdown headers across the documentation zones.
-   - It MUST build a local SQLite database (`memory.db`) to serve as a relational index, enabling low-token historical queries.
-
-## [Execution Phase: The Immutable Router]
-5. Hardcoded Laws: MUST create or rewrite `AGENTS.md` at the project root. This file is the system's brain and must be strictly protected:
-   - It MUST include a directive forbidding sub-agents from modifying it.
-   - It MUST be a lightweight router (< 50 lines).
-   - It MUST define the "Bootstrap Protocol" (Read Payload -> Read State -> Delegate without reading full history).
-   - It MUST enforce "Cognitive Metabolism" (Strict line limits triggering Distillation cycles).
-   - It MUST enforce "Adaptive Alignment" (Path-based escalation matrix invoking the Challenger).
-   - It MUST explicitly state the "Non-blocking Release" rule: agents log subjective reviews asynchronously and never halt execution waiting for human input.
-
-## [Verification Phase]
-6. MUST run the generated `index_memory` script once to initialize the `memory.db` and verify it executes cleanly in the user's environment.
-7. MUST summarize the deployed architecture and the dynamically deduced roles to the user.
-
-[Exit: Await User Instruction]
+---
+name: build-multi-agent-system
+description: 'Deploy a universal, self-adapting Multi-Agent Architecture into any project. It dynamically analyzes the tech stack to scaffold a token-efficient workspace with strict physical boundaries, hybrid SQLite memory, and isomorphic alignment protocols.'
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+# Universal Multi-Agent Workspace Installer
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Tier 3 task requiring a multi-agent workspace to be scaffolded from scratch; explicit request to initialize a multi-agent system. |
+| **Expected Output** | A scaffolded 6-zone folder structure, a generated `index_memory` script that builds `memory.db` (SQLite relational index), and an immutable `AGENTS.md` router (< 50 lines) at the project root. |
+| **State Mutations** | Creates/rewrites `AGENTS.md`; creates the 6 functional zone directories; creates and runs the memory indexer script; writes `memory.db`. |
+| **Enforcement Gate** | MUST run the generated `index_memory` script once and verify it executes cleanly before the task is considered complete. `AGENTS.md` MUST include a directive forbidding sub-agents from modifying it. |
+
+## Core Principles
+- MUST operate using the cognitive loop: Think > Try > Summarize > Record.
+- [Think] Map the project state before altering it. The architecture must adapt to the project's native ecosystem, not force a rigid template.
+- [Try] Build the architecture incrementally. Ensure all constraints are physically enforced by the file system or explicit router rules.
+- [Summarize] Verify that the cognitive pathways (the 6 functional zones) are clearly isolated and language-appropriate.
+- [Record] Leave behind a robust memory indexer and an immutable `AGENTS.md` router as the permanent handoff.
+
+## Cognitive Foundation (The Meta-Framework)
+- `install-cognitive-os` defines *how an agent thinks*. `self-evolve` defines *how an agent learns*.
+- THIS skill defines **WHERE the agent lives**. It is the physical landing gear.
+- Without a strict folder structure and relational index, a multi-agent team will eventually drown in its own Markdown logs, leading to massive token burn and hallucination.
+- This skill enforces "Physical Isolation of Context" and "Cognitive Metabolism", but adapts its implementation dynamically based on the project's domain (Software, Research, Writing, etc.).
+
+## [State Checkpoint]
+- MUST verify the current working directory is the root of the target project.
+- MUST verify we have read/write access to create directories and scripts.
+
+## [Discovery Phase: Environment Audit]
+1. Tech Stack & Domain Analysis: MUST analyze the project (e.g., read `package.json`, `pyproject.toml`, or general file extensions) to determine the primary language and domain.
+2. Dynamic Role Deduction: MUST deduce the required sub-agent roles from a standard Archetype Pool (e.g., Frontend, Backend, Data, Writer).
+   - *Mandatory Roles:* PM (Coordinator) and Challenger (Alignment Enforcer) MUST always be included.
+
+## [Execution Phase: Structural Scaffolding]
+3. Isomorphic Zone Mapping: MUST implement the "6 Functional Zones", adapting the folder names/paths to the project's ecosystem if necessary (e.g., `docs/`, `.agents/`, `.cursor/`), while preserving their strict semantic purpose:
+   - `[State]`: High-frequency, volatile working state (Max 100 lines).
+   - `[Logs]`: Raw dialogue and verification outputs (Strictly excluded from default PM context).
+   - `[Decisions]`: Distilled Project Memory (ADRs, Read-on-demand via Index).
+   - `[Domain]`: Immutable product vision / core rules.
+   - `[Architecture]`: Immutable technical contracts / style guides.
+   - `[Roles]`: Individual sub-agent system prompts.
+
+## [Execution Phase: Hybrid Memory Implementation]
+4. Polyglot Indexer Generation: MUST generate an `index_memory` script in the project's primary language (e.g., Python, Node.js, Bash) or provide a pure CLI fallback.
+   - The script MUST parse YAML frontmatter/Markdown headers across the documentation zones.
+   - It MUST build a local SQLite database (`memory.db`) to serve as a relational index, enabling low-token historical queries.
+
+## [Execution Phase: The Immutable Router]
+5. Hardcoded Laws: MUST create or rewrite `AGENTS.md` at the project root. This file is the system's brain and must be strictly protected:
+   - It MUST include a directive forbidding sub-agents from modifying it.
+   - It MUST be a lightweight router (< 50 lines).
+   - It MUST define the "Bootstrap Protocol" (Read Payload -> Read State -> Delegate without reading full history).
+   - It MUST enforce "Cognitive Metabolism" (Strict line limits triggering Distillation cycles).
+   - It MUST enforce "Adaptive Alignment" (Path-based escalation matrix invoking the Challenger).
+   - It MUST explicitly state the "Non-blocking Release" rule: agents log subjective reviews asynchronously and never halt execution waiting for human input.
+
+## [Verification Phase]
+6. MUST run the generated `index_memory` script once to initialize the `memory.db` and verify it executes cleanly in the user's environment.
+7. MUST summarize the deployed architecture and the dynamically deduced roles to the user.
+
+[Exit: Await User Instruction]

package/create-agent-launcher/SKILL.md

@@ -1,48 +1,48 @@
----
-name: create-agent-launcher
-description: Sub-agent generator for orchestrating multi-domain specialized agents to avoid token waste.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-# Create Agent Launcher
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | Invoked by `fable-mode` for Tier 3 tasks needing domain-specific division of labor — task complexity exceeds a single context, or spans disjoint tech stacks. |
-| **Expected Output** | One or more sub-agents launched with an explicit persona, a resource-isolated scope (only the file paths relevant to their task), and a model-tier assignment (Haiku / Sonnet / Opus by sub-task complexity). |
-| **State Mutations** | None directly to files — mutates the active session's delegation state (which sub-agents are live, what each was briefed to touch). |
-| **Enforcement Gate** | Every sub-agent MUST return a structured handoff report (files modified, new APIs/interfaces exposed, downstream concerns) before its output is trusted. Creating a sub-agent is **PROHIBITED** if the task fits in ≤2 files / ≤300 lines — resolve directly under `tdd` instead. |
-
-This skill is automatically invoked by `fable-mode` when handling Tier 3 (Macro Tasks) that require domain-specific division of labor.
-Its purpose is to avoid wasting Tokens and losing attention caused by a single General Agent handling everything, by creating highly specialized Sub-agents to solve complex problems.
-
-## 1. Responsibilities and Use Cases
-Launch this skill when the task complexity exceeds what a single context can handle, or when switching between entirely different tech stacks is necessary (e.g., the same feature requires modifying Postgres Schema, Node.js Backend, and React Frontend).
-
-## 2. Standard Procedure for Creating Sub-agents
-
-### Step 1: Persona Definition
-Before calling a secondary model (or instantiating a new Agent), you MUST explicitly give it a specialized persona definition.
-- **Bad Example**: "Help me fix these frontend and backend codes."
-- **Good Example**: "You are now a Senior Database Architect. Your sole task is to optimize the indexing and write performance of the User Table for this requirement. You are PROHIBITED from modifying any frontend code."
-
-### Step 2: Resource Isolation
-- Limit the Sub-agent's field of view. Only provide it with the file paths and Context necessary to complete its task.
-- Do not feed the entire project structure to an Agent that is only responsible for writing a single SQL Migration.
-
-### Step 3: Model Selection Strategy
-Based on the complexity of the sub-task, select the most cost-effective model (assuming the underlying Harness supports switching):
-- **Exploration/Finding Files/Simple Edits**: Assign to a fast, low-cost small model (like Claude 3.5 Haiku).
-- **Multi-file Implementation/General Logic**: Assign to a medium-sized main model (like Claude 3.5 Sonnet).
-- **Extremely Complex Algorithms/Security Audits**: Assign to a deep reasoning model (like Claude 3 Opus).
-
-### Step 4: Handoff Contract
-- Tell the Sub-agent that once it completes its task, it MUST output a report in a specific format to the main Orchestrator (`fable-mode`).
-- The report MUST include: which files were modified, what new APIs/interfaces were exposed, and what downstream Agents need to pay attention to.
-
-## 3. Foolproofing Mechanism
-- Avoid over-segmentation: If a cross-stack task can be resolved within 2 files and 300 lines of code, establishing a Sub-agent is **PROHIBITED**. Resolve it directly in the current Context using `tdd` mode.
-- Sub-agents are also Agents, equally bound by the `install-cognitive-os` physical laws and the `zoom-out` circuit breaker.
+---
+name: create-agent-launcher
+description: Sub-agent generator for orchestrating multi-domain specialized agents to avoid token waste.
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+# Create Agent Launcher
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Invoked by `fable-mode` for Tier 3 tasks needing domain-specific division of labor — task complexity exceeds a single context, or spans disjoint tech stacks. |
+| **Expected Output** | One or more sub-agents launched with an explicit persona, a resource-isolated scope (only the file paths relevant to their task), and a model-tier assignment (Haiku / Sonnet / Opus by sub-task complexity). |
+| **State Mutations** | None directly to files — mutates the active session's delegation state (which sub-agents are live, what each was briefed to touch). |
+| **Enforcement Gate** | Every sub-agent MUST return a structured handoff report (files modified, new APIs/interfaces exposed, downstream concerns) before its output is trusted. Creating a sub-agent is **PROHIBITED** if the task fits in ≤2 files / ≤300 lines — resolve directly under `tdd` instead. |
+
+This skill is automatically invoked by `fable-mode` when handling Tier 3 (Macro Tasks) that require domain-specific division of labor.
+Its purpose is to avoid wasting Tokens and losing attention caused by a single General Agent handling everything, by creating highly specialized Sub-agents to solve complex problems.
+
+## 1. Responsibilities and Use Cases
+Launch this skill when the task complexity exceeds what a single context can handle, or when switching between entirely different tech stacks is necessary (e.g., the same feature requires modifying Postgres Schema, Node.js Backend, and React Frontend).
+
+## 2. Standard Procedure for Creating Sub-agents
+
+### Step 1: Persona Definition
+Before calling a secondary model (or instantiating a new Agent), you MUST explicitly give it a specialized persona definition.
+- **Bad Example**: "Help me fix these frontend and backend codes."
+- **Good Example**: "You are now a Senior Database Architect. Your sole task is to optimize the indexing and write performance of the User Table for this requirement. You are PROHIBITED from modifying any frontend code."
+
+### Step 2: Resource Isolation
+- Limit the Sub-agent's field of view. Only provide it with the file paths and Context necessary to complete its task.
+- Do not feed the entire project structure to an Agent that is only responsible for writing a single SQL Migration.
+
+### Step 3: Model Selection Strategy
+Based on the complexity of the sub-task, select the most cost-effective model (assuming the underlying Harness supports switching):
+- **Exploration/Finding Files/Simple Edits**: Assign to a fast, low-cost small model (like Claude 3.5 Haiku).
+- **Multi-file Implementation/General Logic**: Assign to a medium-sized main model (like Claude 3.5 Sonnet).
+- **Extremely Complex Algorithms/Security Audits**: Assign to a deep reasoning model (like Claude 3 Opus).
+
+### Step 4: Handoff Contract
+- Tell the Sub-agent that once it completes its task, it MUST output a report in a specific format to the main Orchestrator (`fable-mode`).
+- The report MUST include: which files were modified, what new APIs/interfaces were exposed, and what downstream Agents need to pay attention to.
+
+## 3. Foolproofing Mechanism
+- Avoid over-segmentation: If a cross-stack task can be resolved within 2 files and 300 lines of code, establishing a Sub-agent is **PROHIBITED**. Resolve it directly in the current Context using `tdd` mode.
+- Sub-agents are also Agents, equally bound by the `install-cognitive-os` physical laws and the `zoom-out` circuit breaker.

package/docs/workflows/build-multi-agent-system.md

@@ -1,62 +1,62 @@
-# Workflow: Build Multi-Agent System
-
-> Deploys an industrial-grade, self-adapting Multi-Agent Workspace architecture, scaffolding physical boundaries and relational SQLite context indexes.
-
----
-
-## 1. Skill Behavior Workflow
-
-This section visualizes how the `build-multi-agent-system` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
-
-```mermaid
-graph TD
-  Start([Workspace Scaffolding Requested]) --> DiscoverStack["Analyze project package.json/runtimes"]
-  DiscoverStack --> DeduceRoles["Deduce required specialist roles & PM / Challenger"]
-  DeduceRoles --> ScaffoldZones["Scaffold '6 Functional Zones' directories: State, Decisions, Logs, etc."]
-  ScaffoldZones --> GenMemoryIndexer["Generate language-appropriate index_memory script"]
-  GenMemoryIndexer --> GenAgentsRouter["Generate AGENTS.md routing brain"]
-  GenAgentsRouter --> RunIndexer["Execute memory indexer to initialize local memory.db SQLite index"]
-  RunIndexer --> VerifyExecution["Verify schema, tables, and execution status"]
-  VerifyExecution --> End([Scaffolding and hybrid relational memory initialized])
-```
-
----
-
-## 2. Triggering and Routing Path
-
-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.
-
-```mermaid
-graph LR
-  Router["harness-everything / tier-router.js"] -->|Keyword: agent / workspace / multi-agent| BMAS["build-multi-agent-system / SKILL.md"]
-  BMAS -->|Works hand-in-hand with spawning tool| CAL["create-agent-launcher / SKILL.md"]
-  BMAS -->|Stores architectural contracts in| GWD["grill-with-docs / SKILL.md"]
-  BMAS -->|Initializes memory rules via| Evolve["self-evolve / SKILL.md"]
-```
-
----
-
-## 3. Real-World Use Case Flowchart
-
-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.
-
-```mermaid
-graph TD
-  Start["User asks to set up an AI developer workspace for a Python backend"] --> Trigger["Invoke build-multi-agent-system"]
-  Trigger --> DetectStack["Identifies Python/Django stack"]
-  DetectStack --> BuildDirs["Creates .agents/, docs/decisions/, docs/architecture/, state/ folders"]
-  BuildDirs --> WriteIndexer["Creates python indexer script parsing markdown frontmatter"]
-  WriteIndexer --> CreateDB["Runs indexer, generating SQLite memory.db schema"]
-  CreateDB --> WriteAgentsRouter["Generates AGENTS.md with routing matrix"]
-  WriteAgentsRouter --> Done([Professional Multi-Agent Workspace deployed and indexed])
-```
-
----
-
-## 4. Verification Check
-
-To ensure that the `build-multi-agent-system` skill is operating in strict compliance with Harness OS design laws, verify the following:
-
-- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
-- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
-- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
+# Workflow: Build Multi-Agent System
+
+> Deploys an industrial-grade, self-adapting Multi-Agent Workspace architecture, scaffolding physical boundaries and relational SQLite context indexes.
+
+---
+
+## 1. Skill Behavior Workflow
+
+This section visualizes how the `build-multi-agent-system` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
+
+```mermaid
+graph TD
+  Start([Workspace Scaffolding Requested]) --> DiscoverStack["Analyze project package.json/runtimes"]
+  DiscoverStack --> DeduceRoles["Deduce required specialist roles & PM / Challenger"]
+  DeduceRoles --> ScaffoldZones["Scaffold '6 Functional Zones' directories: State, Decisions, Logs, etc."]
+  ScaffoldZones --> GenMemoryIndexer["Generate language-appropriate index_memory script"]
+  GenMemoryIndexer --> GenAgentsRouter["Generate AGENTS.md routing brain"]
+  GenAgentsRouter --> RunIndexer["Execute memory indexer to initialize local memory.db SQLite index"]
+  RunIndexer --> VerifyExecution["Verify schema, tables, and execution status"]
+  VerifyExecution --> End([Scaffolding and hybrid relational memory initialized])
+```
+
+---
+
+## 2. Triggering and Routing Path
+
+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.
+
+```mermaid
+graph LR
+  Router["harness-everything / tier-router.js"] -->|Keyword: agent / workspace / multi-agent| BMAS["build-multi-agent-system / SKILL.md"]
+  BMAS -->|Works hand-in-hand with spawning tool| CAL["create-agent-launcher / SKILL.md"]
+  BMAS -->|Stores architectural contracts in| GWD["grill-with-docs / SKILL.md"]
+  BMAS -->|Initializes memory rules via| Evolve["self-evolve / SKILL.md"]
+```
+
+---
+
+## 3. Real-World Use Case Flowchart
+
+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.
+
+```mermaid
+graph TD
+  Start["User asks to set up an AI developer workspace for a Python backend"] --> Trigger["Invoke build-multi-agent-system"]
+  Trigger --> DetectStack["Identifies Python/Django stack"]
+  DetectStack --> BuildDirs["Creates .agents/, docs/decisions/, docs/architecture/, state/ folders"]
+  BuildDirs --> WriteIndexer["Creates python indexer script parsing markdown frontmatter"]
+  WriteIndexer --> CreateDB["Runs indexer, generating SQLite memory.db schema"]
+  CreateDB --> WriteAgentsRouter["Generates AGENTS.md with routing matrix"]
+  WriteAgentsRouter --> Done([Professional Multi-Agent Workspace deployed and indexed])
+```
+
+---
+
+## 4. Verification Check
+
+To ensure that the `build-multi-agent-system` skill is operating in strict compliance with Harness OS design laws, verify the following:
+
+- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
+- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
+- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.

package/docs/workflows/create-agent-launcher.md

@@ -1,62 +1,62 @@
-# Workflow: Create Agent Launcher
-
-> Sub-agent generator for orchestrating multi-domain specialized agents to avoid token context waste and preserve developer focus.
-
----
-
-## 1. Skill Behavior Workflow
-
-This section visualizes how the `create-agent-launcher` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
-
-```mermaid
-graph TD
-  Start([Complex Task Demands Division of Labor]) --> AssessComplexity{Too complex for 1 context?}
-  AssessComplexity -->|No| Reject["Reject creation, resolve in current context via TDD"]
-  AssessComplexity -->|Yes| DefinePersona["Define highly restrictive specialized sub-agent persona"]
-  DefinePersona --> IsolateResources["Map exact, minimum file paths needed for sub-task"]
-  IsolateResources --> SelectModel["Select cost-effective model based on task weight"]
-  SelectModel --> WriteHandoff["Define strict input/output contract for sub-agent return report"]
-  WriteHandoff --> LaunchAgent["Launch specialized sub-agent under isolated sandbox"]
-  LaunchAgent --> MergeReport["Validate and merge sub-agent findings into main orchestrator"]
-  MergeReport --> End([Sub-agent work verified and closed])
-```
-
----
-
-## 2. Triggering and Routing Path
-
-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.
-
-```mermaid
-graph LR
-  Router["harness-everything / tier-router.js"] -->|Requires agent specialization| CAL["create-agent-launcher / SKILL.md"]
-  CAL -->|Spawns agent on scaffolding provided by| BMAS["build-multi-agent-system / SKILL.md"]
-  CAL -->|Plans agent tasks using macro planner| Fable["fable-mode / SKILL.md"]
-  CAL -->|Limits child memory to prevent bloat via| FD["fable-discipline / SKILL.md"]
-```
-
----
-
-## 3. Real-World Use Case Flowchart
-
-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.
-
-```mermaid
-graph TD
-  Start["Refactoring task involves SQL Schema migrations, Node endpoints, and React forms"] --> Trigger["create-agent-launcher skill executed"]
-  Trigger --> SpawnDB["Spawn 'Database Architect': Only views 'schema.sql' and outputs raw SQL migration"]
-  Trigger --> SpawnFE["Spawn 'Frontend Specialist': Only views 'Login.tsx' and outputs validated form code"]
-  SpawnDB & SpawnFE --> Collect["Main orchestrator receives isolated, highly focused diff reports from both"]
-  Collect --> Merge["Integrate changes and run integration testing"]
-  Merge --> Done([Complex task completed with 70% lower token cost and zero context confusion])
-```
-
----
-
-## 4. Verification Check
-
-To ensure that the `create-agent-launcher` skill is operating in strict compliance with Harness OS design laws, verify the following:
-
-- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
-- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
-- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
+# Workflow: Create Agent Launcher
+
+> Sub-agent generator for orchestrating multi-domain specialized agents to avoid token context waste and preserve developer focus.
+
+---
+
+## 1. Skill Behavior Workflow
+
+This section visualizes how the `create-agent-launcher` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
+
+```mermaid
+graph TD
+  Start([Complex Task Demands Division of Labor]) --> AssessComplexity{Too complex for 1 context?}
+  AssessComplexity -->|No| Reject["Reject creation, resolve in current context via TDD"]
+  AssessComplexity -->|Yes| DefinePersona["Define highly restrictive specialized sub-agent persona"]
+  DefinePersona --> IsolateResources["Map exact, minimum file paths needed for sub-task"]
+  IsolateResources --> SelectModel["Select cost-effective model based on task weight"]
+  SelectModel --> WriteHandoff["Define strict input/output contract for sub-agent return report"]
+  WriteHandoff --> LaunchAgent["Launch specialized sub-agent under isolated sandbox"]
+  LaunchAgent --> MergeReport["Validate and merge sub-agent findings into main orchestrator"]
+  MergeReport --> End([Sub-agent work verified and closed])
+```
+
+---
+
+## 2. Triggering and Routing Path
+
+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.
+
+```mermaid
+graph LR
+  Router["harness-everything / tier-router.js"] -->|Requires agent specialization| CAL["create-agent-launcher / SKILL.md"]
+  CAL -->|Spawns agent on scaffolding provided by| BMAS["build-multi-agent-system / SKILL.md"]
+  CAL -->|Plans agent tasks using macro planner| Fable["fable-mode / SKILL.md"]
+  CAL -->|Limits child memory to prevent bloat via| FD["fable-discipline / SKILL.md"]
+```
+
+---
+
+## 3. Real-World Use Case Flowchart
+
+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.
+
+```mermaid
+graph TD
+  Start["Refactoring task involves SQL Schema migrations, Node endpoints, and React forms"] --> Trigger["create-agent-launcher skill executed"]
+  Trigger --> SpawnDB["Spawn 'Database Architect': Only views 'schema.sql' and outputs raw SQL migration"]
+  Trigger --> SpawnFE["Spawn 'Frontend Specialist': Only views 'Login.tsx' and outputs validated form code"]
+  SpawnDB & SpawnFE --> Collect["Main orchestrator receives isolated, highly focused diff reports from both"]
+  Collect --> Merge["Integrate changes and run integration testing"]
+  Merge --> Done([Complex task completed with 70% lower token cost and zero context confusion])
+```
+
+---
+
+## 4. Verification Check
+
+To ensure that the `create-agent-launcher` skill is operating in strict compliance with Harness OS design laws, verify the following:
+
+- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
+- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
+- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.