@sallmarta/eye-hate-agent 1.0.0

package/docs/vibes/skills/code-audit/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: code-audit
+description: "Project-aware expert-role code audit for bugs, risk, redundancy, dead code, weak boundaries, and logic flaws. Reads project docs first, then audits code against the repository's actual architecture and quality rules."
+argument-hint: "Point to the code, file, module, or change to audit"
+---
+
+# Code Audit — Project-Aware
+
+Performs an **expert, systematic, critical audit** of code or code-related artifacts after first reading the project documentation that defines the repository's architecture, verification model, and constraints.
+
+This skill is reusable across application code, backend services, scripts, automation, infrastructure code, and documentation-driven repositories.
+
+---
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+
+| `docs/project-docs/foundation/architecture.md` | Defines boundaries, dependencies, stack choices, and anti-violation rules |
+| `docs/project-docs/technical/testing.md` | Defines available validation and evidence strength |
+| `docs/project-docs/foundation/prd.md` | Clarifies scope, non-goals, and project stage |
+| Relevant feature or guideline docs | Clarify local behavior, workflows, APIs, schemas, or UX expectations |
+| The target code and nearby tests | Provide actual evidence for findings |
+
+---
+
+## When To Use
+
+| Trigger | Example request |
+| --- | --- |
+| Change review | "Audit this change for correctness and boundary risk" |
+| Module or file review | "Audit this module for dead code and duplication" |
+| Reliability check | "Audit this service for failure handling gaps" |
+| Architecture review | "Audit this workflow for boundary violations" |
+
+Use `full-verification` instead when the user wants one broad verification entry point across code, docs, contracts, and repository state rather than a code-first audit.
+
+---
+
+## Procedure
+
+### Step 1 — Understand intent
+
+- What is this code supposed to do?
+- What inputs, outputs, and side effects should it have?
+- Which boundary does it sit behind?
+- What project rules apply here?
+
+### Step 2 — Check correctness risks
+
+Look for:
+
+- runtime crashes
+- missing validation
+- broken assumptions around nullability or absence
+- incorrect state transitions
+- failure to handle empty, partial, duplicate, or delayed inputs
+- unsafe retry or transaction behavior
+- concurrency or sequencing defects
+- schema or serialization mismatches
+
+### Step 3 — Check boundary violations
+
+Use `architecture.md` to inspect:
+
+- layer or module import violations
+- leaked internal types across boundaries
+- controllers or UI doing business logic that belongs elsewhere
+- repositories or services depending on the wrong layer
+- transport or persistence details leaking into durable domain concepts when the project forbids that
+
+### Step 4 — Check risk and operability
+
+Look for:
+
+- security exposure
+- data-loss potential
+- missing error translation
+- logging or observability gaps
+- migration or compatibility risk
+- unbounded memory, time, or query behavior
+- hidden coupling to environment or deployment assumptions
+
+### Step 5 — Check redundancy and dead paths
+
+Look for:
+
+- duplicated logic
+- unused or unreachable branches
+- stale abstractions
+- helper functions with no callers
+- repeated literal values that should be owned centrally
+- duplicated normalization or mapping logic that should be shared
+
+### Step 6 — Check logic quality
+
+Look for:
+
+- unnecessarily complicated logic
+- wrong abstraction level
+- mismatch between code shape and problem shape
+- poor data-structure choice
+- fragile condition ordering
+- subtle off-by-one or ordering issues
+- code that technically works but will be hard to maintain safely
+
+### Step 7 — Prioritize findings
+
+Classify findings by severity:
+
+- critical
+- high
+- medium
+- low
+
+Each finding should include:
+
+- location
+- issue
+- why it matters
+- concrete corrective direction
+
+---
+
+## Output Contract
+
+Include:
+
+1. audit summary
+2. findings ordered by severity
+3. positive observations where relevant
+4. recommended next actions in priority order
+
+---
+
+## Quality Checks
+
+- No finding without evidence from the target artifact
+- No severity inflation
+- No style nitpicks disguised as bugs
+- No architecture complaint without reference to actual project boundaries
+- No recommendation that ignores project stage or available validation
+
+---
+
+## Anti-Patterns
+
+- Calling something dead code without checking workspace usage
+- Calling something a bug without defining the failure condition
+- Criticizing a pattern that the project explicitly chose in `architecture.md`
+- Recommending wide rewrites before testing a local fix or a smaller boundary change
+
+---
+
+## Natural Prompt Shapes
+
+- "Review this code for bugs, risks, and boundary issues."
+- "Audit this module like a strict senior reviewer."
+- "Check whether this implementation has correctness or security problems."
+- "Find dead code, logic flaws, and maintainability risks in this change."
+
+---
+
+## Example Requests
+
+- "Audit this service for boundary violations"
+- "Review this change for correctness risks"
+- "Check this module for dead code and duplication"
+- "Audit this workflow implementation for operability gaps"

