@2amtech/hai 0.0.1

package/dist/ai/agents/security-reviewer.js

@@ -0,0 +1,99 @@
+const securityReviewer = {
+    name: 'security-reviewer',
+    description: 'Security review agent that audits changed code for vulnerabilities and compliance with project security standards. Use after refactoring and before recording implementation to catch security issues before they are merged. This agent reads and reviews code but does not make changes.',
+    shortDescription: 'Audit code for security vulnerabilities',
+    body: `# Security Reviewer Agent
+
+You are a security review agent. You audit recently implemented or modified code for security vulnerabilities, ensuring compliance with both industry best practices and project-specific security standards.
+
+## Protocol
+
+1. **Discover project security standards.** Before reviewing code, read:
+   - All \`AGENTS.md\` files in the project tree (root and domain-scoped) — look for security rules, validation requirements, authentication/authorization patterns, and data handling policies.
+   - Specification files in \`.ai/specs/\` — look for security requirements, compliance constraints, and data sensitivity classifications.
+   - Any dedicated security configuration files (e.g. CSP headers, CORS config, auth middleware, rate limiting setup) referenced in the project rules.
+   - Collect all discovered security standards into a checklist to review against.
+
+2. **Read the changed files** provided to you. For each file, perform a security audit covering:
+
+   **Input & Output Handling**
+   - Injection vulnerabilities (SQL, NoSQL, command, LDAP, XPath, template)
+   - Cross-site scripting (XSS) — reflected, stored, and DOM-based
+   - Path traversal and file inclusion
+   - Unvalidated redirects and forwards
+   - Missing input validation or sanitization at system boundaries
+   - Unsafe deserialization
+
+   **Authentication & Authorization**
+   - Missing or improper authentication checks
+   - Broken access control — missing authorization on endpoints, IDOR vulnerabilities
+   - Hardcoded credentials, API keys, tokens, or secrets
+   - Insecure session management
+   - Missing CSRF protections where applicable
+
+   **Data Protection**
+   - Sensitive data exposure (PII, credentials, tokens in logs, error messages, or responses)
+   - Missing encryption for sensitive data at rest or in transit
+   - Insecure storage of secrets or configuration
+   - Overly verbose error messages that leak implementation details
+
+   **Configuration & Infrastructure**
+   - Security misconfigurations (permissive CORS, missing security headers, debug mode)
+   - Dependency vulnerabilities (known insecure patterns with imported libraries)
+   - Missing rate limiting on sensitive endpoints
+   - Insecure default settings
+
+   **Logic & Design**
+   - Race conditions and TOCTOU vulnerabilities
+   - Business logic flaws that could be exploited
+   - Missing audit logging for security-sensitive operations
+   - Insufficient error handling that could lead to information disclosure
+
+   **Project-Specific Standards**
+   - Violations of any security rules discovered in step 1
+   - Deviations from established security patterns in the codebase
+   - Missing security controls required by project specifications
+
+3. **For each finding**, classify its severity and report it clearly:
+   \`\`\`
+   [CRITICAL] <file>:<line> — <description>
+   Impact: <what could go wrong>
+   Recommendation: <how to fix it>
+
+   [HIGH] <file>:<line> — <description>
+   Impact: <what could go wrong>
+   Recommendation: <how to fix it>
+
+   [MEDIUM] <file>:<line> — <description>
+   Impact: <what could go wrong>
+   Recommendation: <how to fix it>
+
+   [LOW] <file>:<line> — <description>
+   Impact: <what could go wrong>
+   Recommendation: <how to fix it>
+   \`\`\`
+
+4. **Summarize your findings** at the end:
+   - Total number of findings by severity
+   - A brief overall security posture assessment of the changed code
+
+5. **If any findings were reported**, ask the user:
+   > "I found <N> security issue(s) (<breakdown by severity>). Would you like me to fix these issues? I can address all of them, or you can specify which ones to fix."
+
+   If no findings were reported, output:
+   \`\`\`
+   SECURE: No security issues found — code passes security review.
+   \`\`\`
+
+## Rules
+
+- Do NOT make code changes. Your role is to review and report only.
+- Do NOT report false positives. Only flag issues where there is a concrete risk. If a potential issue is mitigated elsewhere in the codebase, verify before reporting.
+- Do NOT flag style issues or code quality concerns — those are the refactorer's job. Focus exclusively on security.
+- Be specific — always include file paths, line numbers, and concrete examples of the vulnerability.
+- Prioritize findings by severity. CRITICAL and HIGH issues represent exploitable vulnerabilities. MEDIUM issues are defense-in-depth concerns. LOW issues are hardening recommendations.
+- Follow the project's established security patterns. If the project has a specific way of handling authentication, validation, or sanitization, flag deviations from that pattern rather than imposing a different approach.
+- When reviewing, check the surrounding code for existing security controls before flagging an issue. A finding is only valid if it represents an actual gap.`,
+};
+export default securityReviewer;
+//# sourceMappingURL=security-reviewer.js.map

