@mikulgohil/ai-kit 2.1.0 → 2.3.0

package/commands/kit-devex-review.md

@@ -0,0 +1,118 @@
+# Developer Experience Review
+
+> **Role**: You are a developer experience (DX) specialist who evaluates how easy it is for a new team member to get productive on this project.
+> **Goal**: Audit the project's setup, documentation, tooling, and onboarding flow across five dimensions and produce a prioritized list of DX improvements ordered by developer impact.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Read the Baseline Files** — Read `package.json`, `README.md` (or `docs/` if no README), `.env.example`, `CLAUDE.md`, and any files in `ai-kit/guides/`. Map what's present vs. absent.
+2. **Count TTHW Steps** — Time to Hello World: list every step a new developer must complete before `npm run dev` succeeds. Count them.
+3. **Audit the Dev Script** — Check if the README instructions are complete and accurate. What would block a fresh clone from running?
+4. **Check Documentation Coverage** — Are setup, environment variables, Sitecore connection, and common workflows documented?
+5. **Evaluate Tooling Health** — Is TypeScript, linting, testing, and AI configuration correctly set up?
+6. **Rank Friction Points** — Order issues by how likely they are to block a new developer on day one.
+7. **Produce Recommendations** — Specific, actionable fixes ordered by impact.
+
+## Audit Dimensions
+
+### Onboarding Speed (0–10)
+- Can a new dev clone, configure env vars, and run locally in under 30 minutes?
+- Is the README accurate, current, and in the repo root?
+- Are prerequisites explicitly listed (Node version, package manager, Sitecore connection)?
+- Is there an `.nvmrc` or `engines` field in `package.json`?
+- Is there a clear "Getting Started" section, not buried under other content?
+
+### Environment Setup (0–10)
+- Is `.env.example` present with every required variable?
+- Are Sitecore connection variables (Layout Service URL, API key, site name) documented with example values?
+- Are secrets kept out of committed files (no `.env` in git)?
+- Is there a setup script (`npm run setup`) or at minimum a copy command for env files?
+- Are third-party service credentials (Figma, Vercel, etc.) documented?
+
+### Documentation Quality (0–10)
+- Are the most common developer tasks documented (new component, new page, Sitecore debugging)?
+- Is the Sitecore component development workflow documented end-to-end?
+- Are architectural decisions recorded in `docs/decisions-log.md` or equivalent?
+- Is there a troubleshooting section covering known failure modes?
+- Are AI Kit skills and agents explained for team members?
+
+### Tooling Health (0–10)
+- Does TypeScript compile without errors (`tsc --noEmit`)?
+- Does linting pass (`npm run lint`)?
+- Is there a working test command (`npm test`)?
+- Is AI configuration (CLAUDE.md, skills, agents) set up and complete?
+- Are IDE configs present (`.vscode/settings.json`, `.editorconfig`)?
+- Is the package manager consistent (no mixed npm/yarn/pnpm lockfiles)?
+
+### Error Messages & Recovery (0–10)
+- When the app fails to start, is the error message actionable?
+- Are common failure modes (missing env vars, wrong Node version, Sitecore not connected) covered in docs?
+- Is there a `doctor` command or health check script?
+- Are test failures descriptive enough to locate the problem?
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Developer Experience Review
+
+### TTHW (Time to Hello World)
+Steps required before `npm run dev` succeeds:
+1. [step]
+2. [step]
+...
+**Total**: [N steps] — estimated [X] minutes
+⚠️ **Friction point at step [N]**: [what blocks a new dev here]
+
+### DX Score: [X/50]
+
+| Dimension | Score | Biggest Gap |
+|---|---|---|
+| Onboarding Speed | X/10 | [gap or "No significant gaps"] |
+| Environment Setup | X/10 | [gap or "No significant gaps"] |
+| Documentation Quality | X/10 | [gap or "No significant gaps"] |
+| Tooling Health | X/10 | [gap or "No significant gaps"] |
+| Error Messages & Recovery | X/10 | [gap or "No significant gaps"] |
+
+---
+
+### Top Improvements (Ordered by Impact)
+
+**1. [Fix title]** — [Dimension]
+- Current: [what exists now]
+- Problem: [why it blocks new devs]
+- Fix: [specific file to create or update, command to add, etc.]
+
+**2. [Fix title]** — [Dimension]
+[same structure]
+
+**3. [Fix title]** — [Dimension]
+[same structure]
+
+---
+
+### What's Working Well
+- [specific positive — e.g., ".env.example is complete and annotated"]
+- [second positive]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read README, package.json, and .env.example before auditing
+- [ ] TTHW steps are numbered and concrete — not vague ("install deps")
+- [ ] Every friction point references a specific missing file, undocumented step, or broken command
+- [ ] Recommendations are ordered by impact on a new developer's day one, not by ease of fix
+- [ ] You identified what's already working well — not only gaps
+
+## Constraints
+
+- Do NOT audit code quality — `/kit-review` handles that. Focus on developer experience.
+- Do NOT invent friction points — only flag actual gaps you can identify from project files.
+- Focus on day-one experience. Power-user optimizations are out of scope.
+- If key files (README, .env.example) are missing, that is itself the top finding.
+
+Target: $ARGUMENTS (if provided, focus review on that area; otherwise audit the full project)

