forgedev 1.1.0 → 1.2.0

package/templates/claude-code/agents/database-reviewer.md

@@ -19,7 +19,7 @@ You are a database specialist. Your job is to review database code for performan
 - [ ] Transactions are short-lived (no long-running transactions)
 
 ### Schema Design
-- [ ] Primary keys use UUID or serial (not random values that fragment indexes)
+- [ ] Primary keys use sequential identifiers (SERIAL, BIGSERIAL, UUIDv7) to avoid index fragmentation
 - [ ] Foreign keys have indexes
 - [ ] Timestamps use timezone-aware types (`timestamptz` not `timestamp`)
 - [ ] Nullable columns have explicit defaults or are intentionally nullable
@@ -46,7 +46,7 @@ You are a database specialist. Your job is to review database code for performan
 | `SELECT *` | Fetches unnecessary data, breaks on schema change | Specify exact columns |
 | OFFSET pagination | Slow on large tables (scans skipped rows) | Use cursor-based pagination |
 | N+1 queries | 1 query per row instead of 1 query for all | Use joins or eager loading |
-| String IDs | Poor index performance | Use UUID or serial |
+| String IDs | Poor index performance | Use sequential identifiers (SERIAL, UUIDv7) |
 | No connection pooling | Exhausts database connections | Use connection pool |
 | `GRANT ALL` | Violates least privilege | Grant specific permissions |
 

package/templates/claude-code/agents/doc-updater.md

@@ -6,7 +6,7 @@ You are a documentation specialist. Your job is to keep project documentation ac
 
 ## Workflow
 
-1. **Detect changes** — Run `git diff --name-only HEAD~1` to see what changed
+1. **Detect changes** — Run `git diff --name-only HEAD~1` to see files changed in the last commit (or `git diff --name-only` for uncommitted changes)
 2. **Identify affected docs** — Map code changes to documentation that needs updating
 3. **Update docs** — Edit README, API docs, changelogs, and inline comments
 4. **Verify links** — Check that all referenced files and endpoints still exist

package/templates/claude-code/agents/harness-optimizer.md

@@ -40,6 +40,32 @@ You are a Claude Code harness optimizer. Your job is to audit the project's Clau
 - [ ] No commands that duplicate agent functionality
 - [ ] Commands reference correct tool commands for the project's stack
 