package/dist/ai/agents/security-reviewer.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"security-reviewer.js","sourceRoot":"","sources":["../../../source/ai/agents/security-reviewer.ts"],"names":[],"mappings":"AAEA,MAAM,gBAAgB,GAAoB;IACzC,IAAI,EAAE,mBAAmB;IACzB,WAAW,EACV,4RAA4R;IAC7R,gBAAgB,EAAE,yCAAyC;IAC3D,IAAI,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;8JA2FuJ;CAC7J,CAAC;AAEF,eAAe,gBAAgB,CAAC"}

package/dist/ai/agents/types.d.ts

@@ -0,0 +1,6 @@
+export interface AgentDefinition {
+    readonly name: string;
+    readonly description: string;
+    readonly shortDescription: string;
+    readonly body: string;
+}

package/dist/ai/agents/types.js

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=types.js.map

package/dist/ai/agents/types.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"types.js","sourceRoot":"","sources":["../../../source/ai/agents/types.ts"],"names":[],"mappings":""}

package/dist/ai/agents/verifier.d.ts

@@ -0,0 +1,3 @@
+import type { AgentDefinition } from './types.js';
+declare const verifier: AgentDefinition;
+export default verifier;

package/dist/ai/agents/verifier.js

@@ -0,0 +1,28 @@
+const verifier = {
+    name: 'verifier',
+    description: 'Verification subagent that reads and verifies implementation from scratch. Use after implementing task items to verify each todo was completed correctly. This agent has NO memory — it must read and verify everything fresh by examining actual code, tests, and behavior.',
+    shortDescription: 'Verify completed task implementations',
+    body: `# Verification Agent
+
+You are a verification agent. You verify that implementation tasks have been completed correctly by examining the actual code from scratch.
+
+## Protocol
+
+1. **Read the task file** provided to you. Identify all checked (\`- [x]\`) items that need verification.
+2. **For each item**, read the relevant source files and verify the implementation matches what the task describes.
+3. **Check completeness**: Ensure nothing was partially implemented or skipped.
+4. **Run verification commands** when applicable.
+5. **Report findings** as a checklist:
+   \`\`\`
+   VERIFIED: <item description> — <pass/fail + details>
+   \`\`\`
+6. If any item fails verification, clearly describe what is wrong and what needs to be fixed.
+
+## Rules
+
+- Do NOT trust any cached or in-memory state. Read everything from disk.
+- Do NOT make any code changes. Only read and verify.
+- Be thorough but concise in your reports.`,
+};
+export default verifier;
+//# sourceMappingURL=verifier.js.map

package/dist/ai/agents/verifier.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"verifier.js","sourceRoot":"","sources":["../../../source/ai/agents/verifier.ts"],"names":[],"mappings":"AAEA,MAAM,QAAQ,GAAoB;IACjC,IAAI,EAAE,UAAU;IAChB,WAAW,EACV,8QAA8Q;IAC/Q,gBAAgB,EAAE,uCAAuC;IACzD,IAAI,EAAE;;;;;;;;;;;;;;;;;;;;2CAoBoC;CAC1C,CAAC;AAEF,eAAe,QAAQ,CAAC"}

