@codyswann/lisa 1.67.3 → 1.69.0

package/plugins/src/base/skills/epic-triage/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: epic-triage
+description: "9-step epic triage and 5-step implementation workflow. Ensures epics are fully scoped, broken down, and ordered before execution begins."
+---
+
+# Epic Triage
+
+Follow this 9-step triage process before implementing any epic. Do not skip triage.
+
+## Triage Steps
+
+1. Verify you have all information needed to understand the full scope of this epic (goals, acceptance criteria, impacted systems, design specs, dependencies, etc.). Do not make assumptions. If anything is missing, stop and ask before proceeding.
+2. Verify the epic is broken down into concrete, well-scoped bugs, tasks, and/or stories that are each fully triaged. If ambiguities exist, stop and resolve them before breaking it down.
+3. Identify all cross-cutting concerns (auth, performance, security, data migrations, third-party integrations) that need to be addressed across the epic.
+4. Identify all dependencies between tasks within the epic, or on external epics, teams, or services. Determine the correct order of execution.
+5. Verify you have access to the tools, environments, and permissions needed to deploy and verify all tasks within this epic (e.g. CI/CD pipelines, deployment targets, logging/monitoring systems, API access, database access). If any are missing or inaccessible, stop and raise them before proceeding.
+6. Define the overall test strategy for the epic (unit, integration, end-to-end, load testing).
+7. Define the documentation that will need to be created or updated to cover the full scope of the epic so another developer understands the architecture, design decisions, and implementation.
+8. Define measurable acceptance criteria that confirm the epic is fully complete.
+9. Define how you will verify the epic is fully delivered beyond a shadow of a doubt (e.g. deploy to the target environment, walk through all acceptance criteria end-to-end, confirm all child tasks/stories are closed, confirm no regressions).
+
+## Implementation
+
+1. Use the output of the triage steps above as your guide. Do not skip triage.
+2. Work through each task and/or story in the order defined during triage, respecting dependencies.
+3. Apply the Bug Implementation and Task Implementation processes to each child bug or task, respectively, as you work through them.
+4. Continuously update the epic and its child issues in JIRA as progress is made.
+5. Do not consider the epic complete until all acceptance criteria are verified in the target environment and all child issues are resolved.

package/plugins/src/base/skills/nightly-add-test-coverage/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: nightly-add-test-coverage
+description: "Nightly direct-execution skill for increasing test coverage. Receives pre-computed threshold data, writes tests targeting coverage gaps, updates thresholds, commits, and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Test Coverage Improvement
+
+The caller provides pre-computed context:
+- **Package manager** (`npm`, `yarn`, or `bun`)
+- **Thresholds file** path (vitest.thresholds.json or jest.thresholds.json)
+- **Current thresholds** (statements, branches, functions, lines percentages)
+- **Proposed thresholds** (each metric increased by the coverage increment, capped at 90%)
+- **Metrics being bumped** (which metrics are below target)
+
+## Instructions
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Run the project's coverage script with the provided package manager (e.g., `npm run test:cov`, `yarn test:cov`, or `bun run test:cov`) to get the coverage report -- identify gaps BEFORE reading any source files
+3. Parse the coverage output to identify the specific files and lines with the lowest coverage. Prioritize files with the most uncovered lines/branches.
+4. Read only the uncovered sections of source files using the coverage report line numbers -- do not explore the codebase broadly
+5. Write new tests to increase coverage enough to meet the proposed thresholds. Focus on the metrics being bumped -- write tests that cover untested branches, statements, functions, and lines.
+6. Re-run the coverage script with the provided package manager to verify the new thresholds pass
+7. Update the thresholds file with the proposed new threshold values
+8. Re-run the coverage script with the provided package manager to confirm the updated thresholds pass
+9. Commit all changes (new tests + updated thresholds file) with conventional commit messages
+10. Create a PR with `gh pr create` with a title like "test: increase test coverage: [metrics being bumped]" summarizing coverage improvements

