@haystackeditor/cli 0.10.2 → 0.11.0

package/dist/utils/skill.js

@@ -1,1671 +0,0 @@
-/**
- * Create the .agents/skills/haystack.md file for agent discovery
- * and .claude/commands/haystack.md for Claude Code slash command
- */
-import * as fs from 'fs/promises';
-import * as path from 'path';
-/**
- * Claude Code slash command - invoked with /haystack
- */
-const CLAUDE_COMMAND_CONTENT = `# Set Up Haystack Verification
-
-Follow .agents/skills/setup-haystack.md to set up Haystack verification for this repo.
-`;
-const SKILL_CONTENT = `# Haystack Verification Setup
-
-**Your job**: Help the verification system understand this app so it can visually verify PRs work correctly.
-
-The verification system has two parts:
-1. **Planner** - An AI that explores the codebase to figure out what to test
-2. **Executor** - Takes screenshots based on the plan
-
-Your \`.haystack.json\` flows feed into the **corpus** - they're hints for the Planner about what routes exist, what selectors to use, and what the core user journey looks like.
-
----
-
-## Step 1: Generate Base Config
-
-\`\`\`bash
-npx @haystackeditor/cli init --yes
-\`\`\`
-
-This detects your dev server command, port, and service dependencies.
-
----
-
-## Step 2: Understand the App's Core Feature
-
-Before writing any flows, answer this:
-
-**What is the ONE main thing users do in this app?**
-
-Read the codebase to understand the core user journey:
-- E-commerce: browse products → add to cart → checkout
-- Dashboard: view metrics → filter data → export
-- Editor: create document → edit → save
-- Social: view feed → create post → interact
-- SaaS: sign up → configure → use feature
-
-Your flows should describe THIS journey, not just "pages load".
-
----
-
-## Step 3: Verify ALL Services Have Flows (CRITICAL)
-
-**Every service in \`.haystack.json\` must have at least one verification flow.** This is the most common mistake - adding services but forgetting to add flows that exercise them.
-
-### Check for Uncovered Services
-
-\`\`\`bash
-# List all services
-grep -A1 '"services"' .haystack.json | grep -E '^\\s+"[^"]+":' | sed 's/.*"\\([^"]*\\)".*/\\1/'
-
-# List all flows
-grep '"name":' .haystack.json
-
-# MANUAL CHECK: Does every service have a flow?
-\`\`\`
-
-### Types of Services
-
-| Service Type | How to Verify |
-|--------------|---------------|
-| **Web frontend** | UI flows (navigate, wait_for, screenshot) |
-| **API/Worker** | UI flows that hit API endpoints |
-| **CLI/Batch** | Backend flows with golden inputs |
-| **Analysis pipeline** | Backend flows with known PR input |
-
-### Backend Verification (CLI tools, analysis pipelines, batch jobs)
-
-**Not everything is a web page.** For CLI tools and batch processes, you need:
-
-1. **Golden input** - A known-good input that produces predictable output
-2. **Run command** - How to execute the service
-3. **Output assertion** - What to check in the output
-
-\`\`\`json
-{
-  "name": "Backend pipeline - golden input",
-  "description": "Run pipeline on known input to verify it works",
-  "trigger": "on_change",
-  "watch_patterns": ["packages/my-pipeline/src/**"],
-  "service": "my-pipeline",
-  "type": "backend",
-  "steps": [
-    {
-      "action": "run",
-      "command": "pnpm start",
-      "env": { "INPUT_ID": "known-good-input-123" },
-      "timeout": 120
-    },
-    { "action": "assert_exit_code", "code": 0 },
-    { "action": "assert_output_contains", "pattern": "Processing complete" }
-  ]
-}
-\`\`\`
-
----
-
-## STOP - Confirm Golden URLs and Golden Data
-
-**If you identified backend services that need verification, you MUST ask the user with a proposed example:**
-
-First, explore the codebase to find:
-- Example inputs used in tests, scripts, or documentation
-- Default/demo values in config files or environment variables
-- IDs or URLs referenced in comments or READMEs
-
-Then propose a specific example:
-
-> I found these backend services that need verification:
-> - **[service name]**: [what it does]
->
-> For backend verification, I need **golden test data** - stable inputs that produce predictable output.
->
-> **Based on what I found in the codebase, here's my suggestion:**
-> - **Golden URL/Input**: \`[specific example you found, e.g., a test ID, demo endpoint, or sample file]\`
-> - **Command**: \`[the command to run with this input]\`
-> - **Expected Output**: \`[what success looks like based on the code]\`
->
-> Does this look right? Or should I use different test data?
-
-**Wait for the user to confirm or provide alternatives before adding backend flows.**
-
----
-
-## Step 4: Assess Data Needs
-
-\`\`\`bash
-# Find API calls
-grep -r "fetch(\\|useQuery\\|useSWR\\|axios" src/ --include="*.tsx" --include="*.ts" | wc -l
-
-# Find dynamic routes
-grep -r "useParams\\|router.query\\|\\[.*\\]" src/ --include="*.tsx" | head -10
-
-# Find external domains
-grep -r "https://" src/ --include="*.ts" --include="*.tsx" | grep -v node_modules | head -10
-\`\`\`
-
----
-
-## STOP - Ask About Test Data Strategy
-
-**You MUST ask the user before proceeding:**
-
-> I analyzed the codebase and found:
-> - X API fetch calls
-> - Y dynamic routes with parameters
-> - These external domains: [list them]
->
-> **How should I handle test data for verification?**
->
-> 1. **Passthrough** - Let API calls through to real servers (add domains to \`network.allow\`)
-> 2. **Staging URL** - Point flows at your staging/demo environment
-> 3. **Local fixtures** - JSON files in \`fixtures/\` directory
-> 4. **Skip data pages** - Only test static pages that don't need API data
-
-**Wait for the user's response before continuing.**
-
----
-
-## STOP - Confirm Frontend Golden URLs
-
-**Goldens are URLs with real staging data** - they let verification test pages that need actual content to render properly. You need MULTIPLE goldens to cover different scenarios.
-
-**Before writing flows for dynamic routes, explore the codebase to find example data:**
-
-1. Check test files (\`*.test.ts\`, \`cypress/\`, \`playwright/\`) for example IDs/URLs
-2. Check README/docs for demo links or example usage
-3. Check seed data, fixtures, or mock files
-4. Check \`.env.example\` or config for staging URLs
-5. Check existing routes to understand the URL format
-
-**Then propose MULTIPLE golden URLs (aim for 3-5) covering different scenarios:**
-
-> I found these dynamic routes that need staging data to render:
->
-> **[Route Name]** (\`/path/:param1/:param2\`)
->
-> | Golden | URL | Why |
-> |--------|-----|-----|
-> | Large dataset | \`/path/example/large-123\` | Tests performance with many items |
-> | Typical case | \`/path/example/medium-456\` | Common user scenario |
-> | Edge case | \`/path/example/empty-789\` | Tests empty/minimal state |
-> | Error state | \`/path/example/error-000\` | Tests error handling UI |
->
-> **Evidence:**
-> - Found \`large-123\` in \`cypress/fixtures/test-data.json\`
-> - Found \`medium-456\` in README as demo example
-> - Found \`empty-789\` in \`src/tests/edge-cases.test.ts\`
->
-> Does this look right?
-> 1. ✅ Yes, use these goldens
-> 2. 🔄 Use different URLs (I'll provide them)
-
-**Add goldens to \`verification.goldens\` in \`.haystack.json\` using this EXACT format:**
-
-\`\`\`json
-{
-  "verification": {
-    "goldens": {
-      "frontend": [
-        {
-          "id": "large-dataset",
-          "description": "100+ items - tests rendering performance",
-          "route": "/the/actual/url/with/data"
-        },
-        {
-          "id": "typical-case",
-          "description": "Standard 10-20 items",
-          "route": "/another/url/with/typical/data"
-        },
-        {
-          "id": "empty-state",
-          "description": "No items - tests empty state UI",
-          "route": "/url/that/shows/empty/state"
-        }
-      ],
-      "backend": [
-        {
-          "id": "golden-input-1",
-          "description": "Known-good input for pipeline testing",
-          "input": { "type": "github_pr", "value": "owner/repo#123" }
-        }
-      ]
-    },
-    "commands": [...]
-  }
-}
-\`\`\`
-
-**DO NOT:**
-- Ask the user what format to use - USE THIS FORMAT
-- Put goldens at the top level - they go inside \`verification.goldens\`
-- Use a flat object like \`{ "goldens": { "name": "url" } }\` - use the array format above
-- Embed golden URLs only in flow steps - also add them to the goldens section for discoverability
-
-**CRITICAL**:
-- Propose MULTIPLE goldens (3-5), not just one
-- Cover different scenarios: large, typical, empty, error states
-- Always propose SPECIFIC URLs, never ask the user to freestyle
-- Show WHERE you found the example data (file path, line if possible)
-- Make sure URLs match the app's actual route format (check \`<Route path=\`)
-- Wait for confirmation before writing flows with these URLs
-
----
-
-## Step 5: Write Flows
-
-Flows tell the Planner about your app's routes, UI elements, and user journeys.
-
-### Structure
-
-\`\`\`yaml
-flows:
-  - name: "Descriptive name of what this tests"
-    trigger: always  # or on_change with watch_patterns
-    steps:
-      - action: navigate
-        url: "/"
-      - action: wait_for
-        selector: "[data-testid='specific-element']"
-      - action: click
-        selector: "[data-testid='button']"
-      - action: screenshot
-        name: "result"
-\`\`\`
-
-### What to Include
-
-**Core journey flow** (trigger: always):
-- The main thing users do in your app
-- Multiple steps with interactions (click, type)
-- Waits for meaningful state changes
-
-**Route coverage flows**:
-- One flow per major route
-- Uses specific selectors the Planner can learn from
-- \`watch_patterns\` to only run when relevant files change
-
-### Finding Good Selectors
-
-\`\`\`bash
-# Find data-testid attributes
-grep -r "data-testid" src/ --include="*.tsx" | head -20
-
-# Find aria-labels
-grep -r "aria-label" src/ --include="*.tsx" | head -20
-
-# Find component class names
-grep -r "className=" src/components/ --include="*.tsx" | head -20
-\`\`\`
-
-Use specific selectors like:
-- \`[data-testid='dashboard-chart']\`
-- \`[aria-label='Submit form']\`
-- \`.pricing-table\`
-- \`button[type='submit']\`
-
-If good selectors don't exist, add \`data-testid\` to key components.
-
-### watch_patterns
-
-For flows that only matter when certain files change:
-
-\`\`\`yaml
-- name: "Settings page works"
-  trigger: on_change
-  watch_patterns:
-    - "src/pages/settings/**"
-    - "src/components/settings/**"
-  steps:
-    - action: navigate
-      url: "/settings"
-    # ...
-\`\`\`
-
----
-
-## Step 6: Configure Fixtures (if needed)
-
-Based on user's answer in Step 3:
-
-**Passthrough**:
-\`\`\`yaml
-network:
-  allow:
-    - "api.example.com"
-    - "cdn.example.com"
-\`\`\`
-
-**Staging URL**:
-\`\`\`yaml
-flows:
-  - name: "Dashboard with real data"
-    steps:
-      - action: navigate
-        url: "https://staging.example.com/dashboard"
-\`\`\`
-
-**Local fixtures**:
-\`\`\`yaml
-fixtures:
-  - pattern: "/api/user"
-    source: "file://fixtures/user.json"
-  - pattern: "/api/data/*"
-    source: "file://fixtures/data.json"
-\`\`\`
-
----
-
-## Step 7: Commit
-
-\`\`\`bash
-git add .haystack.json fixtures/
-git commit -m "Add Haystack verification"
-\`\`\`
-
-Done! The Planner will use your flows to understand the app and create verification plans for PRs.
-`;
-const REFERENCE_CONTENT = `# Haystack Reference
-
-Reference material for \`.haystack.json\` configuration. Only consult when needed for a specific step.
-
----
-
-## Fixture Patterns
-
-### Option 1: Passthrough (Recommended - Easiest!)
-\`\`\`yaml
-# Let API calls through to real servers - no mocking needed
-fixtures:
-  - pattern: "/api/*"
-    source: passthrough
-
-network:
-  allow:
-    - "api.example.com"
-    - "cdn.example.com"
-\`\`\`
-
-**This is the easiest option.** Just allow the domains your app calls and let real APIs handle requests. No fixtures to maintain.
-
-### Option 2: Staging/Demo URL
-\`\`\`yaml
-# Point flows directly at staging - no fixtures needed
-flows:
-  - name: "Dashboard loads"
-    url: "https://staging.example.com/dashboard"
-    wait_for_selector: ".dashboard-content"
-
-network:
-  allow:
-    - "staging.example.com"
-\`\`\`
-
-### Option 3: Pre-signed URLs (S3/Cloud Storage)
-\`\`\`yaml
-fixtures:
-  - pattern: "/api/data"
-    source: "$FIXTURE_DATA_URL"      # Pre-signed URL from CI
-  - pattern: "/api/users"
-    source: "$FIXTURE_USERS_URL"
-
-secrets:
-  - FIXTURE_DATA_URL
-  - FIXTURE_USERS_URL
-\`\`\`
-
-See "Pre-signed URL Setup" below for CI configuration.
-
-### Option 4: Local Fixtures (Simple Apps Only)
-\`\`\`yaml
-fixtures:
-  - pattern: "/api/user"
-    source: "file://fixtures/user.json"
-  - pattern: "/api/settings"
-    source: "file://fixtures/settings.json"
-\`\`\`
-
-Create matching JSON files in \`fixtures/\` directory. Only use for small, stable data.
-
-### Option 5: HTTP Endpoint (Self-hosted)
-\`\`\`yaml
-fixtures:
-  - pattern: "/api/*"
-    source: "https://fixtures.yourcompany.com/api"
-    headers:
-      Authorization: "Bearer $FIXTURES_TOKEN"
-
-network:
-  allow:
-    - "fixtures.yourcompany.com"
-\`\`\`
-
----
-
-## Pre-signed URL Setup
-
-Generate temporary URLs in CI, pass to Haystack. No cloud credentials in sandbox.
-
-**Note:** URLs valid for 24 hours. Run on push to main to keep URLs fresh.
-
-### AWS S3
-\`\`\`bash
-# Generate pre-signed URL (valid 24 hours)
-aws s3 presign s3://my-bucket/fixtures/data.json --expires-in 86400
-\`\`\`
-
-### Google Cloud Storage
-\`\`\`bash
-# Generate signed URL (valid 24 hours)
-gcloud storage sign-url gs://my-bucket/fixtures/data.json --duration=24h
-\`\`\`
-
-### Azure Blob Storage
-\`\`\`bash
-# Generate SAS URL (valid 24 hours)
-az storage blob generate-sas --account-name myaccount --container fixtures \\
-  --name data.json --permissions r --expiry $(date -u -d '+1 day' +%Y-%m-%dT%H:%MZ) \\
-  --full-uri
-\`\`\`
-
-### Cloudflare R2 / DigitalOcean Spaces / MinIO
-\`\`\`bash
-# S3-compatible - use aws cli with custom endpoint
-aws s3 presign s3://my-bucket/data.json --expires-in 86400 \\
-  --endpoint-url https://your-r2-endpoint.com
-\`\`\`
-
----
-
-### GitHub Actions Example
-\`\`\`yaml
-# Run on push to main to keep URLs fresh
-on:
-  push:
-    branches: [main]
-
-jobs:
-  update-fixture-urls:
-    runs-on: ubuntu-latest
-    permissions:
-      id-token: write  # OIDC - no long-lived secrets
-    steps:
-      - uses: aws-actions/configure-aws-credentials@v4
-        with:
-          role-to-assume: arn:aws:iam::123456789:role/haystack-fixtures
-          aws-region: us-east-1
-
-      - name: Generate pre-signed URLs (valid 24 hours)
-        run: |
-          URL=$(aws s3 presign s3://my-bucket/fixtures/data.json --expires-in 86400)
-          haystack secrets set FIXTURE_DATA_URL "$URL"
-\`\`\`
-
-### General Approach
-1. Use OIDC to get temporary cloud credentials (no long-lived secrets)
-2. Generate pre-signed/signed URL for each fixture file (24 hour expiry)
-3. Store with \`haystack secrets set FIXTURE_URL "$URL"\`
-4. Run on push to main to keep URLs fresh
-
----
-
-## Flow Examples
-
-### Basic Page Flow
-\`\`\`yaml
-flows:
-  - name: "Dashboard loads"
-    description: "Verify dashboard renders correctly"
-    trigger: always
-    watch_patterns:
-      - "src/components/dashboard/**"
-    steps:
-      - action: navigate
-        url: "/dashboard"
-      - action: wait_for
-        selector: "[data-testid='dashboard-content']"
-      - action: assert_no_errors
-      - action: screenshot
-        name: "dashboard"
-\`\`\`
-
-### Interactive Flow (click)
-\`\`\`yaml
-  - name: "Modal opens"
-    trigger: on_change
-    watch_patterns:
-      - "src/components/settings/**"
-    steps:
-      - action: navigate
-        url: "/settings"
-      - action: wait_for
-        selector: ".settings-page"
-      - action: click
-        selector: "button[aria-label='Settings']"
-      - action: wait_for
-        selector: "[role='dialog']"
-      - action: screenshot
-        name: "settings-modal"
-\`\`\`
-
-### Form Flow (type)
-\`\`\`yaml
-  - name: "Contact form works"
-    trigger: on_change
-    watch_patterns:
-      - "src/components/contact/**"
-    steps:
-      - action: navigate
-        url: "/contact"
-      - action: wait_for
-        selector: "form"
-      - action: type
-        selector: "input[name='email']"
-        value: "test@example.com"
-      - action: click
-        selector: "button[type='submit']"
-      - action: wait_for
-        selector: ".success-message"
-\`\`\`
-
-### Backend API Flow
-\`\`\`yaml
-  - name: "API health check"
-    trigger: always
-    steps:
-      - action: http_request
-        method: GET
-        url: "http://localhost:3001/health"
-      - action: assert_status
-        status: 200
-\`\`\`
-
----
-
-## Finding Good Selectors
-
-**Priority order:**
-1. \`[data-testid='feature-name']\` - Best
-2. \`[role='main']\`, \`[aria-label='...']\` - Semantic
-3. \`.specific-class-name\` - Component-specific
-4. Avoid: \`#root\`, \`div\`, \`h1\` - Too generic
-
-**How to find:**
-\`\`\`bash
-# Find data-testid attributes
-grep -r "data-testid" src/ --include="*.tsx"
-
-# Find class names
-grep -r "className=" src/components/Dashboard.tsx
-
-# Find semantic roles
-grep -r "role=\\|aria-label=" src/ --include="*.tsx"
-\`\`\`
-
----
-
-## Config Structure
-
-⚠️ **IMPORTANT**: \`flows\` must be at TOP LEVEL, not nested under \`verification\`!
-
-\`\`\`yaml
-version: "1"
-name: my-app
-
-dev_server:
-  command: pnpm dev
-  port: 3000
-  ready_pattern: "ready|Local:|started"  # Regex for server ready
-
-# Verification commands - MUST include build
-verification:
-  commands:
-    - name: build
-      run: pnpm build       # ← REQUIRED
-    - name: lint
-      run: pnpm lint
-    - name: typecheck
-      run: pnpm tsc --noEmit
-
-network:
-  allow:
-    - "api.example.com"
-
-# ⚠️ flows at TOP LEVEL - NOT under verification!
-flows:
-  - name: "Page loads"
-    trigger: always
-    steps:
-      - action: navigate
-        url: "/"
-      - action: wait_for
-        selector: "[data-testid='main']"
-      - action: screenshot
-        name: "home"
-
-secrets:
-  - API_TOKEN
-
-fixtures:
-  - pattern: "/api/*"
-    source: passthrough
-\`\`\`
-
----
-
-## Monorepo Configuration
-
-\`\`\`yaml
-version: "1"
-name: my-monorepo
-
-services:
-  frontend:
-    root: ./
-    command: pnpm dev
-    port: 3000
-    ready_pattern: "Local:"
-
-  api:
-    root: packages/api
-    command: pnpm dev
-    port: 8080
-    ready_pattern: "listening"
-
-  worker:
-    root: infra/worker
-    command: pnpm wrangler dev
-    port: 8787
-\`\`\`
-
----
-
-## Flow Triggers
-
-| Trigger | When it runs |
-|---------|--------------|
-| \`always\` | Every PR |
-| \`on_change\` | Only when \`watch_patterns\` match changed files |
-`;
-const PREPARE_VERIFICATION_CONTENT = `# Prepare Codebase for Verification
-
-**Your job**: Make this codebase easy to verify by adding semantic identifiers that the verification system can target.
-
-The verification Planner needs to find UI elements by selectors. Generic selectors like \`div\` or \`.flex\` are useless. Your job is to add meaningful identifiers throughout the codebase.
-
----
-
-## ⚠️ CRITICAL RULE: Every Button MUST Have \`data-testid\` and \`aria-label\`
-
-**This is non-negotiable.** Every \`<button>\` element in the codebase MUST have:
-1. \`data-testid="descriptive-name"\` - For automated testing/verification
-2. \`aria-label="Action description"\` - For accessibility AND verification
-
-**Why?** The verification system clicks buttons by their \`data-testid\` or \`aria-label\`. Without these, buttons are invisible to automation. We learned this the hard way - a theme toggle button without these attributes broke our entire verification pipeline.
-
-\`\`\`tsx
-// ❌ WRONG - No identifiers, verification cannot click this
-<button onClick={toggleTheme}>
-  <SunIcon />
-</button>
-
-// ✅ CORRECT - Both data-testid AND aria-label
-<button
-  onClick={toggleTheme}
-  data-testid="theme-toggle"
-  aria-label="Toggle dark mode"
->
-  <SunIcon />
-</button>
-\`\`\`
-
-**For button wrapper components**, pass through these props:
-\`\`\`tsx
-interface ButtonProps {
-  'data-testid'?: string;
-  'aria-label'?: string;
-  // ...other props
-}
-
-function IconButton({ 'data-testid': testId, 'aria-label': ariaLabel, ...props }: ButtonProps) {
-  return (
-    <button data-testid={testId} aria-label={ariaLabel} {...props}>
-      {props.children}
-    </button>
-  );
-}
-\`\`\`
-
----
-
-## What to Add
-
-### 1. \`aria-label\` on Interactive Elements
-
-Every clickable/interactive element should have an aria-label describing what it does:
-
-\`\`\`tsx
-// Before
-<button onClick={onSave}>💾</button>
-<button onClick={() => setOpen(true)}>
-  <MenuIcon />
-</button>
-
-// After
-<button onClick={onSave} aria-label="Save document">💾</button>
-<button onClick={() => setOpen(true)} aria-label="Open menu">
-  <MenuIcon />
-</button>
-\`\`\`
-
-**Target elements:**
-- Buttons (especially icon-only buttons)
-- Links without descriptive text
-- Toggle switches
-- Dropdown triggers
-- Modal open/close buttons
-- Form submit buttons
-
-### 2. \`data-testid\` on Key Sections
-
-Major UI sections should have data-testid for easy targeting:
-
-\`\`\`tsx
-// Before
-<div className="flex flex-col p-4">
-  <h1>Dashboard</h1>
-  {/* content */}
-</div>
-
-// After
-<div className="flex flex-col p-4" data-testid="dashboard-container">
-  <h1>Dashboard</h1>
-  {/* content */}
-</div>
-\`\`\`
-
-**Target sections:**
-- Page containers (dashboard, settings, profile)
-- Navigation bars/sidebars
-- Modal/dialog content
-- Form containers
-- Data tables/lists
-- Card components
-- Loading states
-- Error states
-- Empty states
-
-### 3. \`role\` Attributes for Semantic Structure
-
-Add ARIA roles where HTML semantics aren't clear:
-
-\`\`\`tsx
-// Before
-<div className="modal-overlay">
-  <div className="modal-content">
-
-// After
-<div className="modal-overlay" role="presentation">
-  <div className="modal-content" role="dialog" aria-modal="true">
-\`\`\`
-
-**Common roles:**
-- \`role="dialog"\` - Modals/dialogs
-- \`role="navigation"\` - Nav sections
-- \`role="main"\` - Main content area
-- \`role="alert"\` - Error/success messages
-- \`role="status"\` - Loading indicators
-- \`role="tablist"\`, \`role="tab"\`, \`role="tabpanel"\` - Tab interfaces
-
-### 4. State Indicators
-
-Add attributes that indicate UI state:
-
-\`\`\`tsx
-// Before
-<button onClick={toggle}>
-  {isOpen ? 'Close' : 'Open'}
-</button>
-
-// After
-<button
-  onClick={toggle}
-  aria-expanded={isOpen}
-  aria-label={isOpen ? 'Close panel' : 'Open panel'}
->
-  {isOpen ? 'Close' : 'Open'}
-</button>
-\`\`\`
-
-**State attributes:**
-- \`aria-expanded\` - Collapsible sections
-- \`aria-selected\` - Selected items in lists
-- \`aria-checked\` - Checkboxes/toggles
-- \`aria-disabled\` - Disabled elements
-- \`aria-busy\` - Loading states
-- \`data-state="loading|error|success"\` - Custom states
-
-### 5. Form Accessibility
-
-Forms should have proper labels and descriptions:
-
-\`\`\`tsx
-// Before
-<input type="email" placeholder="Email" />
-<span className="text-red-500">{error}</span>
-
-// After
-<input
-  type="email"
-  placeholder="Email"
-  aria-label="Email address"
-  aria-describedby={error ? "email-error" : undefined}
-  aria-invalid={!!error}
-/>
-{error && <span id="email-error" role="alert" className="text-red-500">{error}</span>}
-\`\`\`
-
----
-
-## Step 1: Scan for Missing Identifiers
-
-**Start with buttons - these are the most critical:**
-
-\`\`\`bash
-# CRITICAL: Find ALL buttons missing data-testid (fix ALL of these!)
-grep -rn "<button" src/ --include="*.tsx" | grep -v "data-testid" | head -30
-
-# CRITICAL: Find ALL buttons missing aria-label (fix ALL of these!)
-grep -rn "<button" src/ --include="*.tsx" | grep -v "aria-label" | head -30
-
-# Find icon-only buttons (MUST have aria-label since no visible text)
-grep -rn "<button.*Icon\\|<button.*>.*</.*Icon>" src/ --include="*.tsx" | head -20
-
-# Find button wrapper components that need to pass through data-testid/aria-label
-grep -rn "function.*Button\\|const.*Button.*=" src/ --include="*.tsx" | head -10
-
-# Find modals/dialogs without role
-grep -rn "modal\\|dialog\\|Modal\\|Dialog" src/ --include="*.tsx" | grep -v "role=" | head -20
-
-# Find forms without proper labeling
-grep -rn "<input\\|<select\\|<textarea" src/ --include="*.tsx" | grep -v "aria-label\\|id=" | head -20
-
-# Find major components (likely need data-testid)
-ls src/components/ src/pages/ 2>/dev/null
-\`\`\`
-
-**Every button found without \`data-testid\` or \`aria-label\` MUST be fixed.**
-
----
-
-## Step 2: Prioritize by Impact
-
-Focus on elements the verification system is most likely to need:
-
-**High Priority (do first):**
-1. Navigation elements (header, sidebar, menu buttons)
-2. Primary actions (submit buttons, save buttons, CTAs)
-3. Modal triggers and dialogs
-4. Form inputs and submit buttons
-5. Page-level containers
-
-**Medium Priority:**
-1. Toggle switches and checkboxes
-2. Dropdown menus
-3. Tab interfaces
-4. Cards and list items
-5. Loading/error states
-
-**Lower Priority:**
-1. Decorative elements
-2. Static content sections
-3. Footer links
-
----
-
-## Step 3: Add Identifiers Systematically
-
-Go component by component. For each component:
-
-1. **Check the component's purpose** - What does it DO?
-2. **Add aria-label** to interactive elements describing the ACTION
-3. **Add data-testid** to the container if it's a major section
-4. **Add role** if the semantic HTML isn't clear
-5. **Add state attributes** if the component has dynamic states
-
-### Naming Conventions
-
-**aria-label**: Describe the action, not the element
-- ✅ \`aria-label="Close modal"\`
-- ✅ \`aria-label="Submit contact form"\`
-- ❌ \`aria-label="Button"\`
-- ❌ \`aria-label="Click here"\`
-
-**data-testid**: Use kebab-case, describe the section
-- ✅ \`data-testid="user-profile-card"\`
-- ✅ \`data-testid="search-results-list"\`
-- ❌ \`data-testid="div1"\`
-- ❌ \`data-testid="container"\`
-
----
-
-## Step 4: Verify Coverage
-
-After adding identifiers, check coverage:
-
-\`\`\`bash
-# Count aria-labels added
-grep -r "aria-label" src/ --include="*.tsx" | wc -l
-
-# Count data-testid added
-grep -r "data-testid" src/ --include="*.tsx" | wc -l
-
-# Count role attributes
-grep -r "role=" src/ --include="*.tsx" | wc -l
-
-# List all data-testid values (check for meaningful names)
-grep -oh 'data-testid="[^"]*"' src/ -r --include="*.tsx" | sort -u
-\`\`\`
-
----
-
-## Step 5: Commit
-
-\`\`\`bash
-git add src/
-git commit -m "Add accessibility attributes for verification
-
-- Added aria-labels to interactive elements
-- Added data-testid to major sections
-- Added ARIA roles for semantic structure
-- Added state indicators (aria-expanded, etc.)"
-\`\`\`
-
----
-
-## Quick Reference: Common Patterns
-
-### Icon Button
-\`\`\`tsx
-<button onClick={onAction} aria-label="Descriptive action name">
-  <Icon />
-</button>
-\`\`\`
-
-### Modal
-\`\`\`tsx
-<div role="dialog" aria-modal="true" aria-labelledby="modal-title" data-testid="settings-modal">
-  <h2 id="modal-title">Settings</h2>
-  <button onClick={onClose} aria-label="Close settings">×</button>
-</div>
-\`\`\`
-
-### Navigation
-\`\`\`tsx
-<nav aria-label="Main navigation" data-testid="main-nav">
-  <a href="/dashboard" aria-current={isActive ? "page" : undefined}>Dashboard</a>
-</nav>
-\`\`\`
-
-### Toggle
-\`\`\`tsx
-<button
-  onClick={toggle}
-  aria-pressed={isOn}
-  aria-label={\`\${isOn ? 'Disable' : 'Enable'} notifications\`}
->
-  {isOn ? 'On' : 'Off'}
-</button>
-\`\`\`
-
-### Loading State
-\`\`\`tsx
-<div data-testid="content-area" aria-busy={isLoading}>
-  {isLoading ? (
-    <div role="status" aria-label="Loading content">
-      <Spinner />
-    </div>
-  ) : (
-    content
-  )}
-</div>
-\`\`\`
-
-### Form Field
-\`\`\`tsx
-<div data-testid="email-field">
-  <label htmlFor="email">Email</label>
-  <input
-    id="email"
-    type="email"
-    aria-describedby={error ? "email-error" : "email-hint"}
-    aria-invalid={!!error}
-  />
-  <span id="email-hint">We'll never share your email</span>
-  {error && <span id="email-error" role="alert">{error}</span>}
-</div>
-\`\`\`
-
-### Expandable Section
-\`\`\`tsx
-<div data-testid="faq-section">
-  <button
-    onClick={() => setExpanded(!expanded)}
-    aria-expanded={expanded}
-    aria-controls="faq-content"
-  >
-    FAQ
-  </button>
-  <div id="faq-content" hidden={!expanded}>
-    {content}
-  </div>
-</div>
-\`\`\`
-`;
-const PREPARE_HAYSTACK_COMMAND = `# Prepare Codebase for Verification
-
-Follow .agents/skills/prepare-haystack.md to add accessibility attributes that make verification easier.
-
-Run this BEFORE /setup-haystack to ensure your codebase has good selectors.
-`;
-const SECRETS_COMMAND_CONTENT = `# Set Up Haystack Secrets
-
-Follow .agents/skills/setup-haystack-secrets.md to configure secrets (API keys, credentials) for Haystack verification.
-`;
-const SECRETS_SKILL_CONTENT = `# Set Up Haystack Secrets
-
-**Your job**: Help the user configure secrets needed for Haystack verification, especially LLM API keys for backend services.
-
----
-
-## Step 1: Detect Services That Need Secrets
-
-Scan the codebase to identify services that might need API keys or credentials:
-
-\`\`\`bash
-# Find LLM/AI SDK usage
-grep -rn "openai\\|anthropic\\|bedrock\\|OPENAI_API_KEY\\|ANTHROPIC_API_KEY" --include="*.ts" --include="*.py" --include="*.js" | grep -v node_modules | head -20
-
-# Find environment variable references
-grep -rn "process.env\\.\\|os.environ\\|env\\." --include="*.ts" --include="*.py" --include="*.js" | grep -v node_modules | grep -iE "key|secret|token|api" | head -20
-
-# Check for .env.example or similar
-cat .env.example .env.sample 2>/dev/null || echo "No .env example found"
-
-# Check existing secrets in .haystack.json
-grep -A10 '"secrets"' .haystack.json 2>/dev/null || echo "No secrets configured yet"
-\`\`\`
-
----
-
-## Step 2: Categorize the Secrets Found
-
-Group secrets by type and service:
-
-| Category | Examples | Storage Recommendation |
-|----------|----------|------------------------|
-| **LLM API Keys** | \`OPENAI_API_KEY\`, \`ANTHROPIC_API_KEY\` | Haystack Secrets (encrypted) |
-| **Cloud Credentials** | \`AWS_ACCESS_KEY_ID\`, \`GCP_SERVICE_ACCOUNT\` | Use OIDC in CI, not static keys |
-| **Database** | \`DATABASE_URL\`, \`REDIS_URL\` | Haystack Secrets or passthrough |
-| **Third-party APIs** | \`STRIPE_KEY\`, \`SENDGRID_KEY\` | Haystack Secrets |
-| **Internal Services** | \`API_TOKEN\`, \`WEBHOOK_SECRET\` | Haystack Secrets |
-
----
-
-## STOP - Present Findings and Ask User
-
-**You MUST present what you found and ask the user before proceeding:**
-
-> I scanned the codebase and found these services that may need secrets for verification:
->
-> **Services detected:**
-> - [Service 1]: Uses \`OPENAI_API_KEY\` for [purpose]
-> - [Service 2]: Uses \`DATABASE_URL\` for [purpose]
-> - ...
->
-> **Questions:**
->
-> 1. **LLM API Keys**: Which provider do you use?
->    - OpenAI (\`OPENAI_API_KEY\`)
->    - Anthropic (\`ANTHROPIC_API_KEY\`)
->    - AWS Bedrock (use OIDC, no static keys needed)
->    - Other: ___
->
-> 2. **For each secret**, should verification use:
->    - **Real credentials** (stored securely in Haystack Secrets)
->    - **Test/sandbox credentials** (separate keys for verification only)
->    - **Mock/skip** (service not needed for visual verification)
->
-> 3. **Do you have separate test credentials?**
->    - Yes, I have sandbox/test API keys
->    - No, I'll use production keys (with usage limits)
->    - I need to create test credentials first
-
-**Wait for the user's response before continuing.**
-
----
-
-## Step 3: Configure Secrets in .haystack.json
-
-Based on user's answers, add secrets to the config:
-
-\`\`\`json
-{
-  "secrets": {
-    "OPENAI_API_KEY": {
-      "description": "OpenAI API key for analysis service",
-      "required": true,
-      "services": ["analysis"]
-    },
-    "DATABASE_URL": {
-      "description": "PostgreSQL connection string",
-      "required": false,
-      "services": ["api"]
-    }
-  }
-}
-\`\`\`
-
-### Secret Properties
-
-| Property | Description |
-|----------|-------------|
-| \`description\` | What this secret is for (shown to user) |
-| \`required\` | If \`true\`, verification fails without it |
-| \`services\` | Which services need this secret (for scoping) |
-
----
-
-## Step 4: Guide User to Store Secrets
-
-### Option A: Haystack CLI (Recommended)
-
-\`\`\`bash
-# Store secrets securely (encrypted at rest)
-npx @haystackeditor/cli secrets set OPENAI_API_KEY
-# Prompts for value, never shown in terminal history
-
-# Verify it's stored
-npx @haystackeditor/cli secrets list
-\`\`\`
-
-### Option B: Environment Variables (Local Development)
-
-\`\`\`bash
-# Add to .env.local (gitignored)
-echo 'OPENAI_API_KEY=sk-...' >> .env.local
-
-# Make sure .env.local is in .gitignore
-grep -q '.env.local' .gitignore || echo '.env.local' >> .gitignore
-\`\`\`
-
-### Option C: CI/CD Secrets (GitHub Actions)
-
-\`\`\`yaml
-# .github/workflows/haystack.yml
-env:
-  OPENAI_API_KEY: \${{ secrets.OPENAI_API_KEY }}
-\`\`\`
-
----
-
-## Step 5: Handle Cloud Provider Credentials
-
-**Never store long-lived cloud credentials.** Use OIDC instead:
-
-### AWS (Bedrock, S3, etc.)
-
-\`\`\`yaml
-# GitHub Actions with OIDC - no secrets needed!
-jobs:
-  verify:
-    permissions:
-      id-token: write
-      contents: read
-    steps:
-      - uses: aws-actions/configure-aws-credentials@v4
-        with:
-          role-to-assume: arn:aws:iam::123456789:role/haystack-verify
-          aws-region: us-west-2
-\`\`\`
-
-### GCP (Vertex AI, Cloud Storage, etc.)
-
-\`\`\`yaml
-jobs:
-  verify:
-    permissions:
-      id-token: write
-    steps:
-      - uses: google-github-actions/auth@v2
-        with:
-          workload_identity_provider: projects/123/locations/global/...
-          service_account: haystack-verify@project.iam.gserviceaccount.com
-\`\`\`
-
----
-
-## Step 6: Test Secret Access
-
-After storing secrets, verify they're accessible:
-
-\`\`\`bash
-# Test locally
-npx @haystackeditor/cli secrets test
-
-# Or check manually
-npx @haystackeditor/cli secrets get OPENAI_API_KEY --masked
-# Shows: sk-...xxxx (last 4 chars only)
-\`\`\`
-
----
-
-## Step 7: Update .haystack.json
-
-Add the secrets configuration:
-
-\`\`\`bash
-# Show what to add
-cat << 'EOF'
-Add this to your .haystack.json:
-
-{
-  "secrets": {
-    "OPENAI_API_KEY": {
-      "description": "OpenAI API key for LLM analysis",
-      "required": true
-    }
-  }
-}
-EOF
-\`\`\`
-
----
-
-## Common Patterns
-
-### Analysis Pipeline with LLM
-
-\`\`\`json
-{
-  "services": {
-    "analysis": {
-      "root": "packages/analysis",
-      "command": "pnpm start",
-      "env": {
-        "PR_IDENTIFIER": "$PR_IDENTIFIER"
-      }
-    }
-  },
-  "secrets": {
-    "OPENAI_API_KEY": {
-      "description": "OpenAI API for code analysis",
-      "required": true,
-      "services": ["analysis"]
-    }
-  }
-}
-\`\`\`
-
-### Multiple LLM Providers
-
-\`\`\`json
-{
-  "secrets": {
-    "OPENAI_API_KEY": {
-      "description": "OpenAI for embeddings",
-      "services": ["search"]
-    },
-    "ANTHROPIC_API_KEY": {
-      "description": "Claude for code review",
-      "services": ["review"]
-    }
-  }
-}
-\`\`\`
-
-### Database + API Keys
-
-\`\`\`json
-{
-  "secrets": {
-    "DATABASE_URL": {
-      "description": "PostgreSQL for test database",
-      "required": true
-    },
-    "STRIPE_TEST_KEY": {
-      "description": "Stripe test mode key",
-      "required": false
-    }
-  }
-}
-\`\`\`
-
----
-
-## Security Best Practices
-
-1. **Use test/sandbox credentials** when available (OpenAI, Stripe, etc. offer these)
-2. **Set usage limits** on API keys used for verification
-3. **Never commit secrets** - use \`.gitignore\` for \`.env.local\`
-4. **Rotate regularly** - especially if verification runs on external PRs
-5. **Scope narrowly** - use \`services\` array to limit which services see which secrets
-6. **Prefer OIDC** for cloud providers instead of static credentials
-
----
-
-## Troubleshooting
-
-### "Secret not found" errors
-
-\`\`\`bash
-# Check if secret is stored
-npx @haystackeditor/cli secrets list
-
-# Check if it's in the right scope
-npx @haystackeditor/cli secrets get SECRET_NAME --show-metadata
-\`\`\`
-
-### "Permission denied" for cloud resources
-
-- Verify OIDC trust policy includes your repo
-- Check IAM role has required permissions
-- Ensure GitHub Actions has \`id-token: write\` permission
-
-### Secrets work locally but not in CI
-
-- Secrets stored via CLI are user-scoped by default
-- For CI, use GitHub Secrets or organization-level Haystack secrets
-- Check \`npx @haystackeditor/cli secrets list --scope=org\`
-`;
-const SETUP_RULES_CONTENT = `# Set Up Review Policies & Rules
-
-**Your job**: Help the user configure two systems that control how Haystack evaluates their PRs:
-
-1. **Review Policies** — deterministic, path-based triggers that **always** require human review
-2. **PR Rules** — LLM-evaluated code invariants that **flag violations** in the diff
-
-These are distinct systems. Make sure the user understands the difference before proceeding.
-
----
-
-## The Two Systems
-
-### Review Policies (\`.haystack/review-policy.md\`)
-
-**"If a PR touches X → human review needed, period."**
-
-Policies are simple glob patterns. When a PR changes files matching a policy's paths, Haystack will always recommend human review for that PR, regardless of what the code changes look like.
-
-**Good candidates for policies:**
-- Infrastructure (Terraform, Kubernetes, CI/CD pipelines)
-- Authentication and authorization code
-- Database migrations and schemas
-- API contracts (OpenAPI specs, GraphQL schemas, protobuf)
-- Security-sensitive code (crypto, secrets handling)
-- Billing/payment logic
-- Code that bypasses feature flags or launches directly to production
-
-**Format:**
-\`\`\`markdown
-## Policy name
-- **Paths**: \\\`glob/pattern/**\\\`, \\\`other/pattern/*.ts\\\`
-- **Severity**: critical | high | medium | low
-- **Reason**: Why this always needs human eyes
-\`\`\`
-
-### PR Rules (\`.haystack/pr-rules.yml\`)
-
-**"If this invariant is violated in the diff → flag it."**
-
-Rules are checked by an LLM that reads the PR diff and looks for violations. They catch patterns that shouldn't appear in new code, regardless of which files are touched.
-
-**Good candidates for rules:**
-- Error handling conventions (no silent catches, no swallowed errors)
-- Logging requirements (all API calls must be logged)
-- Security patterns (no hardcoded secrets, no SQL string concatenation)
-- Code style invariants (no TODOs without issue refs, no console.log in production)
-- Architecture boundaries (service A must not import from service B)
-- Naming conventions specific to your team
-
-**Format:**
-\`\`\`yaml
-- id: PR001
-  name: Short rule name
-  type: llm
-  severity: warning | error
-  message: Human-readable description of the violation
-  llm:
-    prompt: >
-      Detailed instructions for the LLM about what to look for
-      in the PR diff. Be specific about what counts as a violation
-      and what doesn't.
-    files: "optional/glob/pattern/**/*.ts"  # optional file scope
-\`\`\`
-
----
-
-## Step 1: Explore the Codebase
-
-Before suggesting anything, understand the repo structure:
-
-\`\`\`bash
-# Understand repo layout
-ls -la
-find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' | head -40
-
-# Find infrastructure files
-find . -name "*.tf" -o -name "Dockerfile*" -o -name "docker-compose*" -o -name "*.yml" -path "*/.github/*" | head -20
-
-# Find auth-related code
-grep -rl "auth\\|login\\|session\\|token\\|credential" --include="*.ts" --include="*.py" --include="*.go" --include="*.js" -l | grep -v node_modules | head -20
-
-# Find database/migration files
-find . -path "*/migration*" -o -path "*/schema*" -o -name "*.sql" | grep -v node_modules | head -20
-
-# Find API contract files
-find . -name "*.proto" -o -name "openapi*" -o -name "swagger*" -o -name "*.graphql" | head -20
-
-# Find feature flag patterns
-grep -rl "feature.?flag\\|feature.?toggle\\|isEnabled\\|FEATURE_" --include="*.ts" --include="*.py" --include="*.go" --include="*.js" -l | grep -v node_modules | head -20
-
-# Check for existing config
-cat .haystack/review-policy.md 2>/dev/null || echo "No review-policy.md yet"
-cat .haystack/pr-rules.yml 2>/dev/null || echo "No pr-rules.yml yet"
-\`\`\`
-
-Also look for:
-- CI/CD pipeline files
-- Payment or billing directories
-- Secrets or credential management code
-- Environment configuration patterns
-- Key shared libraries or core utilities that many things depend on
-
----
-
-## STOP — Propose Review Policies
-
-Present your findings to the user. Be specific about what you found and why each area warrants a policy.
-
-**Format your proposal like this:**
-
-> Based on the codebase, here are the areas I'd recommend always requiring human review:
->
-> | # | Policy | Paths | Severity | Why |
-> |---|--------|-------|----------|-----|
-> | 1 | Infrastructure | \\\`terraform/**\\\`, \\\`*.tf\\\` | high | Cost and security implications |
-> | 2 | Auth & secrets | \\\`src/auth/**\\\`, \\\`**/*.secret*\\\` | critical | Security-sensitive |
-> | 3 | ... | ... | ... | ... |
->
-> **Notes:**
-> - I didn't find any database migrations in this repo, so I'm not including that
-> - The \`src/core/\` directory is imported by everything — should changes there always need review?
->
-> Which of these should I include? Any to add, remove, or modify?
-
-**Wait for the user to confirm before writing anything.**
-
----
-
-## Step 2: Write review-policy.md
-
-Once the user confirms, write the policies to \`.haystack/review-policy.md\`:
-
-\`\`\`markdown
-# Review Policies
-
-Review policies define file patterns that always require human attention. When a PR touches files matching these patterns, Haystack will flag it for human review.
-
-## [Policy name]
-- **Paths**: \\\`pattern/**\\\`
-- **Severity**: [level]
-- **Reason**: [why]
-\`\`\`
-
-Create the \`.haystack/\` directory if it doesn't exist.
-
----
-
-## Step 3: Understand Team Conventions
-
-Now shift to rules. Ask the user about their code quality invariants:
-
-> Now let's set up **PR rules** — these are code invariants that Haystack checks in every diff.
->
-> Unlike policies (which trigger on file paths), rules look at *what the code does*. For example:
-> - "Don't add empty catch blocks"
-> - "Don't add TODOs without issue references"
-> - "Don't hardcode API URLs"
->
-> **What conventions does your team care about?** Some common categories:
->
-> 1. **Error handling** — e.g., no swallowed errors, no silent fallbacks
-> 2. **Security** — e.g., no hardcoded secrets, no raw SQL strings
-> 3. **Logging** — e.g., all API calls must have logging
-> 4. **Code hygiene** — e.g., no TODOs without issues, no console.log in production
-> 5. **Architecture** — e.g., no cross-service imports, no direct DB access from UI layer
-> 6. **Testing** — e.g., no skipped tests without reason, no snapshot-only tests
->
-> Tell me which categories matter to your team, or describe your own conventions.
-
-Also explore the codebase for clues:
-
-\`\`\`bash
-# Check for linter configs (reveals team conventions)
-cat .eslintrc* .eslintrc.json .eslintrc.js eslint.config.* 2>/dev/null | head -50
-
-# Check for existing code review guidelines
-find . -name "CONTRIBUTING*" -o -name "REVIEW*" -o -name "STYLE*" | head -5
-
-# Look for common anti-patterns
-grep -rn "catch.*{\\s*}" --include="*.ts" --include="*.js" | head -5
-grep -rn "console\\.log" --include="*.ts" --include="*.tsx" | grep -v test | head -5
-grep -rn "TODO\\|FIXME\\|HACK\\|XXX" --include="*.ts" --include="*.tsx" | head -10
-\`\`\`
-
----
-
-## STOP — Propose PR Rules
-
-Based on the user's input and your codebase exploration, propose 2-5 custom rules.
-
-**Format your proposal like this:**
-
-> Here are the PR rules I'd suggest:
->
-> **1. PR001 — No silent error handling** (warning)
-> > Flag: Adding catch blocks that swallow errors without logging or re-throwing
->
-> **2. PR002 — No TODOs without tracking issues** (warning)
-> > Flag: Adding TODO/FIXME comments without referencing an issue number
->
-> **3. PR003 — No hardcoded API endpoints** (warning)
-> > Flag: Adding hardcoded URLs or API endpoints instead of using config/env vars
->
-> Should I add, remove, or modify any of these?
-
-**Wait for the user to confirm before writing.**
-
----
-
-## Step 4: Write pr-rules.yml
-
-Once confirmed, write to \`.haystack/pr-rules.yml\`:
-
-\`\`\`yaml
-version: 1
-
-rules:
-  - id: PR001
-    name: [Short name]
-    type: llm
-    severity: warning
-    message: [Human-readable description]
-    llm:
-      prompt: >
-        [Detailed LLM instructions — be specific about what counts as
-        a violation and what doesn't. Include examples of violations
-        and non-violations when helpful.]
-\`\`\`
-
-**Tips for writing good rule prompts:**
-- Be specific about what counts as a violation
-- Mention common false positives to ignore (e.g., "test files are exempt")
-- Use the \`files\` field to scope rules to relevant file types
-- \`severity: error\` caps the Haystack rating at 3 (needs review); \`warning\` is advisory
-
----
-
-## Step 5: Commit
-
-\`\`\`bash
-git add .haystack/review-policy.md .haystack/pr-rules.yml
-git commit -m "Add Haystack review policies and PR rules"
-\`\`\`
-
-Done! Haystack will now:
-- Flag PRs touching policy-matched files for human review
-- Check every PR diff against your custom rules and report violations
-`;
-const SETUP_RULES_COMMAND = `# Set Up Rules
-
-Follow .agents/skills/setup-haystack-rules.md to configure review policies (what always needs human review) and PR rules (what code invariants to enforce).
-`;
-export async function createSkillFile() {
-    const skillDir = path.join(process.cwd(), '.agents', 'skills');
-    const setupPath = path.join(skillDir, 'setup-haystack.md');
-    const refPath = path.join(skillDir, 'haystack-reference.md');
-    const prepPath = path.join(skillDir, 'prepare-haystack.md');
-    const secretsPath = path.join(skillDir, 'setup-haystack-secrets.md');
-    const rulesPath = path.join(skillDir, 'setup-haystack-rules.md');
-    // Create directory if needed
-    await fs.mkdir(skillDir, { recursive: true });
-    // Write all skill files
-    await fs.writeFile(setupPath, SKILL_CONTENT, 'utf-8');
-    await fs.writeFile(refPath, REFERENCE_CONTENT, 'utf-8');
-    await fs.writeFile(prepPath, PREPARE_VERIFICATION_CONTENT, 'utf-8');
-    await fs.writeFile(secretsPath, SECRETS_SKILL_CONTENT, 'utf-8');
-    await fs.writeFile(rulesPath, SETUP_RULES_CONTENT, 'utf-8');
-    return setupPath;
-}
-/**
- * Create the .claude/commands/ files for Claude Code slash commands
- * Users can invoke with /setup-haystack, /prepare-haystack, or /setup-haystack-secrets
- */
-export async function createClaudeCommand() {
-    const commandDir = path.join(process.cwd(), '.claude', 'commands');
-    const setupPath = path.join(commandDir, 'setup-haystack.md');
-    const prepPath = path.join(commandDir, 'prepare-haystack.md');
-    const secretsPath = path.join(commandDir, 'setup-haystack-secrets.md');
-    const rulesPath = path.join(commandDir, 'setup-haystack-rules.md');
-    // Create directory if needed
-    await fs.mkdir(commandDir, { recursive: true });
-    // Write command files
-    await fs.writeFile(setupPath, CLAUDE_COMMAND_CONTENT, 'utf-8');
-    await fs.writeFile(prepPath, PREPARE_HAYSTACK_COMMAND, 'utf-8');
-    await fs.writeFile(secretsPath, SECRETS_COMMAND_CONTENT, 'utf-8');
-    await fs.writeFile(rulesPath, SETUP_RULES_COMMAND, 'utf-8');
-    return setupPath;
-}