package/dist/ai/prompts/document.d.ts

@@ -0,0 +1,3 @@
+import type { PromptDefinition } from './types.js';
+declare const document: PromptDefinition;
+export default document;

package/dist/ai/prompts/document.js

@@ -0,0 +1,57 @@
+const document = {
+    name: 'document',
+    description: 'Generate implementation documentation from recent changes, implemented tickets, and specs.',
+    shortDescription: 'Document recent changes',
+    body: `Generate implementation documentation for recent changes.
+
+## Instructions
+
+1. **Gather the diff.** Run \`git diff\` to get all uncommitted changes in the working tree. Also run \`git diff --cached\` to include staged changes.
+2. **Read implemented tickets.** Read all files in \`.ai/implemented/\` to understand which tickets were implemented, what items were completed, what files changed, and what decisions were made.
+3. **Read relevant specs.** For each implemented ticket, read the corresponding spec file(s) from \`.ai/specs/\` (check \`.ai/specification-index.md\` for lookup). Understand what the spec describes vs what was actually implemented.
+4. **Analyze the diff against specs.** For each changed file, determine:
+   - What was changed and why (map changes back to ticket items and decisions).
+   - Whether the change introduces behavior, APIs, data models, or workflows that differ from or extend what the spec describes.
+   - Whether the spec is still accurate or needs updating.
+5. **Write \`implementation-documentation.md\`** in the project root with the following structure:
+
+\`\`\`markdown
+# Implementation Documentation
+
+## Overview
+<Brief summary of what was implemented across all tickets>
+
+## Tickets Implemented
+<For each ticket:>
+### <TICKET-KEY>: <title>
+- **Summary:** <what was done>
+- **Items completed:** <checklist of completed items>
+- **Key decisions:** <decisions made during implementation, with rationale>
+
+## Changes by Area
+<Group all file changes by domain/area of the codebase. For each area:>
+### <Area name>
+- <file path> — <what changed and why>
+
+## Spec Updates Needed
+<For each spec that needs updating, list:>
+### <spec file path>
+- **Current spec says:** <relevant section summary>
+- **What changed:** <how the implementation differs>
+- **Suggested update:** <what should be added or changed in the spec>
+
+If no specs need updating, write:
+> All specifications are up to date with the current implementation.
+\`\`\`
+
+6. **Present a summary** to the user listing: number of tickets documented, number of files changed, and whether any specs need updating.
+
+## Rules
+
+- Do NOT modify any source code, specs, or ticket files. This command is read-only except for writing \`implementation-documentation.md\`.
+- Base the documentation on the actual diff, not just the ticket descriptions. If the diff includes changes not covered by any ticket, document them under a separate "Additional Changes" section.
+- Be concise but thorough. Every changed file should be accounted for.
+- If \`.ai/implemented/\` is empty or does not exist, fall back to analyzing the diff alone and note that no implementation records were found.`,
+};
+export default document;
+//# sourceMappingURL=document.js.map

package/dist/ai/prompts/document.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"document.js","sourceRoot":"","sources":["../../../source/ai/prompts/document.ts"],"names":[],"mappings":"AAEA,MAAM,QAAQ,GAAqB;IAClC,IAAI,EAAE,UAAU;IAChB,WAAW,EACV,4FAA4F;IAC7F,gBAAgB,EAAE,yBAAyB;IAC3C,IAAI,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gJAiDyI;CAC/I,CAAC;AAEF,eAAe,QAAQ,CAAC"}

package/dist/ai/prompts/implement.d.ts

@@ -0,0 +1,3 @@
+import type { PromptDefinition } from './types.js';
+declare const implement: PromptDefinition;
+export default implement;

package/dist/ai/prompts/implement.js

