harness-everything 0.30.7 → 0.30.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (32) hide show
  1. package/.claude-plugin/marketplace.json +1 -1
  2. package/.claude-plugin/plugin.json +1 -1
  3. package/CHANGELOG.md +31 -0
  4. package/ci/prompt-contract-regressions.test.js +80 -0
  5. package/docs/workflows/fable-discipline.md +18 -59
  6. package/docs/workflows/git-commit.md +21 -67
  7. package/docs/workflows/grill-me.md +20 -12
  8. package/docs/workflows/grill-with-docs.md +21 -12
  9. package/evals/fable-discipline/tasks/positive-trigger.yaml +1 -1
  10. package/evals/git-commit/tasks/positive-trigger.yaml +1 -1
  11. package/evals/grill-me/tasks/positive-trigger.yaml +1 -1
  12. package/fable-discipline/SKILL.md +13 -13
  13. package/fable-discipline/references/discipline-rules.md +4 -4
  14. package/git-commit/SKILL.md +14 -14
  15. package/git-commit/references/commit-flow.md +4 -2
  16. package/grill-me/SKILL.md +19 -21
  17. package/grill-me/references/grilling-playbook.md +5 -5
  18. package/grill-with-docs/SKILL.md +3 -3
  19. package/grill-with-docs/references/session-playbook.md +4 -4
  20. package/opencode-plugin/plugin.json +1 -1
  21. package/package.json +1 -1
  22. package/plugins/harness-everything/.codex-plugin/plugin.json +1 -1
  23. package/plugins/harness-everything/plugin.json +1 -1
  24. package/plugins/harness-everything/skills/fable-discipline/SKILL.md +13 -13
  25. package/plugins/harness-everything/skills/fable-discipline/references/discipline-rules.md +4 -4
  26. package/plugins/harness-everything/skills/git-commit/SKILL.md +14 -14
  27. package/plugins/harness-everything/skills/git-commit/references/commit-flow.md +4 -2
  28. package/plugins/harness-everything/skills/grill-me/SKILL.md +19 -21
  29. package/plugins/harness-everything/skills/grill-me/references/grilling-playbook.md +5 -5
  30. package/plugins/harness-everything/skills/grill-with-docs/SKILL.md +3 -3
  31. package/plugins/harness-everything/skills/grill-with-docs/references/session-playbook.md +4 -4
  32. package/sbom.cdx.json +7 -7
@@ -1,10 +1,10 @@
1
1
  ---
2
2
  name: git-commit
3
- description: "Generate Angular-style commit messages after verifying the environment, submodules, and staged files; use for explicit commit requests or concluded task phases."
3
+ description: "Generate Angular-style commit messages after verifying repo state, submodules, and staged files. Use only for a user-requested or host/workflow-authorized commit; task completion alone is not authorization."
4
4
  license: Apache-2.0
5
5
  metadata:
6
6
  author: Miya Daniel
7
- version: 0.27.0
7
+ version: 0.30.8
8
8
  ---
9
9
 
10
10
  # Git Commit (Angular Style)
@@ -13,26 +13,26 @@ metadata:
13
13
 
14
14
  | Component | Specification |
15
15
  | :--- | :--- |
16
- | **Trigger / Input** | User requests a commit, or a task phase concludes. Input: staged git diff. |
16
+ | **Trigger / Input** | User requests a commit, or the active host/workflow explicitly authorizes one. A concluded task phase alone is not authorization. |
17
17
  | **Expected Output** | Clean Angular-style commit via `git commit -m` or temp file (`git commit -F`). |
18
- | **State Mutations** | Git tree updated; working tree becomes clean. |
19
- | **Enforcement Gate** | Run `git status` first; nothing staged → prompt user; non-git repo → offer `git init` or skip. |
18
+ | **State Mutations** | Authorized Git history update; unrelated working-tree changes remain untouched. |
19
+ | **Enforcement Gate** | **MUST** confirm commit authorization first, then run `git status`; nothing staged → prompt user. |
20
20
 
21
21
  ## Quick Workflow
22
22
 
23
- 1. **MUST** run `git status`; no repo → offer `git init` or skip; submodules changed → commit first per `<this-skill-dir>/guides/SUBMODULES.md`, including its worktree reachability gate.
24
- 2. **MUST** inspect `git diff --cached` before committing. Nothing staged → prompt user / stage only user-authorized targeted files. Unrelated concerns **SHOULD** be split unless coupling or explicit user intent justifies one commit.
25
- 3. Format `<type>(<scope>): <subject>` per `<this-skill-dir>/guides/ANGULAR_STYLE.md`. Multiline/Windows → `.git-commit-msg.txt` + `git commit -F`, clean up.
26
- 4. `git commit -m "..."`, then **MUST** verify the result with `git log -1`.
23
+ 1. **MUST** confirm authorization and run `git status`; no repo → offer `git init` or skip; submodules changed → follow `<this-skill-dir>/guides/SUBMODULES.md`.
24
+ 2. **MUST** inspect `git diff --cached` before committing. Nothing staged → prompt user / stage only authorized targeted files. Unrelated concerns **SHOULD** be split unless coupling or explicit intent justifies one commit.
25
+ 3. Format `<type>(<scope>): <subject>` per `<this-skill-dir>/guides/ANGULAR_STYLE.md`. Multiline/Windows → temp file + `git commit -F`.
26
+ 4. Commit, then **MUST** verify with `git log -1`.
27
27
 