package/plugins/src/base/skills/nightly-improve-tests/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: nightly-improve-tests
+description: "Nightly direct-execution skill for improving test quality. In nightly mode, focuses on tests for recently changed files. In general mode, scans all tests for the weakest ones. Commits and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Test Quality Improvement
+
+The caller provides:
+- **Mode**: "nightly" or "general"
+- **Changed files** (nightly mode only): list of source files changed in the last 24 hours
+
+## Nightly Mode
+
+1. Read CLAUDE.md and package.json for project conventions
+2. For each changed source file, find its corresponding test file(s)
+3. Analyze those test files for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+4. Improve the test files with the most impactful changes
+5. Run the full test suite to verify all tests pass
+6. Commit changes with conventional commit messages
+7. Create a PR with `gh pr create` summarizing what was improved and why
+
+## General Mode
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Scan the test files to find weak, brittle, or poorly-written tests
+3. Look for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+4. Improve 3-5 test files with the most impactful changes
+5. Run the full test suite to verify all tests pass
+6. Commit changes with conventional commit messages
+7. Create a PR with `gh pr create` summarizing what was improved and why

package/plugins/src/base/skills/nightly-lower-code-complexity/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: nightly-lower-code-complexity
+description: "Nightly direct-execution skill for reducing code complexity thresholds. Receives pre-computed threshold data, refactors violations, updates thresholds, commits, and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Code Complexity Reduction
+
+The caller provides pre-computed context:
+- **Package manager** (`npm`, `yarn`, or `bun`)
+- **Current thresholds** (cognitiveComplexity, maxLinesPerFunction from eslint.thresholds.json)
+- **Proposed thresholds** (each metric decreased toward target minimums)
+- **Metrics being reduced** (which metrics are above target)
+
+## Instructions
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Update eslint.thresholds.json with the proposed new threshold values (do NOT change the maxLines threshold)
+3. Run the project's lint script with the provided package manager (e.g., `npm run lint`, `yarn lint`, or `bun run lint`) to find functions that violate the new stricter thresholds
+4. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
+5. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
+6. Re-run the lint script with the provided package manager to verify all violations are resolved
+7. Run the project's test script with the provided package manager (e.g., `npm run test`, `yarn test`, or `bun run test`) to verify no tests are broken by the refactoring
+8. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
+9. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes

package/plugins/src/base/skills/performance-review/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: performance-review
+description: "Performance review methodology. N+1 queries, inefficient algorithms, memory leaks, missing indexes, unnecessary re-renders, bundle size issues. Evidence-based recommendations."
+---
+
+# Performance Review
+
+Identify bottlenecks, inefficiencies, and scalability risks in code changes.
+
+## Analysis Process
+
+1. **Read affected files** -- understand data access patterns, algorithmic complexity, and resource usage
+2. **Identify N+1 queries** -- look for ORM calls inside loops, missing eager loading, unbatched database access
+3. **Check algorithmic complexity** -- nested loops over collections, repeated linear scans, unnecessary sorting
+4. **Evaluate memory usage** -- large object allocations, unbounded caches, retained references, memory leaks
+5. **Review database patterns** -- missing indexes, full table scans, unoptimized joins, excessive round trips
+6. **Check caching** -- missing cache layers, cache invalidation issues, redundant computations
+7. **Assess bundle/payload size** -- unnecessary imports, large dependencies, uncompressed responses
+8. **Review rendering performance** -- unnecessary re-renders, missing memoization, layout thrashing (frontend)
+
+## Output Format
+
+Structure findings as:
+
+```
+## Performance Analysis
+
+### Critical Issues
+Issues that will cause noticeable degradation at scale.
+
+- [issue] -- where in the code, why it matters, estimated impact
+
+### N+1 Query Detection
+| Location | Pattern | Fix |
+|----------|---------|-----|
+| file:line | Description of the N+1 | Eager load / batch / join |
+
+### Algorithmic Complexity
+| Location | Current | Suggested | Why |
+|----------|---------|-----------|-----|
+| file:line | O(n^2) | O(n) | Description |
+
+### Database Concerns
+- Missing indexes, unoptimized queries, excessive round trips
+
+### Memory Concerns
+- Unbounded growth, large allocations, retained references
+
+### Caching Opportunities
+- Computations or queries that could benefit from caching
+
+### Recommendations
+- [recommendation] -- priority (critical/warning/suggestion), estimated impact
+```
+
+## Common Patterns to Flag
+
+### N+1 Queries
+```typescript
+// Bad: N+1 -- one query per user inside loop
+const users = await userRepo.find();
+const profiles = await Promise.all(users.map(u => profileRepo.findOne({ userId: u.id })));
+
+// Good: Single query with join or batch
+const users = await userRepo.find({ relations: ["profile"] });
+```
+
+### Unnecessary Re-computation
+```typescript
+// Bad: Recomputes on every call
+const getExpensiveResult = () => heavyComputation(data);
+
+// Good: Compute once, reuse
+const expensiveResult = heavyComputation(data);
+```
+
+### Unbounded Collection Growth
+```typescript
+// Bad: Cache grows without limit
+const cache = new Map();
+const get = (key) => { if (!cache.has(key)) cache.set(key, compute(key)); return cache.get(key); };
+
+// Good: LRU or bounded cache
+const cache = new LRUCache({ max: 1000 });
+```
+
+## Rules
+
+- Focus on the specific changes proposed, not a full performance audit of the entire codebase
+- Flag only real performance risks -- do not micro-optimize code that runs once at startup
+- Quantify impact where possible (O(n) vs O(n^2), number of database round trips, estimated payload size)
+- Distinguish between critical issues (will degrade at scale) and suggestions (marginal improvement)
+- If the changes have no performance implications, report "No performance concerns" and explain why
+- Always consider the data scale -- an O(n^2) over 5 items is fine, over 10,000 is not

