@sallmarta/eye-hate-agent 1.0.3 → 1.0.4

package/docs/templates/skills/{engineering/test-authoring → 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 | EHA rules, `testing.md` |
-
----
+| Rule, skill, reusable prompt, or documentation change | Consistency review | EHA rules, `testing.md` |
 
-## Output Contract
+### Test Patterns Reference
 
-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,196 +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?"
-
-
----
-
-# 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`
-
-
----
-
-# 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`

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.3",
+  "version": "1.0.4",
   "description": "Template-and-engine toolkit for AI-agent-assisted project workflows.",
   "directories": {
     "doc": "docs"

package/src/engine/index.js

@@ -1,4 +1,5 @@
 const { getWorkflow, listWorkflows } = require('./workflow-registry');
+const { listSkills } = require('./skill-registry');
 const { findRepoRoot, readConfig } = require('./state');
 const { listSupportedRuntimes } = require('./runtime-adapters');
 const { SUPPORTED_AGENT_IDS, doctor, initProject, readProjectManifest, removeProject } = require('./install');
@@ -9,6 +10,7 @@ module.exports = {
   findRepoRoot,
   getWorkflow,
   initProject,
+  listSkills,
   listSupportedRuntimes,
   listWorkflows,
   readConfig,

package/src/engine/install.js

@@ -4,7 +4,7 @@ const { version: EHA_PACKAGE_VERSION } = require('../../package.json');
 
 const { listWorkflows } = require('./workflow-registry');
 const { listSkills } = require('./skill-registry');
-const { getRuntimeAdapter, listSupportedRuntimes } = require('./runtime-adapters');
+const { getRuntimeAdapter, listSupportedRuntimes, SUPPORTED_AGENT_IDS } = require('./runtime-adapters');
 const {
   ensureDir,
   getBundledAssetPath,
@@ -18,8 +18,6 @@ const {
   writeText,
 } = require('./state');
 
-const SUPPORTED_AGENT_IDS = ['claude', 'copilot', 'antigravity'];
-
 function resolveAgentId(agentId) {
   const normalized = String(agentId || '').trim().toLowerCase();
   if (!SUPPORTED_AGENT_IDS.includes(normalized)) {

package/src/engine/runtime-adapters.js

@@ -5,6 +5,8 @@ const path = require('node:path');
 
 const { getBundledAssetPath } = require('./state');
 
+const SUPPORTED_AGENT_IDS = ['claude', 'copilot', 'antigravity'];
+
 // Compact EHA rules embedded in every generated command file so the agent
 // has all structural context without needing any external file reference.
 const EHA_COMPACT_RULES = `## EHA Project Doc Rules
@@ -12,12 +14,12 @@ const EHA_COMPACT_RULES = `## EHA Project Doc Rules
 **4-Layer Taxonomy.** All project docs live under \`docs/project-docs/\`:
 - \`foundation/\` — prd, architecture, workflow, status, phases, changelog, feature-inventory
 - \`operations/\` — ci-cd, production-runbook, governance, compliance, observability, security
-- \`technical/\` — testing, api-contract, database, ui-ux, error-handling, internationalization
+- \`development/\` — testing, api-contract, database, ui-ux, error-handling, internationalization
 - \`technical-guidelines/\` — domain-specific cross-cutting rules (API, database, logging, etc.)
 
 **Legacy/Reference Docs:** Treat folders named \`archive/\`, \`docs-legacy/\`, or \`reference/\` as secondary migration input only, never as authoritative active truth.
 
-**Mandatory core docs:** \`index.md\`, \`getting-started.md\`, \`foundation/prd.md\`, \`foundation/architecture.md\`, \`foundation/workflow.md\`, \`foundation/status.md\`, \`foundation/phases.md\`, \`operations/ci-cd.md\`, \`operations/production-runbook.md\`, \`technical/testing.md\`, \`technical/api-contract.md\`, \`technical/database.md\`, \`technical/ui-ux.md\`.
+**Mandatory core docs:** \`index.md\`, \`getting-started.md\`, \`foundation/prd.md\`, \`foundation/architecture.md\`, \`foundation/workflow.md\`, \`foundation/status.md\`, \`foundation/phases.md\`, \`operations/ci-cd.md\`, \`operations/production-runbook.md\`, \`development/testing.md\`, \`development/api-contract.md\`, \`development/database.md\`, \`development/ui-ux.md\`.
 
 **Authority order:** project docs → codebase → agent judgment. When docs conflict, the owning doc wins. When code and docs conflict and authority is unclear, surface the conflict and ask the user — do not guess.
 
@@ -27,7 +29,7 @@ const EHA_COMPACT_RULES = `## EHA Project Doc Rules
 - Vision, personas, requirements → \`foundation/prd.md\`
 - Stack and architecture → \`foundation/architecture.md\`
 - Dev loop and PR process → \`foundation/workflow.md\`
-- Verification commands and quality gates → \`technical/testing.md\`
+- Verification commands and quality gates → \`development/testing.md\`
 - Execution plan and progress → \`foundation/status.md\`
 - Sprint tracking and backlogs → \`foundation/phases.md\`
 - Optional doc inventory → \`index.md\`
@@ -66,7 +68,7 @@ function loadRuleContent(agentId) {
   let content = fs.readFileSync(rulePath, 'utf8').replace(/^\n+/, '');
   
   if (agentId) {
-    const agentsToFilter = ['claude', 'antigravity', 'copilot'].filter(a => a !== agentId.toLowerCase());
+    const agentsToFilter = SUPPORTED_AGENT_IDS.filter(a => a !== agentId.toLowerCase());
     for (const a of agentsToFilter) {
       const regex = new RegExp(`^\\s*-\\s*\\*\\*${a}.*$\\n?`, 'gmi');
       content = content.replace(regex, '');
@@ -316,4 +318,5 @@ function listSupportedRuntimes() {
 module.exports = {
   getRuntimeAdapter,
   listSupportedRuntimes,
+  SUPPORTED_AGENT_IDS,
 };