@sallmarta/eye-hate-agent 1.0.2 → 1.0.4

package/docs/{vibes/skills/analysis → templates/skills/system-analysis}/SKILL.md

@@ -1,34 +1,29 @@
 ---
-name: analysis
+name: "system-analysis"
 description: "Project-aware expert-role analysis for architecture, debugging, trade-offs, risk, performance, requirements, and design questions. Reads project docs first, then applies expert structured reasoning to the current repository context."
 argument-hint: "Describe the problem, decision, artifact, or system to analyze"
 ---
 
-# Analysis — Project-Aware
+# System Analysis
 
 Produces a **rigorous, expert-level analysis** of a problem, decision, artifact, or system after first reading the project documentation that defines the repository's actual context.
 
 This skill is reusable across product, backend, frontend, infrastructure, monorepo, and documentation-heavy projects. It should not assume a particular stack until the project docs confirm it.
 
----
-
 ## Required Project Inputs
 
 | Document | Why it matters |
 | --- | --- |
-
 | `docs/project-docs/foundation/prd.md` | Clarifies goals, scope, stakeholders, and success metrics |
 | `docs/project-docs/foundation/architecture.md` | Defines stack, boundaries, integration model, constraints, and runtime assumptions |
 | `docs/project-docs/foundation/status.md` | Reveals maturity, roadmap, active workstreams, and known blockers |
-| `docs/project-docs/technical/testing.md` | Shows what validation exists and how strong the available evidence can be |
+| `docs/project-docs/development/testing.md` | Shows what validation exists and how strong the available evidence can be |
 | Relevant feature, workflow, API, or guideline docs | Supply domain-specific truth for the topic being analyzed |
 | Relevant code, logs, tests, or runtime evidence | Support findings with direct evidence rather than guesswork |
 
 If the required project docs are missing, note the gap explicitly and limit confidence accordingly.
 
----
-
-## When To Use
+## When to Use
 
 | Trigger | Example request |
 | --- | --- |
@@ -40,8 +35,6 @@ If the required project docs are missing, note the gap explicitly and limit conf
 | Performance diagnosis | "Analyze where this request path will bottleneck" |
 | Product or roadmap question | "Analyze whether this feature belongs in MVP" |
 
----
-
 ## Procedure
 
 ### Step 1 — Understand the question
@@ -121,22 +114,7 @@ When comparing options or hypotheses:
 - say what could change the conclusion
 - tie the recommendation back to the project's actual constraints
 
----
-
-## Output Contract
-
-Your output should include:
-
-1. summary
-2. analysis by area or component
-3. key findings ordered by importance
-4. recommendation or decision guidance
-5. risks and open questions
-6. confidence and evidence limitations when relevant
-
----
-
-## Quality Checks
+## Quality Check
 
 - No claim without evidence or clearly marked assumption
 - No false precision when evidence is weak
@@ -144,9 +122,7 @@ Your output should include:
 - No vague recommendation without an actionable next step
 - No hidden stack assumptions that were not confirmed from project docs
 
----
-
-## Anti-Patterns
+## Anti-Pattern
 
 - Listing facts without evaluating them
 - Jumping to the first plausible conclusion
@@ -154,20 +130,22 @@ Your output should include:
 - Recommending a rewrite when an incremental fix would solve the problem
 - Ignoring the project stage, roadmap, or non-goals in `prd.md` and `status.md`
 
----
-
-## Natural Prompt Shapes
+## Output Contract
 
-- "Why is this failing, and what do you think is the real cause?"
-- "Analyze this decision and tell me whether it still makes sense."
-- "What are the trade-offs and risks of these two options?"
-- "Check whether these requirements or assumptions still hold up."
+When using this skill, the output should include:
 
----
+1. summary
+2. analysis by area or component
+3. key findings ordered by importance
+4. recommendation or decision guidance
+5. risks and open questions
+6. confidence and evidence limitations when relevant
 
-## Example Requests
+## Neutral Prompt Shape
+`@agent use system-analysis on [Target Directory/Component] focusing on [Specific Goal/Flow].`
 
+## Example Prompt
+- "Analyze this decision and tell me whether it still makes sense."
 - "Analyze this module boundary for coupling risk"
 - "Analyze why this workflow fails intermittently"