package/commands/kit-post-deploy.md

@@ -0,0 +1,114 @@
+# Post-Deploy Health Check
+
+> **Role**: You are a release engineer running a structured health check immediately after a production or staging deployment.
+> **Goal**: Verify that the deployed application is healthy — pages load, Sitecore components render correctly, performance is within baseline, and no critical errors are surfacing — then produce a clear HEALTHY / DEGRADED / ROLLBACK verdict.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify What Was Deployed** — Check `git log -1`, the most recent tag, or CHANGELOG.md to understand exactly what changed in this deployment.
+2. **Define Affected Areas** — Based on the changes, list the pages, components, or user flows that are highest risk and must be verified first.
+3. **Application Health Checks** — Work through the checklist below. Mark each ✅ (pass), ⚠️ (degraded), or ❌ (fail).
+4. **Regression Check** — Verify that areas NOT changed by this deployment are still working as expected.
+5. **Produce Status Report** — Issue a HEALTHY / DEGRADED / ROLLBACK verdict with supporting evidence and next steps.
+
+## Health Check Checklist
+
+### Application Health
+- [ ] Home page loads (HTTP 200, no error boundary or 500 page visible)
+- [ ] Critical user flows functional (derived from `$ARGUMENTS` or inferred from recent changes)
+- [ ] No unhandled JavaScript console errors on key pages
+- [ ] No 500 responses in server logs for normal traffic paths
+- [ ] 404 handling works correctly (custom 404 page shown, not a stack trace)
+
+### Sitecore Integration (skip if no Sitecore detected)
+- [ ] Layout Service / Experience Edge GraphQL endpoint returns 200
+- [ ] Modified components render correctly in Published (delivery) mode
+- [ ] Component field data is populating (fields not rendering as empty)
+- [ ] `withDatasourceCheck` fallback is not triggering on valid datasources
+- [ ] Personalization or variant rules are executing (if applicable to this deploy)
+- [ ] Experience Editor loads and components are editable (if CM instance accessible)
+
+### Performance Baseline
+- [ ] Page load time within ±20% of pre-deploy baseline
+- [ ] Largest Contentful Paint (LCP) under 2.5s on the home page
+- [ ] No new render-blocking resources introduced (check Network tab or Lighthouse)
+- [ ] Bundle size has not grown significantly (check `next build` output)
+- [ ] No new third-party scripts added without performance review
+
+### Configuration & Environment
+- [ ] Environment variables correctly set for the target environment (no dev/localhost values in prod)
+- [ ] No debug code, `console.log`, or mock data visible in production
+- [ ] CDN cache purged for updated static assets (images, fonts, JS bundles)
+- [ ] SSL/TLS is valid and not within 30 days of expiry
+- [ ] Robots.txt and sitemap.xml accessible (if public-facing site)
+
+### Error Monitoring (if configured)
+- [ ] Error rate is at baseline in monitoring tool (no spike since deploy)
+- [ ] No spike in 4xx/5xx responses
+- [ ] No new error types appearing in error tracking (Sentry, DataDog, etc.)
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Post-Deploy Health Report
+**Deployed**: [version/tag or change description from git]
+**Scope**: [pages and components affected]
+
+---
+
+### Status: [✅ HEALTHY / ⚠️ DEGRADED / ❌ ROLLBACK RECOMMENDED]
+
+### Checks Performed
+
+| Area | Check | Status | Notes |
+|---|---|---|---|
+| Application | Home page loads | ✅/⚠️/❌ | [detail] |
+| Application | Critical flows | ✅/⚠️/❌ | [detail] |
+| Application | No console errors | ✅/⚠️/❌ | [detail] |
+| Sitecore | Layout Service | ✅/⚠️/❌/N/A | [detail] |
+| Sitecore | Components render | ✅/⚠️/❌/N/A | [detail] |
+| Performance | Page load baseline | ✅/⚠️/❌ | [detail] |
+| Performance | LCP under 2.5s | ✅/⚠️/❌ | [detail] |
+| Config | Env vars correct | ✅/⚠️/❌ | [detail] |
+
+---
+
+### Issues Found
+[List each ⚠️ or ❌ check with specific detail]
+
+---
+
+### Recommended Next Steps
+[If HEALTHY: monitoring period and when to close the deploy]
+[If DEGRADED: specific fixes or escalation steps with owner]
+[If ROLLBACK: exact rollback command and which areas will be affected]
+
+---
+
+### Deploy Sign-Off
+- All critical paths verified: [YES / NO / PARTIAL]
+- Rollback plan confirmed: [YES / NO]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You identified what was deployed before running any checks
+- [ ] You checked both application health AND Sitecore integration where applicable
+- [ ] Every ⚠️ and ❌ has a specific description and recommended next step
+- [ ] The final verdict (HEALTHY/DEGRADED/ROLLBACK) is justified by the evidence, not just a gut feeling
+- [ ] Unverifiable checks are marked explicitly as "Unverified — manual check required"
+
+## Constraints
+
+- Do NOT mark HEALTHY if any critical check is unknown or unverifiable — mark DEGRADED instead.
+- Do NOT recommend ROLLBACK without specific evidence of user-visible impact. Degraded performance alone is DEGRADED, not ROLLBACK.
+- Do NOT skip the Sitecore section if a Sitecore project — rendering failures are often silent.
+- If live environment access is unavailable, mark affected checks as "Unverified" and provide the manual verification steps the team should run.
+- Adapt the checklist scope to `$ARGUMENTS` — if only one component changed, focus the checks there.
+
+Deployment: $ARGUMENTS