package/plugins/src/base/skills/plan-improve-tests/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: plan-improve-tests
+description: This skill should be used when improving test quality. It scans the test suite for weak, brittle, or poorly-written tests, generates a brief with improvement opportunities, and creates a plan with tasks to strengthen the tests.
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+---
+
+# Improve Test Quality
+
+Target: $ARGUMENTS
+
+If no argument provided, scan the full test suite.
+
+## Step 1: Gather Requirements
+
+1. **Run test suite** to establish baseline:
+   ```bash
+   bun run test 2>&1 | tail -20
+   ```
+2. **Scan test files** for quality issues:
+   - Weak assertions (`toBeTruthy`, `toBeDefined` instead of specific values)
+   - Missing edge cases (no boundary values, no error paths)
+   - Implementation coupling (testing internals rather than behavior)
+   - Missing error path coverage
+   - Duplicated setup that could indicate missing abstractions
+3. **Identify 10-20 test files** with highest improvement potential, noting:
+   - File path
+   - Issues found (weak assertions, missing edge cases, etc.)
+   - Estimated impact of improvement
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```text
+Improve test quality across the test suite.
+
+Test files needing improvement (ordered by impact):
+1. [test file] - [issues found]
+   - Weak assertions: [count]
+   - Missing edge cases: [description]
+   - Implementation coupling: [description]
+2. ...
+
+Verification: `bun run test` -> Expected: All tests pass, improved assertions and coverage
+```
+
+Invoke `/plan-execute` with this brief to create the implementation plan.

package/plugins/src/base/skills/quality-review/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: quality-review
+description: "Code quality review checklist. Correctness, coding philosophy compliance, test coverage, documentation quality. Findings ranked by severity in plain English."
+---
+
+# Quality Review
+
+Review code quality for changed files. Explain all findings in plain English as if speaking to someone with no programming background.
+
+## Review Checklist
+
+For each changed file, evaluate:
+
+1. **Correctness** -- Does the code do what the task says? Logic errors, off-by-one mistakes, missing edge cases?
+2. **Coding philosophy** -- Immutability patterns (no `let`, no mutations, functional transformations)? Correct function structure (variables, side effects, return)?
+3. **Test coverage** -- Tests present? Testing behavior, not implementation details? Edge cases covered?
+4. **Documentation** -- JSDoc on new functions explaining "why"? Preambles on new files?
+5. **Code clarity** -- Readable variable names? Unnecessary complexity? Could a new team member understand this?
+
+## Output Format
+
+Rank findings by severity:
+
+### Critical (must fix before merge)
+Broken logic or violates hard project rules.
+
+### Warning (should fix)
+Could cause problems later or reduce maintainability.
+
+### Suggestion (nice to have)
+Minor improvements, not blocking.
+
+## Finding Format
+
+For each finding:
+
+- **What** -- Plain English description, no jargon
+- **Why** -- What could go wrong? Concrete examples
+- **Where** -- File path and line number
+- **Fix** -- Specific, actionable suggestion
+
+### Example
+
+> **What:** The function changes the original list instead of creating a new one.
+> **Why:** Other code using that list could see unexpected changes, causing hard-to-track bugs.
+> **Where:** `src/utils/transform.ts:42`
+> **Fix:** Use `[...items].sort()` instead of `items.sort()` to create a copy first.
+
+## Rules
+
+- Run `bun run test` to confirm tests pass
+- Run the task's proof command to confirm the implementation works
+- Never approve code with failing tests
+- If no issues found, say so clearly -- do not invent problems