-- "Analyze option A vs option B for this integration"
-- "Analyze whether this feature belongs in MVP"
+- "Analyze option A vs option B for this integration"

package/docs/{vibes/skills/test-authoring → templates/skills/system-tester}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: test-authoring
+name: "system-tester"
 description: "Project-aware expert-role verification strategy and test authoring that reads project docs to choose the right frameworks, commands, layers, and templates. Use when deciding test scope, validating regressions, choosing verification strategy, and writing or reviewing tests across any stack."
 argument-hint: "Describe the behavior, bug, feature, boundary, or artifact to test"
 ---
 
-# Test Authoring — Project-Aware
+# system-tester
 
 Produces an **expert, project-aware verification strategy and test implementation plan** by reading the repository's documentation contract first, then selecting the correct test types, commands, and conventions for the current stack.
 
@@ -12,16 +12,13 @@ This skill is intentionally **not tied to any single stack or framework**. The s
 
 This skill is **verification-strategy-first**. Its primary job is to choose the right verification boundary, check type, commands, and assertions; writing the test code is downstream of that decision when implementation is actually needed.
 
----
-
 ## Required Project Inputs
 
 Read the relevant docs before proposing or writing tests.
 
 | Document | Why it matters |
 | --- | --- |
-
-| `docs/project-docs/technical/testing.md` | Primary source for verification policy, commands, quality gates, and fallback rules |
+| `docs/project-docs/development/testing.md` | Primary source for verification policy, commands, quality gates, and fallback rules |
 | `docs/project-docs/foundation/architecture.md` | Explains runtime boundaries, architecture pattern, integrations, storage, and enforcement rules |
 | `docs/project-docs/foundation/status.md` | Reveals current implementation state, risks, and which workstream the change belongs to |
 | Relevant feature docs under `docs/project-docs/` or `docs/project-docs/technical-guidelines/` | Provide domain-specific behavior, API contracts, or user-flow expectations |
@@ -29,9 +26,7 @@ Read the relevant docs before proposing or writing tests.
 
 If one of the required docs is missing and the task depends on it, surface that explicitly and create or update the doc instead of guessing.
 
----
-
-## When To Use
+## When to Use
 
 | Trigger | Example request |
 | --- | --- |
@@ -40,13 +35,8 @@ If one of the required docs is missing and the task depends on it, surface that
 | Migration or persistence change | "Write a test plan for this migration change" |
 | Documentation-only repo change | "How should I validate a reusable prompt or platform instruction surface update?" |
 
-Use `full-verification` instead when the user wants a broad verification entry point that may need to choose between code review, docs consistency, contract review, health assessment, or executable testing.
-
-Use `code-audit` instead when the main question is whether the implementation is correct.
-
-Use `analysis` instead when the task is explaining a failure or comparing technical options rather than deciding how to verify them.
-
----
+Use `code-audit` instead when the main question is whether the implementation is correct. 
+Use `system-analysis` instead when the task is explaining a failure or comparing technical options.
 
 ## Procedure
 
@@ -133,8 +123,6 @@ Separate:
 - what was not verified
 - what still depends on manual review or future automation
 
----
-
 ### Check Selection Matrix
 
 | Scenario | Preferred check type | Read first |
@@ -145,34 +133,27 @@ Separate:
 | Interface, handler, adapter, or contract boundary | Contract or integration test | `testing.md`, API / integration docs |
 | Interactive or end-user-visible flow | UI or end-to-end test | `testing.md`, app-flow / UI docs |
 | Asynchronous, scheduled, staged, or event-driven processing | Integration or component test | `testing.md`, `architecture.md`, workflow docs |
-| Rule, skill, reusable prompt, or documentation change | Consistency review or structural validation | `docs/eyehateagent-contract.md`, `testing.md` |
+| Rule, skill, reusable prompt, or documentation change | Consistency review | EHA rules, `testing.md` |
 
----
+### Test Patterns Reference
 
-## Output Contract
-
-When using this skill, the output should include:
+#### Pattern A: Narrow Unit Or Component Test
+Arrange inputs/collaborators -> Act on boundary -> Assert on value/effect. Best for pure functions, mappers, validators.
 