28
28
  ## USE FOR:
29
- - Commit request from the user
30
- - Formatting conventional commit messages
29
+ - User-requested or host/workflow-authorized commits
30
+ - Conventional commit formatting
31
31
  - Submodule or monorepo commits
32
32
 
33
33
  ## DO NOT USE FOR:
34
- - Staging without user confirmation
35
- - Branching, rebasing, merging, pushing
36
- - Non-git dirs where user declines `git init`
34
+ - Autonomous commits merely because a phase concluded
35
+ - Staging without authorization
36
+ - Branching, rebasing, merging, or pushing
37
37
 
38
38
  Deep dive: <this-skill-dir>/references/commit-flow.md
@@ -6,7 +6,9 @@ Details moved from SKILL.md. Read when you need the full commit execution flow.
6
6
 
7
7
  ```mermaid
8
8
  flowchart TD
9
- Start[Trigger: Commit Request / Task Complete] --> CheckGit{1. Is Git Repo Initialized?}
9
+ Start[Trigger: User / Host-Authorized Commit] --> CheckAuth{0. Commit Authorized?}
10
+ CheckAuth -- No --> Stop[Do Not Commit; Surface Status]
11
+ CheckAuth -- Yes --> CheckGit{1. Is Git Repo Initialized?}
10
12
 
11
13
  CheckGit -- No --> OfferInit[Prompt User: Run git init or Skip Commit]
12
14
  CheckGit -- Yes --> CheckSubmodules{2. Has Submodule Changes?}
@@ -16,7 +18,7 @@ flowchart TD
16
18
 
17
19
  CheckStatus --> StagedCheck{4. Are Files Staged?}
18
20
 
19
- StagedCheck -- No Staged Files --> AskStage[Prompt User / Stage Targeted Files] --> Format
21
+ StagedCheck -- No Staged Files --> AskStage[Prompt User; Stage Only Authorized Targeted Files] --> Format
20
22
  StagedCheck -- Files Staged --> Format[5. Format Angular Commit Message]
21
23
 
22
24
  Format --> CheckShell{6. Shell / Multiline Escaping Check}
package/grill-me/SKILL.md CHANGED
@@ -1,43 +1,41 @@
1
1
  ---
2
2
  name: grill-me
3
- 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.
3
+ description: Stress-test plans and architectures one question at a time, expose blind spots, update domain terminology, and suggest an explicit to-spec handoff when alignment is complete.
4
4
  license: Apache-2.0
5
5
  metadata:
6
6
  author: Miya Daniel
7
- version: 0.4.0
7
+ version: 0.30.8
8
8
  ---
9
9
 
10
- # Grill Me (Interrogation & Stress Testing)
10
+ # Grill Me
11
11
 
12
- Stress-tests plans one question at a time, then hands off to `to-spec`.
12
+ Stress-test a plan one question at a time.
13
13
 
14
14
  ## USE FOR:
15
- - Stress-test a vague plan or architecture proposal
16
- - Find loopholes and undefined boundary conditions pre-build
17
- - Combat AI sycophancy with adversarial questioning
18
- - Resolve decision-tree ambiguity before spec generation
15
+ - vague plans or architecture proposals
16
+ - adversarial design review
17
+ - unresolved decision branches
19
18
 
20
19
  ## DO NOT USE FOR:
21
- - Implementing code or writing specs (`to-spec`, `tdd`)
22
- - Ticket breakdown of an approved spec (`to-tickets`)
23
- - Casual Q&A needing no adversarial challenge
20
+ - implementation or spec publication
21
+ - ticket decomposition
22
+ - casual Q&A
24
23
 
25
24
  ## Skill Contract
26
25
 
27
26
  | Component | Specification |
28
27
  | :--- | :--- |
29
- | **Trigger / Input** | Vague plan proposal, "evaluate architecture", or explicit "grill me". |
30
- | **Expected Output** | Single-question interrogation loop resolving decision-tree branches; handoff to `to-spec` for spec/ADR generation. |
31
- | **State Mutations** | Updates `CONTEXT.md` glossary inline; delegates document creation to `to-spec`. |
32
- | **Enforcement Gate** | ONE question at a time; on consensus, invoke `to-spec` to preview & publish spec/ADR docs. |
28
+ | **Trigger / Input** | Plan evaluation or explicit "grill me". |
29
+ | **Expected Output** | Resolved decision tree plus explicit `/to-spec` handoff suggestion. |
30
+ | **State Mutations** | May update `CONTEXT.md`; does not auto-run publication/ticket skills. |
31
+ | **Enforcement Gate** | Ask ONE question at a time. Never auto-run `to-spec` or `to-tickets`. |
33
32
 
34
33
  ## Workflow
35
34
 
36
- 1. [Discover] Scan plan-related code plus `<workspace>/CONTEXT.md`, `<workspace>/README.md`, ADRs under `<workspace>/docs/adr/`.
37
- 2. Grill strictly using the project's domain model and terminology.
38
- 3. Ask exactly ONE question at a time (questionnaires prohibited); attach your insight; resolve each branch before moving on.
39
- 4. Update `CONTEXT.md` glossary inline as terms resolve.
40
- 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).
41
- 6. Route execution: `to-tickets`, `fable-mode`, or `tdd`.
35
+ 1. Read relevant code, context, and ADRs.
36
+ 2. Challenge one branch at a time with project terminology.
37
+ 3. Update glossary terms as they resolve.
38
+ 4. On consensus, recommend explicit `/to-spec`.
39
+ 5. Suggest the next execution route without auto-invoking explicit-only skills.
42
40
 
43
41
  Deep dive: <this-skill-dir>/references/grilling-playbook.md
@@ -12,9 +12,9 @@ flowchart TD
12
12
  UpdateGlossary --> MoreBranches{3. Unresolved Decision Branches Remain?}
13
13
 
14
14
  MoreBranches -- Yes --> Loop
15
- MoreBranches -- No (Consensus Reached) --> ToSpec[4. Hand off to to-spec for Outline Preview & Spec/ADR Publishing]
15
+ MoreBranches -- No (Consensus Reached) --> ToSpec[4. Recommend explicit /to-spec handoff]
16
16
 
17
- ToSpec --> Execution[5. Route to to-tickets / fable-mode / tdd via harness-everything]
17
+ ToSpec --> Execution[5. Suggest /to-tickets / fable-mode / tdd as appropriate]
18
18
  ```