package/plugins/src/base/skills/reproduce-bug/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: reproduce-bug
+description: "How to create reliable bug reproduction scenarios. Covers failing tests, minimal scripts, environment verification, and reproduction evidence capture."
+---
+
+# Reproduce Bug
+
+Before investigating root cause, reproduce the issue empirically. A bug that cannot be reproduced cannot be verified as fixed.
+
+## Reproduction Process
+
+### 1. Run the Failing Scenario
+
+- Execute the exact command, test, or request that triggers the bug
+- Capture the complete error output, stack trace, or unexpected behavior
+- Record the exact command used so it can be repeated
+
+### 2. Capture Evidence
+
+- Save the full error output (not just a summary)
+- Note the timestamp and environment details (OS, runtime version, dependency versions)
+- Screenshot or log any visual/UI issues
+- Record the actual behavior vs. the expected behavior
+
+### 3. Investigate Environment Differences (If Cannot Reproduce)
+
+If the issue does not reproduce locally:
+
+- Compare environment configurations (env vars, config files, feature flags)
+- Check runtime versions (Node.js, Python, Java, etc.)
+- Compare dependency versions (`package-lock.json`, `poetry.lock`, etc.)
+- Check data differences (database state, seed data, user roles)
+- Verify network conditions (DNS, proxies, firewalls, VPN)
+- Check for platform-specific behavior (OS, architecture, container vs. host)
+
+### 4. Create a Minimal Reproduction
+
+Create the smallest possible reproduction that triggers the bug:
+
+**Preferred: Failing test**
+- Write a test that exercises the exact code path and asserts the expected behavior
+- The test should fail with the same symptom as the reported bug
+- A failing test is the most reliable reproduction because it runs in CI and prevents regression
+
+**Fallback: Reproduction script**
+- Write a standalone script that triggers the issue
+- Minimize dependencies -- remove anything not needed to reproduce
+- Include setup steps (data seeding, config) in the script itself
+- The script should be runnable by anyone with access to the repo
+
+**Last resort: Manual steps**
+- Document exact click-by-click or command-by-command steps
+- Include prerequisite state (logged-in user, specific data, feature flags)
+- Note any timing-sensitive aspects (race conditions, timeouts)
+
+### 5. Verify Reproduction Is Reliable
+
+- Run the reproduction multiple times to confirm it consistently fails
+- For intermittent bugs, run enough iterations to establish the failure rate
+- If intermittent, note any patterns (timing, load, specific data)
+
+## Output Format
+
+```text
+## Reproduction
+
+### Command/Steps
+The exact command or steps to trigger the bug.
+
+### Actual Behavior
+What happens (error message, wrong output, crash).
+
+### Expected Behavior
+What should happen instead.
+
+### Environment
+- Runtime: [version]
+- OS: [platform]
+- Dependencies: [relevant versions]
+
+### Reproduction Type
+[ ] Failing test: [path to test file]
+[ ] Script: [path to script]
+[ ] Manual steps: [documented above]
+
+### Reliability
+[Always / Intermittent (N/M runs) / Conditional (only when X)]
+```
+
+## Rules
+
+- Never skip reproduction. If you cannot reproduce, report what you tried and what you observed.
+- A failing test is always the preferred reproduction method.
+- Capture complete error output -- do not truncate or summarize.
+- If the bug is environment-specific, document exactly which environment triggers it.
+- Do not begin root cause analysis until you have a reliable reproduction.