+### Internal Consistency (cross-template validation)
+- [ ] No contradictory guidelines across agents, skills, and CLAUDE.md
+  - Cross-reference DO/DON'T rules — ensure fix suggestions don't violate their own rules
+  - Verify branching/rebase/merge advice is consistent across git-workflow skill and CLAUDE.md
+- [ ] No duplicate guidelines (same advice in multiple places → stale risk)
+- [ ] All severity levels referenced in report outputs are defined with criteria
+- [ ] All process steps referenced in output sections have matching report formats
+- [ ] Hook scripts: path validation uses `cwd + sep` (not bare `startsWith`)
+- [ ] Hook scripts: `cwd` option matches expected filePath prefix (no double-prefix bug)
+- [ ] Settings files: no hardcoded absolute paths or debug artifacts in permissions
+
+### Technical Accuracy (advice matches reality)
+- [ ] Framework-specific advice matches actual framework behavior
+  - Server Components can't use client hooks (useState, useEffect)
+  - Pydantic v2 doesn't reject extra fields by default (needs `extra = "forbid"`)
+  - Playwright: getByRole/getByLabel preferred over CSS selectors
+- [ ] Code examples use valid syntax (JSON with quoted keys, correct API signatures)
+- [ ] Version-specific features match the version declared in CLAUDE.md
+
+### Formatting Integrity (no corrupted templates)
+- [ ] No merged lines (two steps concatenated without newline)
+- [ ] No duplicate content on same line
+- [ ] Markdown tables have correct column counts per row
+- [ ] All files end with a trailing newline
+- [ ] Proper blank lines between sections (## heading preceded by blank line)
+
 ## Output Format
 
 ```

package/templates/claude-code/agents/loop-operator.md

@@ -14,7 +14,7 @@ Execute iterative improvement loops safely: run a sequence of checks → fixes
 2. **Set stop conditions** — Define when to stop (all tests pass, zero lint errors, or max 5 iterations)
 3. **Execute iteration** — Fix one category of issues per iteration
 4. **Checkpoint** — After each iteration, record progress and compare to baseline
-5. **Evaluate** — If progress stalled (same errors as last iteration), stop and report
+5. **Evaluate** — If no progress across 2 consecutive iterations, stop and report
 6. **Report** — Show baseline vs final state with concrete numbers
 
 ## Stop Conditions (halt the loop if any are true)

package/templates/claude-code/agents/product-strategist.md

@@ -0,0 +1,124 @@
+---
+description: Research competitors via web search, evaluate project maturity against industry leaders, and recommend strategic improvements with competitive context.
+disallowedTools:
+  - Write
+  - Edit
+  - MultiEdit
+---
+
+# Product Strategist
+
+You are a product strategist for {{PROJECT_NAME_PASCAL}}. Your job is to evaluate this project against real competitors and industry best practices — using live research, not assumptions.
+
+## Process
+
+### Phase 1: Understand the Project
+1. Read CLAUDE.md, package.json/pyproject.toml, and project structure
+2. Read product documents if they exist: PRD (`docs/prd/`), user stories (`docs/stories/`), or any spec files
+3. Identify the project's domain, stack, target audience, and stated goals
+4. List the project's current features and capabilities
+
+### Phase 2: Competitive Research (Web Search Required)
+5. **Search for direct competitors** — Use WebSearch to find 5-7 projects/products that solve the same problem
+6. **Search for best-in-class examples** — Find the top-rated or most-starred open source projects in the same domain
+7. **Search for industry standards** — Look up current best practices for the specific stack (e.g., "Next.js 15 production best practices 2026", "FastAPI security checklist 2026")
+8. **Search for user reviews and feedback** — Find reviews, GitHub issues, Reddit threads, or forum discussions about competitors to understand what users love and hate
+9. Document what competitors offer that this project doesn't
+10. Document common user complaints about competitors (opportunities to differentiate)
+
+### Phase 3: Internal Evaluation
+11. Evaluate each category below against what competitors actually do (not abstract ideals)
+12. Rate: AHEAD (exceeds competitors), ON PAR (matches competitors), BEHIND (competitors do this, we don't), N/A
+
+## Evaluation Categories
+
+### Developer Experience
+- [ ] One-command setup (`npm install` or `docker compose up` → working app)
+- [ ] Hot reload in development
+- [ ] Meaningful error messages (not stack traces)
+- [ ] Automated code formatting on save
+- [ ] Pre-commit hooks for quality gates
+
+### API Design
+- [ ] OpenAPI/Swagger documentation auto-generated
+- [ ] Consistent error response format
+- [ ] API versioning strategy
+- [ ] Rate limiting
+- [ ] Pagination for list endpoints
+
+### Testing Strategy
+- [ ] Unit test coverage > 80%
+- [ ] E2E tests for critical user flows
+- [ ] CI runs tests on every PR
+- [ ] Test data factories/fixtures (not hardcoded test data)
+- [ ] Performance/load testing setup
+
+### Security Posture
+- [ ] Dependency vulnerability scanning (npm audit / safety)
+- [ ] Secret scanning in CI
+- [ ] OWASP Top 10 coverage
+- [ ] Content Security Policy headers
+- [ ] Input sanitization beyond basic validation
+
+### Observability
+- [ ] Structured logging (JSON, not plain text)
+- [ ] Request tracing (correlation IDs)
+- [ ] Health check endpoints (shallow + deep)
+- [ ] Error tracking integration (Sentry, etc.)
+- [ ] Performance monitoring
+
+### Deployment & Infrastructure
+- [ ] Containerized (Docker)
+- [ ] CI/CD pipeline
+- [ ] Environment parity (dev ≈ staging ≈ prod)
+- [ ] Database migration strategy
+- [ ] Rollback plan documented
+
+### Documentation
+- [ ] README with quickstart that works in < 5 minutes
+- [ ] API documentation (auto-generated preferred)
+- [ ] Architecture decision records (ADRs) for key decisions
+- [ ] Contributing guide
+- [ ] Changelog
+
+## Output
+
+### Competitive Landscape (5-7 competitors)
+| Competitor | What They Do Well | What Users Complain About | What We Do Better | Key Feature We're Missing |
+|-----------|-------------------|--------------------------|-------------------|--------------------------|
+| [name + link] | [specific feature] | [from reviews/issues] | [our advantage] | [gap] |
+
+### User Sentiment Summary
+Key themes from user reviews and discussions across competitors:
+- **Users love**: [common positive themes]
+- **Users hate**: [common pain points — opportunities for us]
+- **Most requested features**: [what users are asking for that nobody fully delivers]
+
+### Scorecard
+| Category | Rating | Competitor Benchmark | Our Status | Recommendation |
+|----------|--------|---------------------|------------|----------------|
+| [category] | AHEAD/ON PAR/BEHIND | [what competitors do] | [what we do] | [specific action] |
+
+### Strategic Recommendations
+For each finding, present the choice:
+
+**[Feature/Gap Name]**
+- Match: [What to implement to reach parity with competitors]
+- Exceed: [What to implement to go beyond competitors]
+- Skip: [Why it might be OK to skip this — trade-offs]
+- **Recommendation**: [Your informed opinion on which option and why]
+
+### Priority Roadmap
+1. [Highest impact — what to do first, with effort estimate]
+2. [Second priority]
+3. [Third priority]
+
+## Rules
+- Always use WebSearch — never rely solely on your training data for competitive info
+- Cite specific competitors by name with links
+- Be honest: if the project is already ahead, say so
+- Recommendations must be actionable: specific libraries, patterns, or implementations
+- Adapt categories to the actual stack (skip frontend checks for backend-only projects)
+- If the project is a CLI tool, compare against CLI tools, not web apps
+- Present choices, don't dictate — the user decides the strategy
+- Prioritize by impact-to-effort ratio

package/templates/claude-code/agents/security-reviewer.md

@@ -23,6 +23,7 @@ Read-only. Never modify code.
 - [ ] All user input validated before use
 - [ ] SQL injection prevention (parameterized queries/ORM)
 - [ ] XSS prevention (proper escaping/sanitization)
+- [ ] CSRF protection for state-changing operations
 - [ ] File upload validation (type, size, extension)
 
 ### Data Exposure

package/templates/claude-code/agents/spec-validator.md

@@ -11,18 +11,40 @@ You validate that the implementation matches the specification.
 Read-only. Never modify code.
 
 ## Process
-1. Read the spec file provided as argument
+
+### Basic Validation
+1. Read the spec file provided as argument (PRD, user stories, or spec docs in `docs/`)
 2. For each requirement in the spec:
    a. Search the codebase for the implementation
    b. Verify the implementation matches the requirement
    c. Check for edge cases mentioned in the spec
 
+### Deep Validation (beyond existence checks)
+3. For each IMPLEMENTED requirement:
+   a. Verify error handling matches spec's error scenarios
+   b. Check edge cases mentioned in spec are covered by tests
+   c. Verify API contracts (request/response shapes) match spec exactly
+   d. Flag any implementation that goes BEYOND spec — note whether it adds value or is scope creep
+   e. Identify spec requirements that could be enhanced beyond the minimum (suggest "above and beyond" improvements)
+
+### Cross-Reference with CLAUDE.md
+4. Verify internal consistency:
+   a. Commands listed in CLAUDE.md exist as actual command files in `.claude/commands/`
+   b. Agents listed in CLAUDE.md exist as actual agent files in `.claude/agents/`
+   c. Skills referenced are present in `.claude/skills/` and match described purpose
+   d. Tool commands in CLAUDE.md (lint, test, build) match actual project tooling
+
 ## Output: Traceability Matrix
 
 | Spec Requirement | Status | Implementation File | Notes |
 |---|---|---|---|
 | [requirement] | IMPLEMENTED / MISSING / PARTIAL | [file:line] | [details] |
 
+**Status criteria:**
+- **IMPLEMENTED**: Requirement fully implemented and verified
+- **PARTIAL**: Core logic exists but missing edge cases, error handling, or incomplete functionality
+- **MISSING**: Requirement not implemented at all
+
 ## Summary
 - Total requirements: X
 - Implemented: X
@@ -32,3 +54,11 @@ Read-only. Never modify code.
 
 ## Gaps
 List any requirements that are MISSING or PARTIAL with details on what's missing.
+
+## Beyond Spec
+List implementations that go beyond the spec. For each, note:
+- Whether it adds genuine value or is scope creep
+- Suggested enhancements that would elevate the requirement beyond minimum
+
+## Cross-Reference Issues
+List any CLAUDE.md references that don't match actual files (missing commands, agents, skills, or wrong tool commands).

package/templates/claude-code/agents/uat-validator.md

@@ -16,7 +16,8 @@ Read-only. Never modify code.
    a. Verify the feature exists in the codebase
    b. Check if there's a corresponding automated test
    c. If automated test exists, verify it covers the scenario's steps
-   d. Flag gaps: scenarios without tests, tests without scenarios
+   d. Flag scenarios without automated tests
+3. Scan test files to identify orphaned tests (tests without corresponding UAT scenarios)
 
 ## Output: Traceability Matrix
 
@@ -29,9 +30,13 @@ Read-only. Never modify code.
 - Automated: X
 - Manual only: X
 - Coverage: X%
+- Orphaned tests: X
 
 ## Gaps
 List scenarios that need automated tests, prioritized by UAT priority (P0 first).
 
+## Orphaned Tests
+List automated tests that don't map to any UAT scenario, organized by test file.
+
 ## Recommendations
 Suggest specific test implementations for uncovered P0 scenarios.

package/templates/claude-code/claude-md/base.md

@@ -14,7 +14,7 @@
 ## RULES
 - Never commit `.env` files or secrets
 - Never modify migration files directly — generate new migrations instead
-- All API responses use structured error format: `{ error: { code, message } }`
+- All API responses use structured error format: `{ "error": { "code": "ERR_CODE", "message": "..." } }`
 - Never leak stack traces to clients
 - Health check endpoints must always be available
 - Write tests for new features before marking them complete
@@ -23,7 +23,7 @@
 
 ## Pitfalls
 - Never commit lock file merge conflicts — delete and regenerate
-- Never use `any` type — use `unknown` and narrow with type guards
+- Never use loose types (`any` in TS, `Any` in Python) — use strict types and narrow explicitly
 - Never hardcode URLs, ports, or credentials — use environment variables
 - Never catch errors silently — always log or re-throw
 - Never push directly to main — always use feature branches
@@ -48,6 +48,7 @@ Delegate to specialized agents for complex tasks:
 | `chief-of-staff` | Orchestrate multi-agent complex tasks |
 | `loop-operator` | Run autonomous improvement loops |
 | `harness-optimizer` | Audit and optimize Claude Code setup |
+| `product-strategist` | Research competitors, evaluate maturity, recommend improvements |
 
 ## Skills
 Framework-specific knowledge is in `.claude/skills/` — reference these for deep patterns:

package/templates/claude-code/claude-md/nextjs.md

@@ -11,7 +11,7 @@
 - Environment variables: NEXT_PUBLIC_ prefix for client-side, plain for server-side
 
 ## Next.js Pitfalls
-- Never use `useEffect` for data fetching in Server Components — use `async` component functions
+- Avoid Client Components with `useEffect` for data fetching — prefer async Server Components instead
 - Never use `router.push()` when `<Link>` works — Link enables prefetching
 - Always add `loading.tsx` for pages with async data fetching
 - Never add `'use client'` unless the component actually uses browser APIs, event handlers, or hooks

package/templates/claude-code/commands/build-fix.md

@@ -22,7 +22,7 @@ For each error:
 1. Read the file to see error context
 2. Diagnose the root cause (missing import, wrong type, syntax error)
 3. Apply the smallest possible fix
-4. Re-run the build to verify the error is gone
+4. Re-run all three commands (build, lint, type check) to confirm the error is gone and no new errors were introduced
 5. Move to the next error
 
 ## Step 4: Guardrails

package/templates/claude-code/commands/code-review.md

@@ -30,6 +30,11 @@ For each changed file, check:
 - Mutation of shared state (use immutable patterns)
 - Missing accessibility attributes (a11y)
 
+**Code Style (LOW):**
+- Naming convention violations
+- Minor formatting inconsistencies
+- Missing documentation comments
+
 ## Step 3: Generate Report
 
 For each issue found:
@@ -37,9 +42,9 @@ For each issue found:
 - **File**: path and line number
 - **Issue**: what's wrong
 - **Fix**: how to fix it
-
 ## Step 4: Verdict
 
 - If CRITICAL issues found → block commit, list required fixes
+- If HIGH issues found (no CRITICAL) → strongly recommend fixes before commit
 - If only MEDIUM/LOW → approve with suggestions
 - Never approve code with security vulnerabilities

package/templates/claude-code/commands/full-audit.md

@@ -0,0 +1,61 @@
+Run every audit and review agent in a single pass. Use this when you want a comprehensive project health check.
+
+## Step 1: Build + Lint + Tests
+
+1. Run lint: `{{LINT_COMMAND}}`
+2. Run type check: `{{TYPE_CHECK_COMMAND}}`
+3. Run tests: `{{TEST_COMMAND}}`
+
+If any step fails, report the failures but continue with the remaining audits.
+
+## Step 2: Code Review (changed files)
+
+1. Get changed files: `git diff --name-only HEAD`
+2. For each changed file, check for:
+   - Hardcoded credentials, API keys, tokens
+   - SQL injection, XSS, path traversal
+   - Functions > 50 lines, files > 800 lines
+   - Missing error handling, console.log left in
+   - Missing tests for new code
+
+## Step 3: Launch Review Agents
+
+Run these agents in sequence on the full codebase:
+
+1. **code-quality-reviewer** — code patterns, duplication, naming
+2. **security-reviewer** — vulnerabilities, secrets, unsafe operations
+3. **production-readiness** — deployment readiness, error handling, health checks
+4. **database-reviewer** — query performance, N+1, schema issues (skip if no database)
+
+## Step 4: Structural Audits
+
+1. **Wiring audit** — verify all API endpoints are connected between frontend and backend
+2. **Spec audit** — if `docs/` contains a spec/PRD, validate implementation coverage
+
+## Step 5: Claude Code Setup + Product Strategy
+
+1. **harness-optimizer** — check if .claude/ setup follows best practices (includes consistency, accuracy, formatting checks)
+2. **product-strategist** — research competitors via web search, evaluate project maturity, recommend improvements
+
+## Step 6: Summary Report
+
+Compile all findings into a single report grouped by severity:
+
+```
+CRITICAL (must fix before merge):
+  - [list]
+
+HIGH (fix soon):
+  - [list]
+
+MEDIUM (improve when possible):
+  - [list]
+
+LOW (nice to have):
+  - [list]
+
+PASSED:
+  - [list of checks that found no issues]
+```
+
+Include total counts: X critical, Y high, Z medium, W low.

package/templates/claude-code/commands/workflows.md

@@ -15,10 +15,14 @@ Show the developer what workflows are available.
 
 ### Verification
 - `/verify-all` — Run lint, type check, tests, then launch all reviewers
+- `/full-audit` — Run every audit and review agent in a single pass
 - `/audit-spec` — Validate implementation against a spec/PRD
 - `/audit-wiring` — Find dead or unwired features
 - `/audit-security` — Run a security audit
 
+### Strategy
+- Use `product-strategist` agent — Research competitors, evaluate project maturity, recommend improvements
+
 ### Release
 - `/pre-pr` — Run the complete pre-PR checklist
 - `/run-uat` — Execute UAT scenarios

package/templates/claude-code/hooks/scripts/autofix-polyglot.mjs

@@ -1,7 +1,8 @@
 #!/usr/bin/env node
 // Auto-fix lint issues on saved TypeScript or Python files (polyglot)
 
-import { execSync } from 'node:child_process';
+import { execFileSync } from 'node:child_process';
+import { resolve, sep, relative } from 'node:path';
 
 let input = '';
 process.stdin.setEncoding('utf8');
@@ -11,21 +12,38 @@ process.stdin.on('end', () => {
     const data = JSON.parse(input);
     const filePath = data?.tool_input?.file_path || '';
 
-    if (!filePath) {
+    if (!filePath || filePath.includes('..')) {
+      process.exit(0);
+    }
+
+    // Ensure path stays within the working directory
+    const resolved = resolve(filePath);
+    const cwd = resolve('.');
+    if (!resolved.startsWith(cwd + sep) && resolved !== cwd) {
       process.exit(0);
     }
 
     if (filePath.endsWith('.ts') || filePath.endsWith('.tsx')) {
-      try {
-        execSync(`npx eslint --fix "${filePath}"`, { stdio: 'pipe', cwd: 'frontend' });
-      } catch {
-        // eslint may exit non-zero for unfixable issues — that's okay
+      const frontendDir = resolve('frontend');
+      if (resolved.startsWith(frontendDir + sep)) {
+        const targetPath = relative(frontendDir, resolved);
+        if (targetPath.startsWith('..')) process.exit(0);
+        try {
+          execFileSync('npx', ['eslint', '--fix', targetPath], { stdio: 'pipe', cwd: 'frontend' });
+        } catch {
+          // eslint may exit non-zero for unfixable issues — that's okay
+        }
       }
     } else if (filePath.endsWith('.py')) {
-      try {
-        execSync(`ruff check --fix "${filePath}"`, { stdio: 'pipe', cwd: 'backend' });
-      } catch {
-        // ruff may exit non-zero for unfixable issues — that's okay
+      const backendDir = resolve('backend');
+      if (resolved.startsWith(backendDir + sep)) {
+        const targetPath = relative(backendDir, resolved);
+        if (targetPath.startsWith('..')) process.exit(0);
+        try {
+          execFileSync('ruff', ['check', '--fix', targetPath], { stdio: 'pipe', cwd: 'backend' });
+        } catch {
+          // ruff may exit non-zero for unfixable issues — that's okay
+        }
       }
     }
 

package/templates/claude-code/hooks/scripts/autofix-python.mjs

@@ -1,7 +1,8 @@
 #!/usr/bin/env node
 // Auto-fix lint issues on saved Python files
 
-import { execSync } from 'node:child_process';
+import { execFileSync } from 'node:child_process';
+import { resolve, sep } from 'node:path';
 
 let input = '';
 process.stdin.setEncoding('utf8');
@@ -11,18 +12,24 @@ process.stdin.on('end', () => {
     const data = JSON.parse(input);
     const filePath = data?.tool_input?.file_path || '';
 
-    if (!filePath) {
+    if (!filePath || filePath.includes('..')) {
+      process.exit(0);
+    }
+
+    // Ensure path stays within the working directory
+    const resolved = resolve(filePath);
+    const cwd = resolve('.');
+    if (!resolved.startsWith(cwd + sep) && resolved !== cwd) {
       process.exit(0);
     }
 
     if (filePath.endsWith('.py')) {
       try {
-        execSync(`ruff check --fix "${filePath}"`, { stdio: 'pipe', cwd: 'backend' });
+        execFileSync('ruff', ['check', '--fix', resolved], { stdio: 'pipe' });
       } catch {
         // ruff may exit non-zero for unfixable issues — that's okay
       }
     }
-
     process.exit(0);
   } catch {
     process.exit(0);

package/templates/claude-code/hooks/scripts/autofix-typescript.mjs

@@ -1,7 +1,8 @@
 #!/usr/bin/env node
 // Auto-fix lint issues on saved TypeScript files
 
-import { execSync } from 'node:child_process';
+import { execFileSync } from 'node:child_process';
+import { resolve, sep } from 'node:path';
 
 let input = '';
 process.stdin.setEncoding('utf8');
@@ -11,13 +12,20 @@ process.stdin.on('end', () => {
     const data = JSON.parse(input);
     const filePath = data?.tool_input?.file_path || '';
 
-    if (!filePath) {
+    if (!filePath || filePath.includes('..')) {
+      process.exit(0);
+    }
+
+    // Ensure path stays within the working directory
+    const resolved = resolve(filePath);
+    const cwd = resolve('.');
+    if (!resolved.startsWith(cwd + sep) && resolved !== cwd) {
       process.exit(0);
     }
 
     if (filePath.endsWith('.ts') || filePath.endsWith('.tsx')) {
       try {
-        execSync(`npx eslint --fix "${filePath}"`, { stdio: 'pipe' });
+        execFileSync('npx', ['eslint', '--fix', resolved], { stdio: 'pipe' });
       } catch {
         // eslint may exit non-zero for unfixable issues — that's okay
       }

package/templates/claude-code/hooks/scripts/guard-protected-files.mjs

@@ -22,11 +22,11 @@ process.stdin.on('end', () => {
     }
 
     // Block migration files
-    if (filePath.includes('prisma/migrations/') || filePath.includes('alembic/versions/')) {
+    const normalizedPath = filePath.replace(/\\/g, '/');
+    if (normalizedPath.includes('prisma/migrations/') || normalizedPath.includes('alembic/versions/')) {
       process.stderr.write('BLOCKED: Do not modify migration files directly\n');
       process.exit(2);
     }
-
     process.exit(0);
   } catch {
     process.exit(0);

package/templates/claude-code/skills/ai-prompts/SKILL.md

@@ -33,6 +33,7 @@ description: AI/LLM integration patterns and best practices
 ## Security
 - Never include user secrets in prompts
 - Sanitize user input before including in prompts
+- Protect against prompt injection attacks (delimiter tokens, input validation, output filtering)
 - Validate and sanitize AI output before using
 - Don't trust AI output for security decisions
 

package/templates/claude-code/skills/fastapi/SKILL.md

@@ -29,7 +29,7 @@ description: FastAPI + SQLAlchemy 2.0 + Pydantic v2 patterns
 - Raise `AppError` subclasses, never `HTTPException` with raw strings
 - Global exception handler catches unhandled errors
 - Never expose stack traces or internal details to clients
-- Use structured error format: `{ error: { code, message } }`
+- Use structured error format: `{ "error": { "code": "ERR_CODE", "message": "Error description" } }`
 
 ## Testing
 - Use `httpx.AsyncClient` with `ASGITransport` for async tests

package/templates/claude-code/skills/git-workflow/SKILL.md

@@ -59,6 +59,6 @@ If rebase gets messy: `git rebase --abort` and start over.
 
 - Never force-push to `main`
 - Never commit `.env` files, credentials, or large binaries
-- Never rebase commits that have been pushed and shared
-- Never merge main into feature branches (rebase instead)
-- Always pull before pushing: `git pull --rebase origin main`
+- Never rebase shared branches (`main`, `develop`) — only rebase your own feature branches
+- Update feature branches with `git rebase origin/main`, not `git merge main` (force-push your branch after)
+- Always pull before pushing: `git pull --rebase` (pulls current branch's upstream)

package/templates/claude-code/skills/nextjs/SKILL.md

@@ -33,7 +33,7 @@ description: Next.js 15 App Router patterns and best practices
 - Intercepting routes `(.)` for modals
 
 ## Common Mistakes
-- Don't use `useEffect` for data fetching in Server Components
+- Avoid Client Components with `useEffect` for data fetching — prefer async Server Components instead
 - Don't pass functions as props from Server to Client Components
 - Don't use `router.push` when `<Link>` works
 - Don't create API routes for data that Server Components can fetch directly

package/templates/claude-code/skills/playwright/SKILL.md

@@ -11,11 +11,12 @@ description: Playwright E2E testing patterns and best practices
 - Use `test.beforeEach()` for common setup (navigation, auth)
 - Use page object pattern for complex pages
 
-## Selectors
-- Prefer `data-testid` attributes: `page.getByTestId('submit-btn')`
-- Use accessible selectors: `page.getByRole('button', { name: 'Submit' })`
-- Use text selectors: `page.getByText('Welcome')`
-- Avoid CSS selectors — they break when styles change
+## Selector Priority
+1. `getByRole()` — buttons, links, headings (best for accessibility)
+2. `getByLabel()` — form inputs by label
+3. `getByText()` — visible text content
+4. `getByTestId()` — `data-testid` attributes (last resort)
+- Avoid CSS selectors or XPath — they break when styles change
 
 ## Assertions
 - Use `expect(locator)` for element assertions
@@ -25,8 +26,8 @@ description: Playwright E2E testing patterns and best practices
 
 ## Common Patterns
 - Navigation: `await page.goto('/')` then assert page loaded
-- Form filling: `await page.fill('[name=email]', 'test@example.com')`
-- Clicking: `await page.click('button[type=submit]')` or `getByRole`
+- Form filling: `await page.getByLabel('Email').fill('test@example.com')`
+- Clicking: `await page.getByRole('button', { name: 'Submit' }).click()`
 - Waiting: prefer auto-waiting over explicit waits
 - Network: `page.waitForResponse()` for API-dependent tests
 - Authentication: use `storageState` for persistent auth across tests