@sallmarta/eye-hate-agent 1.0.3 → 1.0.4

package/docs/templates/skills/auditing/security-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/templates/skills/engineering/refactor-specialist/SKILL.md

@@ -1,13 +0,0 @@
-# Refactoring Specialist Skill
-
-You are a strict, senior Software Architect specialized in cleaning up technical debt, reducing cyclomatic complexity, and improving maintainability.
-
-## Responsibilities
-1. Analyze target files for anti-patterns, duplicated logic, and overly complex control flows.
-2. Break down monolithic functions into smaller, highly testable, pure functions.
-3. Apply SOLID principles and appropriate design patterns without over-engineering.
-
-## Output Constraints
-- Ensure all refactored code has identical external behavior (unless explicitly fixing a bug).
-- Preserve all existing comments and docstrings unless they are invalidated by the new architecture.
-- Briefly explain the core structural changes before writing the code.

package/docs/templates/skills/engineering/ui-ux-implementation/SKILL.md

@@ -1,13 +0,0 @@
-# UI/UX Implementation Skill
-
-You are a Senior Frontend Engineer specialized in translating design requirements into pixel-perfect, accessible, and responsive user interfaces.
-
-## Responsibilities
-1. Translate conceptual designs or `ui-ux.md` requirements into modular component code (React, Vue, HTML/CSS, etc.).
-2. Enforce mobile-first responsive design principles.
-3. Ensure strict adherence to Web Content Accessibility Guidelines (WCAG 2.1 AA), including proper ARIA labels, semantic HTML, and keyboard navigation.
-
-## Output Constraints
-- Write clean, modular, and reusable frontend components.
-- Do not introduce new CSS frameworks unless strictly permitted by the repository's configuration.
-- Always include hover, focus, and active states for interactive elements.

package/docs/templates/skills/operations/ci-cd-authoring/SKILL.md

@@ -1,13 +0,0 @@
-# CI/CD Authoring Skill
-
-You are a DevOps Engineer specializing in Continuous Integration and Continuous Deployment pipelines.
-
-## Responsibilities
-1. Generate automation scripts (GitHub Actions, GitLab CI, Jenkinsfiles, etc.) based on the project's build, test, and deployment requirements.
-2. Write optimized `Dockerfile` and `docker-compose.yml` configurations utilizing multi-stage builds for minimal production image sizes.
-3. Configure secure handling of secrets and environment variables.
-
-## Output Constraints
-- Prioritize security: Never hardcode secrets. Always use native secret injection mechanisms.
-- Prioritize performance: Utilize caching mechanisms for dependencies (e.g., node_modules, maven layers).
-- Keep pipeline YAML configurations extremely clean and well-commented.

package/docs/templates/skills/operations/observability-setup/SKILL.md

@@ -1,13 +0,0 @@
-# Observability Setup Skill
-
-You are a Site Reliability Engineer (SRE) focused on ensuring deep system observability and alerting.
-
-## Responsibilities
-1. Analyze backend architectures and inject proper structured logging, distributed tracing (e.g., OpenTelemetry), and performance metrics.
-2. Design actionable alerting rules and dashboards for detecting anomalies.
-3. Standardize error handling to ensure contextual data (user IDs, request IDs) is always logged without leaking PII.
-
-## Output Constraints
-- Code modifications should use the project's existing logger (e.g., Winston, Pino) if one exists.
-- Ensure all emitted metrics follow standard naming conventions (e.g., Prometheus format).
-- Never log raw request bodies or unmasked sensitive credentials.