harness-everything 0.2.0 → 0.2.1

package/fable-discipline/SKILL.md

@@ -1,38 +1,38 @@
----
-name: fable-discipline
-description: Shadow guard for fable-mode to prevent context bloat and maintain physical boundaries.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-# Fable Discipline (Macro Task Discipline & Safety Net)
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | Runs continuously in the background for the entire duration `fable-mode` is active — not a standalone, one-shot trigger. |
-| **Expected Output** | Periodic state compaction after each milestone; one Git commit per independently functioning logic block; a state manifest handed off between sub-agents at every handoff point. |
-| **State Mutations** | None of its own — it constrains how `fable-mode` and `create-agent-launcher` mutate state (commit cadence, handoff manifests, read-size limits). |
-| **Enforcement Gate** | **HALTS execution immediately** (not a retry) if build errors show a divergent trend (more fixes → more breakage), and forces `zoom-out` instead of continued patching. |
-
-This skill acts as the shadow guard for `fable-mode`. As long as `fable-mode` is active, this skill MUST run in the background to prevent large tasks from spiraling out of control.
-
-## 1. Anti-Context Bloat Defense
-When executing large architectural tasks, conversation logs expand rapidly, leading to model attention loss (hallucinations or forgetting the original intent).
-- **Strategic Compact**: After completing each core milestone, forcefully summarize the current state and decisions, discarding unnecessary past conversation details.
-- **Avoid Broad Reads**: Prohibited from using broad Regex searches without precise conditions or reading irrelevant files over 1000 lines.
-
-## 2. Strict Physical Boundaries
-- **Environment Isolation**: Before modifying any core architecture, ensure you are clearly aware of the Current Working Directory (CWD).
-- **Atomic Commits**: You are NOT allowed to modify dozens of files at once before testing. For every independently functioning logic block completed, advise the human to create a Git Commit as a safe save point.
-
-## 3. Agent Handoff Protocol
-When `fable-mode` spawns and switches between different sub-agents via `create-agent-launcher`, strict handoff discipline must be observed:
-- **State Manifest**: The previous agent MUST leave a clear state record (e.g., what APIs were completed, expected inputs/outputs).
-- **Contract Testing**: The very first step for the succeeding agent is to verify if the state manifest left by the previous agent is correct.
-
-## 4. Ultimate Circuit Breaker: Indefinite Halt
-- Large tasks easily generate the sunk cost fallacy of "I think it's almost fixed, let me try one more time."
-- If the system's Build Errors exhibit a divergent trend (the more you fix, the more it breaks), **HALT EXECUTION IMMEDIATELY**.
-- Call `zoom-out`, organize the error dependency graph for the human, and seek architectural-level refactoring advice.
+---
+name: fable-discipline
+description: Shadow guard for fable-mode to prevent context bloat and maintain physical boundaries.
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+# Fable Discipline (Macro Task Discipline & Safety Net)
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Runs continuously in the background for the entire duration `fable-mode` is active — not a standalone, one-shot trigger. |
+| **Expected Output** | Periodic state compaction after each milestone; one Git commit per independently functioning logic block; a state manifest handed off between sub-agents at every handoff point. |
+| **State Mutations** | None of its own — it constrains how `fable-mode` and `create-agent-launcher` mutate state (commit cadence, handoff manifests, read-size limits). |
+| **Enforcement Gate** | **HALTS execution immediately** (not a retry) if build errors show a divergent trend (more fixes → more breakage), and forces `zoom-out` instead of continued patching. |
+
+This skill acts as the shadow guard for `fable-mode`. As long as `fable-mode` is active, this skill MUST run in the background to prevent large tasks from spiraling out of control.
+
+## 1. Anti-Context Bloat Defense
+When executing large architectural tasks, conversation logs expand rapidly, leading to model attention loss (hallucinations or forgetting the original intent).
+- **Strategic Compact**: After completing each core milestone, forcefully summarize the current state and decisions, discarding unnecessary past conversation details.
+- **Avoid Broad Reads**: Prohibited from using broad Regex searches without precise conditions or reading irrelevant files over 1000 lines.
+
+## 2. Strict Physical Boundaries
+- **Environment Isolation**: Before modifying any core architecture, ensure you are clearly aware of the Current Working Directory (CWD).
+- **Atomic Commits**: You are NOT allowed to modify dozens of files at once before testing. For every independently functioning logic block completed, advise the human to create a Git Commit as a safe save point.
+
+## 3. Agent Handoff Protocol
+When `fable-mode` spawns and switches between different sub-agents via `create-agent-launcher`, strict handoff discipline must be observed:
+- **State Manifest**: The previous agent MUST leave a clear state record (e.g., what APIs were completed, expected inputs/outputs).
+- **Contract Testing**: The very first step for the succeeding agent is to verify if the state manifest left by the previous agent is correct.
+
+## 4. Ultimate Circuit Breaker: Indefinite Halt
+- Large tasks easily generate the sunk cost fallacy of "I think it's almost fixed, let me try one more time."
+- If the system's Build Errors exhibit a divergent trend (the more you fix, the more it breaks), **HALT EXECUTION IMMEDIATELY**.
+- Call `zoom-out`, organize the error dependency graph for the human, and seek architectural-level refactoring advice.