19
19
 
20
20
  ## 1. Persona: The Relentless Challenger
@@ -29,10 +29,10 @@ Your goal is to find loopholes, undefined boundary conditions, and potential per
29
29
  - **Rule of Single Question**: **You MUST only ask one question at a time**. Listing a long questionnaire with 5 questions is STRICTLY PROHIBITED.
30
30
  - **Tree Parsing**: Go deep down every branch of the decision tree. Only move to the next blind spot after resolving the current one.
31
31
  - **Provide Your Insight**: When asking a question, attach your professional insight.
32
- - **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).
32
+ - **Real-time Glossary & Spec Handoff**: As domain terms and blind spots resolve, update `CONTEXT.md` (glossary) inline. Once consensus is complete, recommend explicit `/to-spec`. Do not auto-run `to-spec` or `to-tickets`; publication remains behind their user-approval gates.
33
33
 
34
34
  ## 3. Exit Conditions and Handoff
35
35
 
36
36
  - Continue until you and the user reach a **"Shared Understanding with no suspense"**, and all branches of the decision tree are parsed and resolved.
37
- - **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.
38
- - **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).
37
+ - **Specification suggestion (`/to-spec`)**: Once grilling concludes and all branches resolve, recommend explicit `/to-spec`. Only that explicit invocation may enter `to-spec/SKILL.md` and its preview/publication flow.
38
+ - **Execution suggestion**: Suggest `/to-tickets`, `fable-mode`, or `tdd` as appropriate; do not auto-invoke explicit-only skills.
@@ -4,7 +4,7 @@ description: Challenge the plan against the existing domain model, sharpen termi
4
4
  license: Apache-2.0
5
5
  metadata:
6
6
  author: Miya Daniel
7
- version: 0.12.0
7
+ version: 0.30.8
8
8
  ---
9
9
 
10
10
  # Grill With Docs (Domain Modeling & Architectural Alignment)
@@ -18,7 +18,7 @@ Interview the design tree one question at a time with recommended answers; explo
18
18
  | **Trigger / Input** | Stress-testing a plan against domain language and documented decisions. |
19
19
  | **Expected Output** | Structured interview; inline `CONTEXT.md` updates; ADR handoff. |
20
20
  | **State Mutations** | Writes the context glossary and ADRs at resolved locations. |
21
- | **Enforcement Gate** | Pure glossary; ADRs meet the 3-part bar; hand to `to-spec` after. |
21
+ | **Enforcement Gate** | Pure glossary; ADRs meet the 3-part bar; suggest explicit `/to-spec` after alignment. Never auto-run `to-spec` or `to-tickets`. |
22
22
 
23
23
  ## Workflow
24
24
 
@@ -27,7 +27,7 @@ Interview the design tree one question at a time with recommended answers; explo
27
27
  3. Stress-test relationships with concrete scenarios; cross-check claims against code.
28
28
  4. Update the context glossary inline, never batch; zero implementation details.
29
29
  5. Offer an ADR only if hard to reverse + surprising without context + a real trade-off.
30
- 6. Hand off unverified design to `grill-me`; aligned design to `to-spec`; execution to `to-tickets`/`fable-mode`/`tdd`.
30
+ 6. Hand off unverified design to `grill-me`; for aligned design suggest explicit `/to-spec`; for execution suggest `/to-tickets`, `fable-mode`, or `tdd` as appropriate without auto-invoking explicit-only skills.
31
31
 
