@sallmarta/eye-hate-agent 1.0.4 → 1.0.6

package/README.md

@@ -31,11 +31,14 @@ Once initialized, EHA projects a series of interactive workflows directly into y
 
 | Slash Trigger | Primary Purpose |
 | :--- | :--- |
-| **`/eha-bootstrap`** | Initializes the repository's SDD document set, generating a tailored 4-layer taxonomy (Lite, Standard, Enterprise). |
-| **`/eha-refresh`** | Re-aligns and updates the existing documentation set when project scope, stack, or directory layouts shift. |
-| **`/eha-parity`** | Audits the repository to check for document drift, stale headings, structural errors, and ownership mismatches. |
-| **`/sdd-discuss`** | Initiates collaborative scoping and brainstorming sessions to align intent and draft specs before writing code. |
-| **`/sdd-execute`** | Spec-Driven Development execution—translates agreed specifications into robust, verified, and tested code. |
+| **`/eha-bootstrap`** | Initializes the SDD document set for repos with **no existing documentation**. Scans codebase complexity, asks for a Taxonomy Tier (Lite/Standard/Enterprise), generates the tailored doc set. Stops and redirects to Refresh if existing docs or legacy docs are detected. |
+| **`/eha-refresh`** | The main workhorse for repos with **any existing documentation**. Updates active SDD docs, migrates legacy docs, converts non-SDD docs, and creates missing SDD files — all by cross-referencing the actual codebase alongside existing material. Auto-detects the appropriate Taxonomy Tier for migration scenarios. Prompts the user to resolve any drift between codebase and docs. |
+| **`/sdd-discuss`** | Collaborative brainstorming. Interviews you about edge cases, API shapes, data models, and constraints, then drafts spec snippets ready for injection into project docs. No code output. |
+| **`/sdd-execute`** | Spec-Driven code generation via strict TDD. Reads specs → generates tests → generates code → validates against architecture. Refuses to code features not in the spec. |
+
+> **Looking for parity audits?** Use the `parity-audit` skill directly:
+> `@agent use parity-audit on this repository`
+> This provides a full drift analysis without needing a dedicated command.
 
 ---
 
@@ -48,7 +51,7 @@ The EHA CLI provides a lightweight, frictionless setup and maintenance toolbelt:
 | `eha init` (or `npx...`) | Automatically scans your repo root, lets you choose your target AI agent, and projects standard rules/skills. |
 | `eha init <agent>` | Directly initiates the EHA project setup for a specific agent (e.g. `copilot`, `claude`, `antigravity`)  |
 | `eha doctor` | Performs a health check verifying that all projected rules, stubs, and workflows are present and intact. |
-| `eha remove` | Safely deletes EHA's configuration directories, manifest registries, and generated contract files from your repository. |
+| `eha remove [agent]` | Safely deletes EHA's generated contract files for the specified agent (or all agents if omitted), along with configuration files. |
 
 ---
 
@@ -67,9 +70,9 @@ in your repository. The engine will detect the version mismatch automatically, p
 To completely remove EHA from your project and device:
 
 ### 1. Remove project files
-Run the following command in your project root to clean up all projected AI files:
+To clean up projected AI files, run the following command in your project root. You can optionally specify a target agent (e.g. `claude`, `copilot`, `antigravity`) to remove only that agent's files while preserving other active installations:
 ```bash
-$ eha remove
+$ eha remove [agent]
 ```
 
 ### 2. Uninstall the CLI globally

package/bin/eha.js

@@ -24,22 +24,34 @@ const pkg = require('../package.json');
 async function promptAgentChoice(currentAgent) {
   const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
   try {
-    const defaultLabel = currentAgent || SUPPORTED_AGENT_IDS[0];
+    const runtimes = listSupportedRuntimes();
+    const defaultIndex = currentAgent
+      ? runtimes.findIndex(r => r.id === currentAgent) + 1
+      : 1;
+
+    console.log('');
+    console.log('Which agent?');
+    for (let i = 0; i < runtimes.length; i++) {
+      console.log(`  ${i + 1}. ${runtimes[i].name}`);
+    }
+
     const answer = await rl.question(
-      `Which agent? [${SUPPORTED_AGENT_IDS.join('/')}] (default: ${defaultLabel}): `,
+      `Choose [1-${runtimes.length}] (default: ${defaultIndex}): `,
     );
-    const normalized = answer.trim().toLowerCase();
-    return normalized || defaultLabel;
-  } finally {
-    rl.close();
-  }
-}
+    const trimmed = answer.trim();
 