package/docs/vibes/skills/full-verification/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: full-verification
+description: "Project-aware expert-role broad verification that reads project docs first, classifies the verification target, and routes to the best specialist skill for executable or non-executable checks across code, contracts, docs, architecture, quality, security, reliability, and project health."
+argument-hint: "Describe what should be verified against the contract, project docs, guidelines, code, APIs, architecture, or repository state"
+---
+
+# Full Verification — Project-Aware
+
+Provides an **expert, project-aware broad verification entry point** for requests that ask whether something is correct, consistent, healthy, complete, or aligned with the repository's contract and project docs.
+
+This skill is **routing-first**. Its primary job is to identify the dominant verification question and route to the single best specialist skill rather than duplicating every verification procedure itself.
+
+This skill is intentionally **not tied to any single stack or framework**. When executable checks are needed, it should select the correct framework, commands, and conventions from the project's `technical/testing.md`, `foundation/architecture.md`, and local repository patterns.
+
+---
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+| `docs/eyehateagent-contract.md` | Defines routing, ownership, precedence, and the active skill model |
+
+| `docs/project-docs/technical/testing.md` | Defines executable and non-executable verification rules, commands, and fallback policy |
+| `docs/project-docs/foundation/architecture.md` | Defines boundaries, stack, interfaces, dependency rules, and runtime assumptions |
+| `docs/project-docs/foundation/prd.md` | Defines goals, scope, non-goals, and success criteria |
+| `docs/project-docs/foundation/status.md` | Defines maturity, roadmap, active workstreams, and readiness context |
+| Relevant guideline docs under `docs/project-docs/technical-guidelines/` | Define technical standards such as API, logging, database, error-handling, code style, or design patterns |
+| Relevant code, tests, docs, contracts, and repository artifacts | Provide the actual evidence surfaces to verify against |
+
+If required project docs are missing, surface that gap explicitly and limit confidence rather than guessing.
+
+---
+
+## When To Use
+
+| Trigger | Example request |
+| --- | --- |
+| Broad verification request | "Verify this feature against the project docs, contract, and actual code" |
+| API and implementation alignment | "Check whether this API matches the docs, code, and guideline standards" |
+| Repository consistency and health check | "Evaluate this project for health, maturity, architecture drift, and consistency" |
+| Stack-aware validation request | "Use the right testing and review approach for this Go service" |
+| Requirements or decision consistency review | "Check whether these requirements and design decisions still match the repo" |
+
+Use a specialist skill directly when the dominant question is already obvious:
+
+- `test-authoring` for executable verification strategy, stack-aware test selection, and test-writing decisions
+- `code-audit` for code correctness, bug, risk, security, and boundary review
+- `parity` for repository drift across docs, platform instruction surfaces, skills, prompts, and summaries
+- `project-elevation` for forward-looking improvement and readiness planning
+- `analysis` for root-cause reasoning, trade-off evaluation, and requirement or decision analysis
+- `api-design` for API, schema, interface, or boundary contract design and review
+
+---
+
+## Procedure
+
+### Step 1 — Identify the verification target
+
+Determine what the user wants verified:
+
+- executable behavior or regression risk
+- code quality, bug risk, or security exposure
+- API or interface contract alignment
+- docs or contract consistency
+- architecture or design consistency
+- project health, maturity, readiness, or reliability posture
+- requirements, assumptions, trade-offs, or design-decision consistency
+
+### Step 2 — Gather the governing truth
+
+Read the contract and the owning project docs first.
+
+Extract:
+
+- applicable verification rules
+- current stack and boundary model
+- active guidelines and standards
+- project stage and readiness expectations
+- available evidence and validation commands
+
+If documentation and implementation disagree, determine whether the repository already defines which side is authoritative for that fact. If it does not, surface the conflict and ask the user before deciding the fix path.
+
+### Step 3 — Choose the dominant verification mode
+
+Prefer the single strongest verification path unless the user explicitly asks for a broader sweep.
+
+| Dominant verification question | Route to |
+| --- | --- |
+| How should this be verified, tested, or regression-checked in the current stack? | `test-authoring` |
+| Is this code correct, safe, consistent, and free of obvious bugs or boundary violations? | `code-audit` |
+| Does this API or interface contract match the docs, code, and boundary rules? | `api-design` |
+| Do the docs, platform instruction surfaces, skills, prompts, and repository artifacts still agree? | `parity` |
+| What should improve next, and how healthy or mature is this project at its current stage? | `project-elevation` |
+| Do the requirements, trade-offs, design decisions, or explanations hold up? | `analysis` |
+
+Example prompt shapes by verification category:
+
+| Verification category | Example prompts |
+| --- | --- |
+| Executable verification strategy | "Verify this Python bug fix and tell me which `pytest` checks should run." / "Use the right test approach for this Go handler and tell me what command to run." |
+| Code quality, bug, risk, or security review | "Verify whether this module has bug risks, security issues, or boundary violations." / "Check this implementation against the docs and code-quality rules." |
+| API or interface contract alignment | "Verify whether this API matches the project docs, guideline standards, and actual code." / "Check whether this repository contract still matches the service and its documented boundary rules." |
+| Docs, contract, or repository consistency | "Verify whether the project docs still match the current repository and contract." / "Check for drift across docs, platform instruction surfaces, skills, prompts, and quick-reference files." |
+| Architecture, health, maturity, or readiness | "Verify this project's health and maturity against the contract and current repository state." / "Check whether the architecture and current implementation still support production readiness." |
+| Requirements, trade-offs, or decision consistency | "Verify whether these requirements and design decisions still hold up against the current repo." / "Check whether this technical trade-off still makes sense given the architecture and status docs." |
+
+### Step 4 — Select the stack-aware checks
+
+When executable validation is required, choose the appropriate framework and commands from project docs and local repo conventions.
+
+Examples of the decision pattern:
+
+- Go project -> use the Go testing approach documented in `testing.md`
+- Python project -> use the Python testing approach documented in `testing.md`
+- documentation-only project -> use structural consistency review rather than inventing executable checks
+
+Do not hardcode frameworks in the skill itself when the owning repo docs should decide them.
+
+### Step 5 — Report the routed verification plan
+
+State:
+
+- what is being verified
+- which specialist skill is the best fit
+- why that route was chosen over nearby alternatives
+- what evidence and checks should be used
+- what remains outside the chosen verification path
+
+---
+
+## Output Contract
+
+When using this skill, the output should include:
+
+1. the verification target summary
+2. the dominant verification mode
+3. the specialist skill selected and why
+4. the project docs and evidence surfaces consulted
+5. the recommended checks or commands to run, or the reason no executable check exists
+6. the expected output or findings type from the selected path
+7. any residual risks or uncovered verification areas
+8. whether user direction is required before deciding between conflicting docs and implementation
+
+---
+
+## Quality Checks
+
+- Route to the single best specialist skill unless the user explicitly asks for a broader sweep
+- Do not duplicate another skill's full procedure inside this skill
+- Do not assume frameworks or commands before checking the project docs
+- Keep executable and non-executable verification clearly separated
+- State when confidence is limited by missing docs or missing evidence
+- Do not assume docs or implementation win when the repository does not define authority for the disputed fact
+
+---
+
+## Anti-Patterns
+
+- Treating verification as synonymous with writing tests
+- Hardcoding stack-specific frameworks into the skill text
+- Routing a docs-drift problem to `code-audit`
+- Routing a forward-looking improvement question to `analysis`
+- Running a multi-skill sweep by default when one dominant verification path would answer the request
+- Claiming the repository passed a check when the relevant evidence or command was never examined
+
+---
+
+## Example Requests
+
+- "Verify this feature against the project docs, contract, and actual code"
+- "Check whether this API matches the docs, code, and guideline standards"
+- "Evaluate this project for health, maturity, architecture drift, and consistency"
+- "Use the right verification approach for this stack and tell me what to run"