32
32
  Deep dive: <this-skill-dir>/references/session-playbook.md
33
33
 
@@ -22,9 +22,9 @@ flowchart TD
22
22
  WriteFallback --> CheckMore
23
23
 
24
24
  CheckMore -- Unresolved Branches Remain --> Frontier
25
- CheckMore -- All Branches Resolved --> ToSpec[6. Hand off to to-spec for Outline Preview & Spec/ADR Publishing]
25
+ CheckMore -- All Branches Resolved --> ToSpec[6. Recommend explicit /to-spec handoff]
26
26
 
27
- ToSpec --> Execution[7. Route to to-tickets / fable-mode / tdd via harness-everything]
27
+ ToSpec --> Execution[7. Suggest /to-tickets / fable-mode / tdd via harness-everything]
28
28
  ```
29
29
 
30
30
  ## Core interview prompt
@@ -95,5 +95,5 @@ If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](
95
95
 
96
96
  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.
97
97
  2. **Transition**: Once technical issues are hardened in `grill-me`, transition here to solidify domain terms and record architectural choices.
98
- 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.
99
- 4. **Execution Handoff**: Route to `to-tickets` (for ticket decomposition), `fable-mode` (for macro scaffolding), or `tdd` (for feature implementation) via `harness-everything`.
98
+ 3. **Downstream Specification Suggestion**: Once alignment is complete, recommend explicit `/to-spec`. Do not auto-run `to-spec` or `to-tickets`; their approval gates remain authoritative.
99
+ 4. **Execution Suggestion**: Suggest `/to-tickets`, `fable-mode`, or `tdd` through `harness-everything` as appropriate.
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "harness-enforcement",
3
3
  "description": "Repository inventory for the opencode enforcement plugin and its standalone helper",
4
- "version": "0.30.7",
4
+ "version": "0.30.8",
5
5
  "runtime": "index.mjs",
6
6
  "hooks": {
7
7
  "verify": "hooks/verify.js"
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "harness-everything",
3
- "version": "0.30.7",
3
+ "version": "0.30.8",
4
4
  "description": "Harness OS: An Orchestrated Agent Operating System for AI-driven Development",
5
5
  "main": "harness-everything/scripts/bootstrap.js",
6
6
  "bin": {
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "harness-everything",
3
- "version": "0.30.7",
3
+ "version": "0.30.8",
4
4
  "description": "Invariant-first engineering harness for routing, verification, and failure recovery while preserving agent autonomy.",
5
5
  "author": {
6
6
  "name": "Miya Daniel",
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
3
3
  "name": "harness-everything",
4
- "version": "0.30.7",
4
+ "version": "0.30.8",
5
5
  "description": "Invariant-first engineering harness for routing, verification, and failure recovery while preserving agent autonomy.",
6
6
  "author": {
7
7
  "name": "Miya Daniel",
@@ -1,10 +1,10 @@
1
1
  ---
2
2
  name: fable-discipline
3
- description: Enforce fable-mode's context discipline as a shadow guard. Use when running staged multi-agent loops to prevent context bloat, cap per-stage output size, keep each stage within its physical token boundaries, and stop agents from reading files outside the current stage's scope.
3
+ description: Enforce fable-mode context discipline as a shadow guard. Use for staged multi-agent loops to compact state, constrain stage scope, verify handoffs, and surface build divergence without adding an independent hard stop.
4
4
  license: Apache-2.0
5
5
  metadata:
6
6
  author: Miya Daniel
7
- version: 0.4.0
7
+ version: 0.30.8
8
8
  ---
9
9
 
10
10
  # Fable Discipline (Macro Task Discipline & Safety Net)
@@ -13,29 +13,29 @@ metadata:
13
13
 
14
14
  | Component | Specification |
15
15
  | :--- | :--- |
16
- | **Trigger / Input** | Background shadow for the whole duration `fable-mode` is active — not a standalone one-shot trigger. |
17
- | **Expected Output** | State compaction after milestones; one Git commit per independent logic block; a state manifest at every sub-agent handoff. |
16
+ | **Trigger / Input** | Background shadow for the whole duration `fable-mode` is active — not a standalone trigger. |
17
+ | **Expected Output** | State compaction after milestones; authorized commit-boundary guidance; a state manifest at every sub-agent handoff. |
18
18
  | **State Mutations** | None of its own — constrains how `fable-mode` and `multi-agent-workspace` mutate state. |
19
- | **Enforcement Gate** | **HALTS execution immediately** if build errors diverge (more fixes → more breakage); forces `zoom-out` instead of continued patching. |
19
+ | **Enforcement Gate** | Build divergence is a warning signal: surface it and recommend `zoom-out`. Rule-of-3 owns mandatory reflection. |
20
20
 
21
- Shadow guard for `fable-mode`: MUST run in the background for its whole duration.
21
+ Shadow guard for `fable-mode`: **MUST** run in the background for its whole duration.
22
22
 
23
23
  ## USE FOR:
24
24
  - Long architectural tasks under `fable-mode`
25
25
  - Compacting state after milestones
26
26
  - Sub-agent handoffs via `multi-agent-workspace`
27
- - Halting on diverging build errors
27
+ - Surfacing diverging build errors
28
28
 
29
29
  ## DO NOT USE FOR:
30
- - Small tasks where `fable-mode` is not active
31
- - Standalone one-shot invocation (background shadow skill)
30
+ - Small tasks where `fable-mode` is inactive
31
+ - Standalone one-shot invocation
32
32
  - Routine single-file edits
33
33
 
34
34
  ## Core Rules
35
35
 
36
- 1. **Anti-context bloat**: After each milestone, compact state and decisions; drop unneeded history. No broad regex without precise conditions; no reading irrelevant files over 1000 lines.
37
- 2. **Physical boundaries**: Know your CWD before touching core architecture; one Git commit per independent logic block.
38
- 3. **Agent handoff**: Outgoing agents MUST leave a state manifest (completed APIs, expected inputs/outputs); incoming agents MUST verify it first.
39
- 4. **Circuit breaker**: If build errors diverge, HALT, call `zoom-out`, and map the error dependency graph for the human.
36
+ 1. **Anti-context bloat**: After each milestone, **MUST** compact state and decisions; avoid irrelevant broad reads.
37
+ 2. **Physical boundaries**: **MUST** know the CWD. If commits are authorized, independent logic blocks **SHOULD** remain separate; otherwise leave changes uncommitted.
38
+ 3. **Agent handoff**: Outgoing agents **MUST** leave a state manifest; incoming agents **MUST** verify it first.
39
+ 4. **Divergence signal**: **MUST** surface diverging errors and recommend `zoom-out`; **SHOULD** map the dependency graph. Divergence alone does not hard-stop execution.
40
40
 
41
41
  Deep dive: <this-skill-dir>/references/discipline-rules.md
@@ -9,14 +9,14 @@ When executing large architectural tasks, conversation logs expand rapidly, lead
9
9
 
10
10
  ## 2. Strict Physical Boundaries
11
11
  - **Environment Isolation**: Before modifying any core architecture, ensure you are clearly aware of the Current Working Directory (CWD).
12
- - **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.
12
+ - **Atomic Commit Boundaries**: Do not modify dozens of files at once before testing. Treat each independently functioning logic block as a suggested commit boundary. Create the commit only when the user or active host/workflow has authorized commits; otherwise leave changes uncommitted and surface the boundary.
13
13
 
14
14
  ## 3. Agent Handoff Protocol
15
15
  When `fable-mode` spawns and switches between different sub-agents via `multi-agent-workspace`, strict handoff discipline must be observed:
16
16
  - **State Manifest**: The previous agent MUST leave a clear state record (e.g., what APIs were completed, expected inputs/outputs).
17
17
  - **Contract Testing**: The very first step for the succeeding agent is to verify if the state manifest left by the previous agent is correct.
18
18
 
19
- ## 4. Ultimate Circuit Breaker: Indefinite Halt
19
+ ## 4. Divergence Signal
20
20
  - Large tasks easily generate the sunk cost fallacy of "I think it's almost fixed, let me try one more time."
21
- - If the system's Build Errors exhibit a divergent trend (the more you fix, the more it breaks), **HALT EXECUTION IMMEDIATELY**.
22
- - Call `zoom-out`, organize the error dependency graph for the human, and seek architectural-level refactoring advice.
21
+ - If Build Errors exhibit a divergent trend (the more you fix, the more it breaks), surface the regression immediately and recommend `zoom-out`; divergence alone is not a hard stop.
22
+ - Organize the error dependency graph for the human. Mandatory reflection remains owned by Rule-of-3 after repeated same-signature failures, or by explicit user/host permission boundaries.
@@ -1,10 +1,10 @@
1
1
  ---
2
2
  name: git-commit
3
- description: "Generate Angular-style commit messages after verifying the environment, submodules, and staged files; use for explicit commit requests or concluded task phases."
3
+ description: "Generate Angular-style commit messages after verifying repo state, submodules, and staged files. Use only for a user-requested or host/workflow-authorized commit; task completion alone is not authorization."
4
4
  license: Apache-2.0
5
5
  metadata:
6
6
  author: Miya Daniel
7
- version: 0.27.0
7
+ version: 0.30.8
8
8
  ---
9
9
 
10
10
  # Git Commit (Angular Style)
@@ -13,26 +13,26 @@ metadata:
13
13
 
14
14
  | Component | Specification |
15
15
  | :--- | :--- |
16
- | **Trigger / Input** | User requests a commit, or a task phase concludes. Input: staged git diff. |
16
+ | **Trigger / Input** | User requests a commit, or the active host/workflow explicitly authorizes one. A concluded task phase alone is not authorization. |
17
17
  | **Expected Output** | Clean Angular-style commit via `git commit -m` or temp file (`git commit -F`). |
18
- | **State Mutations** | Git tree updated; working tree becomes clean. |
19
- | **Enforcement Gate** | Run `git status` first; nothing staged → prompt user; non-git repo → offer `git init` or skip. |
18
+ | **State Mutations** | Authorized Git history update; unrelated working-tree changes remain untouched. |
19
+ | **Enforcement Gate** | **MUST** confirm commit authorization first, then run `git status`; nothing staged → prompt user. |
20
20
 
21
21
  ## Quick Workflow
22
22
 
23
- 1. **MUST** run `git status`; no repo → offer `git init` or skip; submodules changed → commit first per `<this-skill-dir>/guides/SUBMODULES.md`, including its worktree reachability gate.
24
- 2. **MUST** inspect `git diff --cached` before committing. Nothing staged → prompt user / stage only user-authorized targeted files. Unrelated concerns **SHOULD** be split unless coupling or explicit user intent justifies one commit.
25
- 3. Format `<type>(<scope>): <subject>` per `<this-skill-dir>/guides/ANGULAR_STYLE.md`. Multiline/Windows → `.git-commit-msg.txt` + `git commit -F`, clean up.
26
- 4. `git commit -m "..."`, then **MUST** verify the result with `git log -1`.
23
+ 1. **MUST** confirm authorization and run `git status`; no repo → offer `git init` or skip; submodules changed → follow `<this-skill-dir>/guides/SUBMODULES.md`.
24
+ 2. **MUST** inspect `git diff --cached` before committing. Nothing staged → prompt user / stage only authorized targeted files. Unrelated concerns **SHOULD** be split unless coupling or explicit intent justifies one commit.
25
+ 3. Format `<type>(<scope>): <subject>` per `<this-skill-dir>/guides/ANGULAR_STYLE.md`. Multiline/Windows → temp file + `git commit -F`.
26
+ 4. Commit, then **MUST** verify with `git log -1`.
27
27
 
28
28
  ## USE FOR:
29
- - Commit request from the user
30
- - Formatting conventional commit messages
29
+ - User-requested or host/workflow-authorized commits
30
+ - Conventional commit formatting
31
31
  - Submodule or monorepo commits
32
32
 
33
33
  ## DO NOT USE FOR:
34
- - Staging without user confirmation
35
- - Branching, rebasing, merging, pushing
36
- - Non-git dirs where user declines `git init`
34
+ - Autonomous commits merely because a phase concluded
35
+ - Staging without authorization
36
+ - Branching, rebasing, merging, or pushing
37
37
 
38
38
  Deep dive: <this-skill-dir>/references/commit-flow.md
@@ -6,7 +6,9 @@ Details moved from SKILL.md. Read when you need the full commit execution flow.
6
6
 
7
7
  ```mermaid
