@sallmarta/eye-hate-agent 1.0.0

package/.agents/rules/agent.md

@@ -0,0 +1,66 @@
+---
+trigger: always_on
+---
+
+---
+description: "Lean always-on rules for guardrails, context, intake, verification, and doc sync."
+---
+
+# Agent Rules
+
+## 1. Guardrails & Approach
+
+Prevent unilateral changes that could surprise the user and balance proactive execution with alignment.
+
+- **1.1** Ask before making material architecture, naming, or tool changes. Skip this for micro-decisions.
+- **1.2** Balance proactive execution with user alignment so initiative never outpaces agreement.
+- **1.3** If a better approach exists, compare the user's apparent expectation with the recommended path clearly and briefly. Use a short table when that sharpens the tradeoff. Phrasing to use: *"I have an alternative approach that may be better - want me to use it instead?"*
+
+## 2. Context & Cache Integrity
+
+Protect the prompt prefix cache and manage context-window capacity to preserve the 90% cached-token discount.
+
+- **2.1** Keep always-on context small. Keep rules generic and leave project-specific facts in project docs under `docs/project-docs/`.
+- **2.2** Read the smallest owning doc that resolves the decision rather than scanning the entire repository.
+- **2.3** **Prefix Stability (Gemini):** Never reorder tool definitions, system instructions, or serialized schemas mid-session — the implicit prefix cache requires a byte-identical prompt prefix for the 90% cached-token discount. Do not inject dynamic content (timestamps, session IDs, reordered JSON keys) before or between stable blocks. Append all per-turn dynamic data after the stable prefix. If cache-hit rates drop unexpectedly, suspect non-deterministic serialization or framework-injected metadata before other causes.
+- **2.4** **Session Continuity (No Dynamic Compaction):** Never modify, compact, or delete prior chat turns mid-session—this destroys the hardware prefix cache. If context reaches ~65% capacity, compile a comprehensive session-handoff.md to `active-repo/memories/session/session-handoff.md` (overwriting any previous handoff, and ensure `active-repo/memories/session/` is added to `.gitignore` if created). The handoff must contain a full, detailed summary of the active conversation's progress, decisions, and open threads, strictly redact all sensitive information (such as API keys, passwords, credentials, or PII), and incorporate any user-provided compaction arguments as next-session focus areas. Prompt the user to run `/clear` or open a new session with this file loaded, providing a copy-pasteable short prompt (e.g., "Resume session from memories/session/session-handoff.md") to load the handoff instantly.
+
+## 3. Intake & Scope Alignment
+
+Structure incoming requests before acting to reduce rework and catch ambiguity early.
+
+- **3.1** For non-trivial tasks, follow this 7-step checklist before coding:
+  1. Summarize the request in 1–3 sentences.
+  2. Analyze before implementing. Brainstorm when the task benefits from options, tradeoffs, or sequencing.
+  3. Ask clarifying questions when the request is ambiguous, under-specified, expectations are misplaced, or confidence is below 95%. **Clarify scope or output format before execution, not at completion.**
+  4. Make a short ordered plan or todo list.
+  5. Treat a user-provided list as full scope unless the user changes it.
+  6. Confirm if the plan could materially change scope, output, or direction.
+  7. Then proceed.
+- **3.2** Skip the intake checklist only for trivial single-step edits.
+
+## 4. Docs, Verification, and Completion
+
+Ensure every task ends with verified output, synchronized documentation, and clear follow-ups.
+
+- **4.1** State a point once, in its strongest owning section.
+- **4.2** Default live response shape when no stronger format applies: Summary -> What I'll Do -> Result or Next Action -> Validation or Limitation -> Optional Follow-Up.
+- **4.3** Stronger formats win: user formatting requests > mode-specific files > skill or prompt `Output Contract`.
+- **4.4** **Knowledge & Memory Preservation:** Preserve unique information when writing to memory. If valuable legacy or codebase knowledge does not fit standard headings, decide: new section, new file, or ask the user if the best location is ambiguous.
+- **4.5** **Documentation Sync:** After code or rule changes, sync affected docs under `docs/project-docs/` to ensure they remain the canonical source of truth.
+- **4.6** **Follow-Up Suggestions:** After completing a task, you may suggest 1–3 high-value, optional next actions. Never apply them silently. Phrasing: *"Task complete. Noticed X could be improved - want me to handle that too? or I can explain it if you want to review first."*
+
+## 5. Contract Essentials
+
+Embed the critical behavioral rules from the contract so agents follow them without opening the full contract on every task.
+
+- **5.1 Skills & Relevance:** Treat attached or mentioned skills as relevance hints, not automatic requirements. If a skill is clearly unnecessary, say so briefly and proceed directly unless the user insists. Prefer the single most relevant skill over chaining multiple.
+- **5.2 Decision Precedence:** Resolve routing, conflict, and behavior decisions in this strict order:
+  1. User's requested goal and output.
+  2. User's explicit constraints or preferences.
+  3. The active contract (`docs/eyehateagent-contract.md`) and the owning project docs under `docs/project-docs/`.
+  4. Attached context (skills, notes, or examples) treated as relevance hints unless made mandatory.
+  5. Automatic agent judgment.
+- **5.3 Failure & Fallback:** If a required project doc is missing, note the gap and create the smallest owning doc that unblocks the task. If code, tests, configs, or runtime-facing artifacts conflict with active docs and authority is unclear, do not guess: surface the conflict, cite the evidence, and ask the user before choosing the fix path.
+- **5.4 Codebase & Comment Integrity:** Maintain absolute documentation and codebase integrity when making modifications. Preserve all existing comments, docstrings, formatting, and structures that are unrelated to your changes unless explicitly instructed otherwise. Never delete unrelated comments or placeholder code silently.
+- **5.5 Completion & Verification:** End each task with the requested output and the narrowest applicable validation from `docs/project-docs/testing.md` (or a structural review with an explicit limitation if no executable check exists). Re-read output for correctness, edge cases, and unexpected side effects before finishing. Include a doc-sync check when ownership changed.

