harness-everything 0.2.1 → 0.2.2

package/README.md

@@ -118,7 +118,7 @@ Harness operates through five core cognitive concepts:
 
 | AI Agent Tool | Integration Method | Local Target Location | Enforcement |
 |---|---|---|---|
-| **Claude Code** | Native Lifecycle Hooks (`PreToolUse`, `PostToolUse`, `SessionStart`) | `.claude/settings.json` (project) / `~/.claude/settings.json` (user) | **Hard** — hooks can block a tool call (`exit(2)`) |
+| **Claude Code** | Native Lifecycle Hooks (`PreToolUse`, `PostToolUse`, `SessionStart`) | `.claude/settings.json` (project) / `~/.claude/settings.json` (user)<br>*.claude/skills/* (Project Skills) / *~/.claude/skills/* (Global Skills) | **Hard** — hooks can block a tool call (`exit(2)`) |
 | **Cursor** | Native Project Rules | `.cursorrules` | Advisory only |
 | **Copilot Chat** | Custom Instructions | `.github/copilot-instructions.md` | Advisory only |
 | **Codex** | Custom Instructions (`AGENTS.md`, not `.codex/config.toml` — that file controls CLI/sandbox behavior, not prompt content) | `AGENTS.md` | Advisory only |

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/architecture.md

@@ -60,10 +60,10 @@ Harness is designed to align with the unique capabilities of various AI IDEs and
 
 **Placement rule:** a platform's own native file/folder (`.claude/settings.json`, `.cursorrules`, `.cursor/skills/`, …) is never moved — it lives exactly where that platform expects it. Anything Harness itself needs that has no native home converges into one exclusively-owned subfolder per platform: `<platform-dir>/harness-everything/`. Nothing else ever creates a directory literally named `harness-everything`, which is what lets the installer add or remove it as a unit — including on uninstall — without touching anything else already in that platform's directory (another tool's files, or skills the user installed by hand).
 
-**Runtime state vs. installed skill content:** `<platform-dir>/harness-everything/` holds two kinds of content, kept apart by subfolder. `skills/` — Claude only, since Claude has no native project-skill directory to piggyback on — is the installer's local skill-copy target (see `scripts/lib/skills.js`'s `getInstalledSkills`, which is manifest-tracked, not a blind directory scan) — real files, not cache. Every other platform's skills stay at that platform's own established location (`.cursor/skills`, `.github/skills`, `.codex/skills`, `.continue/skills`) and are never moved. `state/` is pure runtime state: hook JSON, circuit-breaker counters, handoff/verification timestamps. It's scoped per Claude Code `session_id` under `sessions/<id>/` so two sessions open on the same repo never share (and stomp) each other's edit/verify timestamps or breaker counts — invocations with no `session_id` (manual runs, tests) fall into a fixed `sessions/default/` bucket. Both are gitignored and safe to delete; `state/` regenerates itself from nothing but in-session state (losing it mid-session just clears breaker/verification history), while deleting `skills/` requires re-running the installer to restore the copied skill files. A `manifest.json` sibling at the `harness-everything/` root records exactly what the installer put where, per platform, so uninstall never has to guess.
+**Runtime state vs. installed skill content:** `<platform-dir>/harness-everything/` holds runtime state (pure runtime state: hook JSON, circuit-breaker counters, handoff/verification timestamps) kept apart in the `state/` subfolder. On the other hand, the actual installed skills go to each platform's native/expected skills directories (e.g., `.claude/skills/` for Claude, `.cursor/skills/` for Cursor, `.github/skills/` for Copilot, `.codex/skills/` for Codex, `.continue/skills/` for Continue, and `~/.agents/skills/` or `~/.claude/skills/` for Global scope) where they are dynamically discovered and processed. A `manifest.json` under `<platform-dir>/harness-everything/` (or global home) records exactly what the installer put where, per platform, so uninstall can match against the manifest files and perform precise cleanup without guessing. Both runtime state and skills directories are gitignored.
 
 ### 1. Claude Code (hook-enforced)
-Our installer configures native lifecycle hooks inside `.claude/settings.json`:
+Our installer configures native lifecycle hooks inside `.claude/settings.json`, and places project-level skills inside the native `.claude/skills/` directory where Claude Code natively auto-discovers and registers them.
 *   `SessionStart`: Runs `bootstrap.js` to restore previous handoffs, check environment variables, and initialize session state.
 *   `PreToolUse`: Triggers `rule-of-3.js`, `boundary-guard.js`, `depth-guard.js`, `context-compact.js`, and `subagent-scope-guard.js` to intercept tool invocations before they run, and can actually block one (`exit(2)`) — e.g. the Rule of 3 circuit breaker.
 *   `PostToolUse`: Records tool outcomes, updates the persistent transaction log (WAL) via `state-persist.js`, tracks repeat failures, and can only add advisory context back (the tool already ran; nothing here blocks it).

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.