harness-everything 0.2.2 → 0.3.6

package/harness-everything/SKILL.md

@@ -1,141 +1,42 @@
 ---
 name: harness-everything
-description: The single entry point and dynamic router for the Harness ecosystem. Triage tasks into Tier 1, 2, or 3.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
+description: "Triage new software requests into Tier 1/2/3 before work begins. USE FOR: \"triage a new software task\", \"route this coding request\". DO NOT USE FOR: \"chat or general Q&A\", \"non-software writing\", \"a skill is already indicated\"."
+license: Apache-2.0
+metadata:
+  author: Miya Daniel
+  version: 0.3.6
 ---
 
-# Harness Everything (System Main Entry & Dynamic Router)
+# Harness Everything
 
-## 📋 Skill Contract
+## USE FOR:
+- Triage new software tasks before implementation.
 
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | Every new user request where no specific skill is already indicated — the mandatory first load, run via `scripts/tier-router.js "<prompt>"`. |
-| **Expected Output** | A Tier determination (1/2/3) and a mandatory "🚦 Harness OS Routing Checkpoint" block at the very start of the response, listing the tier, rationale, and routed skills/guides. |
-| **State Mutations** | None directly — orchestrates which other skills/guides get loaded and, for Tier 2/3, triggers `todo-driven-workflow` checklist initialization. |
-| **Enforcement Gate** | **MUST** run `scripts/tier-router.js` (or reuse the `UserPromptSubmit` hook's output for the same turn) before deciding the tier — the routing checkpoint output is mandatory, not optional. Rule of 3: 3 consecutive failed fix attempts on the same signature **MUST** stop further edits and force `zoom-out`. |
-
-This is the single entry point for the entire Harness Skills ecosystem. When you receive a new request from the user and no specific Skill is indicated, you **MUST** prioritize loading this Skill to perform Task Triage.
-
-## 1. Core Rule: Global Underlying OS & Base Execution Loop
-Before taking any action, you must awaken and load the principles of `install-cognitive-os`.
-No matter how simple the task is, your behavior must comply with the **Discover > Think > Try > Summarize > Record** cognitive loop.
-Never rush to act before understanding the environment; establish contextual awareness first.
-
-**Base Execution Loop (`todo-driven-workflow`)**: The cognitive loop above defines *how you think*; `todo-driven-workflow` defines *how you execute*. For every **Tier 2 and Tier 3** task, you MUST load `todo-driven-workflow` and initialize its checklist BEFORE editing any file — it is the foundational step-by-step execution layer of this harness (break down into 3-7 verifiable sub-tasks, one `in-progress` at a time, verify with real evidence before marking `completed`). Tier 1 tasks are exempt to avoid checklist bloat.
-
-**Always-On Disciplines** (apply on every tier, alongside the loops above):
-- `fable-mode/execution-guardrails` — verify-before-flag, warning batching, find-and-replace safety. These are behavioral contracts, not Tier-3-only rules.
-- `verify-before-claim` — never assert external framework/API behavior or unmeasured performance numbers from training memory; verify against an authoritative source first.
-- `install-cognitive-os`'s Global Output Normalization — lead with direct answers, suppress preambles/recaps/pleasantries, and enforce natural locale terminology (§6).
-
-**Self-Healing Toolchain (工欲善其事,必先利其器)**: The harness may have been installed from a different editor than the one currently running (e.g., installed via Claude Code, now opened in Copilot). During the `[Discover]` phase, audit the workspace's integration touchpoints and repair any that are missing — the script is idempotent and delegates to the installer, so re-running is always safe:
-```bash
-node "<this-skill-dir>/scripts/self-heal.js"          # audit + auto-repair missing touchpoints
-node "<this-skill-dir>/scripts/self-heal.js" --check  # audit only, never writes
-```
-Also run this immediately whenever the `bootstrap.js` SessionStart output shows a `[Self-Heal] Missing integration touchpoints` warning. Exception: if the user says they intentionally removed one of these files, respect that and do not re-create it.
+## DO NOT USE FOR:
+- Chat or general Q&A.
+- Non-software writing.
+- Requests that already name a skill.
 
-## 2. Task Triage
-To avoid "over-engineering" and maximize efficiency, you must categorize the user's task during the `[Think]` phase and take the corresponding action path.
-- **MANDATORY**: Run the Tier Router script before deciding the tier. The script lives at `scripts/tier-router.js` **inside this skill's own directory** — resolve the path from wherever this SKILL.md was loaded (do not guess a hard-coded location):
-  ```bash
-  node "<this-skill-dir>/scripts/tier-router.js" "<Brief summary of the user's prompt>"
-  ```
-- You MUST follow the `REQUIRED TIER` output by the script.
-- If a `UserPromptSubmit` hook already ran the router this turn (its `[Tier Routing Pre-check]` output is visible in context), reuse that output instead of running it again.
+## Skill Contract
 
-### Mandated Routing Checkpoint Output
-At the very beginning of your response to the user, you **MUST** output a clear, stylized routing report. This report is mandatory for all entries via `harness-everything`. It must list the determined Tier and the exact routing targets:
-```markdown
-## 🚦 Harness OS Routing Checkpoint
-- **Active Tier**: Tier X (Tier Name)
-- **Rationale**: Short 1-sentence reason from the tier router.
-- **Routed Skills, Guides & Actions**:
-  - `path/to/skill/or/guide.md` (Brief description of why this applies)
-  - ...
-```
-
-### Proactive Copilot & VS Code Instruction (Avoid Silent Degrades)
-If you are running in VS Code or GitHub Copilot, you do not have automated hooks to run scripts on your behalf.
-- You **MUST** proactively run the tier-router script (`node harness-everything/scripts/tier-router.js "<prompt>"`) or simulate its routing logic manually at the start.
-- **NEVER degrade newly added features or structural extensions to Tier 1.** Copilot is highly prone to treating new feature requests as trivial Tier 1 direct edits. If the request adds *any* new logic, a new API endpoint, or a new file/module, it **MUST** be triaged as **Tier 2 (Standard Task)** or **Tier 3 (Macro Task)**. This activates:
-  1. The `todo-driven-workflow` checklist (mandatory step-by-step progress tracking).
-  2. Multi-agent spawning / sub-agents via `create-agent-launcher` or macro plan orchestration via `fable-mode`.
-  3. The memory summarization & evolution sequence via `self-evolve` upon completion, ensuring new knowledge is registered in workspace memory.
-
-### Tier 1: Trivial Tasks & Daily Chores
-- **Characteristics**: Fixing typos, simple modifications to a single function, asking/explaining code, syntax adjustments. Or simple `git-commit` and `rewrite-commits`.
-- **Action Strategy (Direct Execution)**:
-  - **PROHIBITED** from writing large plans.
-  - **PROHIBITED** from calling `create-agent-launcher` or `fable-mode`.
-  - Execute the modification directly based on requirements, or load `git-commit` / `rewrite-commits`. Perform a simple `[Record]` after modifying.
-
-### Tier 2: Standard Tasks & Architectural Review
-- **Characteristics**: Adding a single API endpoint, fixing a specific bug, modifications requiring coordination across 2-3 files. Or requiring stress testing and benchmark evaluation for specific designs.
-- **Action Strategy (TDD, Deep Context & Domain Expertise)**:
-  - **Initialize the Base Execution Loop**: Load `todo-driven-workflow` and lay out the checklist first (the TDD Red/Green/Refactor phases map naturally onto todo items).
-  - **Information Depth Requirement**: Before entering TDD, you MUST perform a deep context trace (find references, call sites, and related interfaces). Superficial fixes that break dependencies are strictly forbidden.
-  - **Load Domain Experts (領域專家召喚)**: Based on the tech stack detected in Tier 1, explicitly search for and load the corresponding **Domain Skills** (e.g., `security-review` from this repo, or `frontend-patterns` / `api-design` from the user's legacy skill library) to inject robust expert knowledge into your context.
-  - Development tasks: Automatically load and follow the `tdd` (Test-Driven Development) skill. Write tests first (Red) -> Implement (Green) -> Refactor.
-  - Before starting feature work on a busy repository, consider loading `using-git-worktrees` to isolate your workspace and prevent workspace pollution.
-  - If the user requests grilling or refactoring a plan, load `grill-me` (pure Q&A) or `improve-codebase-architecture` (deep architectural analysis).
-  - If the user requests "scoring" or "benchmark comparison", load `eval-harness` for quantitative scoring and summarization.
-  - **Pre-Delivery Gate**: Before declaring the task done or creating a PR, load `verification-loop` (build / types / lint / tests / security scan / diff review). For changes touching auth, input handling, secrets, or network boundaries, additionally load `security-review`.
-
-### Tier 3: Macro Tasks & Documentation
-- **Characteristics**: New project initialization, low-level architecture refactoring, vague and massive requirements (e.g., "Help me write a user login system"). Or lack of global documentation.
-- **Action Strategy (Multi-Agent Orchestration & Domain Infusion)**:
-  - If initializing a multi-agent system workspace, load `build-multi-agent-system` to scaffold the 6 functional zones, memory relational indexes, and immutable routing laws.
-  - If project-level documentation needs to be created, load `repo-docs`.
-  - If establishing a large system design, strongly recommend loading `grill-with-docs` first to document decisions (ADR, CONTEXT) before proceeding.
-  - **Sub-Agent Specialization**: When calling `create-agent-launcher`, you MUST inject robust Domain Skills into the sub-agent's persona (e.g., passing `database-reviewer` and `backend-patterns` to a Backend Sub-Agent). Do not create generic, empty-shell agents.
-  - Development execution: Automatically load `fable-mode` and `fable-discipline`. The macro plan produced in fable-mode's Discovery phase MUST be materialized as the `todo-driven-workflow` checklist — sub-agent handoffs and milestone checks are tracked there, not in prose.
-  - **Pre-Delivery Gate**: Same as Tier 2 — run `verification-loop` (and `security-review` where applicable) before the final handoff.
-
-## 3. Foolproofing & Circuit Breaker Mechanism
-LLMs have a Reasoning Ceiling. To avoid invalid infinite retries, you must strictly obey the following limits:
-- **Rule of 3**: If attempting to fix the same Bug or test failure fails 3 times consecutively, **STOP modifying code immediately**.
-- **Trigger Circuit Breaker**: Forcefully call the `zoom-out` skill — rebuild the full picture, fact-check the assumption behind each failed attempt with read-only tools, and write the reflection report. Most trips should end in **self-recovery on a fresh diagnosis**, not a cry for help.
-- **Seek Human Help — only for genuine decisions**: Escalate when zoom-out concludes the blocker is a human call (requirement conflict, architecture trade-off, destructive action, missing access), or when the breaker hard-locks on a second trip of the same signature. Present verified facts and 2-3 options with a recommendation — never a bare "I'm stuck".
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | New software request with no skill indicated. |
+| **Expected Output** | Print a Routing Checkpoint with tier and rationale. |
+| **State Mutations** | None; Tier 2/3 starts native TODO or Markdown tracking. |
+| **Enforcement Gate** | Run `scripts/tier-router.js` before edits. |
 
-## 4. Evolution Loop
-- When the circuit breaker is triggered and the problem is ultimately solved — whether by post-reflection self-recovery or with human intervention.
-- Or, when you have expended great effort to overcome difficulties and complete a complex task.
-- You **MUST** automatically call the `self-evolve` skill to write "human key insights" or "successfully avoided traps" into system memory, ensuring the same blind spots are bypassed next time.
+## Workflow
 
-## 6. Always-On ADHD-Friendly Output Shaping
-This is the same always-on discipline `install-cognitive-os` defines under its own §"Global Output Normalization" — this router doesn't restate it (that duplication was flagged in a skill quality audit §1.1 and has been removed). Since §1 already sends every task through `install-cognitive-os` before any action, its output-shaping rules are already in effect by the time this router does anything — apply them as written there, on every response, regardless of tier.
+1. Unless a hook ran it, run `node "<this-skill-dir>/scripts/tier-router.js" "<prompt summary>"`.
+2. Print the checkpoint and execute the selected tier.
+3. On `[Self-Heal]` warnings, run the named self-heal script.
+4. After three same-signature failures, use `zoom-out`, then `self-evolve`.
 
-## 5. Skill Registry (Full Activation Map)
-Every skill in this repository is reachable from this router. If a task matches a trigger below and the skill is not yet loaded, load it.
+## Routing
 
-| Skill | Layer | Activated when |
-| :--- | :--- | :--- |
-| `install-cognitive-os` | Foundation | Always, before any action (§1). |
-| `todo-driven-workflow` | Foundation | Every Tier 2/3 task — the base execution loop (§1). |
-| `environment-detection` | Foundation | Session start / `[Discover]` phase, before running shell commands. |
-| `fable-mode/execution-guardrails` | Always-on discipline | Every tier: flagging problems, batching warnings, find-and-replace edits (§1). |
-| `verify-before-claim` | Always-on discipline | Before asserting external-system behavior or unmeasured numbers (§1). |
-| `git-commit` / `rewrite-commits` | Tier 1 | Commit creation / history rewriting. |
-| `tdd` | Tier 2 | Feature/bugfix development (Red-Green-Refactor). |
-| `using-git-worktrees` | Tier 2 | Isolating feature work on a busy repository. |
-| `grill-me` | Tier 2 | User asks to be grilled on a plan (pure Q&A). |
-| `improve-codebase-architecture` | Tier 2 | Deep architectural analysis / refactor planning. |
-| `eval-harness` | Tier 2 | Scoring, stress testing, benchmark comparison. |
-| `verification-loop` | Tier 2/3 gate | Before declaring done or creating a PR. |
-| `security-review` | Tier 2/3 gate | Changes touching auth, input handling, secrets, network boundaries. |
-| `fable-mode` | Tier 3 | Macro task planning & execution engine. |
-| `fable-discipline` | Tier 3 | Risk control paired with fable-mode. |
-| `fable-mode/fable-haiku` | Tier 3 (opt-in) | User explicitly asks for staged execution run cheaply on Haiku. |
-| `create-agent-launcher` | Tier 3 | Spawning specialized sub-agents. |
-| `build-multi-agent-system` | Tier 3 | Scaffolding a multi-agent workspace. |
-| `repo-docs` | Tier 3 | Creating project-level documentation. |
-| `grill-with-docs` | Tier 3 | Documenting decisions (ADR / CONTEXT) before large designs. |
-| `zoom-out` | Circuit breaker | Rule of 3 trips (§3). |
-| `self-evolve` | Evolution | Post-breaker resolution or major breakthrough (§4). |
-| `skill-style` | Meta | Authoring or modifying any SKILL.md in this repository — the terse Skill Contract format spec. |
-| `skill-creator` | Meta | Creating a new skill from scratch, auditing/refactoring an existing SKILL.md, or `self-evolve`'s dynamic skill generation step (§4) — the fuller authoring, quality-checklist, and testing workflow built on `skill-style`. |
+- **Tier 1:** Trivial edits; direct edit only.
+- **Tier 2:** Standard changes; use `todo-driven-workflow`, `tdd`, and `verification-loop`.
+- **Tier 3:** Macro work; use `fable-mode` and `fable-discipline`, select Haiku/Sonnet/Opus via the model matrix, and delegate through `multi-agent-workspace`.
 
-(`eval-framework/` is internal CI for the router itself — run `node eval-framework/runner.js` after modifying `tier-router.js`; it is not a routable skill. Likewise `scripts/self-heal.js` in this skill is infrastructure, invoked during `[Discover]` per §1.)
+See `references/triage-and-tiers.md` for the full routing contract.

package/harness-everything/examples/README.md

@@ -1,9 +1,9 @@
-# Harness Examples
-This directory contains concrete examples of how to use Harness tools and workflows.
-
-## tier-router.js Quick Start
-If you are unsure how to use the tier router, you can call it directly:
-`node harness-everything/scripts/tier-router.js "YOUR PROMPT HERE"`
-
-Example:
-`node harness-everything/scripts/tier-router.js "Add a login page"`
+# Harness Examples
+This directory contains concrete examples of how to use Harness tools and workflows.
+
+## tier-router.js Quick Start
+If you are unsure how to use the tier router, you can call it directly:
+`node harness-everything/scripts/tier-router.js "YOUR PROMPT HERE"`
+
+Example:
+`node harness-everything/scripts/tier-router.js "Add a login page"`

package/harness-everything/examples/todo-workflow.md

@@ -1,22 +1,22 @@
-# Todo-Driven Workflow Example
-Here is a concrete example of how to implement the Todo-Driven Workflow using VS Code's `manage_todo_list` tool.
-
-## The Goal: Add a User Authentication Endpoint
-
-1. **Initialize the List**: Before writing code, call `manage_todo_list` with these items:
-   - ID: 1, Title: "Write auth tests", Status: "not-started"
-   - ID: 2, Title: "Implement /login API", Status: "not-started"
-   - ID: 3, Title: "Verify DB connection", Status: "not-started"
-
-2. **Start Task 1**: Call `manage_todo_list` to set ID 1 to "in-progress".
-
-3. **Execute**: Create `tests/auth.test.js` and write the tests.
-
-4. **Verify**: Run the tests using `run_in_terminal` (`npm test`). They should fail (Red).
-
-5. **Complete Task 1**: Call `manage_todo_list` to set ID 1 to "completed".
-
-6. **Start Task 2**: Call `manage_todo_list` to set ID 2 to "in-progress".
-...and so on.
-
-**CRITICAL**: Do NOT just type out a checklist in markdown. You MUST call the `manage_todo_list` tool.
+# Todo-Driven Workflow Example
+Here is a concrete example of how to implement the Todo-Driven Workflow using VS Code's `manage_todo_list` tool.
+
+## The Goal: Add a User Authentication Endpoint
+
+1. **Initialize the List**: Before writing code, call `manage_todo_list` with these items:
+   - ID: 1, Title: "Write auth tests", Status: "not-started"
+   - ID: 2, Title: "Implement /login API", Status: "not-started"
+   - ID: 3, Title: "Verify DB connection", Status: "not-started"
+
+2. **Start Task 1**: Call `manage_todo_list` to set ID 1 to "in-progress".
+
+3. **Execute**: Create `tests/auth.test.js` and write the tests.
+
+4. **Verify**: Run the tests using `run_in_terminal` (`npm test`). They should fail (Red).
+
+5. **Complete Task 1**: Call `manage_todo_list` to set ID 1 to "completed".
+
+6. **Start Task 2**: Call `manage_todo_list` to set ID 2 to "in-progress".
+...and so on.
+
+**CRITICAL**: Do NOT just type out a checklist in markdown. You MUST call the `manage_todo_list` tool.

package/harness-everything/references/skill-registry.md

@@ -0,0 +1,39 @@
+# Skill Registry (Full Activation Map)
+
+## 5. Skill Registry (Full Activation Map)
+Every skill in this repository is reachable from this router. If a task matches a trigger below and the skill is not yet loaded, load it.
+
+| Skill | Layer | Activated when |
+| :--- | :--- | :--- |
+| `harness-everything` | Entry point | New software request with no skill indicated; emits the tier checkpoint. |
+| `install-cognitive-os` | Foundation | Always, before any action (§1). |
+| `todo-driven-workflow` | Foundation | Every Tier 2/3 task — the base execution loop (§1). |
+| `environment-detection` | Foundation | Session start / `[Discover]` phase, before running shell commands. |
+| `fable-mode/execution-guardrails` | Always-on discipline | Every tier: flagging problems, batching warnings, find-and-replace edits (§1). |
+| `verify-before-claim` | Always-on discipline | Before asserting external-system behavior or unmeasured numbers (§1). |
+| `git-commit` | Tier 1 | Commit creation and conventional commit verification. |
+| `rewrite-commits` | Tier 1 | History rewriting and commit cleanup. |
+| `tdd` | Tier 2 | Feature/bugfix development (Red-Green-Refactor). |
+| `using-git-worktrees` | Tier 2 | Isolating feature work on a busy repository. |
+| `grill-me` | Tier 2 | User asks to be grilled on a plan (pure Q&A). |
+| `improve-codebase-architecture` | Tier 2 | Deep architectural analysis / refactor planning. |
+| `eval-harness` | Tier 2 | Scoring, stress testing, benchmark comparison. |
+| `verification-loop` | Tier 2/3 gate | Before declaring done or creating a PR. |
+| `security-review` | Tier 2/3 gate | Changes touching auth, input handling, secrets, network boundaries. |
+| `fable-mode` | Tier 3 | v3 staged planning, named-agent delegation, model selection, failable gates, and cold review. |
+| `fable-discipline` | Tier 3 | Risk control paired with fable-mode. |
+| `fable-mode/fable-haiku` | Tier 3 (opt-in) | User explicitly asks for staged execution on Haiku for bulk mechanical work. |
+| `fable-mode/fable-sonnet` | Tier 3 (opt-in) | User explicitly asks for staged execution on Sonnet for bounded reasoning or synthesis. |
+| `fable-mode/fable-opus` | Tier 3 (opt-in) | User explicitly asks for staged execution on Opus for orchestration or high-stakes architecture. |
+| `multi-agent-workspace` | Tier 3 | Scaffolding a multi-agent workspace and selecting bounded specialists. |
+| `repo-docs` | Tier 3 | Creating project-level documentation. |
+| `grill-with-docs` | Tier 3 | Documenting decisions (ADR / CONTEXT) before large designs. |
+| `to-spec` | Tier 2/3 (advisory, never a gate) | Synthesizing the (already-settled) conversation into whichever doc shape fits — feature spec, CLI/API reference, schema doc, or dev doc — published to this repo's issue tracker. Explicit-invoke only — never auto-executed. |
+| `to-tickets` | Tier 2/3 (advisory, never a gate) | Breaking a `to-spec` feature spec (or an already-settled plan/conversation) into tracer-bullet tickets with declared blocking edges. Reuses `to-spec`'s own `check-project-docs.js` gate — never a second setup interview. Explicit-invoke only — never auto-executed. |
+| `zoom-out` | Circuit breaker | Rule of 3 trips (§3). |
+| `self-evolve` | Evolution | Post-breaker resolution or major breakthrough (§4). |
+| `find-skills` | Meta | No static/generated/already-installed skill covers the user's need (checked live via `npx skills list`, not manifest-cached) — searches skills.sh/`npx skills` and, only with explicit approval, applies it ephemerally via a self-expiring OS-temp cache (`scripts/use-skill.js`, the default — zero persistent footprint) or, only if the user wants to keep it, installs via `npx skills add` (the rare exception). Deliberately not manifest-tracked or router-auto-surfaced like `self-evolve`'s `generated[]` — third-party content isn't lifecycle-owned by Harness the way self-authored skills are. |
+| `skill-style` | Meta | Authoring or modifying any SKILL.md in this repository — the terse Skill Contract format spec. |
+| `skill-creator` | Meta | Creating a new skill from scratch, auditing/refactoring an existing SKILL.md, or `self-evolve`'s dynamic skill generation step (§4) — the fuller authoring, quality-checklist, and testing workflow built on `skill-style`. |
+
+(`ci/` is internal CI for the router itself — run `node ci/runner.js` after modifying `tier-router.js`; it is not a routable skill. Likewise `scripts/self-heal.js` in this skill is infrastructure, invoked during `[Discover]` per §1.)

package/harness-everything/references/triage-and-tiers.md

@@ -0,0 +1,116 @@
+# Task Triage & Tier Details (moved from SKILL.md)
+
+## 0. Non-Software Task Bypass Decision Matrix
+
+Follow the decision matrix below to determine whether Harness OS routing applies:
+
+```mermaid
+flowchart TD
+    Start[Receive User Prompt] --> IntentCheck{1. Is this a Software Engineering / Project Task?<br>e.g. coding, refactoring, specs, git, bugs}
+    
+    IntentCheck -- No: Pure Chat / Translation / Web Search / General Q&A --> Bypass[Bypass Harness OS Completely<br>Direct & Natural Answer]
+    IntentCheck -- Yes: Code / Architecture / Project Task --> RunRouter{2. Execute / Reuse tier-router.js}
+    
+    RunRouter --> DetermineTier{Determine Tier}
+    
+    DetermineTier -- Tier 1: Trivial Code Fix / Minor Chore --> T1[Tier 1: Direct Execution]
+    DetermineTier -- Tier 2: Standard Feature / Bug / Refactor --> T2[Tier 2: Load TDD & todo-driven-workflow]
+    DetermineTier -- Tier 3: Macro Arch / Multi-Agent / Spec --> T3[Tier 3: Load Fable Mode & to-spec/to-tickets]
+    
+    T1 --> OutputContract[Output Standardized Routing Checkpoint<br>Establish Deterministic Agent State]
+    T2 --> OutputContract
+    T3 --> OutputContract
+    
+    OutputContract --> Execute[Execute Routed Skills & Deliver Result]
+```
+
+#### Bypass Rules:
+- **Pure Conversations / General Tasks**: If the user prompt is general Q&A, text translation, web searching, or non-software writing, **BYPASS** `harness-everything` completely. Do NOT output a Routing Checkpoint block; reply directly and naturally.
+- **Software Engineering / Codebase Tasks**: **MUST** output the standardized `🚦 Harness OS Routing Checkpoint` block at the top of the response to establish a deterministic status contract across different AI models.
+
+## 1. Core Rule: Global Underlying OS & Base Execution Loop
+Before taking any action, you must awaken and load the principles of `install-cognitive-os`.
+No matter how simple the task is, your behavior must comply with the **Discover > Think > Try > Summarize > Record** cognitive loop.
+Never rush to act before understanding the environment; establish contextual awareness first.
+
+**Base Execution Loop (`todo-driven-workflow`)**: The cognitive loop above defines *how you think*; `todo-driven-workflow` defines *how you execute*. For every **Tier 2 and Tier 3** task, you MUST load `todo-driven-workflow` and initialize its checklist BEFORE editing any file — it is the foundational step-by-step execution layer of this harness (break down into 3-7 verifiable sub-tasks, one `in-progress` at a time, verify with real evidence before marking `completed`). Tier 1 tasks are exempt to avoid checklist bloat.
+
+**Always-On Disciplines** (apply on every tier, alongside the loops above):
+- `fable-mode/execution-guardrails` — verify-before-flag, warning batching, find-and-replace safety. These are behavioral contracts, not Tier-3-only rules.
+- `verify-before-claim` — never assert external framework/API behavior or unmeasured performance numbers from training memory; verify against an authoritative source first.
+- `install-cognitive-os`'s Global Output Normalization — lead with direct answers, suppress preambles/recaps/pleasantries, and enforce natural locale terminology (§6).
+
+**Self-Healing Toolchain (工欲善其事,必先利其器)**: The harness may have been installed from a different editor than the one currently running (e.g., installed via Claude Code, now opened in Copilot). During the `[Discover]` phase, audit the workspace's integration touchpoints and repair any that are missing — the script is idempotent and delegates to the installer, so re-running is always safe:
+```bash
+node "<this-skill-dir>/scripts/self-heal.js"          # audit + auto-repair missing touchpoints
+node "<this-skill-dir>/scripts/self-heal.js" --check  # audit only, never writes
+```
+Also run this immediately whenever the `bootstrap.js` SessionStart output shows a `[Self-Heal] Missing integration touchpoints` warning. Exception: if the user says they intentionally removed one of these files, respect that and do not re-create it.
+
+## 2. Task Triage
+To avoid "over-engineering" and maximize efficiency, you must categorize the user's task during the `[Think]` phase and take the corresponding action path.
+
+**Thinking Discipline (Law of Elimination & Prediction - 預判與刪除定律)**:
+During the `[Think]` phase, analyze requirements and perform forward prediction before taking action. Use elimination early to prune unviable paths, skip scanning directories known to be unrelated, or discard strategies guaranteed to fail (e.g. skip executing a test suite on a file that has obvious syntax errors). Focus your limited attention solely on high-value, highly-relevant files to minimize failure costs.
+
+- **MANDATORY**: Run the Tier Router script before deciding the tier. The script lives at `scripts/tier-router.js` **inside this skill's own directory** — resolve the path from wherever this SKILL.md was loaded (do not guess a hard-coded location):
+  ```bash
+  node "<this-skill-dir>/scripts/tier-router.js" "<Brief summary of the user's prompt>"
+  ```
+- Treat the script's `RECOMMENDED TIER` as the default route — the same rule the router itself prints. If your own read of the task clearly disagrees (the router is a keyword heuristic, not an oracle), follow your read and state why in one line in the Routing Checkpoint. An explicit instruction from the Human Partner always wins.
+- If a `UserPromptSubmit` hook already ran the router this turn (its `[Tier Routing Pre-check]` output is visible in context), reuse that output instead of running it again.
+
+### Mandated Routing Checkpoint Output
+At the very beginning of your response to the user, you **MUST** output a clear, stylized routing report. This report is mandatory for all entries via `harness-everything`. It must list the determined Tier and the exact routing targets:
+```markdown
+## 🚦 Harness OS Routing Checkpoint
+- **Active Tier**: Tier X (Tier Name)
+- **Rationale**: Short 1-sentence reason from the tier router.
+- **Routed Skills, Guides & Actions**:
+  - `path/to/skill/or/guide.md` (Brief description of why this applies)
+  - ...
+```
+
+### Proactive Copilot & VS Code Instruction (Avoid Silent Degrades)
+If you are running in VS Code or GitHub Copilot, you do not have automated hooks to run scripts on your behalf.
+- You **MUST** proactively run the tier-router script (`node "<this-skill-dir>/scripts/tier-router.js" "<prompt>"` or `npx github:dyphn1/Harness-everything next "<prompt>"`) or simulate its routing logic manually at the start.
+- **NEVER degrade newly added features or structural extensions to Tier 1.** Copilot is highly prone to treating new feature requests as trivial Tier 1 direct edits. If the request adds *any* new logic, a new API endpoint, or a new file/module, it **MUST** be triaged as **Tier 2 (Standard Task)** or **Tier 3 (Macro Task)**. This activates:
+  1. The `todo-driven-workflow` checklist (mandatory step-by-step progress tracking).
+  2. Multi-agent spawning / sub-agents via `multi-agent-workspace` or macro plan orchestration via `fable-mode`.
+  3. The memory summarization & evolution sequence via `self-evolve` upon completion, ensuring new knowledge is registered in workspace memory.
+
+### Tier 1: Trivial Tasks & Daily Chores
+- **Characteristics**: Fixing typos, simple modifications to a single function, asking/explaining code, syntax adjustments. Or simple `git-commit` and `rewrite-commits`.
+- **Action Strategy (Direct Execution)**:
+  - **PROHIBITED** from writing large plans.
+  - **PROHIBITED** from calling `multi-agent-workspace` or `fable-mode`.
+  - Execute the modification directly based on requirements, or load `git-commit` / `rewrite-commits`. Perform a simple `[Record]` after modifying.
+
+### Tier 2: Standard Tasks & Architectural Review
+- **Characteristics**: Adding a single API endpoint, fixing a specific bug, modifications requiring coordination across 2-3 files. Or requiring stress testing and benchmark evaluation for specific designs.
+- **Action Strategy (TDD, Deep Context & Domain Expertise)**:
+  - **Initialize the Base Execution Loop**: Load `todo-driven-workflow` and lay out the checklist first (the TDD Red/Green/Refactor phases map naturally onto todo items).
+  - **Information Depth Requirement**: Before entering TDD, you MUST perform a deep context trace (find references, call sites, and related interfaces). Superficial fixes that break dependencies are strictly forbidden.
+  - **Load Domain Experts (領域專家召喚)**: Based on the tech stack detected in Tier 1, explicitly search for and load the corresponding **Domain Skills** (e.g., `security-review` from this repo, or `frontend-patterns` / `api-design` from the user's legacy skill library) to inject robust expert knowledge into your context.
+  - Development tasks: Automatically load and follow the `tdd` (Test-Driven Development) skill. Write tests first (Red) -> Implement (Green) -> Refactor.
+  - Before starting feature work on a busy repository, consider loading `using-git-worktrees` to isolate your workspace and prevent workspace pollution.
+  - **Optional, non-blocking**: if the task introduces a new command/flag, API endpoint, or data shape, consider offering `to-spec` to write the matching lightweight doc (`cli-reference` or `schema-doc` template) before implementing — this is advisory only, skip it for straightforward single-function fixes, and never let it delay or gate TDD.
+  - If the user requests grilling or refactoring a plan, load `grill-me` (pure Q&A) or `improve-codebase-architecture` (deep architectural analysis).
+  - If the user requests "scoring" or "benchmark comparison", load `eval-harness` for quantitative scoring and summarization.
+  - **Pre-Delivery Gate**: Before declaring the task done or creating a PR, load `verification-loop` (build / types / lint / tests / security scan / diff review). For changes touching auth, input handling, secrets, or network boundaries, additionally load `security-review`.
+
+### Tier 3: Macro Tasks & Documentation
+- **Characteristics**: New project initialization, low-level architecture refactoring, vague and massive requirements (e.g., "Help me write a user login system"). Or lack of global documentation.
+- **Action Strategy (Multi-Agent Orchestration & Domain Infusion)**:
+  - If initializing a multi-agent system workspace, load `multi-agent-workspace` to scaffold the 6 functional zones, memory index, immutable router, and agency catalog.
+  - If project-level documentation needs to be created, load `repo-docs`.
+  - If establishing a large system design, strongly recommend loading `grill-with-docs` first to document decisions (ADR, CONTEXT) before proceeding. Once those decisions are settled, load `to-spec` to synthesize the conversation into whichever doc shape fits — a full feature spec (PRD) is the common case here, but `to-spec` also covers CLI/API reference, schema doc, and dev-doc shapes for narrower Tier 3 work. `to-spec` never re-interviews; if it hits an unresolved fork, that's a sign `grill-with-docs`/`grill-me` needed another pass first, not a cue to ask ad hoc questions.
+  - `to-spec` is advisory in both Tier 2 and Tier 3 — never a required gate. Its own internal Step 0 is mechanized, not advisory: it runs `node to-spec/scripts/check-project-docs.js check` to see whether this repo's own `harness-everything/manifest.json` already has a complete `projectDocs` entry (document location + issue tracker + issue definition) — Exit 0 skips straight past it, Exit 1 runs a one-time setup interview and persists the answer via the script's `init` subcommand. That reuses the same manifest this package and `self-evolve` already own, repo-local only (never the global `~/.agents`/`~/.claude` homes, since this data must not leak across projects). Its output is what `to-tickets` reads to cut clean vertical slices afterward.
+  - Once a `to-spec` feature spec exists (or the user just wants an already-settled plan/conversation broken down directly), load `to-tickets` to cut it into tracer-bullet tickets with declared blocking edges. It runs the *same* `check-project-docs.js check` gate `to-spec` does — never a second copy of that interview — and publishes through the identical `tracker`/`issueDefinition` fields, so the repo only ever answers "where do issues live" once. Quizzes the user on the proposed breakdown (granularity, blocking edges) before publishing; never forces multi-ticket decomposition onto a `to-spec` doc that was already a single unit of work (a `cli-reference`/`schema-doc`/`dev-doc` shape).
+  - **Sub-Agent Specialization**: When calling `multi-agent-workspace`, you MUST inject robust Domain Skills into the sub-agent's persona (e.g., selecting an agency specialist for a Backend Sub-Agent). Do not create generic, empty-shell agents.
+  - Development execution: Automatically load `fable-mode` and `fable-discipline`. The macro plan produced in fable-mode's Discovery phase MUST be materialized as the `todo-driven-workflow` checklist — sub-agent handoffs and milestone checks are tracked there, not in prose.
+  - **Pre-Delivery Gate**: Same as Tier 2 — run `verification-loop` (and `security-review` where applicable) before the final handoff.
+
+# Always-On ADHD-Friendly Output Shaping
+
+This is the same always-on discipline `install-cognitive-os` defines under its own §"Global Output Normalization" — this router doesn't restate it (that duplication was flagged in a skill quality audit §1.1 and has been removed). Since §1 already sends every task through `install-cognitive-os` before any action, its output-shaping rules are already in effect by the time this router does anything — apply them as written there, on every response, regardless of tier.