8
8
  flowchart TD
9
- Start[Trigger: Commit Request / Task Complete] --> CheckGit{1. Is Git Repo Initialized?}
9
+ Start[Trigger: User / Host-Authorized Commit] --> CheckAuth{0. Commit Authorized?}
10
+ CheckAuth -- No --> Stop[Do Not Commit; Surface Status]
11
+ CheckAuth -- Yes --> CheckGit{1. Is Git Repo Initialized?}
10
12
 
11
13
  CheckGit -- No --> OfferInit[Prompt User: Run git init or Skip Commit]
12
14
  CheckGit -- Yes --> CheckSubmodules{2. Has Submodule Changes?}
@@ -16,7 +18,7 @@ flowchart TD
16
18
 
17
19
  CheckStatus --> StagedCheck{4. Are Files Staged?}
18
20
 
19
- StagedCheck -- No Staged Files --> AskStage[Prompt User / Stage Targeted Files] --> Format
21
+ StagedCheck -- No Staged Files --> AskStage[Prompt User; Stage Only Authorized Targeted Files] --> Format
20
22
  StagedCheck -- Files Staged --> Format[5. Format Angular Commit Message]
21
23
 
22
24
  Format --> CheckShell{6. Shell / Multiline Escaping Check}
@@ -1,43 +1,41 @@
1
1
  ---