package/docs/vibes/skills/parity/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: parity
+description: "Expert-role parity check across project docs, platform instruction surfaces, skills, reusable prompts, workflows, quick-reference material, and implementation evidence when authority depends on the current codebase. Use when checking whether the template system still agrees with itself or when preparing cleanup after major changes."
+argument-hint: "Describe the scope to audit: full repository, docs only, reusable prompt system, platform instruction surfaces and skills, or a specific workstream"
+---
+
+# Parity — Project-Aware
+
+Performs an **expert repository-wide drift audit** to find contradictions, stale summaries, duplicated ownership, code-vs-doc authority conflicts, and historical artifacts that should be classified rather than confused with active truth.
+
+This skill is the reusable complement to the parity reusable prompt. Use it when the task is analytical rather than generative.
+
+---
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+| `docs/eyehateagent-contract.md` | Ownership map and canonical doc contract |
+| `docs/project-docs/foundation/prd.md` | Active project identity and scope |
+| `docs/project-docs/foundation/architecture.md` | Active stack and architecture truth |
+| `docs/project-docs/technical/testing.md` | Active verification truth |
+| `docs/project-docs/foundation/status.md` | Active roadmap and current-state truth |
+| Platform instruction surfaces | Automatic behavior layer |
+| Skills and reusable prompts | Reusable procedure and generation layers |
+| Workflow, handoff, and historical docs | Potentially valid references or stale artifacts |
+| Relevant code, tests, configs, and runtime-facing artifacts | Evidence for whether active docs still match the current repository |
+
+---
+
+## When To Use
+
+| Trigger | Example request |
+| --- | --- |
+| Full-repo review | "Audit the whole repository for drift after a cleanup pass" |
+| Documentation review | "Check whether project docs, reusable prompts, and the current repository still agree" |
+| Template maintenance | "Audit platform instruction surfaces and skills after changing the contract" |
+| Handoff preparation | "Find contradictions before handing this repo to another maintainer" |
+
+Use `full-verification` instead when the user asks for a broad verification entry point and repository drift is only one possible verification path.
+
+Typical audit targets include:
+
+Check for disagreement across:
+
+- project identity and naming
+- stack and dependency choices
+- architecture and dependency rules
+- test commands and quality gates
+- roadmap, phase, or epic naming
+- API or integration ownership
+- reusable prompt outputs vs project-doc contract
+- rule expectations vs documented workflow
+- active docs vs current code, tests, configs, or runtime-facing behavior when authority is disputed
+
+---
+
+## Procedure
+
+### Step 1 — Establish the source of truth
+
+Use the project docs defined by `docs/eyehateagent-contract.md` as the default source of truth for documentation ownership unless the repository explicitly states otherwise.
+
+### Step 2 — Compare dependent layers
+
+Compare the source-of-truth docs against:
+
+- platform instruction surfaces
+- skills
+- reusable prompts
+- workflow docs
+- quick references and summaries
+- relevant code, tests, configs, and runtime-facing artifacts when a finding depends on current implementation behavior or authority order
+
+If code and docs conflict and the repository does not explicitly define which side is authoritative for that fact, surface the conflict and ask the user before choosing the fix path.
+
+### Step 3 — Classify each mismatch
+
+Every mismatch should be classified as one of:
+
+- contradiction
+- stale summary
+- duplicated ownership
+- historical artifact
+- optional module not active in the current repo
+
+### Step 4 — Assess impact
+
+Determine whether the mismatch affects:
+
+- implementation safety
+- automation behavior
+- reusable prompt outputs
+- onboarding clarity
+- release or verification confidence
+- authority certainty between docs and implementation
+
+### Step 5 — Recommend ownership-level fixes
+
+Recommend which owning file or layer should be updated. Do not spread the same fact across more files than necessary.
+
+---
+
+## Output Contract
+
+For each finding, include:
+
+1. severity
+2. fact in conflict
+3. source-of-truth location
+4. conflicting location
+5. classification
+6. why it matters
+7. recommended owner to update
+8. whether user direction is required before deciding the fix path
+
+End with:
+
+1. highest-priority drift items
+2. acceptable historical artifacts that should not be treated as blockers
+
+---
+
+## Quality Checks
+
+- Do not confuse reference material with active truth
+- Do not propose fixing both sides of a contradiction when one side clearly owns the fact
+- Distinguish blocking contradictions from harmless historical leftovers
+- Keep the audit actionable, not just descriptive
+- Do not assume docs or code win when authority for the disputed fact is not explicit
+
+---
+
+## Anti-Patterns
+
+- Treating summary files as the owner when the contract defines a different source of truth
+- Reporting drift without naming the owning file or layer that should change
+- Escalating every historical artifact as a blocker instead of classifying it correctly
+- Duplicating the same fact across multiple layers as a fix for drift
+- Assuming implementation drift or documentation drift without checking whether the repository defines authority for that fact
+
+---
+
+## Natural Prompt Shapes
+
+- "Check whether the docs and repository still agree."
+- "Audit this repo for drift after the latest changes."
+- "Find contradictions across docs, platform instruction surfaces, skills, and prompts."
+- "Tell me which mismatches are real blockers versus harmless leftovers."
+
+---
+
+## Example Requests
+
+- "Audit the repository for contradictions after the latest template changes"
+- "Check whether reusable prompts and skills still match the contract"
+- "Find stale summaries in the project docs"
+- "Classify which mismatches are blockers versus historical artifacts"

