harness-everything 0.3.6 → 0.4.0

package/plugins/harness-everything/skills/git-commit/guides/ANGULAR_STYLE.md

@@ -0,0 +1,61 @@
+# Angular-Style Conventional Commits
+
+**[State Checkpoint]**
+- MUST verify the target language determined by Language Detection.
+
+## Commit Message Format
+
+```text
+<type>(<scope>): <subject>
+
+<body>
+
+<footer>
+```
+
+## Field Definitions
+
+1. **Type**: MUST be exactly one of: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`.
+   - MUST use `style` or `chore` for trivial/formatting changes.
+2. **Scope**: MUST enclose in parentheses if used.
+   - For Sub Repos: MUST use the Sub Repo name.
+   - For Code: MUST use a concise, high-level module name (e.g., `auth`, `ui`). MUST NOT use file paths.
+3. **Subject**: MUST use imperative mood, present tense, maximum 50 characters, NO trailing period. MUST be in the target language.
+4. **Body**: MUST describe motivation and context, and MUST analyze the staged changes to list the exact modifications in a clear, structured bulleted list.
+   - MUST analyze the `git diff --cached` output to extract the specific files, functions, or logic modified.
+   - MUST list each major change or file-level modification with a brief description of "what was changed" (e.g., `- Updated user schema to support OAuth IDs in src/models/user.ts`).
+   - MUST NOT separate bullet points with blank lines.
+   - MUST NOT artificially wrap lines.
+   - MUST be in the target language.
+5. **Footer**: MUST prefix breaking changes with `BREAKING CHANGE:`. MUST reference issues via `Closes #<id>`.
+
+## Code Change Output Example
+
+```text
+feat(auth): add OAuth2 login support
+
+Core intent: Allows users to sign in using Google and GitHub to simplify user authentication.
+
+Changes:
+- Added OAuth2 client config schema and defaults in `config/auth.ts`
+- Implemented OAuth2 middleware verification pipeline in `src/middleware/oauth.ts`
+- Updated user database model to store external provider IDs in `src/models/user.ts`
+- Added comprehensive integration tests for external provider flows in `tests/auth.test.ts`
+```
+
+## Submodule Update Output Example
+
+```text
+chore(ui): update ui submodule
+
+Core intent: Introduces dark mode support and resolves various UI layout issues.
+
+Included commits:
+- fix: align button text
+- feat: add dark mode
+- style: update primary color hex
+- fix: resolve layout shift on mobile
+```
+- style: update primary color hex
+- fix: resolve layout shift on mobile
+```

package/plugins/harness-everything/skills/git-commit/guides/COMMIT_GENERATION.md

@@ -0,0 +1,24 @@
+# Commit Generation Workflow
+
+**[State Checkpoint]**
+- MUST verify the target repository path passed from the previous step.
+- MUST ensure terminal is located in the target repository BEFORE generating commits.
+- MUST explicitly recall diff content and any provided Sub Repo logs.
+
+## [Preparation Phase]
+1. Language Selection: MUST execute `LANGUAGE_DETECTION.md`.
+2. Format Rules: MUST read and strictly follow `ANGULAR_STYLE.md`.
+
+## [Action Phase]
+3. Message Construction: MUST generate a strict Angular format message (Type, Scope, Subject, Body, Footer) integrating diff analysis.
+   - MUST perform a detailed analysis on `git diff --cached` to extract the exact files modified, functions/classes added or adjusted, and logical configuration changes.
+   - MUST compile these extracted points into a structured, bulleted list in the commit message body (e.g., listing changes file-by-file or feature-by-feature) so that the commit message serves as an accurate, self-contained changelog of the staged changes.
+4. Context Integration: IF Sub Repo logs were passed, MUST seamlessly integrate ALL Sub Repo log summaries into the commit body.
+5. State Isolation: MUST ignore unstaged changes AND MUST NOT run `git add` to prevent contamination.
+6. Execution: MUST execute the commit securely (e.g., `git commit -F - <<EOF` or writing to a temporary file) to ensure special characters do not break the terminal command.
+
+## [Validation & Summarize Phase]
+7. Error Handling: MUST verify if the commit command succeeded. IF it fails (e.g., pre-commit hooks, GPG), MUST NOT blindly halt. MUST diagnose the error, preserve the generated message in a temporary file, and pause to ask the user for remediation.
+
+## [Record: Handoff]
+8. Handoff: MUST record the successful commit log summary and return control with updated state to the calling workflow.

package/plugins/harness-everything/skills/git-commit/guides/LANGUAGE_DETECTION.md

@@ -0,0 +1,16 @@
+# Language Detection Workflow
+
+**[State Checkpoint]**
+- MUST verify terminal access to the target repository.
+
+## [Discovery Phase]
+1. Memory Check: MUST read the resolved Harness memory file `git-commit-prefs.md` for a cached target language. Prefer an existing `MEMORY.md`/`RULES.md`; otherwise use `.github/harness-everything/memories/git-commit-prefs.md`.
+
+## [Evaluation Phase]
+2. Sampling: IF memory cache is missing, MUST run `git log -n 5` securely to sample recent commit languages.
+3. Language Determination:
+   - IF a non-English language is detected dominantly in recent commits, MUST update the resolved Harness memory file with this language.
+   - OTHERWISE, MUST default to English.
+
+## [Record: Handoff]
+4. Handoff: MUST record the determined target language into the state context and return control to the Commit Generation workflow.

package/plugins/harness-everything/skills/git-commit/guides/MAIN_REPO.md

@@ -0,0 +1,15 @@
+# Main Repo Processing Workflow
+
+**[State Checkpoint]**
+- MUST verify terminal is located at the Main Repo root.
+- MUST acknowledge and retrieve any completed Sub Repo updates passed down from the previous phase.
+
+## [Elimination Phase]
+1. Diff Analysis: MUST analyze `git diff --cached` securely to identify staged changes (including Sub Repo pointer updates).
+2. Validation: IF no staged changes exist, MUST declare success and terminate workflow without further action.
+
+## [Summarize Phase]
+3. Context Gathering: IF Sub Repo pointer updates exist, MUST extract their commit logs (e.g., via `git log --oneline <old>..<new>`) to serve as context for the Main Repo commit.
+
+## [Action Phase]
+4. Commit Generation: MUST explicitly pass the verified diff and extracted Sub Repo logs as context, then execute `COMMIT_GENERATION.md`.

package/plugins/harness-everything/skills/git-commit/guides/SUBMODULES.md

@@ -0,0 +1,27 @@
+# Submodule Processing Workflow
+
+**[State Checkpoint]**
+- MUST verify the Main Repo absolute path transferred from the previous step.
+- MUST ensure terminal is located at the Main Repo root BEFORE beginning discovery.
+
+## [Discovery Phase]
+1. Deep Discovery: MUST run `git submodule status --recursive` to find all Sub Repos.
+
+## [Elimination Phase]
+2. Evaluation: For EACH Sub Repo, MUST run `git diff --cached` securely to check for staged changes. IF NO staged changes exist, MUST eliminate from target list.
+
+## [Execution Phase]
+3. Generation: For Sub Repos WITH staged changes, MUST execute `COMMIT_GENERATION.md`.
+4. Validation: MUST verify generation success. IF ANY Sub Repo has remaining staged changes, MUST diagnose failure and halt.
+
+## [Indexing Phase]
+5. Preference Check: MUST read the resolved Harness memory file `git-commit-prefs.md` for the `auto_stage_submodules` setting. Prefer an existing `MEMORY.md`/`RULES.md`; otherwise use `.github/harness-everything/memories/git-commit-prefs.md`.
+6. Execution:
+   - IF `auto_stage_submodules=true`: MUST run `git add <path>` in the Main Repo for all updated Sub Repos.
+   - IF missing: MUST prompt user exactly: "[1] Yes, [2] No, [3] Yes & Always allow".
+   - IF user selects [3]: MUST write `auto_stage_submodules=true` to the resolved Harness memory file AND run `git add <path>`.
+   - IF user selects [1]: MUST run `git add <path>` in the Main Repo.
+   - IF user selects [2]: MUST NOT run `git add`.
+
+## [State Handoff]
+7. Handoff: MUST summarize completed Sub Repo updates (including paths and logs) and explicitly carry them over when returning control to `SKILL.md`.

package/plugins/harness-everything/skills/git-commit/references/commit-flow.md

@@ -0,0 +1,30 @@
+# Git Commit — Decision Matrix
+
+Details moved from SKILL.md. Read when you need the full commit execution flow.
+
+## Process & Commit Execution Flow
+
+```mermaid
+flowchart TD
+    Start[Trigger: Commit Request / Task Complete] --> CheckGit{1. Is Git Repo Initialized?}
+    
+    CheckGit -- No --> OfferInit[Prompt User: Run git init or Skip Commit]
+    CheckGit -- Yes --> CheckSubmodules{2. Has Submodule Changes?}
+    
+    CheckSubmodules -- Yes --> CommitSubmodules["Commit Submodules First (Bottom-Up)<br>Consult git-commit/guides/SUBMODULES.md"] --> CheckStatus
+    CheckSubmodules -- No --> CheckStatus[3. Run git status & git diff --cached]
+    
+    CheckStatus --> StagedCheck{4. Are Files Staged?}
+    
+    StagedCheck -- No Staged Files --> AskStage[Prompt User / Stage Targeted Files] --> Format
+    StagedCheck -- Files Staged --> Format[5. Format Angular Commit Message]
+    
+    Format --> CheckShell{6. Shell / Multiline Escaping Check}
+    
+    CheckShell -- Simple Single Line --> DirectCommit["Run git commit -m 'type(scope): subject'"]
+    CheckShell -- Multiline / Windows Shell --> TempFileCommit[Write .git-commit-msg.txt -> Run git commit -F -> Cleanup]
+    
+    DirectCommit --> VerifyCommit[Run git log -1 to Verify]
+    TempFileCommit --> VerifyCommit
+    VerifyCommit --> Done[Commit Complete]
+```

package/plugins/harness-everything/skills/grill-me/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: grill-me
+description: Acts as a relentless challenger to stress-test plans and architectures by interrogating one question at a time, finding loopholes, combating AI sycophancy, updating the CONTEXT.md glossary in real time, and handing off resolved decisions to to-spec for formal specs/ADRs.
+license: Apache-2.0
+metadata:
+  author: Miya Daniel
+  version: 0.4.0
+---
+
+# Grill Me (Interrogation & Stress Testing)
+
+Stress-tests plans one question at a time, then hands off to `to-spec`.
+
+## USE FOR:
+- Stress-test a vague plan or architecture proposal
+- Find loopholes and undefined boundary conditions pre-build
+- Combat AI sycophancy with adversarial questioning
+- Resolve decision-tree ambiguity before spec generation
+
+## DO NOT USE FOR:
+- Implementing code or writing specs (`to-spec`, `tdd`)
+- Ticket breakdown of an approved spec (`to-tickets`)
+- Casual Q&A needing no adversarial challenge
+
+## Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Vague plan proposal, "evaluate architecture", or explicit "grill me". |
+| **Expected Output** | Single-question interrogation loop resolving decision-tree branches; handoff to `to-spec` for spec/ADR generation. |
+| **State Mutations** | Updates `CONTEXT.md` glossary inline; delegates document creation to `to-spec`. |
+| **Enforcement Gate** | ONE question at a time; on consensus, invoke `to-spec` to preview & publish spec/ADR docs. |
+
+## Workflow
+
+1. [Discover] Scan plan-related code plus `<workspace>/CONTEXT.md`, `<workspace>/README.md`, ADRs under `<workspace>/docs/adr/`.
+2. Grill strictly using the project's domain model and terminology.
+3. Ask exactly ONE question at a time (questionnaires prohibited); attach your insight; resolve each branch before moving on.
+4. Update `CONTEXT.md` glossary inline as terms resolve.
+5. On consensus, hand off to `<skills-repo-root>/to-spec/SKILL.md` to preview the outline and publish (PRD, CLI/API reference, Schema doc, or ADR).
+6. Route execution: `to-tickets`, `fable-mode`, or `tdd`.
+
+Deep dive: <this-skill-dir>/references/grilling-playbook.md

package/plugins/harness-everything/skills/grill-me/references/grilling-playbook.md

@@ -0,0 +1,38 @@
+# Grilling Playbook (Deep Dive)
+
+## Decision Flow
+
+```mermaid
+flowchart TD
+    Start[Trigger: Grill Me / Evaluate Plan] --> Discovery[1. Scan Related Code & Existing ADRs]
+    Discovery --> Loop[2. Ask Exactly ONE Question at a Time]
+    
+    Loop --> Answer[Receive Answer & Resolve Decision Branch]
+    Answer --> UpdateGlossary[Update CONTEXT.md Glossary Inline if Term Resolves]
+    UpdateGlossary --> MoreBranches{3. Unresolved Decision Branches Remain?}
+    
+    MoreBranches -- Yes --> Loop
+    MoreBranches -- No (Consensus Reached) --> ToSpec[4. Hand off to to-spec for Outline Preview & Spec/ADR Publishing]
+    
+    ToSpec --> Execution[5. Route to to-tickets / fable-mode / tdd via harness-everything]
+```
+
+## 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 Glossary & Spec Handoff**: As domain terms and blind spots resolve, update `CONTEXT.md` (glossary) inline. Once the interrogation concludes with a full consensus, hand off to `to-spec` to preview the outline and publish the formal specification document (PRD, CLI/API reference, Schema doc, or ADR).
+
+## 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 resolved.
+- **Handoff to Specification (`to-spec`)**: Once grilling concludes and all decision-tree branches are resolved, **MUST** hand off to `to-spec/SKILL.md` to synthesize the conversation into an outline preview and publish the corresponding document (PRD, CLI reference, Schema doc, or ADR) using `to-spec`'s path resolution flow.
+- **Handoff to Execution**: After `to-spec` publishes the specification, route to `to-tickets` (for ticket breakdown), `fable-mode` (for macro scaffolding), or `tdd` (for feature implementation).

package/plugins/harness-everything/skills/grill-with-docs/ADR-FORMAT.md

@@ -0,0 +1,47 @@
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `docs/adr/` directory lazily — only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When to offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will look at the code and wonder "why on earth 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 a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.

package/plugins/harness-everything/skills/grill-with-docs/CONTEXT-FORMAT.md

@@ -0,0 +1,63 @@
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A one or two sentence description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
+- **Flag conflicts explicitly.** If a term is used ambiguously, call it out in "Flagged ambiguities" with a clear resolution.
+- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
+- **Show relationships.** Use bold term names and express cardinality where obvious.
+- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
+- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+- **Write an example dialogue.** A conversation between a dev and a domain expert that demonstrates how the terms interact naturally and clarifies boundaries between related concepts.
+
+## Single vs multi-context repos
+
+**Single context (most repos):** One `CONTEXT.md` at the repo root.
+
+**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
+- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts
+- If only a root `CONTEXT.md` exists, single context
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+
+When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.

package/plugins/harness-everything/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: grill-with-docs
+description: Challenge the plan against the existing domain model, sharpen terminology, and update CONTEXT.md and ADRs inline as decisions crystallise; use when stress-testing a plan against documented language and decisions.
+license: Apache-2.0
+metadata:
+  author: Miya Daniel
+  version: 0.4.0
+---
+
+# Grill With Docs (Domain Modeling & Architectural Alignment)
+
+Interview the design tree one question at a time with recommended answers; explore the codebase instead of asking.
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Stress-testing a plan against domain language and documented decisions. |
+| **Expected Output** | Structured interview; inline `CONTEXT.md` updates; ADR handoff. |
+| **State Mutations** | Writes the context glossary and ADRs at resolved locations. |
+| **Enforcement Gate** | Pure glossary; ADRs meet the 3-part bar; hand to `to-spec` after. |
+
+## Workflow
+
+1. Resolve storage with `<skills-repo-root>/multi-agent-workspace/scripts/project-docs-resolver.js`; root `<workspace>/CONTEXT-MAP.md` wins.
+2. Challenge glossary conflicts; sharpen fuzzy terms to canonical ones.
+3. Stress-test relationships with concrete scenarios; cross-check claims against code.
+4. Update the context glossary inline, never batch; zero implementation details.
+5. Offer an ADR only if hard to reverse + surprising without context + a real trade-off.
+6. Hand off unverified design to `grill-me`; aligned design to `to-spec`; execution to `to-tickets`/`fable-mode`/`tdd`.
+
+Deep dive: <this-skill-dir>/references/session-playbook.md
+
+## USE FOR:
+- stress-testing plans against the domain model
+- resolving fuzzy domain terminology
+- capturing decisions into CONTEXT.md/ADRs inline
+
+## DO NOT USE FOR:
+- verifying unstable designs (`grill-me`)
+- spec publishing without a grilling pass

package/plugins/harness-everything/skills/grill-with-docs/references/session-playbook.md

@@ -0,0 +1,99 @@
+# Grill With Docs — Full Session Playbook
+
+## Decision Flow
+
+```mermaid
+flowchart TD
+    Start[Trigger: Stress-test Plan against Domain Model] --> Scan[1. Scan Codebase, CONTEXT.md & Existing ADRs]
+    Scan --> Frontier[2. Calculate Frontier & Ask Questions]
+
+    Frontier --> Answer[Receive Answer & Resolve Domain Term]
+    Answer --> UpdateGlossary[3. Update CONTEXT.md Glossary Inline]
+
+    UpdateGlossary --> CheckADR{4. Hard-to-reverse Trade-off Decision Reached?}
+
+    CheckADR -- Yes --> ResolvePath{Resolve ADR Storage Path}
+    CheckADR -- No --> CheckMore
+
+    ResolvePath -- projectDocs / docs/adr Exists --> WriteMain[Write to docs/adr/ or CONTEXT-MAP.md Location]
+    ResolvePath -- No Folder Found --> WriteFallback[Write to committable docs/adr, docs/domain, or docs/architecture]
+
+    WriteMain --> CheckMore{5. All Design Tree Branches Resolved?}
+    WriteFallback --> CheckMore
+
+    CheckMore -- Unresolved Branches Remain --> Frontier
+    CheckMore -- All Branches Resolved --> ToSpec[6. Hand off to to-spec for Outline Preview & Spec/ADR Publishing]
+
+    ToSpec --> Execution[7. Route to to-tickets / fable-mode / tdd via harness-everything]
+```
+
+## Core interview prompt
+
+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.
+
+## Dynamic storage resolution & file structure
+
+Inspect the workspace and resolve document locations dynamically:
+
+1. **Monorepo / Multi-Context**: If `CONTEXT-MAP.md` exists at the root, follow its context-specific mapping.
+2. **Project Configured / Inferred Location**: Run `node "to-spec/scripts/check-project-docs.js" check` or inspect if `docs/adr/` or `docs/` exists in the workspace.
+3. **Committable fallback**: If no documentation directory exists, use the shared resolver's `docs/adr/`, `docs/domain/`, and `docs/architecture/` paths, creating them lazily. Do not write ADRs under ignored platform homes.
+
+```
+/
+├── CONTEXT.md                        ← Primary domain glossary
+├── docs/                             ← Default documentation root
+│   └── adr/                          ← System-wide ADR decisions
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+├── docs/adr/                         ← Fallback ADR storage
+├── docs/domain/                      ← Fallback domain records
+└── docs/architecture/                ← Fallback architecture contracts
+```
+
+Create files lazily — only when you have resolved terms or ADRs to write.
+
+## Session techniques in full
+
+### 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).
+
+## Handoffs in full
+
+1. **Pre-flight**: If the core proposal is highly vague or its technical robustness (SRE, security, locks, concurrency, fail-safes) is unverified, recommend the user run `grill-me` first. Do not attempt to align a glossary for a broken or unstable design.
+2. **Transition**: Once technical issues are hardened in `grill-me`, transition here to solidify domain terms and record architectural choices.
+3. **Downstream Specification Handoff**: Once alignment is complete and domain terms are updated, hand off to `to-spec/SKILL.md` to present an outline preview and publish the formal specification document or ADR.
+4. **Execution Handoff**: Route to `to-tickets` (for ticket decomposition), `fable-mode` (for macro scaffolding), or `tdd` (for feature implementation) via `harness-everything`.

package/plugins/harness-everything/skills/harness-everything/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-everything
+description: "Route software/project work through the Harness kernel: classify Tier 1/2/3, establish mandatory invariants, then let the agent choose tactics and domain skills. Use for software triage, routing, and re-routing; not general Q&A or non-software writing."
+license: Apache-2.0
+metadata:
+  author: Miya Daniel
+  version: 0.4.0
+---
+
+# Harness Everything
+
+Public/manual Harness kernel entry. Hook-capable hosts should run the kernel before peer/domain skill selection.
+
+## USE FOR:
+- Software triage/re-routing, including work that already names or strongly matches another skill.
+- Inspecting Tier, invariants, or suggestions.
+
+## DO NOT USE FOR:
+- General Q&A or non-software writing.
+
+## Invariants
+
+1. **Route before execution** — establish scope/tier before mutation.
+2. **Verify before claim** — completion needs objective evidence.
+3. **Re-plan on repetition** — after 3 same-signature failures, stop micro-retrying and use `zoom-out`/fresh diagnosis.
+
+These rails are mandatory; Tier guidance is not a fixed pipeline.
+
+## Workflow
+
+1. Reuse current-turn kernel output, or run `node "<this-skill-dir>/scripts/kernel-router.js" "<prompt summary>"`.
+2. Preserve the invariants.
+3. Treat suggested skills as advisory: choose, combine, reorder, or omit them as useful.
+
+## Tier Guidance
+
+- **Tier 1:** Prefer direct execution.
+- **Tier 2:** TODO tracking, TDD, and verification are common suggestions.
+- **Tier 3:** Fable/multi-agent skills are optional when macro planning or delegation helps.
+
+**Rule:** do not enforce workflow order; let the agent orchestrate itself inside the invariants.
+
+Deep dive: <this-skill-dir>/references/triage-and-tiers.md

package/plugins/harness-everything/skills/harness-everything/examples/README.md

@@ -0,0 +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"`

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

@@ -0,0 +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.