-1. the recommended verification boundary
-2. the specific check type to use
-3. the project docs consulted
-4. whether new or changed tests are actually needed
-5. the command(s) to run, or the reason no executable command exists
-6. the expected assertions or behaviors to verify
-7. any residual risks or uncovered paths
+#### Pattern B: Persistence Or Contract Test
+Set up environment -> Insert/send inputs -> Read/decode output -> Assert on correctness. Best for schema, migrations, API compatibility.
 
----
+#### Pattern C: Flow Or Interaction Test
+Start from entry point -> Drive interaction -> Wait for transition -> Assert on outcome. Best for UI flows, end-to-end boundaries.
 
-## Quality Checks
+## Quality Check
 
 - Choose the narrowest check that can falsify the current assumption
 - Do not recommend commands before checking `testing.md`
 - Keep the verification boundary aligned with `architecture.md`
 - Separate what was verified from what still depends on manual review or future automation
 
----
-
-## Anti-Patterns
+## Anti-Pattern
 
 - Hardcoding one framework's tools into the skill text when that belongs in `testing.md`
 - Writing an end-to-end test when a narrow unit or contract test would falsify the same assumption
@@ -182,20 +163,21 @@ When using this skill, the output should include:
 - Treating documentation-only repositories as if they must already have executable tests
 - Confusing architecture examples with mandatory implementation details
 
----
-
-## Natural Prompt Shapes
-
-- "What is the right way to verify this change?"
-- "Which tests should we add for this API or bug fix?"
-- "Use the correct testing approach for this stack and tell me what to run."
-- "Do we actually need new tests here, and if so at what boundary?"
+## Output Contract
 
----
+When using this skill, the output should include:
+1. the recommended verification boundary
+2. the specific check type to use
+3. the project docs consulted
+4. whether new or changed tests are actually needed
+5. the command(s) to run, or the reason no executable command exists
+6. the expected assertions or behaviors to verify
+7. any residual risks or uncovered paths
 
-## Example Requests
+## Neutral Prompt Shape
+`@agent use system-tester on [Target Component/Feature] focusing on [Specific Test Boundaries].`
 
+## Example Prompt
 - "Choose the right verification for this repository-layer change"
 - "What tests should cover this API contract update?"
 - "Write a test plan for this migration change"
-- "This repo has no code yet — how should I validate a reusable prompt or platform instruction surface update?"