package/docs/vibes/skills/project-elevation/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: project-elevation
+description: "Project-aware expert-role elevation analysis to identify missing capabilities, weak reliability, poor user or operator experience, and high-value next improvements. Reads project docs first, then suggests realistic upgrades for the repository's current stage."
+argument-hint: "Point to the project, module, workflow, or feature to evaluate for improvement"
+---
+
+# Project Elevation — Project-Aware
+
+Performs an **expert forward-looking evaluation** of a project, feature, workflow, or module to find meaningful improvements in reliability, usability, maintainability, delivery readiness, and developer experience.
+
+This skill is designed to avoid generic wish lists. It should recommend improvements that are realistic for the repository's actual scope, stage, and constraints.
+
+---
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+
+| `docs/project-docs/foundation/prd.md` | Clarifies goals, stakeholders, non-goals, and success metrics |
+| `docs/project-docs/foundation/architecture.md` | Defines stack, boundaries, and implementation constraints |
+| `docs/project-docs/foundation/status.md` | Shows maturity, roadmap, and current execution state |
+| `docs/project-docs/technical/testing.md` | Shows current verification maturity and release confidence |
+| Relevant feature, API, workflow, or UX docs | Clarify what the system already promises |
+
+---
+
+## When To Use
+
+| Trigger | Example request |
+| --- | --- |
+| Roadmap review | "Evaluate this project for the next highest-value improvements" |
+| Feature assessment | "What is missing from this workflow before it is production-ready?" |
+| Reliability review | "Where should this module be elevated for resilience first?" |
+| Delivery readiness | "What should improve before we call this MVP complete?" |
+
+Use `full-verification` instead when the user wants a broad verification pass across code, docs, contract, architecture, and project health rather than a forward-looking improvement plan.
+
+Use `analysis` instead when the main question is why something behaves the way it does, whether a decision is correct, or which option is better.
+
+Use `code-audit` instead when the main question is whether an existing implementation has correctness, logic, or boundary defects.
+
+Use `test-authoring` instead when the main question is how a change or behavior should be verified.
+
+---
+
+## Procedure
+
+### Step 1 — Understand the current state
+
+- What does the system already do?
+- Who uses it or depends on it?
+- What stage is it in: concept, prototype, MVP, production, maintenance?
+- What is explicitly out of scope?
+- What current constraints would make some improvements unrealistic right now?
+
+### Step 2 — Scan for missing failure handling
+
+Look for places where the system could fail silently or recover poorly.
+
+Examples:
+
+- no clear offline or dependency-failure behavior
+- missing retry, timeout, or rollback behavior
+- no error-state UX or operator feedback
+- missing migration or compatibility handling
+- no recovery path for partial success or interruption
+
+### Step 3 — Scan for natural feature gaps
+
+Look for missing capabilities that are implied by current user flows or system promises.
+
+Examples:
+
+- one-way workflows with no cleanup or reverse action
+- creation or capture flow with no correction, update, archival, or removal path
+- discovery or lookup behavior with no empty, degraded, or large-result handling
+- output generation or save action with no review, history, or management path
+- automation with no observability or intervention path
+- release or rollout process with no rollback, verification, or recovery checks
+
+### Step 4 — Scan for improvement opportunities
+
+Evaluate:
+
+- reliability
+- security
+- performance
+- observability
+- developer experience
+- user experience
+- maintainability
+
+Prioritize changes that improve the system materially without violating the project's scope or stage.
+
+### Step 5 — Prioritize recommendations
+
+Classify each recommendation as:
+
+- must-have
+- high-value
+- nice-to-have
+- future
+
+Tie the rating back to current goals and constraints from `prd.md` and `status.md`.
+
+Prefer the smallest realistic next step over a broad rewrite when both could address the same gap.
+
+---
+
+## Output Contract
+
+Include:
+
+1. elevation summary
+2. missing error handling
+3. missing features
+4. improvement opportunities by category
+5. recommended roadmap or next actions
+
+---
+
+## Quality Checks
+
+- No gold-plating for an early-stage project
+- No recommendation that conflicts with explicit non-goals
+- No large rewrite suggestion without a clear payoff
+- No generic checklist detached from the actual repository
+- Recommendations are prioritized and actionable
+
+---
+
+## Anti-Patterns
+
+- Suggesting enterprise-scale systems for a small internal or MVP project
+- Ignoring what the project explicitly does not want to become
+- Producing a long unranked list with no delivery guidance
+- Using this skill as a generic root-cause analysis or code-review wrapper when `analysis` or `code-audit` is the real fit
+- Recommending improvements that the current architecture cannot plausibly support without acknowledging that cost
+
+---
+
+## Natural Prompt Shapes
+
+- "What should we improve next in this project?"
+- "What is still missing before this workflow is ready?"
+- "Where are the biggest maturity or readiness gaps right now?"
+- "What are the highest-value next improvements without overbuilding?"
+
+---
+
+## Example Requests
+
+- "Evaluate this project for the next highest-value improvements"
+- "What should improve before this workflow is production-ready?"
+- "Where is the biggest reliability gap in this module?"
+- "What should we add before calling this MVP complete?"