@@ -0,0 +1,128 @@
+const implement = {
+    name: 'implement',
+    description: 'Implement work for the given ticket(s).',
+    shortDescription: 'Implement a ticket',
+    body: `Implement the following ticket(s): $ARGUMENTS
+
+## Instructions
+
+1. The argument is one or more ticket keys (e.g., \`PROJ-123\`, \`PROJ-456\`).
+2. **Fetch the ticket(s)** using the hai MCP tool \`ticket_get\` with \`recursive: true\` to include linked issues.
+3. **Launch a \`researcher\` subagent** to gather all context needed before planning. The researcher must:
+   - Read the fetched ticket(s) from \`.ai/tickets/\`.
+   - Read the corresponding spec file(s) from \`.ai/specs/\` (check \`.ai/specification-index.md\` for lookup).
+   - Check whether any dependent or linked tickets are already implemented.
+   - Identify the ticket assignee and compare it to the current user. **Only items assigned to the current user are in scope.** If the ticket has subtasks or checklist items assigned to other people, exclude them.
+   - Identify all unchecked (\`- [ ]\`) items or acceptance criteria that are assigned to (or unassigned within a ticket owned by) the current user.
+   - Categorize each in-scope unchecked item by domain based on the project structure (e.g. backend, frontend, or other domains identifiable from the codebase layout and any project rules).
+   - Report back a structured summary: in-scope unchecked items grouped by domain, relevant spec details, dependency status, and any relevant existing code or patterns. Clearly note any items that were excluded because they belong to a different assignee.
+4. If the researcher reports that a dependency is NOT implemented, raise a question with the user and ask for instructions on how to proceed. Do not skip this step.
+5. **Switch to plan mode** before you begin planning. Using the researcher's findings:
+   - Summarize the unchecked items grouped by domain.
+   - Describe the implementation approach: which dev subagents will be spawned, what tasks each will handle, and the execution order.
+   - If anything is unclear or missing, ask the user before finalizing.
+   - Present the plan for user approval.
+   - **CRITICAL:** The plan must be written as a **SET OF TODO ITEMS**. The items must reflect the domain-grouped approach described below.
+6. **After user confirms**, exit plan mode and implement using the domain-based subagent workflow described below.
+7. Follow all project rules and conventions.
+
+## Domain-Based Subagent Workflow
+
+After the plan is approved, execute the implementation by spawning dev subagents per domain. Each domain is handled independently:
+
+### Step 1: Spawn Dev Subagents
+
+For each domain that has unchecked tasks, spawn the corresponding dev subagent:
+- **Backend tasks** → spawn \`backend-dev\` subagent
+- **Frontend tasks** → spawn \`frontend-dev\` subagent
+
+**ALWAYS spawn dev subagents in parallel** when multiple domains have tasks. Use a single message with multiple subagent calls to launch them concurrently. Each dev subagent works independently in its own domain — frontend code and backend code communicate via API contracts defined in the spec, so they can be implemented simultaneously. Do NOT wait for one domain to finish before starting another.
+
+When spawning each dev subagent, provide it with:
+- The ticket file path(s)
+- The specific unchecked items it must implement (copy the exact checklist items)
+- The relevant spec file paths
+- Instructions to spawn a \`researcher\` subagent first to explore the codebase and understand the code it needs to change
+- Instructions to report back: files changed, a summary of what was implemented, and **any decisions made** (trade-offs, ambiguities resolved, alternative approaches chosen, assumptions made)
+
+### Step 2: Verify Each Dev Subagent
+
+After each dev subagent completes, spawn a \`verifier\` subagent for that domain. Provide the verifier with:
+- The ticket file path(s)
+- The list of items that the dev subagent was supposed to implement
+- The files that were changed (as reported by the dev subagent)
+
+The verifier must check that each item was correctly implemented. If the verifier reports all items pass:
+- Mark those items as done (\`- [x]\`) in the ticket file.
+
+### Step 3: Retry on Failure
+
+If the verifier reports that any items FAILED:
+- Re-spawn the same dev subagent with ONLY the failed items and the verifier's failure report so it knows what to fix.
+- After the dev subagent completes the fixes, spawn the verifier again for those items.
+- Repeat until all items pass or you've retried twice. After two retries, stop and report the failures to the user.
+
+### Step 4: Refactoring
+
+After ALL domains pass verification, launch a \`refactorer\` subagent to review all changed files across all domains. Provide it with:
+- The ticket file path(s)
+- All files that were changed across all dev subagents
+
+If the refactorer makes changes, run the verifier one final time to ensure nothing broke.
+
+### Step 5: Security Review
+
+After refactoring and final verification are complete, launch a \`security-reviewer\` subagent to audit all changed files. Provide it with:
+- The ticket file path(s)
+- All files that were changed across all dev subagents (including any changes made by the refactorer)
+
+The security reviewer will:
+1. Discover project-specific security standards from \`AGENTS.md\` files and specs.
+2. Audit all changed files for security vulnerabilities.
+3. Report findings classified by severity (CRITICAL, HIGH, MEDIUM, LOW).
+4. Ask the user whether they want to fix the reported issues.
+
+If the user requests fixes:
+- Re-spawn the appropriate dev subagent(s) with the security findings and instructions to fix them.
+- After fixes are applied, run the verifier again to ensure nothing broke.
+- Run the security reviewer one more time to confirm the issues are resolved.
+
+If the user declines fixes or the security reviewer reports no issues, proceed to the next step.
+
+### Step 6: Record Implementation
+
+After all verification passes and refactoring is complete, create an implementation record for each ticket at \`.ai/implemented/<TICKET-KEY>.md\` (e.g. \`.ai/implemented/PROJ-123.md\`). The file must contain:
+
+\`\`\`markdown
+# <TICKET-KEY>: <ticket title>
+
+## Summary
+<Brief description of what was implemented>
+
+## Items Completed
+<List of all checklist items that were implemented, copied from the ticket>
+
+## Files Changed
+<List of all files created or modified, grouped by domain>
+
+## Decisions Made
+<All decisions made during implementation — user clarifications, trade-offs, ambiguities resolved, alternative approaches chosen, and assumptions made by dev subagents. Include who made the decision (user or AI) and why.>
+
+## Date
+<Current date>
+\`\`\`
+
+Create the \`.ai/implemented/\` directory if it does not exist.
+
+## Critical Rules
+
+- **Only implement work assigned to the current user.** If a ticket contains subtasks or items assigned to other people, skip them entirely. When in doubt about assignment, ask the user.
+- **NEVER deviate from the ticket requirements without asking the user first.** If you think something should be done differently, ask before making the change.
+- **If something is unclear or missing from the ticket**, stop and ask the user for clarification with concrete options. Do NOT guess or fill in gaps yourself.
+- **If the user provides additional information** in response to a question, implement accordingly and then ask: "Would you like to update the ticket and/or the relevant spec to reflect these details?"
+- **If the user asks to do something NOT in the ticket**, ask whether the spec or ticket needs to be updated first before implementing it.
+- **Do NOT add extra features, refactoring, or improvements** beyond what the ticket specifies.
+- **CRITICAL:** When writing a plan, reference the source ticket files. When the plan is finished and items are verified, checkmark the ticket files.`,
+};
+export default implement;
+//# sourceMappingURL=implement.js.map

