agent-builder/.claude/plans/blueprints/session-6-integration.md

Session 6: Integration — Docker, Transfer, Additional Templates

Steps 22, 23, 24 | Wave 1 | Depends on: none

Dependencies

Entry condition: none (creates new directories only, no overlap with other sessions)

Scope Fence

Touch:

• scripts/templates/docker/Dockerfile (new)
• scripts/templates/docker/docker-compose.yml (new)
• scripts/templates/docker/docker-entrypoint.sh (new)
• scripts/templates/docker/README.md (new)
• scripts/templates/transfer/export-system.sh (new)
• scripts/templates/transfer/import-system.sh (new)
• scripts/templates/transfer/MANIFEST.md (new)
• scripts/templates/transfer/README.md (new)
• scripts/templates/domains/customer-support.md (new)
• scripts/templates/domains/devops-automation.md (new)
• scripts/templates/domains/legal-review.md (new)
• scripts/templates/domains/sales-intelligence.md (new)
• scripts/templates/domains/security-audit.md (new)
• scripts/templates/domains/README.md (update only — add 5 new entries)

Never touch:

• commands/
• agents/
• skills/
• scripts/templates/domains/content-pipeline.md
• scripts/templates/domains/code-review.md
• scripts/templates/domains/monitoring.md
• scripts/templates/domains/research-synthesis.md
• scripts/templates/domains/data-processing.md

---

Step 22: Create Docker deployment templates

Files to create

scripts/templates/docker/Dockerfile:

# Agent Factory — Docker deployment template
# Runs a Claude Code agent system in an isolated container.
# Replace {{PROJECT_NAME}} and {{ANTHROPIC_API_KEY}} with real values
# (or pass them at runtime via .env / docker compose env_file).

FROM node:22-slim

# Install Claude Code globally
RUN npm install -g @anthropic-ai/claude-code

# Create a non-root agent user for security
RUN useradd -m -s /bin/bash agent

WORKDIR /home/agent/project

# Copy project files (adjust to your project structure)
COPY --chown=agent:agent . .

# Set up entrypoint script
COPY --chown=agent:agent docker-entrypoint.sh /usr/local/bin/docker-entrypoint.sh
RUN chmod +x /usr/local/bin/docker-entrypoint.sh

USER agent

# API key injected at runtime — never bake into image
ENV ANTHROPIC_API_KEY={{ANTHROPIC_API_KEY}}

# Health check — entrypoint writes /tmp/agent-health on each beat
HEALTHCHECK --interval=60s --timeout=10s --start-period=30s --retries=3 \
  CMD test -f /tmp/agent-health && \
      test $(( $(date +%s) - $(date +%s -r /tmp/agent-health 2>/dev/null || echo 0) )) -lt 300

ENTRYPOINT ["docker-entrypoint.sh"]

scripts/templates/docker/docker-compose.yml:

# Agent Factory — docker-compose deployment template
# Usage: docker compose up -d
# Requires: .env file with ANTHROPIC_API_KEY=...

version: "3.8"

services:
  agent:
    container_name: {{PROJECT_NAME}}-agent
    build: .
    restart: unless-stopped
    env_file:
      - .env
    volumes:
      # Persistent data directories — survive container restarts
      - ./data:/home/agent/project/data
      - ./memory:/home/agent/project/memory
      - ./budget:/home/agent/project/budget
      - ./logs:/home/agent/project/logs
    security_opt:
      - no-new-privileges:true
    read_only: false
    # No Docker socket mount — agent cannot control the Docker daemon
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

scripts/templates/docker/docker-entrypoint.sh:

#!/bin/bash
# Agent Factory — Docker container entrypoint
# Validates environment, then runs the heartbeat runner in a loop.
# Bash 3.2 compatible.

set -e

HEALTH_FILE="/tmp/agent-health"
LOG_DIR="/home/agent/project/logs"
HEARTBEAT_SCRIPT="/home/agent/project/automation/heartbeat-runner.sh"

# Graceful shutdown handler
shutdown_handler() {
  echo "[entrypoint] SIGTERM received — shutting down gracefully"
  if [ -n "$RUNNER_PID" ]; then
    kill "$RUNNER_PID" 2>/dev/null || true
    wait "$RUNNER_PID" 2>/dev/null || true
  fi
  rm -f "$HEALTH_FILE"
  echo "[entrypoint] Shutdown complete"
  exit 0
}

trap shutdown_handler TERM INT

# Validate required environment variables
if [ -z "$ANTHROPIC_API_KEY" ]; then
  echo "[entrypoint] ERROR: ANTHROPIC_API_KEY is not set" >&2
  exit 1
fi

# Create required directories
mkdir -p "$LOG_DIR"
mkdir -p "/home/agent/project/data"
mkdir -p "/home/agent/project/memory"
mkdir -p "/home/agent/project/budget"
mkdir -p "/home/agent/project/pipeline-output"

echo "[entrypoint] Starting agent container at $(date)"
echo "[entrypoint] Project: $(basename /home/agent/project)"

# Verify Claude Code is available
if ! command -v claude >/dev/null 2>&1; then
  echo "[entrypoint] ERROR: claude command not found" >&2
  exit 1
fi

# Run heartbeat runner in loop
while true; do
  # Write health check timestamp
  date > "$HEALTH_FILE"

  if [ -f "$HEARTBEAT_SCRIPT" ]; then
    echo "[entrypoint] Running heartbeat at $(date)"
    bash "$HEARTBEAT_SCRIPT" >> "$LOG_DIR/agent.log" 2>&1 &
    RUNNER_PID=$!
    wait $RUNNER_PID
    RUNNER_PID=""
  else
    echo "[entrypoint] WARNING: $HEARTBEAT_SCRIPT not found — sleeping"
  fi

  # Sleep between beats (default 3600s = 1 hour)
  BEAT_INTERVAL="${AGENT_BEAT_INTERVAL:-3600}"
  echo "[entrypoint] Sleeping ${BEAT_INTERVAL}s until next beat"
  sleep "$BEAT_INTERVAL" &
  RUNNER_PID=$!
  wait $RUNNER_PID
  RUNNER_PID=""
done

scripts/templates/docker/README.md:

# Docker Deployment

Run your agent system in an isolated Docker container.

## Prerequisites

- Docker and Docker Compose installed
- `.env` file with your API key (see below)
- Agent system built with `/agent-factory:build`

## Setup

1. Copy these files to your project root:
   - `Dockerfile`
   - `docker-compose.yml`
   - `docker-entrypoint.sh`

2. Create `.env` in your project root:

ANTHROPIC_API_KEY=sk-ant-... AGENT_BEAT_INTERVAL=3600

Add `.env` to `.gitignore` — never commit API keys.

3. Replace `{{PROJECT_NAME}}` in `docker-compose.yml` with your project name.

## Build and run