package/.claude/commands/eha/README.md

@@ -0,0 +1,3 @@
+# Generated EHA Claude commands
+
+These files are generated by `eha install` from the canonical workflow registry.

package/.claude/commands/eha/eha-bootstrap.md

@@ -0,0 +1,9 @@
+---
+description: "Run the EHA bootstrap workflow"
+---
+
+Read `docs/eyehateagent-contract.md` first.
+
+Execute `docs/vibes/reusable-prompts/00-project-docs-bootstrap.md`.
+
+If the user provides additional context, apply it while preserving the workflow's output contract and the owning-doc rules in `docs/project-docs/`.

package/.claude/commands/eha/eha-discuss.md

@@ -0,0 +1,9 @@
+---
+description: "Run the EHA discuss workflow"
+---
+
+Read `docs/eyehateagent-contract.md` first.
+
+Execute `docs/vibes/reusable-prompts/02-sdd-discuss.md`.
+
+If the user provides additional context, apply it while preserving the workflow's output contract and the owning-doc rules in `docs/project-docs/`.

package/.claude/commands/eha/eha-execute.md

@@ -0,0 +1,9 @@
+---
+description: "Run the EHA execute workflow"
+---
+
+Read `docs/eyehateagent-contract.md` first.
+
+Execute `docs/vibes/reusable-prompts/01-sdd-execute.md`.
+
+If the user provides additional context, apply it while preserving the workflow's output contract and the owning-doc rules in `docs/project-docs/`.

package/.claude/commands/eha/eha-parity.md

@@ -0,0 +1,9 @@
+---
+description: "Run the EHA parity workflow"
+---
+
+Read `docs/eyehateagent-contract.md` first.
+
+Execute `docs/vibes/reusable-prompts/00-project-docs-parity.md`.
+
+If the user provides additional context, apply it while preserving the workflow's output contract and the owning-doc rules in `docs/project-docs/`.

package/.claude/commands/eha/eha-refresh.md

@@ -0,0 +1,9 @@
+---
+description: "Run the EHA refresh workflow"
+---
+
+Read `docs/eyehateagent-contract.md` first.
+
+Execute `docs/vibes/reusable-prompts/00-project-docs-refresh.md`.
+
+If the user provides additional context, apply it while preserving the workflow's output contract and the owning-doc rules in `docs/project-docs/`.

package/.claude/commands/eha/eha-verify.md

@@ -0,0 +1,9 @@
+---
+description: "Run the EHA verify workflow"
+---
+
+Read `docs/eyehateagent-contract.md` first.
+
+Execute `docs/vibes/reusable-prompts/00-project-docs-parity.md`.
+
+If the user provides additional context, apply it while preserving the workflow's output contract and the owning-doc rules in `docs/project-docs/`.

package/.claude/rules/agent-rules.md