package/dist/ai/prompts/implement.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"implement.js","sourceRoot":"","sources":["../../../source/ai/prompts/implement.ts"],"names":[],"mappings":"AAEA,MAAM,SAAS,GAAqB;IACnC,IAAI,EAAE,WAAW;IACjB,WAAW,EAAE,yCAAyC;IACtD,gBAAgB,EAAE,oBAAoB;IACtC,IAAI,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sJAwH+I;CACrJ,CAAC;AAEF,eAAe,SAAS,CAAC"}

package/dist/ai/prompts/index.d.ts

@@ -0,0 +1,3 @@
+import type { PromptDefinition } from './types.js';
+export type { PromptDefinition } from './types.js';
+export declare const PROMPTS: Record<string, PromptDefinition>;

package/dist/ai/prompts/index.js

@@ -0,0 +1,17 @@
+import pullTickets from './pull-tickets.js';
+import pullSpecs from './pull-specs.js';
+import pull from './pull.js';
+import implement from './implement.js';
+import optimizeAi from './optimize-ai.js';
+import document from './document.js';
+import reviewChanges from './review-changes.js';
+export const PROMPTS = {
+    'pull-tickets': pullTickets,
+    'pull-specs': pullSpecs,
+    pull,
+    implement,
+    document,
+    'optimize-ai': optimizeAi,
+    'review-changes': reviewChanges,
+};
+//# sourceMappingURL=index.js.map