package/plugins/src/base/skills/root-cause-analysis/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: root-cause-analysis
+description: "Root cause analysis methodology. Evidence gathering from logs, execution path tracing, strategic log placement, and building irrefutable proof chains."
+---
+
+# Root Cause Analysis
+
+Definitively prove what is causing a problem. Do not guess. Do not theorize without evidence. Trace the actual execution path, read real logs, and produce irrefutable proof of root cause.
+
+**Core principle: "Show me the proof."** Every conclusion must be backed by concrete evidence -- a log line, a stack trace, a reproducible sequence, or a failing test.
+
+## Phase 1: Gather Evidence from Logs
+
+### Local Logs
+
+- Search application logs in the project directory (`logs/`, `tmp/`, stdout/stderr output)
+- Run tests with verbose logging enabled to capture execution flow
+- Check framework-specific log locations (e.g., `.next/`, `dist/`, build output)
+
+### Remote Logs (AWS CloudWatch, etc.)
+
+- Discover existing scripts and tools in the project for tailing logs:
+  - Check `package.json` scripts for log-related commands
+  - Search for shell scripts: `scripts/*log*`, `scripts/*tail*`, `scripts/*watch*`
+  - Look for AWS CLI wrappers, CloudWatch log group configurations
+  - Check for `.env` files referencing log groups or log streams
+- Use discovered tools first before falling back to raw CLI commands
+- When using AWS CLI directly:
+  ```bash
+  # Discover available log groups
+  aws logs describe-log-groups --query 'logGroups[].logGroupName' --output text
+
+  # Tail recent logs with filter
+  aws logs filter-log-events \
+    --log-group-name "/aws/lambda/function-name" \
+    --start-time $(date -d '30 minutes ago' +%s000) \
+    --filter-pattern "ERROR" \
+    --query 'events[].message' --output text
+
+  # Follow live logs
+  aws logs tail "/aws/lambda/function-name" --follow --since 10m
+  ```
+
+## Phase 2: Trace the Execution Path
+
+- Start from the error and work backward through the call stack
+- Read every function in the chain -- do not skip intermediate code
+- Identify the exact line where behavior diverges from expectation
+- Map the data flow: what value was expected vs. what value was actually present
+
+## Phase 3: Strategic Log Placement
+
+When existing logs are insufficient, add targeted log statements to prove or disprove hypotheses.
+
+### Log Statement Guidelines
+
+- **Be surgical** -- add the minimum number of log statements needed to confirm the root cause
+- **Include context** -- log the actual values, not just "reached here"
+- **Use structured format** -- make logs easy to find and parse
+
+```typescript
+// Bad: Vague, unhelpful
+console.log("here");
+console.log("data:", data);
+
+// Good: Precise, searchable, includes context
+console.log("[DEBUG:issue-123] processOrder entry", {
+  orderId: order.id,
+  status: order.status,
+  itemCount: order.items.length,
+  timestamp: new Date().toISOString(),
+});
+```
+
+### Placement Strategy
+
+| Placement | Purpose |
+|-----------|---------|
+| Function entry | Confirm the function is called and with what arguments |
+| Before conditional branches | Verify which branch is taken and why |
+| Before/after async operations | Detect timing issues, race conditions, failed awaits |
+| Before/after data transformations | Catch where data becomes corrupted or unexpected |
+| Error handlers and catch blocks | Ensure errors are not silently swallowed |
+
+### Hypothesis Elimination
+
+When multiple hypotheses exist, design a log placement strategy that eliminates all but one. Each log statement should be placed to confirm or rule out a specific hypothesis.
+
+## Phase 4: Prove the Root Cause
+
+Build an evidence chain that is irrefutable:
+
+1. **The symptom** -- what the user observes (error message, wrong output, crash)
+2. **The proximate cause** -- the line of code that directly produces the symptom
+3. **The root cause** -- the underlying reason the proximate cause occurs
+4. **The proof** -- log output, test result, or reproduction steps that confirm each link
+
+### Evidence Chain Format
+
+```text
+Symptom: [exact error message or behavior]
+    |
+    v
+Proximate cause: [file:line] -- [the line that directly produces the error]
+    |
+    v
+Root cause: [file:line] -- [the underlying reason]
+    |
+    v
+Proof: [log output / test result / reproduction that confirms the chain]
+```
+
+## Phase 5: Clean Up
+
+After root cause is confirmed, **remove all debug log statements** added during investigation. Leave only:
+
+- Log statements that belong in the application permanently (error logging, audit trails)
+- Statements explicitly requested by the user
+
+Verify cleanup:
+```bash
+# Search for any remaining debug markers
+grep -rn "\[DEBUG:" src/ --include="*.ts" --include="*.tsx" --include="*.js"
+```
+
+## Output Format
+
+```text
+## Root Cause Analysis
+
+### Evidence Trail
+| Step | Location | Evidence | Conclusion |
+|------|----------|----------|------------|
+| 1 | file:line | Log output or observed value | What this proves |
+| 2 | file:line | Log output or observed value | What this proves |
+
+### Root Cause
+**Proximate cause:** The line that directly produces the error.
+**Root cause:** The underlying reason this line behaves incorrectly.
+**Proof:** The specific evidence that confirms this beyond doubt.
+
+### Recommended Fix
+What needs to change and why. Include file:line references.
+```
+
+## Rules
+
+- Never guess at root cause -- prove it with evidence
+- Read the actual code in the execution path -- do not rely on function names or comments to infer behavior
+- When adding debug logs, use a consistent prefix (e.g., `[DEBUG:issue-name]`) so they are easy to find and clean up
+- Remove all temporary debug log statements after investigation is complete
+- If remote log access is unavailable, report what logs would be needed and from where
+- Prefer project-specific tooling and scripts over raw CLI commands for log access
+- If the root cause is in a third-party dependency, identify the exact version and known issue
+- Always verify the fix resolves the issue -- do not mark investigation complete without proof