2
2
  name: grill-me
3
- 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.
3
+ description: Stress-test plans and architectures one question at a time, expose blind spots, update domain terminology, and suggest an explicit to-spec handoff when alignment is complete.
4
4
  license: Apache-2.0
5
5
  metadata:
6
6
  author: Miya Daniel
7
- version: 0.4.0
7
+ version: 0.30.8
8
8
  ---
9
9
 
10
- # Grill Me (Interrogation & Stress Testing)
10
+ # Grill Me
11
11
 
12
- Stress-tests plans one question at a time, then hands off to `to-spec`.
12
+ Stress-test a plan one question at a time.
13
13
 
14
14
  ## USE FOR:
15
- - Stress-test a vague plan or architecture proposal
16
- - Find loopholes and undefined boundary conditions pre-build
17
- - Combat AI sycophancy with adversarial questioning
18
- - Resolve decision-tree ambiguity before spec generation
15
+ - vague plans or architecture proposals
16
+ - adversarial design review
17
+ - unresolved decision branches
19
18
 
20
19
  ## DO NOT USE FOR:
21
- - Implementing code or writing specs (`to-spec`, `tdd`)
22
- - Ticket breakdown of an approved spec (`to-tickets`)
23
- - Casual Q&A needing no adversarial challenge
20
+ - implementation or spec publication
21
+ - ticket decomposition
22
+ - casual Q&A
24
23
 