package/docs/templates/skills/ui-ux-design/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: "ui-ux-design"
+description: "Project-aware expert-role for frontend UI/UX design and implementation. Reads project docs first, enforces design systems, responsive bounds, accessibility, and visual testing constraints."
+argument-hint: "Describe the component, page, or interaction to build or review"
+---
+
+# ui-ux-design
+
+Produces a **project-aware, expert-level frontend implementation** by reading the repository's project docs first, then applying a rigorous component-driven methodology.
+
+This skill is reusable across any frontend framework (React, Vue, Svelte, plain HTML/CSS) or styling solution (Tailwind, CSS Modules, Styled Components).
+
+It should **not** assume a specific component library (like Material UI) or styling engine until the project docs confirm them.
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+| `docs/project-docs/development/ui-ux.md` | Defines the design system, color palette, typography, accessibility (a11y) targets, and responsive breakpoints. |
+| `docs/project-docs/foundation/prd.md` | Clarifies the target audience and expected user flows. |
+| `docs/project-docs/foundation/architecture.md` | Defines where state management lives versus pure presentation components. |
+| `docs/project-docs/development/testing.md` | Defines how the UI should be validated (e.g., unit tests, visual regression, e2e). |
+
+If the repository lacks the UI docs needed for styling or layout, call that out and create or update the missing docs instead of inventing arbitrary colors or padding values.
+
+## When to Use
+
+Use this skill when building or reviewing one of these boundary types:
+
+| Boundary type | Typical artifacts |
+| --- | --- |
+| Presentation Component | Buttons, inputs, cards, typography components. |
+| Layout / Page | Grid structures, responsive containers, navigation shells. |
+| Interaction / Animation | Modals, dropdowns, transitions, hover states. |
+| State-Connected Component | Forms, data tables, fetching wrappers. |
+
+## Procedure
+
+### Step 1 — Extract Design Constraints
+Extract from `ui-ux.md`:
+- CSS variables, Tailwind config, or design token values.
+- Responsive breakpoints (e.g., mobile-first vs desktop-first).
+- Required a11y standards (e.g., WCAG AA).
+
+### Step 2 — Separate State from Presentation
+Extract from `architecture.md`:
+- Identify if this component is "dumb" (presentation only) or "smart" (data fetching/stateful).
+- Do not mix complex global state logic into a simple presentational button.
+
+### Step 3 — Design for Edge Cases
+Before writing HTML/CSS, define:
+- Empty states (what if the data array is empty?)
+- Loading states (skeletons vs spinners).
+- Error states (inline validation vs toast notifications).
+- Overflow states (what if the text is 100 characters long?).
+
+### Step 4 — Implement with Accessibility (A11y)
+Ensure the implementation includes:
+- Proper semantic HTML (`<button>` instead of `<div onClick>`).
+- ARIA labels where semantics fall short.
+- Keyboard navigation support (focus states).
+- Sufficient color contrast.
+
+### Step 5 — Verify Responsive Behavior
+Write the code to adapt gracefully across the breakpoints defined in `ui-ux.md`. Ensure touch targets are large enough on mobile.
+
+### Step 6 — Define Verification Requirements
+Use `testing.md` to decide how this will be validated.
+Examples:
+- Component tests (e.g., React Testing Library) asserting ARIA roles.
+- Storybook stories for visual isolation.
+
+## Quality Check
+
+- Does it use hardcoded hex colors or arbitrary pixel values instead of the design system tokens?
+- Is it accessible via keyboard only?
+- Does it break layout on mobile screens?
+- Are loading and error states handled gracefully?
+- Is state managed at the correct architectural layer?
+
+## Anti-Pattern
+
+- Inventing new colors, fonts, padding, and any other relevant values that aren't in `ui-ux.md`.
+- Writing `<div onClick={...}>` instead of semantic interactive elements.
+- Ignoring loading/error states in asynchronous components.
+- Coupling global state management (like Redux or Zustand) directly into low-level UI components.
+
+## Output Contract
+
+When using this skill, the output should include:
+1. the project docs consulted (specifically the design system tokens)
+2. the component API (props/inputs)
+3. the implementation code (separated by state vs presentation if applicable)
+4. the edge cases handled (loading, empty, error, overflow)
+5. accessibility and responsive verification steps
+
+## Neutral Prompt Shape
+`@agent use ui-ux-design on [Target Theme/Tokens] focusing on [Specific Branding/Accessibility Goal].`
+
+## Example Prompt
+- "Implement this presentational card component using the project design tokens."
+- "Review this stateful component for accessibility and responsive layout issues."