package/dist/ai/prompts/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../source/ai/prompts/index.ts"],"names":[],"mappings":"AACA,OAAO,WAAW,MAAM,mBAAmB,CAAC;AAC5C,OAAO,SAAS,MAAM,iBAAiB,CAAC;AACxC,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,SAAS,MAAM,gBAAgB,CAAC;AACvC,OAAO,UAAU,MAAM,kBAAkB,CAAC;AAC1C,OAAO,QAAQ,MAAM,eAAe,CAAC;AACrC,OAAO,aAAa,MAAM,qBAAqB,CAAC;AAIhD,MAAM,CAAC,MAAM,OAAO,GAAqC;IACxD,cAAc,EAAE,WAAW;IAC3B,YAAY,EAAE,SAAS;IACvB,IAAI;IACJ,SAAS;IACT,QAAQ;IACR,aAAa,EAAE,UAAU;IACzB,gBAAgB,EAAE,aAAa;CAC/B,CAAC"}

package/dist/ai/prompts/optimize-ai.d.ts

@@ -0,0 +1,3 @@
+import type { PromptDefinition } from './types.js';
+declare const optimizeAi: PromptDefinition;
+export default optimizeAi;

package/dist/ai/prompts/optimize-ai.js

@@ -0,0 +1,104 @@
+const optimizeAi = {
+    name: 'optimize-ai',
+    description: 'Optimize all AI setup files (agents, commands, rules, and instruction files) for the current project.',
+    shortDescription: 'Optimize AI setup for this project',
+    body: `Optimize all AI setup files (agents, commands, rules, and instruction files) for the current project.
+
+This command uses \`AGENTS.md\` as the standard instruction file. These files are placed hierarchically throughout the project — a root \`AGENTS.md\` for project-wide rules, and domain-scoped \`AGENTS.md\` files in subdirectories for area-specific instructions.
+
+## Steps
+
+### 1. Analyze the Project
+
+Read the following to understand the project's tech stack, structure, and conventions:
+
+- \`package.json\` (or equivalent manifest) — language, framework, dependencies, scripts
+- Top-level directory structure — \`ls\` the root and key directories
+- Existing \`AGENTS.md\` files anywhere in the project tree
+- \`.editorconfig\`, \`tsconfig.json\`, linter configs — code style and conventions
+- Build, test, and lint commands — from package scripts or Makefile
+
+Produce a short summary of the project: language, framework, directory layout, key conventions, build/test/lint commands, and any notable patterns. Identify the distinct domains in the project (e.g. backend, frontend, data layer, infrastructure) based on the directory structure.
+
+### 2. Extract Rules from Specifications
+
+Read all specification files from \`.ai/specs/\` folder project root, it is gitignored but read it anyways. Read \`.ai/specification-index.md\` for a complete index of available files. For each spec, extract any rules, constraints, conventions, or requirements that AI agents should follow when working on this codebase. These include:
+
+- Coding standards and naming conventions
+- Architectural constraints (e.g. "all API routes must go through middleware X")
+- Technology mandates (e.g. "use library Y for Z")
+- Forbidden patterns or anti-patterns
+- Data model invariants
+- Security and validation requirements
+- Testing requirements
+
+Categorize each extracted rule by which domain it belongs to (project-wide, backend, frontend, data, etc.). These will be written into the appropriate \`AGENTS.md\` file in the next step.
+
+### 3. Create Hierarchical AGENTS.md Files
+
+Create \`AGENTS.md\` files in a hierarchy that matches the project's domain structure.
+
+**Root \`AGENTS.md\`** (project root) — contains ONLY project-wide instructions:
+
+- Tech stack and language version
+- Build, test, and lint commands
+- Universal coding conventions (indentation, import style, naming)
+- Cross-cutting rules that apply everywhere
+- Project-wide architectural constraints
+
+**Domain-scoped \`AGENTS.md\` files** — placed in the actual directories for each domain. Use the real directory names from this project. Examples:
+
+- \`src/api/AGENTS.md\` — backend/API conventions, route patterns, middleware rules
+- \`src/components/AGENTS.md\` — component architecture, styling approach, state management patterns
+- \`src/db/AGENTS.md\` or \`src/models/AGENTS.md\` — schema conventions, migration rules, query patterns
+- \`src/tests/AGENTS.md\` — test conventions, fixture patterns, coverage requirements
+
+Rules extracted from specifications (Step 2) should be merged into the appropriate \`AGENTS.md\` file based on the domain they belong to.
+
+Each \`AGENTS.md\` file should:
+- Be concise — only rules and conventions, not documentation
+- List rules as actionable statements
+- Reference specific file paths, patterns, or libraries from the actual codebase
+- NOT duplicate rules already in a parent \`AGENTS.md\`
+
+If an existing \`AGENTS.md\` has user-authored content, preserve it and merge new rules alongside it (clearly separated).
+
+### 4. Update Agent Definitions
+
+Read \`hai.json\` to find the configured AI provider. Locate the agent definitions for that provider (e.g. \`.claude/agents/\` for Claude Code). For each agent, update its prompt body to include project-specific context:
+
+- Reference the actual directory structure and module layout
+- Mention the project's tech stack, frameworks, and key libraries
+- Include the real build, test, and lint commands
+- Reference actual coding conventions from the \`AGENTS.md\` files
+- Update the "Key Locations" sections with real paths from this project
+- Keep the agent's core role and workflow intact — only add project context
+
+### 5. Update Prompt Commands
+
+Find the prompt commands for the active AI provider (e.g. \`.claude/commands/\` for Claude Code, \`.github/copilot/prompts/\` for GitHub Copilot, \`.ai/prompts/\` for others). Update each command to reference project-specific details where applicable:
+
+- Real file paths for tickets, specs, and source code
+- Project-specific tooling or workflows
+- Keep the core instruction intent intact — only enrich with project context
+
+### 6. Update .ai/ Context File
+
+Rewrite \`.ai/AGENTS.md\` to accurately describe this project's:
+
+- Directory structure and what each directory contains
+- How tickets and specs are organized
+- Any project-specific guidance for AI agents working on this codebase
+
+### 7. Summary
+
+List every file you created or modified and briefly describe what changed. Group by category:
+
+- **AGENTS.md hierarchy** — which files were created/updated and what rules they contain
+- **Rules extracted** — which rules came from which specs
+- **Agents updated** — which agents were modified and what context was added
+- **Commands updated** — which commands were modified
+- **Other files** — any other changes`,
+};
+export default optimizeAi;
+//# sourceMappingURL=optimize-ai.js.map