package/plugins/src/base/skills/security-review/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: security-review
+description: "Security review methodology. STRIDE threat modeling, OWASP Top 10 vulnerability checks, auth/validation/secrets handling review, and mitigation recommendations."
+---
+
+# Security Review
+
+Identify vulnerabilities, evaluate threats, and recommend mitigations for code changes.
+
+## Analysis Process
+
+1. **Read affected files** -- understand current security posture of the code being changed
+2. **STRIDE analysis** -- evaluate Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege risks
+3. **Check input validation** -- are user inputs sanitized at system boundaries?
+4. **Check secrets handling** -- are credentials, tokens, or API keys exposed in code, logs, or error messages?
+5. **Check auth/authz** -- are access controls properly enforced for new endpoints or features?
+6. **Review dependencies** -- do new dependencies introduce known vulnerabilities?
+
+## Output Format
+
+Structure findings as:
+
+```
+## Security Analysis
+
+### Threat Model (STRIDE)
+| Threat | Applies? | Description | Mitigation |
+|--------|----------|-------------|------------|
+| Spoofing | Yes/No | ... | ... |
+| Tampering | Yes/No | ... | ... |
+| Repudiation | Yes/No | ... | ... |
+| Info Disclosure | Yes/No | ... | ... |
+| Denial of Service | Yes/No | ... | ... |
+| Elevation of Privilege | Yes/No | ... | ... |
+
+### Security Checklist
+- [ ] Input validation at system boundaries
+- [ ] No secrets in code or logs
+- [ ] Auth/authz enforced on new endpoints
+- [ ] No SQL/NoSQL injection vectors
+- [ ] No XSS vectors in user-facing output
+- [ ] Dependencies free of known CVEs
+
+### Vulnerabilities Found
+- [vulnerability] -- where in the code, how to prevent
+
+### Recommendations
+- [recommendation] -- priority (critical/warning/suggestion)
+```
+
+## Rules
+
+- Focus on the specific changes proposed, not a full security audit of the entire codebase
+- Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input
+- Prioritize OWASP Top 10 vulnerabilities
+- If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why
+- Always check `.gitleaksignore` patterns to understand what secrets scanning is already in place