package/docs/templates/skills/wireframing/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: "wireframing"
+description: "Project-aware expert-role for wireframing and prototyping. Reads project docs first, then translates requirements into structural UI flows, low-fidelity layouts, and component hierarchies without getting bogged down in visual design details."
+---
+
+# wireframing
+
+Produces a project-aware, expert-level wireframe or prototype structure by reading the repository's project docs first, then applying a user-centric structural design methodology.
+
+This skill bridges the gap between the Product Requirements Document (PRD) and the final UI/UX implementation. It focuses on layout, information architecture, user journeys, and component structure, deferring specific styling decisions to the UI/UX phase.
+
+## Required Project Inputs
+
+| Document | Why it matters |
+| --- | --- |
+| `docs/project-docs/foundation/prd.md` | Defines the user personas, core workflows, and required data points for the interface. |
+| `docs/project-docs/development/ui-ux.md` | Provides the baseline component vocabulary (e.g., standard layouts, navigation patterns) to reuse. |
+| `docs/project-docs/foundation/architecture.md` | Clarifies constraints on client-side vs server-side rendering and data availability. |
+
+If the repository lacks a PRD for the feature being wireframed, call that out and define the user goals before attempting to draw layouts.
+
+## When to Use
+
+Use this skill when planning the structure of a new interface before committing to high-fidelity design or code.
+
+| Boundary type | Typical artifacts |
+| --- | --- |
+| Page Layout | Grid structures, navigation placement, content zones. |
+| User Flow | Multi-step wizards, checkout processes, onboarding journeys. |
+| Component Hierarchy | Identifying which logical components are needed on a screen. |
+| Information Architecture | Grouping related data, defining hierarchy of importance. |
+
+## Procedure
+
+### Step 1 — Extract User Goals
+Extract from `prd.md`: What is the primary objective of the user on this screen? What are the secondary actions? What data must be visible for them to make decisions?
+
+### Step 2 — Define the Information Architecture
+Determine the hierarchy of information. The most critical data and primary calls-to-action (CTAs) must sit prominently (e.g., above the fold or in highly accessible areas). Group related information into logical sections or cards.
+
+### Step 3 — Draft the Component Structure
+Without writing CSS or final HTML, outline the required components.
+For example:
+- Navigation Header (Logo, User Menu)
+- Hero Section (Primary Title, Main CTA)
+- Data Grid (List of items with specific columns)
+- Sidebar (Filters, Categories)
+
+### Step 4 — Map the Interaction Flow
+Define how the user navigates between states:
+- What happens when a button is clicked? (Modal opens, navigation occurs, inline expansion).
+- How are empty states represented?
+- How are loading and error states handled structurally?
+
+### Step 5 — Produce the Wireframe Representation
+Generate a structural representation. This could be a text-based ASCII wireframe, a markdown-based component hierarchy tree, or a Mermaid state diagram representing the flow. Keep it strictly low-fidelity.
+
+## Quality Check
+
+- Is the primary call-to-action immediately obvious in the structure?
+- Does the layout follow established patterns from `ui-ux.md`?
+- Are edge cases (empty states, errors) accounted for in the flow?
+- Is the information hierarchy logical and aligned with the PRD?
+- Is the structure free of distracting styling details (colors, exact fonts)?
+
+## Anti-Pattern
+
+- Focusing on colors, typography, or exact pixel padding during the wireframing stage.
+- Designing layouts that assume perfect, fully populated data at all times.
+- Creating disjointed screens without defining the navigation flow between them.
+- Ignoring accessibility concerns regarding logical reading order.
+
+## Output Contract
+
+When using this skill, the output should include:
+1. the project docs consulted and user goals assumed
+2. the proposed information architecture and data hierarchy
+3. a structural wireframe (ASCII, Markdown list, or Diagram)
+4. defined interaction flows between states
+5. identified edge cases (empty, loading, error states)
+
+## Neutral Prompt Shape
+`@agent use wireframing on [Target Feature/Page] focusing on [Specific User Journey].`
+
+## Example Prompt
+- "Create a structural wireframe for the new user dashboard."
+- "Map out the component hierarchy and interaction flow for the checkout process."
+- "Draft a low-fidelity layout for the data analytics page."

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sallmarta/eye-hate-agent",
-  "version": "1.0.2",
+  "version": "1.0.4",
   "description": "Template-and-engine toolkit for AI-agent-assisted project workflows.",
   "directories": {
     "doc": "docs"
@@ -8,10 +8,7 @@
   "files": [
     "bin",
     "src",
-    "docs",
-    ".claude",
-    ".github",
-    ".agents",
+    "docs/templates",
     "README.md"
   ],
   "scripts": {
@@ -44,8 +41,9 @@
     "node": ">=18"
   },
   "bin": {
+    "eha": "./bin/eha.js",
     "eye-hate-agent": "./bin/eha.js",
-    "eha": "./bin/eha.js"
+    "eyehateagent": "./bin/eha.js"
   },
   "dependencies": {
     "commander": "^12.0.0",

package/src/engine/index.js

@@ -1,22 +1,19 @@
 const { getWorkflow, listWorkflows } = require('./workflow-registry');
-const { findRepoRoot } = require('./state');
+const { listSkills } = require('./skill-registry');
+const { findRepoRoot, readConfig } = require('./state');
 const { listSupportedRuntimes } = require('./runtime-adapters');
-const {
-  DEFAULT_RUNTIME_IDS,
-  doctor,
-  installRuntimes,
-  prepareWorkflowRun,
-  uninstallRuntimes,
-} = require('./install');
+const { SUPPORTED_AGENT_IDS, doctor, initProject, readProjectManifest, removeProject } = require('./install');
 
 module.exports = {
-  DEFAULT_RUNTIME_IDS,
+  SUPPORTED_AGENT_IDS,
   doctor,
   findRepoRoot,
   getWorkflow,
-  installRuntimes,
+  initProject,
+  listSkills,
   listSupportedRuntimes,
   listWorkflows,
-  prepareWorkflowRun,
-  uninstallRuntimes,
+  readConfig,
+  readProjectManifest,
+  removeProject,
 };