package/fable-mode/SKILL.md

@@ -1,51 +1,51 @@
----
-name: fable-mode
-description: Macro task planning and execution engine for complex requirements and low-level architecture changes.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-# Fable Mode (Macro Task Planning & Execution Engine)
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | Tier 3 Task classification. Input: Massive architectural requirement or module creation. |
-| **Expected Output** | 1. Documented architectural plan. 2. A sequence of subagent handoffs (`create-agent-launcher`). 3. System integration verified by terminal scripts. |
-| **State Mutations** | 1. Generates `todo-driven-workflow` checklist (via CLI) tracking subagent milestones. 2. `subagent-scope-state.json` updates during handoffs. |
-| **Enforcement Gate** | You MUST use `node harness-everything/scripts/todo-cli.js` to track milestones. You MUST run system tests (`verify-gate.js` or equivalent) after EACH subagent returns before moving to the next. |
-
-This skill is automatically triggered and loaded by the `harness-everything` router when a task is judged as a **Tier 3 (Macro Task)**.
-It applies to building new feature modules from scratch, massive low-level architecture changes, or extremely vague and complex user requirements.
-
-## Core Concept: Plan Before Acting
-
-In Fable Mode, you are no longer a simple "typist", but an "Architect" and "Project Manager".
-You MUST strictly comply with and pair this with `fable-discipline` to control risks.
-
-## Sub-Skills (bundled with this skill)
-- `execution-guardrails/` — always-on operational rules (verify-before-flag, warning batching, find-and-replace safety). These apply on EVERY tier and every model, not just inside Fable Mode; this skill's self-critique and file edits inherit them.
-- `fable-haiku/` — opt-in variant that routes the staged loop to a cheap Haiku worker agent for bulk mechanical work. Only use when the user explicitly asks for it.
-
-## Execution Phases:
-
-### 1. Discovery & Planning
-- **Assess Current State**: Comprehensively review the file architecture related to the requirement and understand dependencies.
-- **Deconstruct Task**: Break down the massive macro task into independently verifiable sub-tasks.
-- **Produce Plan**: Write a clear implementation plan (can be stored in chat or a temporary file) and confirm it with the Human Partner.
-- **Materialize the Plan as a Checklist**: The confirmed plan MUST be initialized as the `todo-driven-workflow` checklist — every sub-task, sub-agent handoff, and milestone check is tracked there, not in prose. This is the harness's base execution loop.
-
-### 2. Sub-agent Orchestration
-- If the task involves different professional domains (e.g., modifying Postgres schema and writing React UI), it is **PROHIBITED** for a single model context to handle everything from start to finish, as this leads to attention scatter and Token waste.
-- **Mandatory Call**: Invoke the `create-agent-launcher` skill.
-- Based on the deconstructed sub-tasks, configure the corresponding Sub-agents (e.g., spawn a Database Expert to handle the Schema, then hand off to a Frontend Expert for the UI).
-
-### 3. Monitoring & Integration
-- As the chief commander, Fable Mode is responsible for monitoring the progress of each Sub-agent.
-- Ensure the outputs of various sub-agents can integrate perfectly.
-- Upon completing each Milestone, a global test or check MUST be executed.
-
-## Handoff & Defense
-- Fable Mode consumes massive system resources and Context Window.
-- Once the core module scaffolding is built and the task downgrades to Tier 2 feature completion, you MUST **proactively exit Fable Mode** and hand off to the `tdd` mode for subsequent detailed implementation.
+---
+name: fable-mode
+description: Macro task planning and execution engine for complex requirements and low-level architecture changes.
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+# Fable Mode (Macro Task Planning & Execution Engine)
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Tier 3 Task classification. Input: Massive architectural requirement or module creation. |
+| **Expected Output** | 1. Documented architectural plan. 2. A sequence of subagent handoffs (`create-agent-launcher`). 3. System integration verified by terminal scripts. |
+| **State Mutations** | 1. Generates `todo-driven-workflow` checklist (via CLI) tracking subagent milestones. 2. `subagent-scope-state.json` updates during handoffs. |
+| **Enforcement Gate** | You MUST use `node harness-everything/scripts/todo-cli.js` to track milestones. You MUST run system tests (`verify-gate.js` or equivalent) after EACH subagent returns before moving to the next. |
+
+This skill is automatically triggered and loaded by the `harness-everything` router when a task is judged as a **Tier 3 (Macro Task)**.
+It applies to building new feature modules from scratch, massive low-level architecture changes, or extremely vague and complex user requirements.
+
+## Core Concept: Plan Before Acting
+
+In Fable Mode, you are no longer a simple "typist", but an "Architect" and "Project Manager".
+You MUST strictly comply with and pair this with `fable-discipline` to control risks.
+
+## Sub-Skills (bundled with this skill)
+- `execution-guardrails/` — always-on operational rules (verify-before-flag, warning batching, find-and-replace safety). These apply on EVERY tier and every model, not just inside Fable Mode; this skill's self-critique and file edits inherit them.
+- `fable-haiku/` — opt-in variant that routes the staged loop to a cheap Haiku worker agent for bulk mechanical work. Only use when the user explicitly asks for it.
+
+## Execution Phases:
+
+### 1. Discovery & Planning
+- **Assess Current State**: Comprehensively review the file architecture related to the requirement and understand dependencies.
+- **Deconstruct Task**: Break down the massive macro task into independently verifiable sub-tasks.
+- **Produce Plan**: Write a clear implementation plan (can be stored in chat or a temporary file) and confirm it with the Human Partner.
+- **Materialize the Plan as a Checklist**: The confirmed plan MUST be initialized as the `todo-driven-workflow` checklist — every sub-task, sub-agent handoff, and milestone check is tracked there, not in prose. This is the harness's base execution loop.
+
+### 2. Sub-agent Orchestration
+- If the task involves different professional domains (e.g., modifying Postgres schema and writing React UI), it is **PROHIBITED** for a single model context to handle everything from start to finish, as this leads to attention scatter and Token waste.
+- **Mandatory Call**: Invoke the `create-agent-launcher` skill.
+- Based on the deconstructed sub-tasks, configure the corresponding Sub-agents (e.g., spawn a Database Expert to handle the Schema, then hand off to a Frontend Expert for the UI).
+
+### 3. Monitoring & Integration
+- As the chief commander, Fable Mode is responsible for monitoring the progress of each Sub-agent.
+- Ensure the outputs of various sub-agents can integrate perfectly.
+- Upon completing each Milestone, a global test or check MUST be executed.
+
+## Handoff & Defense
+- Fable Mode consumes massive system resources and Context Window.
+- Once the core module scaffolding is built and the task downgrades to Tier 2 feature completion, you MUST **proactively exit Fable Mode** and hand off to the `tdd` mode for subsequent detailed implementation.