@@ -0,0 +1,64 @@
+---
+description: "Lean always-on rules for guardrails, context, intake, verification, and doc sync."
+applyTo: "**"
+---
+
+# Agent Rules
+
+## 1. Guardrails & Approach
+
+Prevent unilateral changes that could surprise the user and balance proactive execution with alignment.
+
+- **1.1** Ask before making material architecture, naming, or tool changes. Skip this for micro-decisions.
+- **1.2** Balance proactive execution with user alignment so initiative never outpaces agreement.
+- **1.3** If a better approach exists, compare the user's apparent expectation with the recommended path clearly and briefly. Use a short table when that sharpens the tradeoff. Phrasing to use: *"I have an alternative approach that may be better - want me to use it instead?"*
+
+## 2. Context & Cache Integrity
+
+Protect the prompt prefix cache and manage context-window capacity to preserve the 90% cached-token discount.
+
+- **2.1** Keep always-on context small. Keep rules generic and leave project-specific facts in project docs under `docs/project-docs/`.
+- **2.2** Read the smallest owning doc that resolves the decision rather than scanning the entire repository.
+- **2.3** **Prefix & Lookback Integrity (Claude):** Cache reads cost 90% less but require a byte-identical prefix in tools -> system -> messages order. Never reorder, add, or remove tool definitions mid-session. Never inject dynamic content (timestamps, per-request IDs) into the system prompt — move it to a late user message instead.
+- **2.4** **Claude Cache Breakpoints:** In heavy agentic loops, be aware of the ~20-block lookback window. If a single turn produces more than ~15 tool-use/tool-result pairs, explicitly request the user to perform a minor conversational interaction or place a cache breakpoint block to prevent silent cache misses on subsequent turns.
+- **2.5** **Session Continuity (No Dynamic Compaction):** Never modify, compact, or delete prior chat turns mid-session—this destroys the hardware prefix cache. If context reaches ~65% capacity, compile a comprehensive session-handoff.md to `active-repo/memories/session/session-handoff.md` (overwriting any previous handoff, and ensure `active-repo/memories/session/` is added to `.gitignore` if created). The handoff must contain a full, detailed summary of the active conversation's progress, decisions, and open threads, strictly redact all sensitive information (such as API keys, passwords, credentials, or PII), and incorporate any user-provided compaction arguments as next-session focus areas. Prompt the user to run `/clear` or open a new session with this file loaded, providing a copy-pasteable short prompt (e.g., "Resume session from memories/session/session-handoff.md") to load the handoff instantly.
+
+## 3. Intake & Scope Alignment
+
+Structure incoming requests before acting to reduce rework and catch ambiguity early.
+
+- **3.1** For non-trivial tasks, follow this 7-step checklist before coding:
+  1. Summarize the request in 1–3 sentences.
+  2. Analyze before implementing. Brainstorm when the task benefits from options, tradeoffs, or sequencing.
+  3. Ask clarifying questions when the request is ambiguous, under-specified, expectations are misplaced, or confidence is below 95%. **Clarify scope or output format before execution, not at completion.**
+  4. Make a short ordered plan or todo list.
+  5. Treat a user-provided list as full scope unless the user changes it.
+  6. Confirm if the plan could materially change scope, output, or direction.
+  7. Then proceed.
+- **3.2** Skip the intake checklist only for trivial single-step edits.
+
+## 4. Docs, Verification, and Completion
+
+Ensure every task ends with verified output, synchronized documentation, and clear follow-ups.
+
+- **4.1** State a point once, in its strongest owning section.
+- **4.2** Default live response shape when no stronger format applies: Summary -> What I'll Do -> Result or Next Action -> Validation or Limitation -> Optional Follow-Up.
+- **4.3** Stronger formats win: user formatting requests > mode-specific files > skill or prompt `Output Contract`.
+- **4.4** **Knowledge & Memory Preservation:** Preserve unique information when writing to memory. If valuable legacy or codebase knowledge does not fit standard headings, decide: new section, new file, or ask the user if the best location is ambiguous.
+- **4.5** **Documentation Sync:** After code or rule changes, sync affected docs under `docs/project-docs/` to ensure they remain the canonical source of truth.
+- **4.6** **Follow-Up Suggestions:** After completing a task, you may suggest 1–3 high-value, optional next actions. Never apply them silently. Phrasing: *"Task complete. Noticed X could be improved - want me to handle that too? or I can explain it if you want to review first."*
+
+## 5. Contract Essentials
+
+Embed the critical behavioral rules from the contract so agents follow them without opening the full contract on every task.
+
+- **5.1 Skills & Relevance:** Treat attached or mentioned skills as relevance hints, not automatic requirements. If a skill is clearly unnecessary, say so briefly and proceed directly unless the user insists. Prefer the single most relevant skill over chaining multiple.
+- **5.2 Decision Precedence:** Resolve routing, conflict, and behavior decisions in this strict order:
+  1. User's requested goal and output.
+  2. User's explicit constraints or preferences.
+  3. The active contract (`docs/eyehateagent-contract.md`) and the owning project docs under `docs/project-docs/`.
+  4. Attached context (skills, notes, or examples) treated as relevance hints unless made mandatory.
+  5. Automatic agent judgment.
+- **5.3 Failure & Fallback:** If a required project doc is missing, note the gap and create the smallest owning doc that unblocks the task. If code, tests, configs, or runtime-facing artifacts conflict with active docs and authority is unclear, do not guess: surface the conflict, cite the evidence, and ask the user before choosing the fix path.
+- **5.4 Codebase & Comment Integrity:** Maintain absolute documentation and codebase integrity when making modifications. Preserve all existing comments, docstrings, formatting, and structures that are unrelated to your changes unless explicitly instructed otherwise. Never delete unrelated comments or placeholder code silently.
+- **5.5 Completion & Verification:** End each task with the requested output and the narrowest applicable validation from `docs/project-docs/testing.md` (or a structural review with an explicit limitation if no executable check exists). Re-read output for correctness, edge cases, and unexpected side effects before finishing. Include a doc-sync check when ownership changed.