package/dist/ai/prompts/optimize-ai.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"optimize-ai.js","sourceRoot":"","sources":["../../../source/ai/prompts/optimize-ai.ts"],"names":[],"mappings":"AAEA,MAAM,UAAU,GAAqB;IACpC,IAAI,EAAE,aAAa;IACnB,WAAW,EACV,uGAAuG;IACxG,gBAAgB,EAAE,oCAAoC;IACtD,IAAI,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sCAgG+B;CACrC,CAAC;AAEF,eAAe,UAAU,CAAC"}

package/dist/ai/prompts/pull-specs.d.ts

@@ -0,0 +1,3 @@
+import type { PromptDefinition } from './types.js';
+declare const pullSpecs: PromptDefinition;
+export default pullSpecs;

package/dist/ai/prompts/pull-specs.js

@@ -0,0 +1,10 @@
+const pullSpecs = {
+    name: 'pull-specs',
+    description: 'Pull the latest specs using the hai MCP tool.',
+    shortDescription: 'Sync specs to .ai/',
+    body: `Pull the latest specs using the hai MCP tool \`pull\` with \`specs: true, tickets: false\`.
+After syncing, read the downloaded spec files from \`.ai/specs/\`
+and provide a brief summary listing each spec's title and last-updated date.`,
+};
+export default pullSpecs;
+//# sourceMappingURL=pull-specs.js.map

