@sallmarta/eye-hate-agent 1.0.2 → 1.0.4

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

@@ -1,170 +0,0 @@
----
-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/project-elevation/SKILL.md

@@ -1,157 +0,0 @@
----
-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?"

package/docs/vibes/skills/test-authoring/references/patterns.md

@@ -1,116 +0,0 @@
-# Test Patterns Reference — Project-Aware
-
-Quick reference for common test-pattern shapes. Use these as **structural examples**, then adapt them using the repository's `testing.md`, `architecture.md`, and local conventions.
-
----
-
-## Pattern A: Narrow Unit Or Component Test
-
-Use when you want the fastest check at a clear boundary.
-
-### Pattern A Skeleton
-
-```text
-Arrange inputs and collaborators
-Act on one function, method, or component boundary
-Assert on the returned value, state change, or emitted effect
-```
-
-### Pattern A Good Fit
-
-- pure functions
-- mappers or transformers
-- validators
-- repository or service methods with mocked dependencies
-- small boundary-level business logic
-
-### Pattern A Checklist
-
-- isolate one behavior
-- keep collaborators fake or mocked when helpful
-- assert on outcomes, not internal implementation noise
-- name tests by observable behavior
-
----
-
-## Pattern B: Persistence Or Contract Test
-
-Use when you need confidence in schema, queries, serialization, or boundary compatibility.
-
-### Pattern B Skeleton
-
-```text
-Set up an isolated persistence or contract environment
-Insert or send representative inputs
-Read back or decode the resulting output
-Assert on correctness, constraints, and error cases
-```
-
-### Pattern B Good Fit
-
-- database queries
-- repository persistence rules
-- schema evolution
-- migration behavior
-- request / response or message serialization
-- interface compatibility checks
-
-### Pattern B Checklist
-
-- include one happy path
-- include one invalid or edge case
-- assert on durable outcomes, not just returned status
-- use representative fixtures where that improves clarity
-
----
-
-## Pattern C: Flow Or Interaction Test
-
-Use when the value lies in verifying a user, operator, or system flow instead of an isolated unit.
-
-### Pattern C Skeleton
-
-```text
-Start from a realistic entry point
-Drive the interaction or workflow
-Wait for the expected state transition
-Assert on visible output, routed behavior, or side effects
-```
-
-### Pattern C Good Fit
-
-- UI interactions
-- endpoint-to-service flow
-- command or job workflows
-- integration boundaries
-- navigation or routing flows
-
-### Pattern C Checklist
-
-- keep the flow focused on one meaningful outcome
-- mock or isolate irrelevant external dependencies when possible
-- assert on the behavior the caller or user experiences
-- avoid testing multiple unrelated journeys in one case
-
----
-
-## Common Assertions To Prefer
-
-- returned values or result envelopes
-- persisted state
-- emitted events or messages
-- visible UI state
-- boundary calls that materially define behavior
-- error category and recovery path
-
-Prefer observable behavior over internal implementation details.
-
----
-
-## Common Anti-Patterns
-
-- testing too many branches in one test
-- asserting on private implementation details
-- using full integration tests when a narrow unit or contract test would falsify the same assumption
-- naming tests after implementation rather than behavior
-- copying framework-specific scaffolds without checking `testing.md`

package/docs/vibes/skills/test-authoring/references/test-types.md

@@ -1,52 +0,0 @@
-# Test Type Decision Table — Project-Aware
-
-Use this table to choose the smallest verification type that matches the actual boundary being changed. Confirm the final choice against the repository's `testing.md`.
-
-| Scenario | Preferred check type | Why |
-| --- | --- | --- |
-| Pure function, mapper, validator, parser | Unit | Fastest falsifiable check with minimal setup |
-| Internal service or repository rule | Unit or component | Verifies business behavior without unnecessary system setup |
-| Persistence query, migration, or schema rule | Persistence / migration test | Verifies durable state and compatibility at the right boundary |
-| Request, handler, controller, or public API contract | Contract or integration test | Verifies visible boundary behavior and schema expectations |
-| UI or operator interaction flow | Flow / interaction test | Verifies user-visible behavior rather than isolated internals |
-| Async job, workflow, or queue behavior | Component or integration test | Verifies sequencing, retry, and side-effect behavior |
-| Documentation, reusable prompt, or platform instruction surfaces change | Structural consistency review | Executable tests may not exist; consistency becomes the real boundary |
-
----
-
-## Test Type Summary
-
-| Type | Best for | Typical cost | Isolation |
-| --- | --- | --- | --- |
-| Unit | Pure logic and narrow behavior | Lowest | Highest |
-| Component | One internal boundary with collaborators | Low to medium | High |
-| Persistence / contract | Durable state or schema behavior | Low to medium | Medium to high |
-| Flow / interaction | User or system-visible path | Medium | Medium |
-| Integration | Real dependency or end-to-end boundary | Highest | Lowest |
-| Consistency review | Docs, reusable prompts, platform instruction surfaces, and template systems | Low | High |
-
----
-
-## Selection Rules
-
-1. Prefer the narrowest check that can prove the change is correct.
-2. Escalate to broader tests only when the boundary truly requires it.
-3. Use project docs to choose commands, harnesses, and file placement.
-4. When no executable validation exists, make the structural review explicit rather than pretending the repo is fully testable.
-
----
-
-## Naming Guidance
-
-Prefer behavior-driven names such as:
-
-- `returns empty result when no records match`
-- `rejects invalid payload when required field is missing`
-- `shows retry state after dependency timeout`
-- `persists latest progress after successful update`
-
-Avoid placeholder names such as:
-
-- `test1`
-- `happy path`
-- `error case`