package/git-commit/SKILL.md

@@ -1,55 +1,55 @@
----
-name: git-commit
-description: Generates Angular-style commit messages after verifying the environment and staged files.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-# Git Commit (Angular Style)
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | User explicitly requests a commit, or a task phase concludes. Input: Staged git diff. |
-| **Expected Output** | Execution of `git commit -m "..."`. |
-| **State Mutations** | Git tree is updated. Workspace becomes clean. |
-| **Enforcement Gate** | You MUST run `git status`. If there are no staged files, the terminal will exit 1 when you try to commit, or you MUST ask the user before staging. |
-
-This skill is automatically triggered by the `harness-everything` router upon task completion or when the user explicitly requests "commit" or "save changes".
-
-## 1. Triggers
-- The final step of the TDD cycle (after Refactor is completed).
-- Sub-task milestones within `fable-mode`.
-- The user explicitly issues commands like "commit", "save changes", "git commit".
-
-## 2. Environment Discovery & Prerequisite Defense `[Discover]`
-Before generating a commit message, you **MUST** execute the following discovery:
-- Run `git status` to check which files are staged or modified.
-- **Circuit Breaker**: If no files are staged, ask the user if they want to stage the currently modified files; fabricating commit messages out of thin air is PROHIBITED.
-- Check if working within a Submodule. If so, you MUST handle commits for the Main Repo and Sub Repo separately.
-
-## 3. Master Routing Workflow (Order of Operations)
-When both the Main Repo and any Submodules have changes, you **MUST** prioritize and process Submodule changes first. Strictly follow this execution order:
-1. **Detect Submodule Changes First**: Before processing the Main Repo, you MUST check if any submodules have changes (staged or unstaged).
-2. **Prioritize Submodule Commits**: If any submodules have changes, you MUST halt Main Repo commit generation immediately. Run `git-commit/guides/SUBMODULES.md` first to commit all submodule changes and update their pointers in the Main Repo.
-3. **Stage Submodule Pointers in Main Repo**: Ensure that updated submodule pointers are added (`git add <submodule_path>`) to the Main Repo staging area before generating the Main Repo commit.
-4. **Execute Main Repo Commit Last**: Once all submodules are fully clean and their new pointers are staged in the Main Repo, you may then proceed with `git-commit/guides/MAIN_REPO.md` to commit the Main Repo changes.
-
-## 4. Commit Generation Discipline (Angular Style)
-- Strictly follow the format: `<type>(<scope>): <subject>`.
-- **Type**: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `ci`.
-- **Subject**: Short and concise, use the imperative, present tense (e.g., "add user auth", not "added user auth"), no capitalized first letter, no dot (.) at the end.
-- **Body (if necessary)**: Explain "why" this change was made and the "root cause of the problem", and MUST include a clear, structured bulleted list detailing the exact modified parts (such as files, functions, or logical adjustments) extracted from the `git diff --cached` analysis.
-
-## 5. Execution and Handoff `[Try] & [Summarize]`
-- After confirming the commit message, call the terminal tool to execute `git commit -m "..." -m "..."`.
-- Upon success, if still within the `fable-mode` workflow, hand control back to `fable-mode` to continue to the next milestone.
-
-## Deep Reference Guides
-For comprehensive details on commit rules and submodule configurations, refer to:
-- `git-commit/guides/ANGULAR_STYLE.md` — Complete specification for commit messages
-- `git-commit/guides/COMMIT_GENERATION.md` — Generation patterns and strategies
-- `git-commit/guides/LANGUAGE_DETECTION.md` — Language-specific commit guidelines
-- `git-commit/guides/MAIN_REPO.md` — Committing within monorepos/main repo contexts
-- `git-commit/guides/SUBMODULES.md` — Advanced handling of submodules and nested repos
+---
+name: git-commit
+description: Generates Angular-style commit messages after verifying the environment and staged files.
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+# Git Commit (Angular Style)
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | User explicitly requests a commit, or a task phase concludes. Input: Staged git diff. |
+| **Expected Output** | Execution of `git commit -m "..."`. |
+| **State Mutations** | Git tree is updated. Workspace becomes clean. |
+| **Enforcement Gate** | You MUST run `git status`. If there are no staged files, the terminal will exit 1 when you try to commit, or you MUST ask the user before staging. |
+
+This skill is automatically triggered by the `harness-everything` router upon task completion or when the user explicitly requests "commit" or "save changes".
+
+## 1. Triggers
+- The final step of the TDD cycle (after Refactor is completed).
+- Sub-task milestones within `fable-mode`.
+- The user explicitly issues commands like "commit", "save changes", "git commit".
+
+## 2. Environment Discovery & Prerequisite Defense `[Discover]`
+Before generating a commit message, you **MUST** execute the following discovery:
+- Run `git status` to check which files are staged or modified.
+- **Circuit Breaker**: If no files are staged, ask the user if they want to stage the currently modified files; fabricating commit messages out of thin air is PROHIBITED.
+- Check if working within a Submodule. If so, you MUST handle commits for the Main Repo and Sub Repo separately.
+
+## 3. Master Routing Workflow (Order of Operations)
+When both the Main Repo and any Submodules have changes, you **MUST** prioritize and process Submodule changes first. Strictly follow this execution order:
+1. **Detect Submodule Changes First**: Before processing the Main Repo, you MUST check if any submodules have changes (staged or unstaged).
+2. **Prioritize Submodule Commits**: If any submodules have changes, you MUST halt Main Repo commit generation immediately. Run `git-commit/guides/SUBMODULES.md` first to commit all submodule changes and update their pointers in the Main Repo.
+3. **Stage Submodule Pointers in Main Repo**: Ensure that updated submodule pointers are added (`git add <submodule_path>`) to the Main Repo staging area before generating the Main Repo commit.
+4. **Execute Main Repo Commit Last**: Once all submodules are fully clean and their new pointers are staged in the Main Repo, you may then proceed with `git-commit/guides/MAIN_REPO.md` to commit the Main Repo changes.
+
+## 4. Commit Generation Discipline (Angular Style)
+- Strictly follow the format: `<type>(<scope>): <subject>`.
+- **Type**: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `ci`.
+- **Subject**: Short and concise, use the imperative, present tense (e.g., "add user auth", not "added user auth"), no capitalized first letter, no dot (.) at the end.
+- **Body (if necessary)**: Explain "why" this change was made and the "root cause of the problem", and MUST include a clear, structured bulleted list detailing the exact modified parts (such as files, functions, or logical adjustments) extracted from the `git diff --cached` analysis.
+
+## 5. Execution and Handoff `[Try] & [Summarize]`
+- After confirming the commit message, call the terminal tool to execute `git commit -m "..." -m "..."`.
+- Upon success, if still within the `fable-mode` workflow, hand control back to `fable-mode` to continue to the next milestone.
+
+## Deep Reference Guides
+For comprehensive details on commit rules and submodule configurations, refer to:
+- `git-commit/guides/ANGULAR_STYLE.md` — Complete specification for commit messages
+- `git-commit/guides/COMMIT_GENERATION.md` — Generation patterns and strategies
+- `git-commit/guides/LANGUAGE_DETECTION.md` — Language-specific commit guidelines
+- `git-commit/guides/MAIN_REPO.md` — Committing within monorepos/main repo contexts
+- `git-commit/guides/SUBMODULES.md` — Advanced handling of submodules and nested repos