```bash
# Build the image
docker compose build

# Start in background
docker compose up -d

# View logs
docker compose logs -f

# Stop
docker compose down

Volume mounts

Host path	Container path	Purpose
./data	/home/agent/project/data	Run state, outputs
./memory	/home/agent/project/memory	Long-term memory files
./budget	/home/agent/project/budget	Budget tracking
./logs	/home/agent/project/logs	Agent activity logs

These directories are created automatically on first run.

Environment variables

Variable	Required	Default	Description
ANTHROPIC_API_KEY	Yes	—	Your Anthropic API key
AGENT_BEAT_INTERVAL	No	3600	Seconds between heartbeat runs

Security

• Never bake the API key into the image. Always pass it via .env or --env-file.
• Never mount the Docker socket (/var/run/docker.sock) — the agent does not need Docker control.
• The container runs as a non-root agent user.
• no-new-privileges:true prevents privilege escalation.
• restart: unless-stopped ensures the agent recovers from crashes automatically.

Health check

The entrypoint writes a timestamp to /tmp/agent-health on each beat. Docker's HEALTHCHECK verifies this file is updated within 5 minutes.

Check health status:

docker inspect --format='{{.State.Health.Status}}' {{PROJECT_NAME}}-agent

### Verify

```bash
test -f /Users/ktg/repos/agent-builder/scripts/templates/docker/Dockerfile && \
test -f /Users/ktg/repos/agent-builder/scripts/templates/docker/docker-compose.yml && \
test -f /Users/ktg/repos/agent-builder/scripts/templates/docker/docker-entrypoint.sh && \
test -f /Users/ktg/repos/agent-builder/scripts/templates/docker/README.md && \
echo OK

Expected: OK

On failure

revert

Checkpoint

git commit -m "feat(templates): add Docker deployment templates"

---

Step 23: Create import/export system

Files to create

scripts/templates/transfer/export-system.sh:

#!/bin/bash
# Agent Factory — export-system.sh
# Packages an agent system into a portable tarball with checksums.
# Usage: bash export-system.sh <export-name>
# Bash 3.2 compatible.

set -e

EXPORT_NAME="${1:-agent-system}"
DATE=$(python3 -c "import datetime; print(datetime.date.today().strftime('%Y-%m-%d'))")
OUTPUT_FILE="agent-system-${EXPORT_NAME}-${DATE}.tar.gz"
STAGING_DIR="/tmp/agent-export-$$"
MANIFEST_FILE="${STAGING_DIR}/MANIFEST.md"

# Determine project root (directory containing .claude/)
PROJECT_ROOT="$(pwd)"
if [ ! -d "${PROJECT_ROOT}/.claude" ]; then
  echo "ERROR: No .claude/ directory found in $(pwd)" >&2
  echo "Run this script from your project root." >&2
  exit 1
fi

echo "[export] Starting export: ${EXPORT_NAME}"
echo "[export] Date: ${DATE}"
echo "[export] Output: ${OUTPUT_FILE}"

mkdir -p "${STAGING_DIR}"

# Collect files — explicit inclusions only
collect_files() {
  local dir="$1"
  local dest="$2"
  if [ -d "${PROJECT_ROOT}/${dir}" ]; then
    mkdir -p "${STAGING_DIR}/${dest}"
    cp -r "${PROJECT_ROOT}/${dir}/." "${STAGING_DIR}/${dest}/" 2>/dev/null || true
    echo "[export] Collected: ${dir}"
  fi
}

collect_files ".claude/agents"  ".claude/agents"
collect_files ".claude/skills"  ".claude/skills"
collect_files ".claude/hooks"   ".claude/hooks"
collect_files "hooks"           "hooks"
collect_files "automation"      "automation"
collect_files "scripts"         "scripts"

# Copy settings.json if it exists
if [ -f "${PROJECT_ROOT}/.claude/settings.json" ]; then
  mkdir -p "${STAGING_DIR}/.claude"
  cp "${PROJECT_ROOT}/.claude/settings.json" "${STAGING_DIR}/.claude/settings.json"
  echo "[export] Collected: .claude/settings.json"
fi

# Copy CLAUDE.md if it exists
if [ -f "${PROJECT_ROOT}/CLAUDE.md" ]; then
  cp "${PROJECT_ROOT}/CLAUDE.md" "${STAGING_DIR}/CLAUDE.md"
  echo "[export] Collected: CLAUDE.md"
fi

# Remove excluded files from staging
echo "[export] Removing excluded files"
rm -f "${STAGING_DIR}/.env" 2>/dev/null || true
find "${STAGING_DIR}" -name "*.local.*" -delete 2>/dev/null || true
find "${STAGING_DIR}" -name "audit.log" -delete 2>/dev/null || true
find "${STAGING_DIR}" -name "cost-events.jsonl" -delete 2>/dev/null || true
find "${STAGING_DIR}" -name ".git" -prune -o -print | grep "\.git$" | xargs rm -rf 2>/dev/null || true
rm -rf "${STAGING_DIR}/memory" 2>/dev/null || true

# Generate MANIFEST.md with checksums
echo "[export] Generating manifest"