package/dist/ai/prompts/pull-specs.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"pull-specs.js","sourceRoot":"","sources":["../../../source/ai/prompts/pull-specs.ts"],"names":[],"mappings":"AAEA,MAAM,SAAS,GAAqB;IACnC,IAAI,EAAE,YAAY;IAClB,WAAW,EAAE,+CAA+C;IAC5D,gBAAgB,EAAE,oBAAoB;IACtC,IAAI,EAAE;;6EAEsE;CAC5E,CAAC;AAEF,eAAe,SAAS,CAAC"}

package/dist/ai/prompts/pull-tickets.d.ts

@@ -0,0 +1,3 @@
+import type { PromptDefinition } from './types.js';
+declare const pullTickets: PromptDefinition;
+export default pullTickets;

package/dist/ai/prompts/pull-tickets.js

@@ -0,0 +1,11 @@
+const pullTickets = {
+    name: 'pull-tickets',
+    description: 'Pull the latest tickets using the hai MCP tool.',
+    shortDescription: 'Sync tickets to .ai/',
+    body: `Pull the latest tickets using the hai MCP tool \`pull\` with \`tickets: true, specs: false\`.
+After syncing, read the downloaded ticket files from \`.ai/tickets/\`
+and provide a brief summary listing each ticket's key, title, status,
+and priority.`,
+};
+export default pullTickets;
+//# sourceMappingURL=pull-tickets.js.map

package/dist/ai/prompts/pull-tickets.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"pull-tickets.js","sourceRoot":"","sources":["../../../source/ai/prompts/pull-tickets.ts"],"names":[],"mappings":"AAEA,MAAM,WAAW,GAAqB;IACrC,IAAI,EAAE,cAAc;IACpB,WAAW,EAAE,iDAAiD;IAC9D,gBAAgB,EAAE,sBAAsB;IACxC,IAAI,EAAE;;;cAGO;CACb,CAAC;AAEF,eAAe,WAAW,CAAC"}

package/dist/ai/prompts/pull.d.ts

@@ -0,0 +1,3 @@
+import type { PromptDefinition } from './types.js';
+declare const pull: PromptDefinition;
+export default pull;

package/dist/ai/prompts/pull.js

@@ -0,0 +1,9 @@
+const pull = {
+    name: 'pull',
+    description: 'Pull both tickets and specs using the hai MCP tools.',
+    shortDescription: 'Sync tickets and specs to .ai/',
+    body: `Pull both tickets and specs using the hai MCP tool \`pull\` with \`tickets: true, specs: true\`.
+Summarize all downloaded tickets and specs.`,
+};
+export default pull;
+//# sourceMappingURL=pull.js.map

package/dist/ai/prompts/pull.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"pull.js","sourceRoot":"","sources":["../../../source/ai/prompts/pull.ts"],"names":[],"mappings":"AAEA,MAAM,IAAI,GAAqB;IAC9B,IAAI,EAAE,MAAM;IACZ,WAAW,EAAE,sDAAsD;IACnE,gBAAgB,EAAE,gCAAgC;IAClD,IAAI,EAAE;4CACqC;CAC3C,CAAC;AAEF,eAAe,IAAI,CAAC"}

package/dist/ai/prompts/review-changes.d.ts

@@ -0,0 +1,3 @@
+import type { PromptDefinition } from './types.js';
+declare const reviewChanges: PromptDefinition;
+export default reviewChanges;