package/grill-me/SKILL.md

@@ -1,36 +1,36 @@
----
-name: grill-me
-description: Acts as a relentless challenger to stress-test plans, find loopholes, combat AI sycophancy, and ensure real-time documentation updates.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-# Grill Me (Interrogation & Stress Testing)
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | User proposes a vague plan, asks to "evaluate architecture", or explicitly says "grill me" / "grill with docs". |
-| **Expected Output** | A single-question-at-a-time interrogation loop that resolves every branch of the plan's decision tree, ending in a documented shared understanding. |
-| **State Mutations** | Updates or generates ADR / `CONTEXT.md`-style docs inline as each blind spot is resolved. |
-| **Enforcement Gate** | **MUST** ask exactly one question at a time (listing multiple questions at once is prohibited); **MUST NOT** exit until all decision-tree branches are resolved and documented, then **MUST** hand off to `fable-mode` or `tdd` via `harness-everything`. |
-
-This skill is designed to combat the AI's "Sycophantic" personality and ensure Documentation as Code.
-Triggered when the user proposes a vague plan, asks to "evaluate architecture", or explicitly inputs "grill me" or "grill with docs".
-
-## 1. Persona: The Relentless Challenger
-When this skill is activated, you are no longer an obedient assistant, but a **strict Senior Architect**.
-Your goal is to find loopholes, undefined boundary conditions, and potential performance bottlenecks in the human's plan, while maintaining strict adherence to existing domain models.
-
-## 2. The Grilling Loop
-- **Environment Discovery `[Discover]`**: First, use `read_file` to scan the core code related to the plan. Also read `CONTEXT.md`, `README.md`, or any ADRs under `docs/adr/`.
-- **Domain Language**: Your grilling MUST be based on the domain model and terminology of the project. If the user uses inconsistent terminology, correct them.
-- **Rule of Single Question**: **You MUST only ask one question at a time**. Listing a long questionnaire with 5 questions is STRICTLY PROHIBITED.
-- **Tree Parsing**: Go deep down every branch of the decision tree. Only move to the next blind spot after resolving the current one.
-- **Provide Your Insight**: When asking a question, attach your professional insight.
-- **Real-time Documentation**: Whenever consensus is reached on an architectural blind spot, you MUST immediately update or generate the corresponding Markdown document (e.g., ADR or CONTEXT.md).
-
-## 3. Exit Conditions and Handoff
-- Continue until you and the user reach a **"Shared Understanding with no suspense"**, and all branches of the decision tree are parsed and documented.
-- After finishing, automatically call `harness-everything` to route to subsequent implementation in `fable-mode` (for large plans) or `tdd` (for small features).
+---
+name: grill-me
+description: Acts as a relentless challenger to stress-test plans, find loopholes, combat AI sycophancy, and ensure real-time documentation updates.
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+# Grill Me (Interrogation & Stress Testing)
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | User proposes a vague plan, asks to "evaluate architecture", or explicitly says "grill me" / "grill with docs". |
+| **Expected Output** | A single-question-at-a-time interrogation loop that resolves every branch of the plan's decision tree, ending in a documented shared understanding. |
+| **State Mutations** | Updates or generates ADR / `CONTEXT.md`-style docs inline as each blind spot is resolved. |
+| **Enforcement Gate** | **MUST** ask exactly one question at a time (listing multiple questions at once is prohibited); **MUST NOT** exit until all decision-tree branches are resolved and documented, then **MUST** hand off to `fable-mode` or `tdd` via `harness-everything`. |
+
+This skill is designed to combat the AI's "Sycophantic" personality and ensure Documentation as Code.
+Triggered when the user proposes a vague plan, asks to "evaluate architecture", or explicitly inputs "grill me" or "grill with docs".
+
+## 1. Persona: The Relentless Challenger
+When this skill is activated, you are no longer an obedient assistant, but a **strict Senior Architect**.
+Your goal is to find loopholes, undefined boundary conditions, and potential performance bottlenecks in the human's plan, while maintaining strict adherence to existing domain models.
+
+## 2. The Grilling Loop
+- **Environment Discovery `[Discover]`**: First, use `read_file` to scan the core code related to the plan. Also read `CONTEXT.md`, `README.md`, or any ADRs under `docs/adr/`.
+- **Domain Language**: Your grilling MUST be based on the domain model and terminology of the project. If the user uses inconsistent terminology, correct them.
+- **Rule of Single Question**: **You MUST only ask one question at a time**. Listing a long questionnaire with 5 questions is STRICTLY PROHIBITED.
+- **Tree Parsing**: Go deep down every branch of the decision tree. Only move to the next blind spot after resolving the current one.
+- **Provide Your Insight**: When asking a question, attach your professional insight.
+- **Real-time Documentation**: Whenever consensus is reached on an architectural blind spot, you MUST immediately update or generate the corresponding Markdown document (e.g., ADR or CONTEXT.md).
+
+## 3. Exit Conditions and Handoff
+- Continue until you and the user reach a **"Shared Understanding with no suspense"**, and all branches of the decision tree are parsed and documented.
+- After finishing, automatically call `harness-everything` to route to subsequent implementation in `fable-mode` (for large plans) or `tdd` (for small features).