25
24
  ## Skill Contract
26
25
 
27
26
  | Component | Specification |
28
27
  | :--- | :--- |
29
- | **Trigger / Input** | Vague plan proposal, "evaluate architecture", or explicit "grill me". |
30
- | **Expected Output** | Single-question interrogation loop resolving decision-tree branches; handoff to `to-spec` for spec/ADR generation. |
31
- | **State Mutations** | Updates `CONTEXT.md` glossary inline; delegates document creation to `to-spec`. |
32
- | **Enforcement Gate** | ONE question at a time; on consensus, invoke `to-spec` to preview & publish spec/ADR docs. |
28
+ | **Trigger / Input** | Plan evaluation or explicit "grill me". |
29
+ | **Expected Output** | Resolved decision tree plus explicit `/to-spec` handoff suggestion. |
30
+ | **State Mutations** | May update `CONTEXT.md`; does not auto-run publication/ticket skills. |
31
+ | **Enforcement Gate** | Ask ONE question at a time. Never auto-run `to-spec` or `to-tickets`. |
33
32
 
34
33
  ## Workflow
35
34
 
36
- 1. [Discover] Scan plan-related code plus `<workspace>/CONTEXT.md`, `<workspace>/README.md`, ADRs under `<workspace>/docs/adr/`.
37
- 2. Grill strictly using the project's domain model and terminology.
38
- 3. Ask exactly ONE question at a time (questionnaires prohibited); attach your insight; resolve each branch before moving on.
39
- 4. Update `CONTEXT.md` glossary inline as terms resolve.
40
- 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).
41
- 6. Route execution: `to-tickets`, `fable-mode`, or `tdd`.
35
+ 1. Read relevant code, context, and ADRs.
36
+ 2. Challenge one branch at a time with project terminology.
37
+ 3. Update glossary terms as they resolve.
38
+ 4. On consensus, recommend explicit `/to-spec`.
39
+ 5. Suggest the next execution route without auto-invoking explicit-only skills.
42
40
 
43
41
  Deep dive: <this-skill-dir>/references/grilling-playbook.md
@@ -12,9 +12,9 @@ flowchart TD
12
12
  UpdateGlossary --> MoreBranches{3. Unresolved Decision Branches Remain?}
13
13
 
14
14
  MoreBranches -- Yes --> Loop
15
- MoreBranches -- No (Consensus Reached) --> ToSpec[4. Hand off to to-spec for Outline Preview & Spec/ADR Publishing]
15
+ MoreBranches -- No (Consensus Reached) --> ToSpec[4. Recommend explicit /to-spec handoff]
16
16
 