COMPONENT_ROWS=""
find "${STAGING_DIR}" -type f | sort | while read -r fpath; do
  rel="${fpath#${STAGING_DIR}/}"
  checksum=$(python3 -c "import hashlib; print(hashlib.sha256(open('${fpath}','rb').read()).hexdigest()[:16])")
  filetype="other"
  case "$rel" in
    .claude/agents/*) filetype="agent" ;;
    .claude/skills/*) filetype="skill" ;;
    .claude/hooks/*|hooks/*) filetype="hook" ;;
    .claude/settings.json) filetype="settings" ;;
    automation/*) filetype="automation" ;;
    CLAUDE.md) filetype="context" ;;
  esac
  echo "| ${filetype} | ${rel} | ${checksum} |" >> "${MANIFEST_FILE}.rows"
done

cat > "${MANIFEST_FILE}" << MANIFEST
# Agent System Manifest
Export name: ${EXPORT_NAME}
Export date: ${DATE}
Generated by: Agent Factory export-system.sh

## Components

| Type | File | Checksum (SHA256, first 16) |
|------|------|---------------------------|
MANIFEST

if [ -f "${MANIFEST_FILE}.rows" ]; then
  cat "${MANIFEST_FILE}.rows" >> "${MANIFEST_FILE}"
  rm "${MANIFEST_FILE}.rows"
fi

cat >> "${MANIFEST_FILE}" << MANIFEST

## Requirements

| Requirement | Value |
|-------------|-------|
| Claude Code version | 1.x or later |
| MCP servers | List any required MCP servers here |
| Tools | List any required tools (Bash, WebSearch, etc.) |
| Environment | List required env vars (ANTHROPIC_API_KEY, etc.) |

## Notes

Add any project-specific setup notes here.
MANIFEST

echo "[export] Manifest written"

# Create tarball
cd "${STAGING_DIR}"
tar -czf "${PROJECT_ROOT}/${OUTPUT_FILE}" .
cd "${PROJECT_ROOT}"

# Cleanup
rm -rf "${STAGING_DIR}"

echo "[export] Done: ${OUTPUT_FILE}"
echo "[export] Size: $(du -sh "${OUTPUT_FILE}" | cut -f1)"

scripts/templates/transfer/import-system.sh:

#!/bin/bash
# Agent Factory — import-system.sh
# Imports an exported agent system tarball into the current project.
# Usage: bash import-system.sh <tarball> [--force]
# Bash 3.2 compatible.

set -e

TARBALL="$1"
FORCE="${2:-}"
STAGING_DIR="/tmp/agent-import-$$"

if [ -z "$TARBALL" ]; then
  echo "Usage: bash import-system.sh <agent-system-*.tar.gz> [--force]" >&2
  exit 1
fi

if [ ! -f "$TARBALL" ]; then
  echo "ERROR: File not found: $TARBALL" >&2
  exit 1
fi

echo "[import] Importing: $TARBALL"

mkdir -p "$STAGING_DIR"
tar -xzf "$TARBALL" -C "$STAGING_DIR"

# Read MANIFEST.md
MANIFEST="${STAGING_DIR}/MANIFEST.md"
if [ ! -f "$MANIFEST" ]; then
  echo "ERROR: No MANIFEST.md found in tarball — may not be a valid Agent Factory export" >&2
  rm -rf "$STAGING_DIR"
  exit 1
fi

echo "[import] Manifest found:"
head -5 "$MANIFEST"
echo ""

# Check for conflicts (existing files in destination)
CONFLICTS=""
find "$STAGING_DIR" -type f | sort | while read -r fpath; do
  rel="${fpath#${STAGING_DIR}/}"
  dest="${PWD}/${rel}"
  if [ -f "$dest" ] && [ "$FORCE" != "--force" ]; then
    echo "[import] CONFLICT: $rel already exists"
    CONFLICTS="yes"
  fi
done

if [ -n "$CONFLICTS" ] && [ "$FORCE" != "--force" ]; then
  echo ""
  echo "Conflicts detected. Re-run with --force to overwrite, or remove conflicting files first." >&2
  rm -rf "$STAGING_DIR"
  exit 1
fi

# Extract files to project
echo "[import] Extracting files"
find "$STAGING_DIR" -type f | sort | while read -r fpath; do
  rel="${fpath#${STAGING_DIR}/}"
  dest="${PWD}/${rel}"
  destdir="$(dirname "$dest")"
  mkdir -p "$destdir"
  cp "$fpath" "$dest"
  echo "[import] Wrote: $rel"
done

# Replace {{PLACEHOLDER}} variables
echo "[import] Replacing placeholders"
PROJECT_DIR="$(pwd)"
PROJECT_NAME="$(basename "$PROJECT_DIR")"

find "$PROJECT_DIR/.claude" "$PROJECT_DIR/automation" "$PROJECT_DIR/hooks" \
     "$PROJECT_DIR/CLAUDE.md" -type f 2>/dev/null | while read -r fpath; do
  case "$fpath" in
    *.sh|*.md|*.json|*.yml|*.yaml)
      python3 - "$fpath" "$PROJECT_DIR" "$PROJECT_NAME" << 'PYEOF'
import sys, re
path, project_dir, project_name = sys.argv[1], sys.argv[2], sys.argv[3]
try:
    with open(path, 'r', encoding='utf-8') as f:
        content = f.read()
    content = content.replace('{{PROJECT_DIR}}', project_dir)
    content = content.replace('{{PROJECT_NAME}}', project_name)
    with open(path, 'w', encoding='utf-8') as f:
        f.write(content)
except Exception:
    pass
PYEOF
      ;;
  esac
done

# Make .sh files executable
echo "[import] Setting executable permissions"
find "$PROJECT_DIR/.claude/hooks" "$PROJECT_DIR/hooks" "$PROJECT_DIR/automation" \
     -name "*.sh" -type f 2>/dev/null | while read -r fpath; do
  chmod +x "$fpath"
  echo "[import] chmod +x: $fpath"
done

# Validate frontmatter in agent files
echo "[import] Validating agent frontmatter"
INVALID_AGENTS=""
if [ -d "$PROJECT_DIR/.claude/agents" ]; then
  for agent in "$PROJECT_DIR/.claude/agents"/*.md; do
    [ -f "$agent" ] || continue
    python3 - "$agent" << 'PYEOF'
import sys, re
path = sys.argv[1]
try:
    with open(path, 'r') as f:
        content = f.read()
    if not content.startswith('---'):
        print(f"WARN: {path} missing YAML frontmatter")
        sys.exit(0)
    parts = content.split('---', 2)
    if len(parts) < 3:
        print(f"WARN: {path} malformed frontmatter")
except Exception as e:
    print(f"WARN: {path} could not be validated: {e}")
PYEOF
  done
fi

# Validate bash syntax on hook scripts
echo "[import] Validating hook syntax"
if [ -d "$PROJECT_DIR/.claude/hooks" ]; then
  for script in "$PROJECT_DIR/.claude/hooks"/*.sh; do
    [ -f "$script" ] || continue
    if bash -n "$script" 2>/dev/null; then
      echo "[import] OK: $script"
    else
      echo "[import] WARN: $script failed bash -n check"
    fi
  done
fi

rm -rf "$STAGING_DIR"

echo ""
echo "[import] Import complete."
echo "[import] Next steps:"
echo "  1. Review CLAUDE.md and update project-specific sections"
echo "  2. Add your ANTHROPIC_API_KEY to .env"
echo "  3. Run /agent-factory:status to verify the system"

scripts/templates/transfer/MANIFEST.md:

# Agent System Manifest
Export name: {{EXPORT_NAME}}
Export date: {{EXPORT_DATE}}
Generated by: Agent Factory export-system.sh

## Components

| Type | File | Checksum (SHA256, first 16) |
|------|------|---------------------------|
| agent | .claude/agents/pipeline-runner.md | a1b2c3d4e5f6a7b8 |
| skill | .claude/skills/my-pipeline/SKILL.md | b2c3d4e5f6a7b8c9 |
| hook | .claude/hooks/pre-tool-use.sh | c3d4e5f6a7b8c9d0 |
| settings | .claude/settings.json | d4e5f6a7b8c9d0e1 |
| automation | automation/run-pipeline.sh | e5f6a7b8c9d0e1f2 |
| context | CLAUDE.md | f6a7b8c9d0e1f2a3 |

## Requirements

| Requirement | Value |
|-------------|-------|
| Claude Code version | 1.x or later |
| MCP servers | (list any required MCP servers, e.g. GitHub, Slack) |
| Tools | Bash, Read, Write, Glob, Grep |
| Environment | ANTHROPIC_API_KEY |

## Notes

Replace all `{{PLACEHOLDER}}` variables after import.
See transfer/README.md for import instructions.

scripts/templates/transfer/README.md:

# Import / Export System

Portable packaging for agent systems. Export a working agent system from one
project and import it into another, with automatic placeholder substitution.

## Export

Pack your current agent system into a tarball:

```bash
bash scripts/templates/transfer/export-system.sh my-project-name
# Creates: agent-system-my-project-name-2026-04-11.tar.gz

What is included

Included	Excluded
.claude/agents/	.env (secrets)
.claude/skills/	*.local.* files
.claude/hooks/	audit.log
.claude/settings.json	cost-events.jsonl
hooks/	memory/ (machine-specific state)
automation/	.git/
scripts/
CLAUDE.md

Import

Extract a tarball into a new project directory:

# Dry run first: inspect without extracting
tar -tzf agent-system-my-project-name-2026-04-11.tar.gz

# Import (will stop if files conflict)
bash scripts/templates/transfer/import-system.sh agent-system-my-project-name-2026-04-11.tar.gz

# Import and overwrite existing files
bash scripts/templates/transfer/import-system.sh agent-system-my-project-name-2026-04-11.tar.gz --force

The import script will:

1. Read MANIFEST.md and verify the archive
2. Check for conflicts with existing files (stops unless --force)
3. Extract all files
4. Replace {{PROJECT_DIR}} and {{PROJECT_NAME}} placeholders
5. Make .sh files executable
6. Validate agent frontmatter and hook syntax

Customization after import

1. Update CLAUDE.md — replace project-specific context, goals, and constraints
2. Add secrets — create .env with ANTHROPIC_API_KEY=sk-ant-...
3. Review hooks — check that paths in hook scripts match your environment
4. Run /agent-factory:status — verify all components load correctly
5. Run /agent-factory:evaluate — check capability coverage

Manifest

Each export includes MANIFEST.md listing every file with a SHA256 checksum (first 16 hex characters). Use this to verify file integrity after transfer.

Template manifest: scripts/templates/transfer/MANIFEST.md

### Verify

```bash
bash -n /Users/ktg/repos/agent-builder/scripts/templates/transfer/export-system.sh && \
bash -n /Users/ktg/repos/agent-builder/scripts/templates/transfer/import-system.sh && \
echo OK

Expected: OK

On failure

retry — fix syntax errors in the failing script, then re-verify

Checkpoint

git commit -m "feat(templates): add import/export system for agent systems"

---

Step 24: Create 5 additional domain templates (total 10)

Files to create

scripts/templates/domains/customer-support.md:

# Domain Template: Customer Support

<!-- Domain: Customer support ticket handling and escalation -->
<!-- Agents: 3 (ticket-classifier, response-drafter, escalation-checker) -->
<!-- Pipeline: Classify → Draft response → Check escalation → Send -->

## Agent Definitions

### ticket-classifier

---
name: ticket-classifier
description: |
  Use this agent to classify incoming support tickets by type, priority, and sentiment.

  <example>
  Context: New support ticket needs routing
  user: "Classify this support ticket"
  assistant: "I'll use the ticket-classifier to determine type and priority."
  <commentary>Ticket triage step in customer support pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Glob", "Grep", "Bash"]
---

You classify customer support tickets for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read the ticket content from $ARGUMENTS or from `pipeline-input/` directory
2. Read CLAUDE.md for product context and classification taxonomy
3. Read memory/MEMORY.md for patterns from prior tickets
4. Classify along 3 axes:
   - Type: billing, technical, feature-request, complaint, general
   - Priority: critical (SLA breach risk), high, normal, low
   - Sentiment: angry, frustrated, neutral, satisfied
5. Extract: customer name (if present), product area, key complaint phrase
6. Write classification to `pipeline-output/classified-$(date +%Y-%m-%d-%H%M).md`

## Rules

- Never guess at account details — extract only what is written
- If type is ambiguous, choose the broader category
- Mark as critical if: mentions legal action, data loss, or account termination threat
- Always output structured JSON in addition to the markdown report

## Output format

```json
{
  "type": "technical",
  "priority": "high",
  "sentiment": "frustrated",
  "product_area": "{{DOMAIN}}",
  "key_phrase": "cannot log in since yesterday",
  "requires_escalation": false
}

response-drafter

---

name: response-drafter description: | Use this agent to draft a customer support response from a classified ticket.

Context: Ticket has been classified and needs a response user: "Draft a response for this ticket" assistant: "I'll use the response-drafter to write a support reply." Response drafting stage of customer support pipeline triggers this agent. model: opus tools: ["Read", "Write", "Glob"] ---

You draft customer support responses for {{DOMAIN}} in {{PROJECT_DIR}}.

How you work

1. Read the classified ticket and its JSON classification
2. Read CLAUDE.md for tone guidelines, response templates, and SLA commitments
3. Read support-templates/ directory if it exists for approved response patterns
4. Match the tone to the sentiment: empathetic for frustrated, direct for neutral
5. Draft a response that: acknowledges the issue, provides a resolution or next step, sets expectations
6. Never promise features not confirmed in CLAUDE.md
7. Save draft to pipeline-output/draft-response-$(date +%Y-%m-%d-%H%M).md

Rules

• Always acknowledge the customer's experience before explaining the solution
• Never use corporate jargon or hollow phrases ("We apologize for any inconvenience")
• If resolution is unclear: provide a concrete next step (link, escalation, timeline)
• Keep responses under 200 words unless complex technical explanation is needed
• Match formality to the customer's writing style

escalation-checker

---

name: escalation-checker description: | Use this agent to determine whether a ticket requires escalation beyond a standard response.

Context: Draft response is ready, need to check escalation policy user: "Should this ticket be escalated?" assistant: "I'll use the escalation-checker to evaluate the escalation criteria." Escalation check stage of customer support pipeline triggers this agent. model: sonnet tools: ["Read", "Glob", "Grep"] ---

You check escalation criteria for customer support tickets in {{PROJECT_DIR}}.

How you work

1. Read the classified ticket, draft response, and escalation policy from CLAUDE.md
2. Check escalation triggers:
   • Priority is critical
   • Sentiment is angry AND issue is unresolved
   • Customer has contacted support more than 3 times on the same issue (check memory)
   • Legal or regulatory language in ticket
   • Data loss or security concern
3. If escalation is triggered: identify the appropriate escalation path from CLAUDE.md
4. Output escalation decision with reasoning

Output format

ESCALATION DECISION: [YES / NO]
Triggers met: [list triggers, or "none"]
Escalation path: [team or person if YES, "n/a" if NO]
Recommended action: [specific next step]

Pipeline Skill Template

---
name: {{PIPELINE_NAME}}
description: |
  Run customer support ticket pipeline. Classifies, drafts responses, checks escalation.
  Triggers on: "handle support ticket", "process ticket", "support pipeline"
version: 0.1.0
---

**Step 1 — Load context:** Read CLAUDE.md for product info and support policy
**Step 2 — Classify:** Use ticket-classifier agent on incoming ticket
**Step 3 — Draft response:** Use response-drafter agent with classification
**Step 4 — Check escalation:** Use escalation-checker agent with ticket and draft
**Step 5 — Route:** If escalation YES: save to pipeline-output/escalate/. If NO: save to pipeline-output/ready/
**Step 6 — Update memory:** Log ticket type, sentiment, resolution approach
**Step 7 — Report:** Output classification, response path, escalation decision

Recommended Hooks

Pre-tool-use: Block writes outside {{PROJECT_DIR}} and pipeline-output/ Post-tool-use: Audit log all tool calls with ticket ID reference

Example CLAUDE.md Sections

## Customer Support Policy

- Product: [your product name]
- Support channels: [email/chat/ticketing system]
- SLA: [response time commitments by priority]
- Escalation team: [team name or contact]
- Tone: [professional, friendly, direct]
- Approved resolution paths: [list standard resolutions]

**`scripts/templates/domains/devops-automation.md`**:

```markdown
# Domain Template: DevOps Automation

<!-- Domain: Deployment checks, incident detection, and runbook execution -->
<!-- Agents: 3 (deploy-checker, incident-detector, runbook-executor) -->
<!-- Pipeline: Check deployment → Detect incidents → Execute runbook → Report -->

## Agent Definitions

### deploy-checker

---
name: deploy-checker
description: |
  Use this agent to verify deployment health after a release.

  <example>
  Context: Deployment just completed
  user: "Check the deployment health"
  assistant: "I'll use the deploy-checker to verify service status post-deploy."
  <commentary>Post-deployment health check triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Bash", "Glob", "Grep", "WebFetch"]
---

You check deployment health for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read deployment config from CLAUDE.md or `devops/config.md`
2. Run health checks:
   - HTTP endpoint checks: expected status codes and response content
   - Service process checks: expected processes running
   - Log scanning: new ERROR/FATAL entries since deploy timestamp
   - Resource checks: disk, memory within thresholds (via Bash if available)
3. Compare against baseline from memory/MEMORY.md
4. Classify findings: healthy, degraded, down

## Rules

- Record the check timestamp and deployment reference
- Never modify deployed services — read-only checks only
- Flag any ERROR log line introduced within 10 minutes of deploy

### incident-detector

---
name: incident-detector
description: |
  Use this agent to detect and classify incidents from system signals.

  <example>
  Context: Monitoring data shows anomalies
  user: "Detect incidents from this data"
  assistant: "I'll use the incident-detector to classify the anomalies."
  <commentary>Incident detection step in DevOps pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Bash", "Grep", "Glob"]
---

You detect and classify incidents for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read health check output from deploy-checker
2. Scan log files for error patterns: stack traces, OOM kills, connection timeouts
3. Check alert rules from CLAUDE.md or `devops/alert-rules.md`
4. Classify incident severity:
   - P1 (critical): service down, data loss risk, security breach
   - P2 (high): significant degradation, partial outage
   - P3 (medium): minor degradation, non-critical errors
   - P4 (low): cosmetic issues, single isolated errors
5. Link incident to known runbooks if available in `devops/runbooks/`

### runbook-executor

---
name: runbook-executor
description: |
  Use this agent to execute a runbook in response to a detected incident.

  <example>
  Context: Incident detected and runbook identified
  user: "Execute the restart runbook for this incident"
  assistant: "I'll use the runbook-executor to run the appropriate runbook."
  <commentary>Runbook execution step in DevOps pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Bash", "Write", "Glob"]
---

You execute runbooks for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read the incident report and identified runbook from `devops/runbooks/`
2. Parse runbook steps — each step has: description, command, expected outcome, rollback
3. Execute steps one at a time via Bash, checking outcome against expected
4. If a step fails: stop, log failure, do NOT proceed to next step
5. Write execution log to `pipeline-output/runbook-run-$(date +%Y-%m-%d-%H%M).md`

## Rules

- Never execute runbook steps marked MANUAL — list them for human action instead
- Always confirm destructive operations (restart, delete) by re-reading the runbook step
- Log every command and its output before moving to the next step
- If the runbook is missing or incomplete: report and wait for human input

## Pipeline Skill Template

```markdown
---
name: {{PIPELINE_NAME}}
description: |
  Run DevOps automation pipeline. Checks deployment, detects incidents, executes runbooks.
  Triggers on: "check deployment", "run devops pipeline", "incident check"
version: 0.1.0
---

**Step 1 — Load config:** Read CLAUDE.md for service endpoints and alert thresholds
**Step 2 — Check deployment:** Use deploy-checker agent
**Step 3 — Detect incidents:** If issues found, use incident-detector agent
**Step 4 — Execute runbook:** For P1/P2 incidents with matching runbook, use runbook-executor
**Step 5 — Save:** Write report to pipeline-output/devops-$(date +%Y-%m-%d-%H%M).md
**Step 6 — Alert:** For P1 incidents: print prominent warning; for P2: note in report
**Step 7 — Update memory:** Log check time, incident count, runbooks executed

Recommended Hooks

Pre-tool-use: Require confirmation before Bash commands matching restart|stop|kill|delete|drop Post-tool-use: Audit all Bash executions with full command and exit code

Example CLAUDE.md Sections

## DevOps Configuration

- Services: [list service names and endpoints]
- Health check endpoints: [URLs with expected responses]
- Log paths: [absolute paths to log files]
- Alert thresholds: [error rate, response time, disk usage]
- Runbooks: devops/runbooks/ directory
- On-call contact: [team or person for P1 incidents]

**`scripts/templates/domains/legal-review.md`**:

```markdown
# Domain Template: Legal Review

<!-- Domain: Contract and document legal review -->
<!-- Agents: 3 (clause-extractor, risk-assessor, compliance-checker) -->
<!-- Pipeline: Extract clauses → Assess risk → Check compliance → Produce report -->

## Agent Definitions

### clause-extractor

---
name: clause-extractor
description: |
  Use this agent to extract and categorize clauses from legal documents.

  <example>
  Context: Contract needs clause extraction before review
  user: "Extract clauses from this contract"
  assistant: "I'll use the clause-extractor to identify and categorize all clauses."
  <commentary>Clause extraction step in legal review pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Glob", "Write"]
---

You extract and categorize clauses from legal documents for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read the document from $ARGUMENTS or the `legal-input/` directory
2. Read CLAUDE.md for the clause taxonomy (which types of clauses matter for this domain)
3. Identify and extract all clauses, organized by type:
   - Liability and indemnification
   - Termination and notice
   - Intellectual property
   - Confidentiality and NDA
   - Governing law and dispute resolution
   - Payment and fee terms
   - Warranties and representations
4. Note clause location (section number, page reference if available)
5. Flag non-standard or unusual phrasing

## Rules

- Extract verbatim — never paraphrase clauses in the extraction stage
- Note if a standard clause type appears to be missing
- This agent does NOT give legal advice — it extracts and organizes

### risk-assessor

---
name: risk-assessor
description: |
  Use this agent to assess risk in extracted contract clauses.

  <example>
  Context: Clauses have been extracted from a contract
  user: "Assess the risk in these clauses"
  assistant: "I'll use the risk-assessor to evaluate each clause for risk."
  <commentary>Risk assessment step in legal review pipeline triggers this agent.</commentary>
  </example>
model: opus
tools: ["Read", "Write", "Glob"]
---

You assess risk in legal clauses for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read the extracted clauses from clause-extractor output
2. Read CLAUDE.md for risk tolerance guidelines and known problematic patterns
3. For each clause type, assess:
   - Exposure: what liability or obligation does this create?
   - Asymmetry: is this clause balanced or heavily one-sided?
   - Ambiguity: are key terms defined? Are obligations measurable?
   - Precedent: is this standard for this type of contract?
4. Rate each finding: high risk, medium risk, low risk, note only
5. Provide specific commentary on high-risk clauses

## Rules

- This is a risk identification tool, not legal advice
- Always note that findings should be reviewed by qualified legal counsel
- Focus on structural risk, not stylistic preferences
- Compare against market standard where CLAUDE.md provides benchmarks

### compliance-checker

---
name: compliance-checker
description: |
  Use this agent to check a legal document against regulatory compliance requirements.

  <example>
  Context: Contract needs compliance verification
  user: "Check this contract for GDPR compliance"
  assistant: "I'll use the compliance-checker to verify regulatory requirements."
  <commentary>Compliance check step in legal review pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Glob", "Grep"]
---

You check legal documents for compliance requirements in {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read the document and extracted clauses
2. Read CLAUDE.md for applicable regulations and compliance checklist
3. For each regulation in scope: verify required clauses or language is present
4. Check data processing agreements if GDPR/CCPA in scope
5. Check jurisdiction-specific requirements from the governing law clause
6. Output: compliance checklist with PASS/FAIL/MISSING per requirement

## Rules

- Only check against regulations explicitly listed in CLAUDE.md
- Flag if governing law clause is missing or ambiguous
- Note if jurisdiction creates additional requirements not covered in CLAUDE.md
- This is a checklist tool — final compliance determination requires legal counsel

## Pipeline Skill Template

```markdown
---
name: {{PIPELINE_NAME}}
description: |
  Run legal review pipeline. Extracts clauses, assesses risk, checks compliance.
  Triggers on: "review contract", "legal review", "check this agreement"
version: 0.1.0
---

**Step 1 — Load context:** Read CLAUDE.md for clause taxonomy and compliance requirements
**Step 2 — Extract clauses:** Use clause-extractor agent on the document
**Step 3 — Assess risk:** Use risk-assessor agent on extracted clauses
**Step 4 — Check compliance:** Use compliance-checker agent
**Step 5 — Combine:** Merge risk and compliance findings into a single report
**Step 6 — Save:** Write to pipeline-output/legal-review-$(date +%Y-%m-%d).md
**Step 7 — Update memory:** Log document type, risk findings count, compliance status

Recommended Hooks

Pre-tool-use: Block all writes outside {{PROJECT_DIR}} and pipeline-output/ — legal docs must not leave the project Post-tool-use: Audit all file reads for data governance logging

Example CLAUDE.md Sections

## Legal Review Configuration

- Contract types in scope: [MSA, NDA, SaaS agreements, etc.]
- Clause taxonomy: [list clause types that matter for your domain]
- Risk tolerance: [what risk levels require escalation to counsel]
- Regulations in scope: [GDPR, CCPA, SOC2, industry-specific]
- Compliance checklist: [link to or embed the checklist]
- Legal counsel contact: [for escalation of high-risk findings]

IMPORTANT: This agent system identifies risk patterns and compliance gaps.
It does not provide legal advice. All high-risk findings must be reviewed
by qualified legal counsel before signing.

**`scripts/templates/domains/sales-intelligence.md`**:

```markdown
# Domain Template: Sales Intelligence

<!-- Domain: Prospect research, pitch customization, and follow-up tracking -->
<!-- Agents: 3 (prospect-researcher, pitch-customizer, follow-up-tracker) -->
<!-- Pipeline: Research prospect → Customize pitch → Track follow-up → Report -->

## Agent Definitions

### prospect-researcher

---
name: prospect-researcher
description: |
  Use this agent to research a prospect before a sales engagement.

  <example>
  Context: Sales team needs intelligence on a prospect
  user: "Research this prospect company"
  assistant: "I'll use the prospect-researcher to gather intelligence on the company."
  <commentary>Prospect research step in sales intelligence pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Glob", "Grep", "WebSearch", "WebFetch", "Write"]
---

You research sales prospects for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Parse prospect name/URL from $ARGUMENTS
2. Read CLAUDE.md for ICP (ideal customer profile) and what signals matter
3. Gather intelligence:
   - Company overview: size, industry, funding stage, recent news
   - Technology stack clues: job postings, tech blog, GitHub presence
   - Pain signals: recent hiring patterns, product announcements, leadership changes
   - Budget signals: funding rounds, enterprise customer base
   - Decision-makers: who buys your category (from LinkedIn structure if available)
4. Score against ICP: strong fit, partial fit, weak fit
5. Save to `pipeline-output/prospect-{{AGENT_NAME}}-$(date +%Y-%m-%d).md`

## Rules

- Only use publicly available information
- Note source for every data point
- Mark inferences explicitly as [INFERRED] vs [CONFIRMED]
- Never fabricate contact details or company information

### pitch-customizer

---
name: pitch-customizer
description: |
  Use this agent to customize a sales pitch based on prospect research.

  <example>
  Context: Prospect research is complete and pitch needs customization
  user: "Customize the pitch for this prospect"
  assistant: "I'll use the pitch-customizer to tailor the messaging."
  <commentary>Pitch customization step in sales intelligence pipeline triggers this agent.</commentary>
  </example>
model: opus
tools: ["Read", "Write", "Glob"]
---

You customize sales pitches for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read the prospect research brief
2. Read the base pitch from CLAUDE.md or `sales/pitch-base.md`
3. Identify the 2-3 pain signals most relevant to your solution
4. Customize the pitch:
   - Opening: reference specific prospect context (recent news, known challenge)
   - Value proposition: emphasize benefits most relevant to their pain signals
   - Social proof: pick case studies matching their industry/size
   - Call to action: match their stage (awareness vs. evaluation vs. decision)
5. Keep the customization to specific paragraphs — do not rewrite the entire pitch

## Rules

- Stay within the approved pitch framework from CLAUDE.md
- Never claim capabilities not listed in the base pitch
- Flag if no matching case study exists for the prospect's profile

### follow-up-tracker

---
name: follow-up-tracker
description: |
  Use this agent to track and schedule follow-up actions for sales opportunities.

  <example>
  Context: Sales interaction completed and follow-up needed
  user: "Schedule follow-up actions for this opportunity"
  assistant: "I'll use the follow-up-tracker to log and schedule next steps."
  <commentary>Follow-up tracking step in sales intelligence pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Write", "Glob", "Grep", "Bash"]
---

You track follow-up actions for sales opportunities in {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read the interaction notes from $ARGUMENTS or `pipeline-input/`
2. Read memory/MEMORY.md for prior interactions with this prospect
3. Extract commitments: what was promised, by whom, by when
4. Identify next steps: follow-up date, required materials, approvals needed
5. Write to `pipeline-output/follow-up-$(date +%Y-%m-%d).md`
6. Append summary to memory/MEMORY.md for continuity

## Output format

OPPORTUNITY: [prospect name] Last interaction: [date] Stage: [awareness / evaluation / proposal / negotiation / closed]

Commitments:

• [who] will [what] by [when]

Next steps:

• [action] by [date] — owner: [person or agent]

Follow-up due: [date]

## Pipeline Skill Template

```markdown
---
name: {{PIPELINE_NAME}}
description: |
  Run sales intelligence pipeline. Researches prospects, customizes pitches, tracks follow-up.
  Triggers on: "research prospect", "sales pipeline", "prepare for meeting"
version: 0.1.0
---

**Step 1 — Load context:** Read CLAUDE.md for ICP, pitch framework, and active opportunities
**Step 2 — Research prospect:** Use prospect-researcher agent with $ARGUMENTS
**Step 3 — Customize pitch:** Use pitch-customizer agent with research brief
**Step 4 — Track follow-up:** Use follow-up-tracker agent to log commitments and schedule next steps
**Step 5 — Save:** Write complete intelligence pack to pipeline-output/sales-$(date +%Y-%m-%d).md
**Step 6 — Update memory:** Append interaction summary, ICP score, next follow-up date

Recommended Hooks

Pre-tool-use: Block writes outside {{PROJECT_DIR}} and pipeline-output/ — prospect data must stay within project Post-tool-use: Log all web fetches for source attribution

Example CLAUDE.md Sections

## Sales Configuration

- Product: [what you sell]
- ICP: [ideal customer profile — industry, size, tech stack signals, pain points]
- Base pitch: sales/pitch-base.md
- Case studies: sales/case-studies/
- Pitch framework: [problem → solution → proof → CTA]
- CRM integration: [manual log, or MCP connector for your CRM]

**`scripts/templates/domains/security-audit.md`**:

```markdown
# Domain Template: Security Audit

<!-- Domain: Configuration scanning, vulnerability checking, and remediation -->
<!-- Agents: 3 (config-scanner, vulnerability-checker, remediation-advisor) -->
<!-- Pipeline: Scan config → Check vulnerabilities → Advise remediation → Report -->

## Agent Definitions

### config-scanner

---
name: config-scanner
description: |
  Use this agent to scan configuration files for security misconfigurations.

  <example>
  Context: Security audit of project configuration needed
  user: "Scan this project's configuration for security issues"
  assistant: "I'll use the config-scanner to check for misconfigurations."
  <commentary>Configuration scanning step in security audit pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Glob", "Grep", "Bash"]
---

You scan configurations for security issues in {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read CLAUDE.md for the technology stack and what config files exist
2. Glob for all config files: `.env.example`, `*.yml`, `*.yaml`, `*.json`, `*.toml`, `*.ini`
3. For each config file, check:
   - Secrets in plain text (API keys, passwords, tokens)
   - Overly permissive file permissions (`chmod 777`, world-writable paths)
   - Debug mode enabled in production configs
   - Insecure defaults (default credentials, open CORS, disabled auth)
   - Dependency versions with known CVEs (check package.json, requirements.txt)
4. Classify findings: critical, high, medium, informational

## Rules

- Never output the actual secret values — mask them as `[REDACTED]`
- Check `.gitignore` and warn if secret files might not be excluded
- Flag if `.env` files are committed (check git log if available)

### vulnerability-checker

---
name: vulnerability-checker
description: |
  Use this agent to check a project for known vulnerabilities.

  <example>
  Context: Config scan is complete and deeper vulnerability check is needed
  user: "Check for vulnerabilities in this project"
  assistant: "I'll use the vulnerability-checker to identify known CVEs and security patterns."
  <commentary>Vulnerability checking step in security audit pipeline triggers this agent.</commentary>
  </example>
model: sonnet
tools: ["Read", "Bash", "Glob", "Grep"]
---

You check for vulnerabilities in {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read config-scanner findings
2. Run available dependency audit tools via Bash (non-destructive only):
   - Node.js: `npm audit --json 2>/dev/null` if package.json exists
   - Python: `pip-audit --output json 2>/dev/null` if requirements.txt exists
3. Check code patterns for common vulnerabilities:
   - SQL injection: string concatenation in queries
   - Command injection: unsanitized user input in shell commands
   - Path traversal: user-controlled file paths without validation
   - Hardcoded credentials in source code
   - Insecure direct object references
4. Check Claude Code-specific risks:
   - Hooks running untrusted input as shell commands
   - Agents with Bash tool and no deny-list
   - `--dangerously-skip-permissions` outside sandboxed context
5. Output: CVE list (if found), code pattern findings, Claude Code-specific risks

### remediation-advisor

---
name: remediation-advisor
description: |
  Use this agent to recommend remediation steps for security findings.

  <example>
  Context: Security findings need remediation recommendations
  user: "Recommend fixes for these security findings"
  assistant: "I'll use the remediation-advisor to produce actionable remediation steps."
  <commentary>Remediation advice step in security audit pipeline triggers this agent.</commentary>
  </example>
model: opus
tools: ["Read", "Write", "Glob"]
---

You recommend security remediations for {{DOMAIN}} in {{PROJECT_DIR}}.

## How you work

1. Read all security findings from config-scanner and vulnerability-checker
2. For each finding, produce a remediation entry:
   - What is the risk (plain language)
   - Specific fix (exact change, not vague guidance)
   - Effort estimate: low (< 1 hour), medium (< 1 day), high (> 1 day)
   - Whether the fix can be automated vs. requires manual review
3. Prioritize: critical first, then by effort-to-impact ratio
4. For dependency CVEs: provide the minimum safe version to upgrade to
5. For Claude Code-specific findings: reference the appropriate settings.json pattern

## Rules

- Provide specific, actionable fixes — not "improve security"
- Never suggest fixes that would break functionality without noting the trade-off
- For critical findings with no easy fix: note interim mitigations

## Output format

SECURITY AUDIT REPORT — {{DOMAIN}} Date: [date] Scope: {{PROJECT_DIR}}

Summary

Critical: [N] | High: [N] | Medium: [N] | Informational: [N]

Critical Findings

[Finding ID]: [Title]

Risk: [plain language risk description] Location: [file:line or component] Fix: [specific remediation] Effort: [low/medium/high]

[repeat for each finding]

Recommended Priority Order

1. [finding ID] — [one line reason] ...

## Pipeline Skill Template

```markdown
---
name: {{PIPELINE_NAME}}
description: |
  Run security audit pipeline. Scans config, checks vulnerabilities, recommends remediation.
  Triggers on: "run security audit", "check security", "security scan"
version: 0.1.0
---

**Step 1 — Load context:** Read CLAUDE.md for tech stack and security scope
**Step 2 — Scan config:** Use config-scanner agent on project files
**Step 3 — Check vulnerabilities:** Use vulnerability-checker agent
**Step 4 — Recommend remediation:** Use remediation-advisor agent with all findings
**Step 5 — Save:** Write full report to pipeline-output/security-audit-$(date +%Y-%m-%d).md
**Step 6 — Alert:** If critical findings: print prominent summary with finding IDs
**Step 7 — Update memory:** Log audit date, finding counts, remediated items from prior audits

Recommended Hooks

Pre-tool-use: Block writes outside {{PROJECT_DIR}} and pipeline-output/ — audit output must stay local Post-tool-use: Log all file reads for audit trail

Example CLAUDE.md Sections

## Security Audit Configuration

- Tech stack: [languages, frameworks, infrastructure]
- Config files to scan: [list key config file paths]
- Dependency manifests: [package.json, requirements.txt, go.mod, etc.]
- Compliance requirements: [SOC2, ISO 27001, PCI-DSS, etc.]
- Known accepted risks: [any accepted findings with risk owner and date]
- Secret patterns: [regex patterns for project-specific secrets to scan for]

Now update `scripts/templates/domains/README.md` to list all 10 templates. The existing README covers 5; add the new 5 rows and update the table:

**`scripts/templates/domains/README.md`** — replace the `## Available Templates` table with:

```markdown
# Domain Templates

Pre-built pipeline templates for common use cases. The builder agent reads these
during `/agent-factory:build` Phase 0 to pre-populate the design sketch.

## Available Templates

| Template | Domain | Agents | Pipeline |
|----------|--------|--------|----------|
| content-pipeline | Content production | content-researcher, content-writer, content-reviewer | Research → Draft → Review → Publish |
| code-review | Code review | code-analyzer, review-writer, standards-checker | Analyze → Write review → Check standards → Post |
| monitoring | System monitoring | monitor-checker, incident-reporter, remediation-advisor | Check → Detect → Report → Advise |
| research-synthesis | Research & analysis | source-gatherer, synthesizer, fact-checker | Gather → Synthesize → Verify → Produce brief |
| data-processing | Data transformation | data-validator, transformer, quality-checker | Validate → Transform → Check quality → Save |
| customer-support | Customer support | ticket-classifier, response-drafter, escalation-checker | Classify → Draft → Escalation check → Route |
| devops-automation | DevOps automation | deploy-checker, incident-detector, runbook-executor | Deploy check → Detect → Execute runbook → Report |
| legal-review | Legal document review | clause-extractor, risk-assessor, compliance-checker | Extract → Assess risk → Compliance check → Report |
| sales-intelligence | Sales intelligence | prospect-researcher, pitch-customizer, follow-up-tracker | Research → Customize pitch → Track follow-up → Report |
| security-audit | Security auditing | config-scanner, vulnerability-checker, remediation-advisor | Scan config → Check CVEs → Remediation → Report |

## Usage

During `/agent-factory:build`, choose a template when prompted:
"Would you like to start from a domain template?"

The builder reads the chosen template and pre-populates:
- Agent roles and descriptions
- Pipeline steps and handoff points
- Recommended hooks for the domain
- Example CLAUDE.md sections

## Template format

Each template is a plain markdown file with `{{PLACEHOLDER}}` variables.
The builder agent replaces placeholders with project-specific values during
scaffolding. All templates follow the same structure:

1. Header comment (domain description)
2. Agent definitions (frontmatter + system prompt per agent)
3. Pipeline skill template
4. Recommended hooks
5. Example CLAUDE.md sections

## Placeholders

All templates use these standard placeholders:

| Placeholder | Description |
|------------|-------------|
| `{{PROJECT_DIR}}` | Absolute path to the user's project |
| `{{AGENT_NAME}}` | Name of the agent being generated |
| `{{PIPELINE_NAME}}` | Name of the pipeline skill |
| `{{SCHEDULE}}` | Cron expression or schedule description |
| `{{DOMAIN}}` | Domain name (e.g., "content", "code-review") |

## Creating custom templates

Copy any existing template and modify it. The builder agent can also generate
custom templates during the build workflow.

Verify

ls /Users/ktg/repos/agent-builder/scripts/templates/domains/*.md | wc -l

Expected: 11 (6 from Session 2 + 5 new = 11 total)

On failure

retry — ensure all 5 new templates follow the same structure as the existing 5, then revert if still failing

Checkpoint

git commit -m "feat(templates): add 5 more domain templates (10 total)"

---

Exit Condition

• ls /Users/ktg/repos/agent-builder/scripts/templates/docker/ | wc -l → 4
• bash -n /Users/ktg/repos/agent-builder/scripts/templates/docker/docker-entrypoint.sh && echo OK → OK
• bash -n /Users/ktg/repos/agent-builder/scripts/templates/transfer/export-system.sh && echo OK → OK
• bash -n /Users/ktg/repos/agent-builder/scripts/templates/transfer/import-system.sh && echo OK → OK
• ls /Users/ktg/repos/agent-builder/scripts/templates/transfer/ | wc -l → 4
• ls /Users/ktg/repos/agent-builder/scripts/templates/domains/*.md | wc -l → 11
• All 5 new domain templates contain {{PIPELINE_NAME}} placeholder: grep -l "PIPELINE_NAME" /Users/ktg/repos/agent-builder/scripts/templates/domains/customer-support.md /Users/ktg/repos/agent-builder/scripts/templates/domains/devops-automation.md /Users/ktg/repos/agent-builder/scripts/templates/domains/legal-review.md /Users/ktg/repos/agent-builder/scripts/templates/domains/sales-intelligence.md /Users/ktg/repos/agent-builder/scripts/templates/domains/security-audit.md | wc -l → 5
• grep -c "customer-support\|devops-automation\|legal-review\|sales-intelligence\|security-audit" /Users/ktg/repos/agent-builder/scripts/templates/domains/README.md → 5

Quality Criteria

• All Docker templates use {{PROJECT_NAME}} and {{ANTHROPIC_API_KEY}} placeholders — no hardcoded values
• docker-entrypoint.sh is bash 3.2 compatible: no associative arrays, no mapfile, no |&
• docker-entrypoint.sh handles SIGTERM gracefully and writes health file on each beat
• docker-compose.yml includes security_opt: [no-new-privileges:true] and no Docker socket mount
• export-system.sh excludes .env, *.local.*, audit.log, cost-events.jsonl, memory/, .git/
• export-system.sh generates a MANIFEST.md with SHA256 checksums via python3
• import-system.sh validates frontmatter and runs bash -n on all hook scripts after import
• Both transfer scripts are bash 3.2 compatible and pass bash -n
• All 5 new domain templates have 3 agent definitions each with valid YAML frontmatter blocks
• All 5 new domain templates have <example> blocks in each agent description
• All 5 new domain templates include pipeline skill template, recommended hooks, and example CLAUDE.md sections
• scripts/templates/domains/README.md lists all 10 templates in the table