package/grill-with-docs/SKILL.md

@@ -1,99 +1,99 @@
----
-name: grill-with-docs
-description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | User wants to stress-test a plan against the project's existing domain language and documented decisions (`CONTEXT.md`, ADRs). |
-| **Expected Output** | A one-question-at-a-time interview walking the design tree to resolution; `CONTEXT.md` updated inline as terms resolve; new ADRs created only when a decision is hard-to-reverse, surprising, and a genuine trade-off. |
-| **State Mutations** | Creates/edits `CONTEXT.md` and `docs/adr/*.md` (or the per-context equivalents under a `CONTEXT-MAP.md` layout). |
-| **Enforcement Gate** | `CONTEXT.md` **MUST** stay a pure glossary — no implementation details. An ADR **MUST NOT** be offered unless all three criteria (hard to reverse, surprising without context, real trade-off) hold. |
-
-<what-to-do>
-
-Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
-
-Ask the questions one at a time, waiting for feedback on each question before continuing.
-
-If a question can be answered by exploring the codebase, explore the codebase instead.
-
-</what-to-do>
-
-<supporting-info>
-
-## Domain awareness
-
-During codebase exploration, also look for existing documentation:
-
-### File structure
-
-Most repos have a single context:
-
-```
-/
-├── CONTEXT.md
-├── docs/
-│   └── adr/
-│       ├── 0001-event-sourced-orders.md
-│       └── 0002-postgres-for-write-model.md
-└── src/
-```
-
-If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
-
-```
-/
-├── CONTEXT-MAP.md
-├── docs/
-│   └── adr/                          ← system-wide decisions
-├── src/
-│   ├── ordering/
-│   │   ├── CONTEXT.md
-│   │   └── docs/adr/                 ← context-specific decisions
-│   └── billing/
-│       ├── CONTEXT.md
-│       └── docs/adr/
-```
-
-Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
-
-## During the session
-
-### Challenge against the glossary
-
-When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
-
-### Sharpen fuzzy language
-
-When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
-
-### Discuss concrete scenarios
-
-When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
-
-### Cross-reference with code
-
-When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
-
-### Update CONTEXT.md inline
-
-When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
-
-`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
-
-### Offer ADRs sparingly
-
-Only offer to create an ADR when all three are true:
-
-1. **Hard to reverse** — the cost of changing your mind later is meaningful
-2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
-3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
-
-If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
-
-</supporting-info>
+---
+name: grill-with-docs
+description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | User wants to stress-test a plan against the project's existing domain language and documented decisions (`CONTEXT.md`, ADRs). |
+| **Expected Output** | A one-question-at-a-time interview walking the design tree to resolution; `CONTEXT.md` updated inline as terms resolve; new ADRs created only when a decision is hard-to-reverse, surprising, and a genuine trade-off. |
+| **State Mutations** | Creates/edits `CONTEXT.md` and `docs/adr/*.md` (or the per-context equivalents under a `CONTEXT-MAP.md` layout). |
+| **Enforcement Gate** | `CONTEXT.md` **MUST** stay a pure glossary — no implementation details. An ADR **MUST NOT** be offered unless all three criteria (hard to reverse, surprising without context, real trade-off) hold. |
+
+<what-to-do>
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
+
+</what-to-do>
+
+<supporting-info>
+
+## Domain awareness
+
+During codebase exploration, also look for existing documentation:
+
+### File structure
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── docs/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── docs/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+### Cross-reference with code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+
+### Update CONTEXT.md inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
+
+</supporting-info>