17
- ToSpec --> Execution[5. Route to to-tickets / fable-mode / tdd via harness-everything]
17
+ ToSpec --> Execution[5. Suggest /to-tickets / fable-mode / tdd as appropriate]
18
18
  ```
19
19
 
20
20
  ## 1. Persona: The Relentless Challenger
@@ -29,10 +29,10 @@ Your goal is to find loopholes, undefined boundary conditions, and potential per
29
29
  - **Rule of Single Question**: **You MUST only ask one question at a time**. Listing a long questionnaire with 5 questions is STRICTLY PROHIBITED.
30
30
  - **Tree Parsing**: Go deep down every branch of the decision tree. Only move to the next blind spot after resolving the current one.
31
31
  - **Provide Your Insight**: When asking a question, attach your professional insight.
32
- - **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).
32
+ - **Real-time Glossary & Spec Handoff**: As domain terms and blind spots resolve, update `CONTEXT.md` (glossary) inline. Once consensus is complete, recommend explicit `/to-spec`. Do not auto-run `to-spec` or `to-tickets`; publication remains behind their user-approval gates.
33
33
 
34
34
  ## 3. Exit Conditions and Handoff
35
35
 
36
36
  - Continue until you and the user reach a **"Shared Understanding with no suspense"**, and all branches of the decision tree are parsed and resolved.
37
- - **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.
38
- - **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).
37
+ - **Specification suggestion (`/to-spec`)**: Once grilling concludes and all branches resolve, recommend explicit `/to-spec`. Only that explicit invocation may enter `to-spec/SKILL.md` and its preview/publication flow.
38
+ - **Execution suggestion**: Suggest `/to-tickets`, `fable-mode`, or `tdd` as appropriate; do not auto-invoke explicit-only skills.
@@ -4,7 +4,7 @@ description: Challenge the plan against the existing domain model, sharpen termi
4
4
  license: Apache-2.0
5
5
  metadata:
6
6
  author: Miya Daniel
7
- version: 0.12.0
7
+ version: 0.30.8
8
8
  ---
9
9
 
10
10
  # Grill With Docs (Domain Modeling & Architectural Alignment)
@@ -18,7 +18,7 @@ Interview the design tree one question at a time with recommended answers; explo
18
18
  | **Trigger / Input** | Stress-testing a plan against domain language and documented decisions. |
19
19
  | **Expected Output** | Structured interview; inline `CONTEXT.md` updates; ADR handoff. |
20
20
  | **State Mutations** | Writes the context glossary and ADRs at resolved locations. |
21
- | **Enforcement Gate** | Pure glossary; ADRs meet the 3-part bar; hand to `to-spec` after. |
21
+ | **Enforcement Gate** | Pure glossary; ADRs meet the 3-part bar; suggest explicit `/to-spec` after alignment. Never auto-run `to-spec` or `to-tickets`. |
22
22
 
23
23
  ## Workflow
24
24
 
@@ -27,7 +27,7 @@ Interview the design tree one question at a time with recommended answers; explo
27
27
  3. Stress-test relationships with concrete scenarios; cross-check claims against code.
28
28
  4. Update the context glossary inline, never batch; zero implementation details.
29
29
  5. Offer an ADR only if hard to reverse + surprising without context + a real trade-off.
30
- 6. Hand off unverified design to `grill-me`; aligned design to `to-spec`; execution to `to-tickets`/`fable-mode`/`tdd`.
30
+ 6. Hand off unverified design to `grill-me`; for aligned design suggest explicit `/to-spec`; for execution suggest `/to-tickets`, `fable-mode`, or `tdd` as appropriate without auto-invoking explicit-only skills.
31
31
 
32
32
  Deep dive: <this-skill-dir>/references/session-playbook.md
33
33
 
@@ -22,9 +22,9 @@ flowchart TD
22
22
  WriteFallback --> CheckMore
23
23
 
24
24
  CheckMore -- Unresolved Branches Remain --> Frontier
25
- CheckMore -- All Branches Resolved --> ToSpec[6. Hand off to to-spec for Outline Preview & Spec/ADR Publishing]
25
+ CheckMore -- All Branches Resolved --> ToSpec[6. Recommend explicit /to-spec handoff]
26
26
 
27
- ToSpec --> Execution[7. Route to to-tickets / fable-mode / tdd via harness-everything]
27
+ ToSpec --> Execution[7. Suggest /to-tickets / fable-mode / tdd via harness-everything]
28
28
  ```
29
29
 
30
30
  ## Core interview prompt
@@ -95,5 +95,5 @@ If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](
95
95
 
96
96
  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.
97
97
  2. **Transition**: Once technical issues are hardened in `grill-me`, transition here to solidify domain terms and record architectural choices.
98
- 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.
99
- 4. **Execution Handoff**: Route to `to-tickets` (for ticket decomposition), `fable-mode` (for macro scaffolding), or `tdd` (for feature implementation) via `harness-everything`.
98
+ 3. **Downstream Specification Suggestion**: Once alignment is complete, recommend explicit `/to-spec`. Do not auto-run `to-spec` or `to-tickets`; their approval gates remain authoritative.
99
+ 4. **Execution Suggestion**: Suggest `/to-tickets`, `fable-mode`, or `tdd` through `harness-everything` as appropriate.
package/sbom.cdx.json CHANGED
@@ -2,23 +2,23 @@
2
2
  "$schema": "https://cyclonedx.org/schema/bom-1.7.schema.json",
3
3
  "bomFormat": "CycloneDX",
4
4
  "specVersion": "1.7",
5
- "serialNumber": "urn:uuid:20a8a552-ae6f-558f-8a4b-07bc73059c4a",
5
+ "serialNumber": "urn:uuid:ce51652b-572b-5c28-8da4-6b2f30888f30",
6
6
  "version": 1,
7
7
  "metadata": {
8
- "timestamp": "2026-10-07T02:50:57.855Z",
8
+ "timestamp": "2026-10-07T08:18:17.804Z",
9
9
  "tools": [
10
10
  {
11
11
  "vendor": "Harness Everything",
12
12
  "name": "generate-sbom.js",
13
- "version": "0.30.7"
13
+ "version": "0.30.8"
14
14
  }
15
15
  ],
16
16
  "component": {
17
17
  "type": "application",
18
- "bom-ref": "pkg:npm/harness-everything@0.30.7",
18
+ "bom-ref": "pkg:npm/harness-everything@0.30.8",
19
19
  "name": "harness-everything",
20
- "version": "0.30.7",
21
- "purl": "pkg:npm/harness-everything@0.30.7"
20
+ "version": "0.30.8",
21
+ "purl": "pkg:npm/harness-everything@0.30.8"
22
22
  }
23
23
  },
24
24
  "components": [
@@ -1999,7 +1999,7 @@
1999
1999
  ]
2000
2000
  },
2001
2001
  {
2002
- "ref": "pkg:npm/harness-everything@0.30.7",
2002
+ "ref": "pkg:npm/harness-everything@0.30.8",
2003
2003
  "dependsOn": [
2004
2004
  "pkg:npm/%40commitlint/cli@19.8.1",
2005
2005
  "pkg:npm/%40commitlint/config-conventional@19.8.1",