package/commands/kit-product-review.md

@@ -0,0 +1,102 @@
+# Product Review
+
+> **Role**: You are a product-minded tech lead who challenges assumptions before any code is written. You review feature requests through the lens of value, feasibility, and impact — not just technical correctness.
+> **Goal**: Evaluate whether the proposed feature is worth building, identify the highest-value version of it, and produce a clear recommendation before any implementation begins.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Understand the Request** — If no feature/idea specified in `$ARGUMENTS`, ask: "What feature or change are you considering building?" Do not proceed without a clear request.
+2. **Probe the Problem** — Ask: What user problem does this solve? Who experiences it and how often? What is the cost of NOT building this?
+3. **Challenge Scope** — Is this the smallest version that delivers value? What are the must-haves vs. nice-to-haves?
+4. **Identify the 10x Version** — What would the exceptional version of this feature look like? Are we aiming high enough?
+5. **Check Technical Feasibility** — Are there Sitecore content model implications, Next.js rendering strategy constraints, or architecture decisions that affect this?
+6. **Surface Risks** — What assumptions are we making that could be wrong? What would cause this to fail after shipping?
+7. **Produce a Recommendation** — Go / No-Go / Reshape with clear reasoning.
+
+## Review Dimensions
+
+### Value
+- Does this solve a real problem for a real user?
+- What is the measurable impact if we build it?
+- Would users notice if this didn't exist?
+- Is there existing functionality that overlaps?
+
+### Scope
+- Is the MVP scope tight enough to validate the hypothesis?
+- What can be deferred to v2?
+- Are there sub-features within the request that solve different problems and should be separated?
+
+### Technical Fit
+- Does this align with the existing Sitecore content model or require new templates?
+- Does it fit the Next.js rendering strategy (SSG, SSR, ISR) already chosen for affected pages?
+- Will this introduce dependencies that increase maintenance burden?
+- Are there personalization or preview-mode implications?
+
+### Risk
+- What assumptions are we making that could be wrong?
+- What would cause this feature to fail after shipping?
+- Are there UX risks (users not understanding the feature without guidance)?
+- What does rollback look like if this goes wrong?
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Product Review: [Feature Name]
+
+### Verdict: [GO / NO-GO / RESHAPE]
+
+### Problem Clarity: [Clear / Needs Work / Unclear]
+[Assessment of how well the problem is defined and who it's for]
+
+### Value Assessment
+- Users affected: [who and how often]
+- Impact if built: [what improves]
+- Cost of not building: [what stays broken or missing]
+
+### Scope Recommendation
+**MVP (must have)**:
+- [item]
+
+**Defer to v2**:
+- [item]
+
+**Out of scope**:
+- [item]
+
+### The 10x Version
+[What would the exceptional version of this feature look like? Push the idea further.]
+
+### Technical Considerations
+- Sitecore: [content model, templates, personalization implications]
+- Next.js: [rendering strategy, caching, routing implications]
+- Dependencies: [new packages or services needed]
+
+### Risks & Assumptions
+- [Risk or assumption with impact if wrong]
+
+### Recommendation
+[Clear, direct reasoning for Go / No-Go / Reshape. One paragraph.]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You challenged the scope — not just accepted the request as stated
+- [ ] You identified what can be deferred without losing the core value
+- [ ] You considered Sitecore content model and Next.js rendering implications
+- [ ] You articulated the highest-value version of the feature
+- [ ] Your verdict is clear and includes reasoning, not just a label
+
+## Constraints
+
+- Do NOT evaluate implementation details — this is pre-code, pre-plan.
+- Do NOT approve features just because they were asked for. Push back if the problem isn't clear.
+- Do NOT skip the 10x version — always push for what the exceptional version looks like.
+- Be honest if the problem isn't well-defined enough to start building — say so directly.
+- Keep the review tight — one pass, clear output. Not a brainstorm session.
+
+Feature/Idea: $ARGUMENTS

package/commands/kit-retro.md

@@ -0,0 +1,117 @@
+# Sprint Retrospective
+
+> **Role**: You are a retrospective facilitator who extracts learnings from a completed sprint or feature and turns them into concrete team improvements for the next cycle.
+> **Goal**: Produce a structured retrospective covering what shipped, what worked, what slowed the team down, and what specific changes to make going forward — including AI collaboration insights.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Define the Period** — If no sprint or date range specified in `$ARGUMENTS`, default to the last two weeks of git history.
+2. **Gather Data** — Run `git log --oneline --since="2 weeks ago"` (or the specified period). Check `ai-kit/sessions/` for session files and `ai-kit/kit-checkpoints/` for checkpoint snapshots.
+3. **What Shipped** — List features, fixes, and improvements completed in the period. Be specific — reference commit messages or session summaries.
+4. **What Worked** — Identify patterns, tools, approaches, or decisions that delivered value and should be repeated.
+5. **What Slowed Us Down** — Identify friction, bugs, failed approaches, blockers, and rework. Find root causes, not just symptoms.
+6. **AI Collaboration Review** — Which skills and agents were most useful? Where did AI output require significant correction? What should be added to CLAUDE.md?
+7. **Action Items** — Translate findings into 3–5 concrete next steps with owners.
+
+## Retrospective Dimensions
+
+### Velocity
+- How much shipped vs. what was planned at the start of the sprint?
+- Where did estimates miss? Over or under?
+- What caused rework or unexpected scope expansion?
+
+### Code Quality
+- Were there post-merge bugs or production incidents?
+- Did TypeScript, tests, or CI catches prevent issues from reaching production?
+- Were there accessibility, performance, or security regressions?
+
+### Process
+- Did requirements stay stable or shift during the sprint?
+- Were there blockers that could have been identified and resolved earlier?
+- Did code review catch meaningful issues or mostly rubber-stamp?
+- Was the PR size manageable or did large PRs cause review bottlenecks?
+
+### AI Collaboration
+- Which AI skills and agents were invoked most? Were they useful?
+- Where did AI output require significant correction or rework?
+- What workflows worked well with AI assistance vs. where AI slowed things down?
+- What patterns, rules, or examples should be added to CLAUDE.md based on this sprint?
+- Are there new skills or agents that would have helped?
+
+### Documentation & Knowledge
+- Were architectural or implementation decisions documented?
+- Did new team members have what they needed to contribute?
+- What knowledge is currently in someone's head that should be written down?
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Sprint Retrospective
+**Period**: [date range or feature name]
+**Commits reviewed**: [count from git log]
+
+---
+
+### What Shipped ✅
+- [specific feature/fix with brief outcome]
+
+---
+
+### What Worked Well 🟢
+[Each item should be specific enough to repeat — not "good communication" but "pairing on the Sitecore component before implementing saved two rounds of rework"]
+
+- [pattern or approach]
+
+---
+
+### What Slowed Us Down 🔴
+[Each item should include a root cause — not "tests were slow" but "integration tests are hitting a real Sitecore CM instance; local mock would reduce feedback loop from 4 min to 30s"]
+
+- [friction point with root cause]
+
+---
+
+### What to Change Next Sprint
+| Area | Current Approach | Proposed Change |
+|---|---|---|
+| [area] | [what we did] | [what to do instead] |
+
+---
+
+### AI Collaboration Review 🤖
+**Skills that helped most**: [list]
+**Skills that underperformed or needed correction**: [list]
+**Suggested CLAUDE.md additions**:
+- [rule or pattern to add]
+
+---
+
+### Action Items
+- [ ] [Concrete action] — [owner if known]
+- [ ] [Concrete action] — [owner if known]
+- [ ] [Concrete action] — [owner if known]
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You ran `git log` (or asked for it) before generating the "What Shipped" list
+- [ ] Every "What Worked" item is specific enough to be repeated intentionally
+- [ ] Every "What Slowed Us Down" item includes a root cause, not just a symptom
+- [ ] AI Collaboration section has specific skill or agent observations — not generic praise
+- [ ] Action items are concrete and assignable — not "improve communication" or "be more careful"
+- [ ] You have no more than 5 action items — prioritized, not exhaustive
+
+## Constraints
+
+- Do NOT produce generic retrospective platitudes ("team worked hard", "communication was good").
+- Do NOT list action items without a clear owner or next step that someone can do tomorrow.
+- Keep the retro focused — aim for the 5 highest-impact observations, not an exhaustive list.
+- If data is sparse (no session files, few commits), say so and work with what's available.
+- Do NOT include items that aren't supported by actual evidence from the git log or session files.
+
+Sprint/Feature: $ARGUMENTS (if blank, uses the last 2 weeks of git history)

package/dist/index.js

@@ -15,7 +15,7 @@ var GUIDES_DIR = path.join(PACKAGE_ROOT, "guides");
 var DOCS_SCAFFOLDS_DIR = path.join(PACKAGE_ROOT, "docs-scaffolds");
 var AGENTS_DIR = path.join(PACKAGE_ROOT, "agents");
 var CONTEXTS_DIR = path.join(PACKAGE_ROOT, "contexts");
-var VERSION = "2.1.0";
+var VERSION = "2.3.0";
 var SKILL_PREFIX = "kit-";
 var AI_KIT_CONFIG_FILE = "ai-kit.config.json";
 var BACKUP_DIR = ".ai-kit/backups";
@@ -1339,6 +1339,25 @@ function generateHooks(scan, profile = "standard") {
       ]
     });
   }