package/.github/instructions/agent-rules.instructions.md

@@ -0,0 +1,63 @@
+---
+description: "Lean always-on rules for guardrails, context, intake, verification, and doc sync."
+applyTo: "**"
+---
+
+# Agent Rules
+
+## 1. Guardrails & Approach
+
+Prevent unilateral changes that could surprise the user and balance proactive execution with alignment.
+
+- **1.1** Ask before making material architecture, naming, or tool changes. Skip this for micro-decisions.
+- **1.2** Balance proactive execution with user alignment so initiative never outpaces agreement.
+- **1.3** If a better approach exists, compare the user's apparent expectation with the recommended path clearly and briefly. Use a short table when that sharpens the tradeoff. Phrasing to use: *"I have an alternative approach that may be better - want me to use it instead?"*
+
+## 2. Context & Cache Integrity
+
+Protect the prompt prefix cache and manage context-window capacity to preserve the 90% cached-token discount.
+
+- **2.1** Keep always-on context small. Keep rules generic and leave project-specific facts in project docs under `docs/project-docs/`.
+- **2.2** Read the smallest owning doc that resolves the decision rather than scanning the entire repository.
+- **2.3** **Context Efficiency (Copilot):** Under usage-based billing, cached tokens still cost AI Credits — keep instruction files and session context lean rather than exhaustive. Prefer explicit context (`#file`, `#selection`) over broad implicit context. Start a fresh session or use `/clear` when switching to an unrelated task to prevent context clutter from degrading cache-hit quality. Do not accumulate stale file references or conversation history that is no longer relevant to the active task.
+- **2.4** **Session Continuity (No Dynamic Compaction):** Never modify, compact, or delete prior chat turns mid-session—this destroys the hardware prefix cache. If context reaches ~65% capacity, compile a comprehensive session-handoff.md to `active-repo/memories/session/session-handoff.md` (overwriting any previous handoff, and ensure `active-repo/memories/session/` is added to `.gitignore` if created). The handoff must contain a full, detailed summary of the active conversation's progress, decisions, and open threads, strictly redact all sensitive information (such as API keys, passwords, credentials, or PII), and incorporate any user-provided compaction arguments as next-session focus areas. Prompt the user to run `/clear` or open a new session with this file loaded, providing a copy-pasteable short prompt (e.g., "Resume session from memories/session/session-handoff.md") to load the handoff instantly.
+
+## 3. Intake & Scope Alignment
+
+Structure incoming requests before acting to reduce rework and catch ambiguity early.
+
+- **3.1** For non-trivial tasks, follow this 7-step checklist before coding:
+  1. Summarize the request in 1–3 sentences.
+  2. Analyze before implementing. Brainstorm when the task benefits from options, tradeoffs, or sequencing.
+  3. Ask clarifying questions when the request is ambiguous, under-specified, expectations are misplaced, or confidence is below 95%. **Clarify scope or output format before execution, not at completion.**
+  4. Make a short ordered plan or todo list.
+  5. Treat a user-provided list as full scope unless the user changes it.
+  6. Confirm if the plan could materially change scope, output, or direction.
+  7. Then proceed.
+- **3.2** Skip the intake checklist only for trivial single-step edits.
+
+## 4. Docs, Verification, and Completion
+
+Ensure every task ends with verified output, synchronized documentation, and clear follow-ups.
+
+- **4.1** State a point once, in its strongest owning section.
+- **4.2** Default live response shape when no stronger format applies: Summary -> What I'll Do -> Result or Next Action -> Validation or Limitation -> Optional Follow-Up.
+- **4.3** Stronger formats win: user formatting requests > mode-specific files > skill or prompt `Output Contract`.
+- **4.4** **Knowledge & Memory Preservation:** Preserve unique information when writing to memory. If valuable legacy or codebase knowledge does not fit standard headings, decide: new section, new file, or ask the user if the best location is ambiguous.
+- **4.5** **Documentation Sync:** After code or rule changes, sync affected docs under `docs/project-docs/` to ensure they remain the canonical source of truth.
+- **4.6** **Follow-Up Suggestions:** After completing a task, you may suggest 1–3 high-value, optional next actions. Never apply them silently. Phrasing: *"Task complete. Noticed X could be improved - want me to handle that too? or I can explain it if you want to review first."*
+
+## 5. Contract Essentials
+
+Embed the critical behavioral rules from the contract so agents follow them without opening the full contract on every task.
+
+- **5.1 Skills & Relevance:** Treat attached or mentioned skills as relevance hints, not automatic requirements. If a skill is clearly unnecessary, say so briefly and proceed directly unless the user insists. Prefer the single most relevant skill over chaining multiple.
+- **5.2 Decision Precedence:** Resolve routing, conflict, and behavior decisions in this strict order:
+  1. User's requested goal and output.
+  2. User's explicit constraints or preferences.
+  3. The active contract (`docs/eyehateagent-contract.md`) and the owning project docs under `docs/project-docs/`.
+  4. Attached context (skills, notes, or examples) treated as relevance hints unless made mandatory.
+  5. Automatic agent judgment.
+- **5.3 Failure & Fallback:** If a required project doc is missing, note the gap and create the smallest owning doc that unblocks the task. If code, tests, configs, or runtime-facing artifacts conflict with active docs and authority is unclear, do not guess: surface the conflict, cite the evidence, and ask the user before choosing the fix path.
+- **5.4 Codebase & Comment Integrity:** Maintain absolute documentation and codebase integrity when making modifications. Preserve all existing comments, docstrings, formatting, and structures that are unrelated to your changes unless explicitly instructed otherwise. Never delete unrelated comments or placeholder code silently.
+- **5.5 Completion & Verification:** End each task with the requested output and the narrowest applicable validation from `docs/project-docs/testing.md` (or a structural review with an explicit limitation if no executable check exists). Re-read output for correctness, edge cases, and unexpected side effects before finishing. Include a doc-sync check when ownership changed.

package/.github/instructions/eha-workflows.instructions.md

@@ -0,0 +1,21 @@
+---
+description: "Generated EHA workflow routing for GitHub Copilot"
+applyTo: "**"
+---
+
+# EHA Engine Workflows
+
+When a user asks to run an EHA workflow, prefer the canonical reusable prompt file listed below and preserve its output contract.
+
+- `bootstrap` -> `docs/vibes/reusable-prompts/00-project-docs-bootstrap.md`
+- `refresh` -> `docs/vibes/reusable-prompts/00-project-docs-refresh.md`
+- `parity` -> `docs/vibes/reusable-prompts/00-project-docs-parity.md`
+- `discuss` -> `docs/vibes/reusable-prompts/02-sdd-discuss.md`
+- `execute` -> `docs/vibes/reusable-prompts/01-sdd-execute.md`
+- `verify` -> `docs/vibes/reusable-prompts/00-project-docs-parity.md` (A dedicated verify workflow does not exist yet; verify currently routes to the parity workflow.)
+
+## Runtime support
+
+- GitHub Copilot support tier is **guided**
+- this install generates repo-local instructions, not slash commands
+- generated outputs stay inside the repository for transparency

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 SallMarta
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.