-async function promptOverwriteOrDiscard(message) {
-  const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
-  try {
-    const answer = await rl.question(`${message} [O]verwrite / [D]iscard (default: D): `);
-    return answer.trim().toLowerCase() === 'o';
+    // Accept number or name
+    if (!trimmed) return runtimes[defaultIndex - 1].id;
+
+    const num = parseInt(trimmed, 10);
+    if (num >= 1 && num <= runtimes.length) return runtimes[num - 1].id;
+
+    // Fallback: try to match by name (backward compat)
+    const normalized = trimmed.toLowerCase();
+    const match = runtimes.find(r => r.id === normalized);
+    if (match) return match.id;
+
+    return trimmed.toLowerCase(); // Let it fall through
   } finally {
     rl.close();
   }
@@ -101,7 +113,11 @@ function printDoctorSummary(result) {
   console.log(chalk.blue('EHA doctor'));
   console.log(`  Root   : ${result.rootDir}`);
   console.log(`  Config : ${result.paths.configPath}`);
-  console.log(`  Agent  : ${result.agentId ? chalk.cyan(result.agentId) : chalk.yellow('not set — run eha init')}`);
+  const agents = result.config.agents || (result.config.agent ? [result.config.agent] : []);
+  const agentDisplay = agents.length > 0
+    ? agents.map(a => chalk.cyan(a)).join(', ')
+    : chalk.yellow('not set — run eha init');
+  console.log(`  Agents : ${agentDisplay}`);
   console.log('');
 
   if (!result.isInitialized) {
@@ -128,60 +144,60 @@ function printDoctorSummary(result) {
 async function runInitWizard(agentIdArg) {
   const rootDir = resolveRootDir();
   const config = readConfig(rootDir);
+  const manifest = readProjectManifest(rootDir);
 
   let agentId = agentIdArg ? String(agentIdArg).trim().toLowerCase() : null;
+  const isInteractive = process.stdin.isTTY && process.stdout.isTTY;
 
   if (!agentId) {
-    if (config.agent) {
-      const manifest = readProjectManifest(rootDir);
-      if (manifest.packageVersion !== pkg.version && process.stdin.isTTY && process.stdout.isTTY) {
-        const regenerate = await promptConfirm(
-          `EHA files were generated by v${manifest.packageVersion ?? 'unknown'}, current is v${pkg.version}. Regenerate?`,
-          true,
-        );
-        if (!regenerate) {
-          console.log('Skipped.');
-          return;
-        }
-        const result = initProject({ rootDir, agentId: config.agent });
-        printInitSummary(result);
-        return;
-      }
-      if (process.stdin.isTTY && process.stdout.isTTY) {
-        const overwrite = await promptOverwriteOrDiscard(
-          `EHA already set up (agent: ${chalk.cyan(config.agent)}).`,
-        );
-        if (!overwrite) {
-          console.log('Discarded.');
-          return;
-        }
-      }
-    }
-
-    if (process.stdin.isTTY && process.stdout.isTTY) {
+    if (isInteractive) {
       agentId = await promptAgentChoice(config.agent);
     } else {
       agentId = config.agent || SUPPORTED_AGENT_IDS[0];
     }
-  } else if (config.agent && config.agent !== agentId) {
-    if (process.stdin.isTTY && process.stdout.isTTY) {
-      const overwrite = await promptOverwriteOrDiscard(
-        `EHA already set up (agent: ${chalk.cyan(config.agent)}). Switch to ${chalk.cyan(agentId)}?`,
-      );
-      if (!overwrite) {
-        console.log('Discarded.');
-        return;
-      }
-    }
   }
 
-  if (!SUPPORTED_AGENT_IDS.includes(agentId)) {
+  const normalized = String(agentId).trim().toLowerCase();
+  if (!SUPPORTED_AGENT_IDS.includes(normalized)) {
+    const runtimes = listSupportedRuntimes();
+    const list = runtimes.map((r, i) => `${i + 1}. ${r.name}`).join(', ');
     console.error(
-      chalk.red(`Unsupported agent: ${agentId}.`) +
-        ` Choose one of: ${SUPPORTED_AGENT_IDS.join(', ')}.`,
+      chalk.red(`Unsupported agent: ${agentIdArg || agentId}.`) +
+        ` Choose one of: ${list}.`,
     );
     process.exit(1);
   }
+  agentId = normalized;
+
+  const installedAgents = config.agents || (config.agent ? [config.agent] : []);
+  const isAlreadyInstalled = installedAgents.includes(agentId);
+
+  if (isInteractive) {
+    if (isAlreadyInstalled) {
+      const currentVer = manifest.packageVersion || 'unknown';
+      let msg = '';
+      if (currentVer !== pkg.version) {
+        msg = `EHA is already set up for ${chalk.cyan(agentId)} (v${currentVer}). Regenerate with v${pkg.version}?`;
+      } else {
+        msg = `EHA is already set up for ${chalk.cyan(agentId)}. Regenerate/overwrite?`;
+      }
+      const confirm = await promptConfirm(msg, true);
+      if (!confirm) {
+        console.log('Skipped.');
+        return;
+      }
+    } else if (installedAgents.length > 0) {
+      const listStr = installedAgents.map(a => chalk.cyan(a)).join(', ');
+      const confirm = await promptConfirm(
+        `EHA is set up for: ${listStr}. Add ${chalk.cyan(agentId)}?`,
+        true,
+      );
+      if (!confirm) {
+        console.log('Skipped.');
+        return;
+      }
+    }
+  }
 
   const result = initProject({ rootDir, agentId });
   printInitSummary(result);
@@ -204,34 +220,64 @@ program
   });
 
 program
-  .command('remove')
-  .description('Remove EHA-generated files and config from this project')
-  .action(async () => {
+  .command('remove [agent]')
+  .description('Remove EHA-generated files and config from this project (optionally for a specific agent)')
+  .action(async (agentArg) => {
     const rootDir = resolveRootDir();
     const config = readConfig(rootDir);
+    const installedAgents = config.agents || (config.agent ? [config.agent] : []);
 
-    if (!config.agent) {
+    if (installedAgents.length === 0) {
       console.log(chalk.yellow('EHA is not initialized here. Nothing to remove.'));
       return;
     }
 
-    if (process.stdin.isTTY && process.stdout.isTTY) {
-      const confirmed = await promptConfirm(
-        `Remove EHA (agent: ${chalk.cyan(config.agent)}) from this project?`,
-      );
-      if (!confirmed) {
-        console.log('Aborted.');
+    let targetAgent = agentArg ? String(agentArg).trim().toLowerCase() : null;
+
+    if (targetAgent) {
+      if (!installedAgents.includes(targetAgent)) {
+        console.log(chalk.yellow(`Agent ${chalk.cyan(targetAgent)} is not currently set up in this project.`));
         return;
       }
-    }
 
-    const result = removeProject({ rootDir });
-    console.log('');
-    console.log(chalk.green('✓ EHA removed.'));
-    for (const f of result.removedFiles) {
-      console.log(`  ${chalk.gray(f)}`);
+      if (process.stdin.isTTY && process.stdout.isTTY) {
+        const confirmed = await promptConfirm(
+          `Remove EHA for agent: ${chalk.cyan(targetAgent)} from this project?`,
+          true,
+        );
+        if (!confirmed) {
+          console.log('Aborted.');
+          return;
+        }
+      }
+
+      const result = removeProject({ rootDir, agentId: targetAgent });
+      console.log('');
+      console.log(chalk.green(`✓ EHA files for ${chalk.cyan(targetAgent)} removed.`));
+      for (const f of result.removedFiles) {
+        console.log(`  ${chalk.gray(f)}`);
+      }
+      console.log('');
+    } else {
+      if (process.stdin.isTTY && process.stdout.isTTY) {
+        const listStr = installedAgents.map(a => chalk.cyan(a)).join(', ');
+        const confirmed = await promptConfirm(
+          `Remove EHA (all agents: ${listStr}) from this project?`,
+        );
+        if (!confirmed) {
+          console.log('Aborted.');
+          return;
+        }
+      }
+
+      const result = removeProject({ rootDir });
+      console.log('');
+      console.log(chalk.green('✓ EHA removed.'));
+      for (const f of result.removedFiles) {
+        console.log(`  ${chalk.gray(f)}`);
+      }
+      console.log('');
     }
-    console.log('');
   });
 
 program

package/docs/templates/reusable-prompts/00-project-docs-bootstrap.md

@@ -3,8 +3,28 @@
 Generate the **initial project documentation set** for a repository. 
 You must dynamically adjust your behavior based on the current state of the repository.
 
-## Step 1: State & Complexity Detection (The Adaptive Taxonomy)
-Before writing any documents, analyze the workspace to determine its state (Zero Docs vs. Unclear Docs vs. Mature Docs) and its complexity. 
+## Step 0: Pre-Flight Check
+
+Before analyzing complexity, scan the repository for existing documentation:
+
+1. Check for `docs/project-docs/` with any content.
+2. Check for `docs-legacy/`, `docs-old/`, `archive/`, or `reference/` folders with content.
+3. Check for any `docs/` folder containing structured markdown beyond a bare root README.
+
+**If ANY of the above exist:**
+STOP. Do not proceed with bootstrap. Inform the user:
+
+"I found existing documentation in this repository:
+- [list what was found]
+
+Bootstrap is for repos with no documentation. For repos with existing docs (even legacy or non-SDD format), use the **Refresh** workflow instead — it can migrate, update, and create SDD docs from your existing content combined with codebase analysis.
+
+Should I switch to the Refresh workflow?"
+
+**If NONE exist (only code and/or a bare root README):** Proceed to Step 1.
+
+## Step 1: Complexity Detection (The Adaptive Taxonomy)
+Analyze the workspace to determine its complexity by inspecting the codebase. 
 
 Based on the repository's complexity, you MUST recommend one of the following **Taxonomy Tiers**:
 
@@ -37,4 +57,4 @@ Before finishing, check that:
 3. The generated documents strictly match the approved Taxonomy Tier and structural definitions cataloged in the master registry.
 
 ## Inputs
-Use the project brief, codebase, and constraints provided below to begin your Phase 1 analysis.
+Use the project brief, codebase, and constraints provided below to begin your analysis.

package/docs/templates/reusable-prompts/00-project-docs-refresh.md

@@ -1,10 +1,33 @@
 # Project Docs Refresh Reusable Prompt
 
-Refresh the existing project documentation after a change in scope, stack, workflow, architecture, testing policy, or product behavior.
+Refresh, migrate, or create project documentation by combining the **codebase** and any **existing documentation** (active SDD docs, legacy docs, or non-SDD markdown).
 
 ## Goal
 
-Update **only the docs that own the changed information** while keeping the documentation set consistent.
+Update **only the docs that own the changed information** while keeping the documentation set consistent. When creating docs for the first time from existing material, combine codebase evidence with legacy/existing content to produce accurate SDD-compliant documentation.
+
+## Step 0: Doc State Detection
+
+Before refreshing, classify the repository's documentation state:
+
+| State | Condition | Action Path |
+|:---|:---|:---|
+| **Active SDD** | `docs/project-docs/` exists with SDD-format files (stable headings, 4-layer taxonomy) | Standard refresh: update owning docs, sync dependents |
+| **Legacy Only** | `docs-legacy/`, `docs-old/`, `archive/`, or `reference/` exist, but no `docs/project-docs/` | Migration refresh: create SDD docs from legacy content + codebase |
+| **Non-SDD Docs** | `docs/` exists with unstructured markdown (no stable headings, no taxonomy) | Conversion refresh: treat as legacy input, create SDD docs from content + codebase |
+| **Mixed** | `docs/project-docs/` exists AND legacy/reference folders also exist | Hybrid refresh: update active SDD docs + migrate unmapped legacy content + codebase |
+
+For **Legacy Only** and **Non-SDD Docs** states, auto-detect the Taxonomy Tier:
+- Examine the breadth and depth of the existing documentation + codebase complexity.
+- If content covers only core concerns (identity, architecture, status) → Tier 1 (Lite).
+- If content includes testing, API, database, or CI/CD concerns → Tier 2 (Standard).
+- If content includes governance, security, compliance, observability, i18n → Tier 3 (Enterprise).
+- When uncertain, choose the lower tier and note what would trigger upgrade.
+- State the auto-detected tier in your output so the user can override it if needed.
+
+**Dynamic Generation from Registry:** You MUST read the master registry file `docs/templates/project-docs-template/index.md` to obtain the universal stable headings schema and the unique domain-specific headings for each document type within the detected or applicable tier. Generate each document dynamically using this structural mapping.
+
+Proceed to the applicable action path.
 
 ## Required Behavior
 
@@ -19,30 +42,48 @@ Update **only the docs that own the changed information** while keeping the docu
 9. If the change affects an optional regular doc or its metadata, update `docs/project-docs/index.md` when present.
 10. If the change affects domain-specific technical guidance, update the owning guideline and `technical-guidelines/index.md` when present.
 11. When legacy or reference docs are being mapped into the active owner-doc set, classify them by the durable concern they govern rather than by the legacy folder or filename; legacy names are hints only.
-12. Normalize non-standard legacy labels by meaning when they map cleanly to an active owner. For example, `epic`, `milestone`, or `roadmap` material may map to `docs/project-docs/foundation/phases/`, while `protocol`, `procedure`, `policy`, or `standard` material may map to `docs/project-docs/technical-guidelines/` when the content is domain-specific technical guidance.
+12. Normalize non-standard legacy labels by meaning when they map cleanly to an active owner. For example, `epic`, `milestone`, or `roadmap` material may map to `docs/project-docs/foundation/phases.md`, while `protocol`, `procedure`, `policy`, or `standard` material may map to `docs/project-docs/technical-guidelines/` when the content is domain-specific technical guidance.
 13. When legacy or reference docs show that a justified optional doc should become active under `docs/project-docs/`, promote it into the active owner-doc set instead of leaving it stranded in reference-only folders.
 14. When legacy or reference docs contain domain-specific technical guidance that is still valid, create or update the relevant files under `docs/project-docs/technical-guidelines/` and create `technical-guidelines/index.md` when any guideline becomes active.
-15. When legacy or reference docs contain explicit phased planning, epic tracking, or execution-map detail that should stay active, create or update the relevant files under `docs/project-docs/foundation/phases/`, including `foundation/phases/index.md`, and register the active optional doc in `docs/project-docs/index.md`.
+15. When legacy or reference docs contain explicit phased planning, epic tracking, or execution-map detail that should stay active, create or update `docs/project-docs/foundation/phases.md` and register the active optional doc in `docs/project-docs/index.md`.
 16. If a legacy artifact could plausibly map to more than one active owner, or if preserving the legacy label may be intentional, ask the user for direction instead of guessing.
 17. Preserve valuable legacy sections (e.g., 'Decision Rationale') that do not exist in the starter templates. Decide whether this information belongs as a new custom section in an existing document or warrants a new separate file entirely. Ask the user if the best approach is ambiguous. Do not discard domain-specific knowledge just because it lacks a standard template heading.
 18. When asking for that direction, prefer a concise question that states the inferred owner and the fallback choices. Example: `I found legacy "protocol" docs that look like technical guidance. Should I 1. skip them, 2. migrate them into active guideline docs, or 3. preserve "protocol" as a project-specific doc type?`
-19. When docs are being created for the first time against an existing codebase with no prior documentation, inspect code, comments, configs, tests, and repository structure for valuable domain knowledge that goes beyond standard template headings. Surface these findings as new custom sections or new files where justified. Mark codebase-inferred facts as `Inferred from code` or `Open Question` until the user confirms them.
+19. When docs are being created for the first time against an existing codebase with no prior documentation, inspect code, comments, configs, tests, and repository structure for valuable domain knowledge that goes beyond standard template headings. Surface these findings as new custom sections or new files where justified. Mark codebase-inferred facts as `Inferred from codebase` or `Open Question` until the user confirms them.
+20. **Always cross-reference the codebase.** When creating or updating any SDD document, inspect the relevant source code, configs, tests, package manifests, CI/CD pipelines, and runtime artifacts to verify and enrich the documentation. Do not rely solely on existing docs or legacy material — the codebase is evidence.
+21. **When codebase evidence contradicts existing documentation or legacy material, do NOT silently choose one side.** Instead, prompt the user with a concise question and option selection. Example: `I found a drift between the codebase and the docs: [describe the conflict]. Which is correct? 1. The codebase (update the docs to match), 2. The docs (flag the code as needing a fix), or 3. Both are intentionally different (document the exception).` Always present at least these three options. Do not proceed until the user resolves the conflict.
+22. When creating SDD docs from legacy + codebase, actively mine:
+    - `package.json` / dependency manifests → architecture, stack, testing frameworks
+    - CI/CD configs (`.github/workflows/`, `Dockerfile`, etc.) → operations/ci-cd
+    - Test directories and test runners → development/testing
+    - Database schemas, migrations, ORM configs → development/database
+    - API route definitions, controllers, middleware → development/api-contract
+    - Environment variables, secrets management → operations/production-runbook
+    - Error handling patterns, logging setup → operations/observability-error-handling
+    - Auth/RBAC implementations → operations/security-compliance
+    - i18n config, locale files → development/internationalization
+    - README, inline comments, decision rationale → foundation/prd, architecture
+23. Mark all codebase-inferred facts as `Inferred from codebase` until the user confirms them.
 
 ### Review Sequence
 
-1. Read the change summary.
-2. Read the owning project docs.
-3. Read `docs/project-docs/index.md` and `docs/project-docs/technical-guidelines/index.md` when present.
-4. Read clearly named reference or archive folders such as `docs-legacy/`, `docs-old/`, `archive/`, or `reference/` when the repo is migrating from another documentation format.
-5. Decide whether any legacy material should be promoted into active optional docs such as `technical-guidelines/` or `foundation/phases/` instead of staying reference-only, using content and governed concern as the primary signal rather than legacy names.
-6. Read the relevant guideline docs when the change touches technical rules or implementation conventions.
-7. Identify impacted dependent docs.
-8. Refresh the owning docs first.
-9. Refresh summary or index docs second.
-10. Run a consistency pass.
+1. Run Step 0 (Doc State Detection).
+2. Read the change summary (if provided) or the user's intent.
+3. **Scan the codebase** — inspect source code, configs, tests, CI/CD pipelines, and package manifests for current truth. This step is NOT optional.
+4. Read the owning project docs (if Active SDD or Mixed state).
+5. Read `docs/project-docs/index.md` and `docs/project-docs/technical-guidelines/index.md` when present.
+6. Read legacy/reference folders when present.
+7. Read relevant guideline docs when the change touches technical rules.
+8. Identify impacted dependent docs.
+9. Cross-reference codebase findings against doc/legacy claims — resolve conflicts by prompting the user (see rule 21).
+10. Refresh/create the owning docs first (using combined codebase + docs evidence).
+11. Refresh summary or index docs second.
+12. Run a consistency pass.
 
 ## Ownership Examples
 
+For each mapping below, also inspect the corresponding codebase artifacts (source files, configs, tests) to verify and enrich the documentation.
+
 - stack or dependency changes → `foundation/architecture.md`, `development/testing.md`
 - feature scope changes → `foundation/prd.md`, `foundation/status.md`
 - detailed requirements or acceptance changes → `foundation/prd.md`, `foundation/status.md`
@@ -63,10 +104,12 @@ Update **only the docs that own the changed information** while keeping the docu
 
 Your result should state:
 
-1. which docs were updated
-2. why each doc was updated
+1. which docs were updated or created
+2. why each doc was updated or created
 3. which docs were intentionally left unchanged
 4. any remaining consistency risks or open questions
+5. which codebase-vs-doc conflicts were resolved and how (per user direction)
+6. the auto-detected tier (for Legacy Only / Non-SDD states), if applicable
 
 ## Final Pass
 
@@ -75,7 +118,9 @@ Before finishing, check that:
 1. the updated docs still match the EHA Project Doc Rules above
 2. platform instruction surfaces and skills would now read the correct project-specific truth
 3. no stale summary remains in `foundation/status.md`, `docs/project-docs/index.md`, `technical-guidelines/index.md`, or other index docs
+4. codebase-inferred facts are clearly marked and do not silently override user-confirmed truths
+5. the auto-detected tier (for Legacy Only / Non-SDD states) is stated in the output so the user can override it if needed
 
 ## Inputs
 
-Use the change summary, affected artifacts, and current project docs provided below.
+Use the change summary, affected artifacts, current project docs, legacy/reference docs, AND the current codebase (source code, configs, tests, CI/CD, package manifests) provided below.

package/docs/templates/skills/parity-audit/SKILL.md

@@ -8,7 +8,7 @@ argument-hint: "Describe the scope to audit: full repository, docs only, reusabl
 
 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.
+This skill is the dedicated parity audit capability for the EHA system. Use it when the task is analytical rather than generative.
 
 ## Required Project Inputs
 
@@ -33,17 +33,33 @@ This skill is the reusable complement to the parity reusable prompt. Use it when
 | Template maintenance | "Audit platform instruction surfaces and skills after changing the contract" |
 | Handoff preparation | "Find contradictions before handing this repo to another maintainer" |
 
-Check for disagreement across:
+## Scope
+
+Check at least these areas when present:
+
+- `docs/project-docs/`
+- `docs/project-docs/index.md`
+- `docs/project-docs/technical-guidelines/`
+- relevant code, tests, configs, or runtime-facing artifacts when a finding depends on current implementation behavior or source-of-truth ownership
+- clearly named reference or archive folders such as `docs-legacy/`, `docs-old/`, `archive/`, or `reference/`
+- platform instruction surfaces (mirrored rule files)
+- skills and reusable prompts
+- workflow docs and handoff docs
+
+### High-Value Drift Categories
 
-- 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
+- architecture and dependency rules
+- optional and conditional regular-doc inventory mismatches
+- API / integration ownership
+- technical guideline ownership, overlap, and missing guideline index coverage
+- semantic legacy-to-owner mapping mismatches where content is relevant but naming differs
+- code-vs-doc authority mismatches where current implementation and active docs disagree
+- workflow expectations
+- roadmap / phase naming
+- project identity and naming
+- undocumented domain knowledge embedded in the codebase (e.g., decision rationale in comments, architectural constraints in configs, domain rules in validation logic) that should be surfaced into project docs
 
 ## Procedure
 
@@ -51,6 +67,10 @@ Check for disagreement across:
 
 Use the active EHA rules as the default source of truth for documentation ownership unless the repository explicitly states otherwise.
 
+Treat `docs/project-docs/index.md` and `docs/project-docs/technical-guidelines/index.md` as the authoritative inventories for optional regular docs and guideline docs when present.
+
+Treat clearly named reference or archive folders such as `docs-legacy/`, `docs-old/`, `archive/`, or `reference/` as migration input only, not as owner-doc paths.
+
 ### Step 2 — Compare dependent layers
 
 Compare the source-of-truth docs against:
@@ -64,6 +84,8 @@ Compare the source-of-truth docs against:
 
 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.
 
+When a repo is migrating from another documentation format, use those reference folders to map legacy topics into the correct owner docs under `docs/project-docs/`.
+
 ### Step 3 — Classify each mismatch
 
 Every mismatch should be classified as one of:
@@ -74,7 +96,20 @@ Every mismatch should be classified as one of:
 - historical artifact
 - optional module not active in the current repo
 
-### Step 4 — Assess impact
+When evaluating legacy material, classify it by the durable concern it governs rather than by its legacy name or path. Treat names such as `epic`, `milestone`, `roadmap`, `protocol`, `procedure`, `policy`, or `standard` as hints only.
+
+Report likely mappings when content points to an active owner even if naming differs, such as phased-planning content that should map to `foundation/phases.md` or technical-rule content that should map to `technical-guidelines/`.
+
+### Step 4 — Apply structural drift rules
+
+Check for these specific structural drift conditions:
+
+- A missing `docs/project-docs/index.md` when optional or conditional regular docs exist beyond the always-required core set.
+- A missing `technical-guidelines/index.md` when guideline files exist.
+- Registry entries without matching files and files without matching registry entries, unless the registry explicitly marks them deprecated or archived.
+- A missing recommended guideline only when the repo already claims that domain is covered or the repo claims to be fully documented for that domain.
+
+### Step 5 — Assess impact
 
 Determine whether the mismatch affects:
 
@@ -85,10 +120,16 @@ Determine whether the mismatch affects:
 - release or verification confidence
 - authority certainty between docs and implementation
 
-### Step 5 — Recommend ownership-level fixes
+### Step 6 — Recommend ownership-level fixes
 
 Recommend which owning file or layer should be updated. Do not spread the same fact across more files than necessary.
 
+If a legacy artifact could plausibly map to more than one active owner, or if preserving the legacy label may be intentional, ask the user for direction instead of silently classifying it.
+
+When asking for that direction, prefer a concise question that names the fact in conflict and the likely choices. Example: `I found a conflict between the code and the docs for the active API behavior. Should I treat 1. the code as correct and update the docs, 2. the docs as correct and treat the code as drift, or 3. mark this as an intentional temporary mismatch?`
+
+If strong repository evidence already establishes the authority order for that fact, state that evidence explicitly instead of asking.
+
 ## Quality Check
 
 - Do not confuse reference material with active truth
@@ -96,6 +137,8 @@ Recommend which owning file or layer should be updated. Do not spread the same f
 - 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
+- Treat missing code evidence the same as missing doc evidence: reduce confidence, state the limitation, and avoid guessing
+- Do not fix anything unless explicitly asked
 
 ## Anti-Pattern
 
@@ -114,9 +157,10 @@ For each finding, include:
 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
+6. whether the conflict is doc-vs-doc, code-vs-doc, or registry-vs-file
+7. why it matters
+8. recommended owner to update
+9. whether user direction is required before deciding the fix path
 
 End with:
 1. highest-priority drift items

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sallmarta/eye-hate-agent",
-  "version": "1.0.4",
+  "version": "1.0.6",
   "description": "Template-and-engine toolkit for AI-agent-assisted project workflows.",
   "directories": {
     "doc": "docs"
@@ -16,13 +16,17 @@
   },
   "keywords": [
     "ai-agent",
-    "agent-workflow",
-    "cli",
+    "ai-assistant",
+    "coding-agent",
     "claude",
     "copilot",
-    "project-docs",
+    "gemini",
+    "sdd",
+    "spec-driven",
+    "spec-driven-development",
     "prompt-engineering",
-    "template"
+    "context-engineering ",
+    "meta-prompting"
   ],
   "author": "SallMarta",
   "license": "MIT",
@@ -49,4 +53,4 @@
     "commander": "^12.0.0",
     "chalk": "^4.1.2"
   }
-}
+}

package/src/engine/install.js

@@ -27,13 +27,40 @@ function resolveAgentId(agentId) {
 }
 
 function readManifest(manifestPath) {
-  return (
-    readJsonIfExists(manifestPath) || {
-      manifestVersion: 1,
+  const data = readJsonIfExists(manifestPath);
+  if (!data) {
+    return {
+      manifestVersion: 2,
       agent: null,
+      agents: [],
       files: [],
-    }
-  );
+    };
+  }
+  
+  const manifestVersion = data.manifestVersion || 1;
+  const agent = data.agent || null;
+  let agents = data.agents || [];
+  let files = data.files || [];
+  
+  if (manifestVersion === 1 && agent && agents.length === 0) {
+    agents = [
+      {
+        id: agent,
+        files: [...files],
+        updatedAt: data.updatedAt || new Date().toISOString(),
+        packageVersion: data.packageVersion || EHA_PACKAGE_VERSION,
+      }
+    ];
+  }
+
+  return {
+    manifestVersion: 2,
+    agent,
+    agents,
+    files,
+    updatedAt: data.updatedAt,
+    packageVersion: data.packageVersion,
+  };
 }
 
 function initProject({ rootDir, agentId }) {
@@ -50,41 +77,134 @@ function initProject({ rootDir, agentId }) {
   }
 
   const enginePaths = getEnginePaths(rootDir);
+  const existingManifest = readManifest(enginePaths.manifestPath);
+  const existingAgents = existingManifest.agents || [];
+
+  const agentEntry = {
+    id: normalizedAgentId,
+    files: files.map((f) => f.relativePath),
+    updatedAt: new Date().toISOString(),
+    packageVersion: EHA_PACKAGE_VERSION,
+  };
+
+  const updatedAgents = existingAgents.filter((a) => a.id !== normalizedAgentId);
+  updatedAgents.push(agentEntry);
+
+  const allFiles = new Set();
+  for (const agent of updatedAgents) {
+    for (const f of agent.files || []) {
+      allFiles.add(f);
+    }
+  }
+
   const manifest = {
-    manifestVersion: 1,
+    manifestVersion: 2,
     agent: normalizedAgentId,
-    files: files.map((f) => f.relativePath),
+    agents: updatedAgents,
+    files: [...allFiles],
     updatedAt: new Date().toISOString(),
     packageVersion: EHA_PACKAGE_VERSION,
   };
   writeJson(enginePaths.manifestPath, manifest);
-  const config = writeConfig(rootDir, { agent: normalizedAgentId });
+
+  const existingConfig = readConfig(rootDir);
+  const allAgents = [...new Set([...(existingConfig.agents || []), normalizedAgentId])];
+  const config = writeConfig(rootDir, { agent: normalizedAgentId, agents: allAgents });
 
   return {
     rootDir,
     agentId: normalizedAgentId,
     config,
-    files: manifest.files,
+    files: files.map((f) => f.relativePath),
     fileCount: files.length,
   };
 }
 
-function removeProject({ rootDir }) {
+function removeProject({ rootDir, agentId = null }) {
   const enginePaths = getEnginePaths(rootDir);
   const manifest = readManifest(enginePaths.manifestPath);
   const removedFiles = [];
 
-  for (const relativePath of manifest.files || []) {
-    const absolutePath = path.join(rootDir, relativePath);
-    removeFileIfExists(absolutePath);
-    removeEmptyParents(path.dirname(absolutePath), rootDir);
-    removedFiles.push(relativePath);
-  }
+  if (agentId) {
+    const normalizedAgentId = resolveAgentId(agentId);
+    const agentEntry = manifest.agents.find((a) => a.id === normalizedAgentId);
+    if (!agentEntry) {
+      return { rootDir, removedFiles };
+    }
+
+    const otherAgents = manifest.agents.filter((a) => a.id !== normalizedAgentId);
+    const otherFiles = new Set();
+    for (const other of otherAgents) {
+      for (const f of other.files || []) {
+        otherFiles.add(f);
+      }
+    }
+
+    const filesToRemove = (agentEntry.files || []).filter((f) => !otherFiles.has(f));
 
-  removeFileIfExists(enginePaths.manifestPath);
-  removeEmptyParents(path.dirname(enginePaths.manifestPath), rootDir);
-  removeFileIfExists(enginePaths.configPath);
-  removeEmptyParents(path.dirname(enginePaths.configPath), rootDir);
+    for (const relativePath of filesToRemove) {
+      const absolutePath = path.join(rootDir, relativePath);
+      removeFileIfExists(absolutePath);
+      removeEmptyParents(path.dirname(absolutePath), rootDir);
+      removedFiles.push(relativePath);
+    }
+
+    const remainingAgents = otherAgents;
+    if (remainingAgents.length === 0) {
+      removeFileIfExists(enginePaths.manifestPath);
+      removeEmptyParents(path.dirname(enginePaths.manifestPath), rootDir);
+      removeFileIfExists(enginePaths.configPath);
+      removeEmptyParents(path.dirname(enginePaths.configPath), rootDir);
+    } else {
+      const lastAgent = remainingAgents[remainingAgents.length - 1].id;
+      const allFiles = new Set();
+      for (const other of remainingAgents) {
+        for (const f of other.files || []) {
+          allFiles.add(f);
+        }
+      }
+
+      const updatedManifest = {
+        manifestVersion: 2,
+        agent: lastAgent,
+        agents: remainingAgents,
+        files: [...allFiles],
+        updatedAt: new Date().toISOString(),
+        packageVersion: EHA_PACKAGE_VERSION,
+      };
+      writeJson(enginePaths.manifestPath, updatedManifest);
+
+      writeConfig(rootDir, {
+        agent: lastAgent,
+        agents: remainingAgents.map((a) => a.id),
+      });
+    }
+  } else {
+    const allFiles = new Set();
+    if (manifest.agents && manifest.agents.length > 0) {
+      for (const agentEntry of manifest.agents) {
+        for (const f of agentEntry.files || []) {
+          allFiles.add(f);
+        }
+      }
+    } else {
+      for (const f of manifest.files || []) {
+        allFiles.add(f);
+      }
+    }
+
+    for (const relativePath of allFiles) {
+      const absolutePath = path.join(rootDir, relativePath);
+      removeFileIfExists(absolutePath);
+      removeEmptyParents(path.dirname(absolutePath), rootDir);
+      removedFiles.push(relativePath);
+    }
+
+    removeFileIfExists(enginePaths.manifestPath);
+    removeEmptyParents(path.dirname(enginePaths.manifestPath), rootDir);
+    removeFileIfExists(enginePaths.configPath);
+    removeEmptyParents(path.dirname(enginePaths.configPath), rootDir);
+  }
 
   return { rootDir, removedFiles };
 }

package/src/engine/runtime-adapters.js

@@ -215,7 +215,7 @@ const RUNTIME_ADAPTERS = {
       }
       files.push({
         relativePath: path.join('.claude', 'commands', 'eha', 'README.md'),
-        content: `# EHA Claude commands\n\nGenerated by \`eha init\`. Use \`/eha-bootstrap\`, \`/eha-refresh\`, \`/eha-parity\`, or \`/eha-discuss\` in Claude.\n`,
+        content: `# EHA Claude commands\n\nGenerated by \`eha init\`. Use \`/eha-bootstrap\`, \`/eha-refresh\`, \`/sdd-discuss\`, or \`/sdd-execute\` in Claude.\n`,
       });
       
       for (const skill of skills) {
@@ -268,7 +268,7 @@ const RUNTIME_ADAPTERS = {
   antigravity: {
     id: 'antigravity',
     name: 'Antigravity',
-    description: 'Generates Antigravity-compatible skills in .agents/skills/',
+    description: 'Generates Antigravity-compatible skills in .agents/skills/ and rules in .agents/rules/',
     generateFiles(rootDir, workflows, skills) {
       const files = [];
       for (const workflow of workflows) {
@@ -290,7 +290,7 @@ const RUNTIME_ADAPTERS = {
       }
       
       files.push({
-        relativePath: path.join('.agents', 'skills', 'eha-agent-rules', 'SKILL.md'),
+        relativePath: path.join('.agents', 'rules', 'eha-agent-rules.md'),
         content: buildAntigravityRuleFile(),
       });
       

package/src/engine/state.js

@@ -3,8 +3,9 @@ const path = require('node:path');
 
 const ROOT_MARKERS = ['package.json', '.git'];
 const DEFAULT_CONFIG = {
-  configVersion: 1,
+  configVersion: 2,
   agent: null,
+  agents: [],
 };
 
 function ensureDir(dirPath) {
@@ -72,9 +73,15 @@ function getEnginePaths(rootDir) {
 
 function normalizeConfig(config) {
   const candidate = config && typeof config === 'object' ? config : {};
+  const agent = candidate.agent ? String(candidate.agent).trim().toLowerCase() : null;
+  let agents = Array.isArray(candidate.agents) ? candidate.agents : [];
+  if (agent && agents.length === 0) {
+    agents = [agent];
+  }
   return {
-    configVersion: Number.isInteger(candidate.configVersion) ? candidate.configVersion : DEFAULT_CONFIG.configVersion,
-    agent: candidate.agent ? String(candidate.agent).trim().toLowerCase() : null,
+    configVersion: 2,
+    agent,
+    agents: [...new Set(agents)],
   };
 }
 

package/src/engine/workflow-registry.js

@@ -13,12 +13,6 @@ const WORKFLOW_DEFINITIONS = {
     description: 'Refresh project docs after a change in scope, stack, or behavior',
     repoRelativePath: path.join('docs', 'templates', 'reusable-prompts', '00-project-docs-refresh.md'),
   },
-  parity: {
-    id: 'parity',
-    commandName: 'parity',
-    description: 'Audit for documentation drift and ownership mismatches',
-    repoRelativePath: path.join('docs', 'templates', 'reusable-prompts', '00-project-docs-parity.md'),
-  },
   discuss: {
     id: 'discuss',
     commandName: 'discuss',

package/docs/templates/reusable-prompts/00-project-docs-parity.md

@@ -1,86 +0,0 @@
-# Project Docs Parity Reusable Prompt
-
-Audit the repository for **documentation-system drift**.
-
-## Goal
-
-Find mismatches where project docs, platform instruction surfaces (mirrored rule files), skills, reusable prompts, workflow docs, quick-reference material, or relevant implementation evidence disagree about the same fact.
-
-## Scope
-
-Check at least these areas when present:
-
-- `docs/project-docs/`
-- `docs/project-docs/index.md`
-- `docs/project-docs/technical-guidelines/`
-- relevant code, tests, configs, or runtime-facing artifacts when a finding depends on current implementation behavior or source-of-truth ownership
-- clearly named reference or archive folders such as `docs-legacy/`, `docs-old/`, `archive/`, or `reference/`
-- platform instruction surfaces (mirrored rule files)
-- `docs/templates/skills/`
-- `docs/templates/reusable-prompts/`
-- workflow docs and handoff docs
-
-### High-Value Drift Categories
-
-- stack and dependency choices
-- test commands and quality gates
-- architecture and dependency rules
-- optional and conditional regular-doc inventory mismatches
-- API / integration ownership
-- technical guideline ownership, overlap, and missing guideline index coverage
-- semantic legacy-to-owner mapping mismatches where content is relevant but naming differs
-- code-vs-doc authority mismatches where current implementation and active docs disagree
-- workflow expectations
-- roadmap / phase naming
-- project identity and naming
-- undocumented domain knowledge embedded in the codebase (e.g., decision rationale in comments, architectural constraints in configs, domain rules in validation logic) that should be surfaced into project docs
-
-## Required Behavior
-
-1. Use project docs as the primary source of truth for documentation ownership and doc-to-doc drift unless the repository explicitly states otherwise.
-2. Use the EHA Project Doc Rules above as the ownership map.
-3. Treat `docs/project-docs/index.md` and `docs/project-docs/technical-guidelines/index.md` as the authoritative inventories for optional regular docs and guideline docs when present.
-4. Treat clearly named reference or archive folders such as `docs-legacy/`, `docs-old/`, `archive/`, or `reference/` as migration input only, not as owner-doc paths.
-5. When evaluating legacy material, classify it by the durable concern it governs rather than by its legacy name or path. Treat names such as `epic`, `milestone`, `roadmap`, `protocol`, `procedure`, `policy`, or `standard` as hints only.
-6. Report likely mappings when content points to an active owner even if naming differs, such as phased-planning content that should map to `foundation/phases.md` or technical-rule content that should map to `technical-guidelines/`.
-7. Distinguish between:
-   - true contradiction
-   - stale summary
-   - historical artifact
-   - optional module not currently active
-8. When a repo is migrating from another documentation format, use those reference folders to map legacy topics into the correct owner docs under `docs/project-docs/`.
-9. Treat a missing `docs/project-docs/index.md` as drift when optional or conditional regular docs exist beyond the always-required core set.
-10. Treat a missing `technical-guidelines/index.md` as drift when guideline files exist.
-11. Treat registry entries without matching files and files without matching registry entries as drift unless the registry explicitly marks them deprecated or archived.
-12. Treat a missing recommended guideline as drift only when the repo already claims that domain is covered or the repo claims to be fully documented for that domain.
-13. When a finding depends on whether the implementation or the documentation is authoritative, inspect the relevant code, tests, configs, or runtime-facing artifacts before classifying the issue.
-14. If code and documentation conflict and the repository does not explicitly declare which source is authoritative for that fact, do not assume. Report the conflict and ask the user for direction before recommending a fix path.
-15. If a legacy artifact could plausibly map to more than one active owner, or if preserving the legacy label may be intentional, ask the user for direction instead of silently classifying it.
-16. When asking for that direction, prefer a concise question that names the fact in conflict and the likely choices. Example: `I found a conflict between the code and the docs for the active API behavior. Should I treat 1. the code as correct and update the docs, 2. the docs as correct and treat the code as drift, or 3. mark this as an intentional temporary mismatch?`
-17. If strong repository evidence already establishes the authority order for that fact, state that evidence explicitly instead of asking.
-18. Treat missing code evidence the same as missing doc evidence: reduce confidence, state the limitation, and avoid guessing.
-19. Do not fix anything unless explicitly asked.
-
-## Output Contract
-
-For each finding, include:
-
-- severity
-- fact in conflict
-- source-of-truth file
-- conflicting file
-- whether the conflict is doc-vs-doc, code-vs-doc, or registry-vs-file
-- why it matters
-- recommended owner to update
-- whether user direction is required before deciding the fix path
-
-## Final Pass
-
-End with:
-
-1. a short list of highest-priority drift items
-2. a short list of acceptable historical artifacts that should not be treated as blockers
-
-## Inputs
-
-Use the current repository docs, platform instruction surfaces, skills, reusable prompts, and any relevant workflow or summary artifacts available below.