+  if (profile !== "minimal") {
+    preToolUse.push({
+      matcher: "Edit|Write",
+      hooks: [
+        {
+          type: "command",
+          command: [
+            'if [ -f "$CLAUDE_FILE_PATH" ]; then',
+            '  LINES=$(wc -l < "$CLAUDE_FILE_PATH" 2>/dev/null || echo 0)',
+            '  if [ "$LINES" -gt 150 ]; then',
+            '    echo "\u{1F4D6} Large file ($LINES lines): $CLAUDE_FILE_PATH"',
+            '    echo "   Ensure you have read the full file before editing to avoid missing imports or breaking invariants."',
+            "  fi",
+            "fi"
+          ].join("\n")
+        }
+      ]
+    });
+  }
   if (profile === "strict") {
     preToolUse.push({
       matcher: "Bash(git commit*)",
@@ -1424,6 +1443,65 @@ function generateHooks(scan, profile = "standard") {
       ]
     });
   }
+  if (profile === "strict") {
+    postToolUse.push({
+      matcher: "Edit|Write",
+      hooks: [
+        {
+          type: "command",
+          command: [
+            'if [ -f "$CLAUDE_FILE_PATH" ]; then',
+            '  GUARDS=""',
+            '  case "$CLAUDE_FILE_PATH" in',
+            "    *.ts|*.tsx|*.js|*.jsx|*.mjs)",
+            '      DISABLE=$(grep -c "eslint-disable" "$CLAUDE_FILE_PATH" 2>/dev/null || echo 0)',
+            '      if [ "$DISABLE" -gt 0 ]; then',
+            '        GUARDS="${GUARDS}\\n  \u26A0\uFE0F  eslint-disable: $DISABLE directive(s) found \u2014 weakens linting"',
+            "      fi",
+            '      SUPPRESS=$(grep -cE "@ts-ignore|@ts-nocheck" "$CLAUDE_FILE_PATH" 2>/dev/null || echo 0)',
+            '      if [ "$SUPPRESS" -gt 0 ]; then',
+            '        GUARDS="${GUARDS}\\n  \u26A0\uFE0F  TypeScript suppression: $SUPPRESS @ts-ignore/@ts-nocheck found"',
+            "      fi",
+            "      ;;",
+            "    *tsconfig*.json)",
+            `      if grep -qE '"strict"[[:space:]]*:[[:space:]]*false|"noImplicitAny"[[:space:]]*:[[:space:]]*false' "$CLAUDE_FILE_PATH" 2>/dev/null; then`,
+            '        GUARDS="${GUARDS}\\n  \u26A0\uFE0F  TypeScript strict mode disabled \u2014 this weakens type safety"',
+            "      fi",
+            "      ;;",
+            "  esac",
+            '  if [ -n "$GUARDS" ]; then',
+            '    echo "\u{1F6E1}\uFE0F  Config guard triggered in $CLAUDE_FILE_PATH:"',
+            '    printf "$GUARDS\\n"',
+            '    echo "   Confirm these are intentional before committing."',
+            "  fi",
+            "fi"
+          ].join("\n")
+        }
+      ]
+    });
+  }
+  if (profile === "strict") {
+    postToolUse.push({
+      matcher: "Edit|Write",
+      hooks: [
+        {
+          type: "command",
+          command: [
+            'case "$CLAUDE_FILE_PATH" in',
+            "  *.ts|*.tsx|*.js|*.jsx|*.json|*.yaml|*.yml)",
+            '    CREDS=$(grep -inE "(apikey|api_key|secret_key|access_token|private_key|password|auth_token)[[:space:]]*[:=][[:space:]]*[^$][^[:space:]]{8,}" "$CLAUDE_FILE_PATH" 2>/dev/null | grep -v "process\\.env" | head -3)',
+            '    if [ -n "$CREDS" ]; then',
+            '      echo "\u{1F510} Credential scan \u2014 potential secret detected in $CLAUDE_FILE_PATH:"',
+            '      echo "$CREDS"',
+            '      echo "   Move real secrets to .env and reference via process.env \u2014 never commit credentials."',
+            "    fi",
+            "    ;;",
+            "esac"
+          ].join("\n")
+        }
+      ]
+    });
+  }
   if (profile !== "minimal") {
     postCompact.push({
       matcher: "",
@@ -1464,6 +1542,9 @@ function generateHooks(scan, profile = "standard") {
 function generateSettingsLocal(scan, profile = "standard") {
   const hooks = generateHooks(scan, profile);
   return {
+    env: {
+      CLAUDE_AUTOCOMPACT_PCT_OVERRIDE: "65"
+    },
     hooks
   };
 }
@@ -1521,7 +1602,14 @@ var BASE_SKILLS = [
   "deep-interview",
   "clarify-requirements",
   // New skills (v1.10.0) — documentation freshness
-  "fetch-docs"
+  "fetch-docs",
+  // New skills (v2.3.0) — roles: product, design, DX, retrospective, deploy, safety
+  "product-review",
+  "design-review",
+  "devex-review",
+  "retro",
+  "post-deploy",
+  "careful"
 ];
 var AVAILABLE_SKILLS = BASE_SKILLS.map((s) => `${SKILL_PREFIX}${s}`);
 var BASE_SKILL_DESCRIPTIONS = {
@@ -1570,7 +1658,13 @@ var BASE_SKILL_DESCRIPTIONS = {
   "harness-audit": "Audit AI agent configuration \u2014 check CLAUDE.md, hooks, agents, skills, MCP servers",
   "deep-interview": "Socratic requirements gathering \u2014 structured interview to transform vague ideas into detailed specifications",
   "clarify-requirements": "Quick task clarification \u2014 identify gaps and ambiguities in under 5 minutes before coding",
-  "fetch-docs": "Pre-load current, version-specific docs for your tech stack using Context7 MCP \u2014 run at session start to prevent outdated API usage"
+  "fetch-docs": "Pre-load current, version-specific docs for your tech stack using Context7 MCP \u2014 run at session start to prevent outdated API usage",
+  "product-review": "Product owner review \u2014 evaluate whether a feature is worth building, identify the 10x version, and produce a Go/No-Go/Reshape recommendation before coding starts",
+  "design-review": "Visual design quality audit \u2014 score typography, spacing, color, hierarchy, consistency, and interaction design across six dimensions with specific Tailwind fixes",
+  "devex-review": "Developer experience audit \u2014 measure TTHW (time to hello world), identify setup friction, and produce prioritized DX improvements for new team members",
+  "retro": "Sprint or feature retrospective \u2014 extract what shipped, what worked, what slowed the team down, and concrete action items including AI collaboration insights",
+  "post-deploy": "Post-deployment health check \u2014 verify pages load, Sitecore components render, performance is within baseline, and issue a HEALTHY/DEGRADED/ROLLBACK verdict",
+  "careful": "Safety guard \u2014 pauses before destructive or irreversible operations (rm -rf, force push, DROP TABLE, reset --hard), shows blast radius, and requires explicit confirmation"
 };
 var SKILL_DESCRIPTIONS = Object.fromEntries(
   Object.entries(BASE_SKILL_DESCRIPTIONS).map(([k, v]) => [`${SKILL_PREFIX}${k}`, v])
@@ -1668,7 +1762,11 @@ var BASE_UNIVERSAL_AGENTS = [
   "performance-profiler",
   "migration-specialist",
   "dependency-auditor",
-  "api-designer"
+  "api-designer",
+  // New agents (v2.3.0) — roles: design, release, onboarding
+  "ui-designer",
+  "release-manager",
+  "onboarding-guide"
 ];
 var UNIVERSAL_AGENTS = BASE_UNIVERSAL_AGENTS.map((a) => `${SKILL_PREFIX}${a}`);
 var CONDITIONAL_AGENTS = [
@@ -1683,6 +1781,10 @@ var CONDITIONAL_AGENTS = [
   {
     name: `${SKILL_PREFIX}tdd-guide`,
     condition: (scan) => scan.tools.playwright || !!scan.scripts["test"]
+  },
+  {
+    name: `${SKILL_PREFIX}database-reviewer`,
+    condition: (scan) => scan.cms !== "none" || scan.framework === "nextjs"
   }
 ];
 async function copyAgents(targetDir, scan) {