@codyswann/lisa 1.78.8 → 1.79.0

package/package.json

@@ -76,7 +76,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.78.8",
+  "version": "1.79.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "1.78.8",
+  "version": "1.79.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

@@ -15,13 +15,26 @@ The caller provides pre-computed context:
 
 ## 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
+### Phase 1: Identify gaps
+
+1. 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
+2. Parse the coverage output to identify the specific files and lines with the lowest coverage. Prioritize files with the most uncovered lines/branches.
+3. Read ONE existing test file to learn the project's testing patterns (mocks, imports, assertions). Do not read more than one.
+
+### Phase 2: Write tests incrementally — one file at a time
+
+For each source file with low coverage (starting with the lowest):
+
+4. Read only the uncovered sections of the source file using the coverage report line numbers -- do not explore the codebase broadly
+5. Write a test file targeting the uncovered branches/lines for that source file
+6. Run the test file in isolation (e.g., `npx vitest run tests/my-new-test.test.ts`) to verify it passes before moving on
+7. If the test fails, fix it immediately. Do not move to the next file until the current test passes.
+8. Repeat steps 4-7 for the next source file. Stop once you estimate the proposed thresholds will be met.
+
+### Phase 3: Verify and ship
+
+9. Run the full coverage script to verify the new thresholds pass
+10. Update the thresholds file with the proposed new threshold values
+11. Re-run the coverage script to confirm the updated thresholds pass
+12. Commit all changes (new tests + updated thresholds file) with conventional commit messages
+13. Create a PR with `gh pr create` with a title like "test: increase test coverage: [metrics being bumped]" summarizing coverage improvements

package/plugins/lisa/skills/nightly-improve-tests/SKILL.md

@@ -12,20 +12,18 @@ The caller provides:
 
 ## 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
+1. For each changed source file, find its corresponding test file(s)
+2. 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
+3. Improve the test files with the most impactful changes
+4. Run the full test suite to verify all tests pass
+5. Commit changes with conventional commit messages
+6. 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
+1. Scan the test files to find weak, brittle, or poorly-written tests
+2. Look for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+3. Improve 3-5 test files with the most impactful changes
+4. Run the full test suite to verify all tests pass
+5. Commit changes with conventional commit messages
+6. Create a PR with `gh pr create` summarizing what was improved and why

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

@@ -14,16 +14,15 @@ The caller provides pre-computed context:
 
 ## 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. **Before editing**, check each violating file's total line count (`wc -l`). If a file is within 20 lines of its `max-lines` ESLint limit (typically 300), extract helpers into a **separate companion file** (e.g., `fooHelpers.ts`) instead of adding them to the same file. Extracting functions into the same file adds net lines and can create new max-lines violations.
-5. Fix violations one file at a time. Read only the specific function that violates — do not pre-read all files upfront. Fix it, then move to the next.
-6. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
-7. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
-8. After each file edit, run the project's formatter (e.g., `bun run format` or `npx prettier --write <file>`) to ensure line counts reflect the final formatted state before moving on
-9. Re-run the lint script with the provided package manager to verify all violations are resolved (both the target metric AND max-lines)
-10. Run the TypeScript compiler to catch type errors early: `npx tsc --noEmit 2>&1 | head -30`. If there are type errors, fix them now — do NOT wait until the commit step. Pre-commit hooks run type checking, and discovering errors at commit time wastes turns.
-11. 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
-12. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
-13. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes
+1. Update eslint.thresholds.json with the proposed new threshold values (do NOT change the maxLines threshold)
+2. 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
+3. **Before editing**, check each violating file's total line count (`wc -l`). If a file is within 20 lines of its `max-lines` ESLint limit (typically 300), extract helpers into a **separate companion file** (e.g., `fooHelpers.ts`) instead of adding them to the same file. Extracting functions into the same file adds net lines and can create new max-lines violations.
+4. Fix violations one file at a time. Read only the specific function that violates — do not pre-read all files upfront. Fix it, then move to the next.
+5. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
+6. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
+7. After each file edit, run the project's formatter (e.g., `bun run format` or `npx prettier --write <file>`) to ensure line counts reflect the final formatted state before moving on
+8. Re-run the lint script with the provided package manager to verify all violations are resolved (both the target metric AND max-lines)
+9. Run the TypeScript compiler to catch type errors early: `npx tsc --noEmit 2>&1 | head -30`. If there are type errors, fix them now — do NOT wait until the commit step. Pre-commit hooks run type checking, and discovering errors at commit time wastes turns.
+10. 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
+11. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
+12. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes

package/plugins/lisa/skills/notion-to-jira/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: notion-to-jira
+description: >
+  Break down a Notion PRD into JIRA epics, stories, and sub-tasks. Use this skill whenever the user
+  shares a Notion PRD URL and wants it converted into JIRA tickets, or asks to "break down a PRD",
+  "create tickets from a PRD", "turn this PRD into JIRA", or similar. Also trigger when the user
+  mentions creating epics/stories/tasks from a Notion document. This skill handles the full pipeline:
+  fetching the PRD, analyzing comments, researching the codebase, identifying blockers, and creating
+  all tickets with empirical verification plans.
+---
+
+# Notion PRD to JIRA Breakdown
+
+Convert a Notion PRD into a structured JIRA ticket hierarchy: Epics > Stories > Sub-tasks.
+Each sub-task is scoped to exactly one repo and includes an empirical verification plan.
+
+## Input
+
+A Notion PRD URL. The PRD is expected to have:
+- A main page with context, problems, and links to Epic sub-pages
+- Epic sub-pages with User Stories and functional/non-functional requirements
+- Comments/discussions on each page with engineering notes and product decisions
+
+## Configuration
+
+This skill reads project-specific configuration from environment variables. If these are not set,
+ask the user for the values before proceeding.
+
+| Variable | Purpose | Example |
+|----------|---------|---------|
+| `JIRA_PROJECT` | JIRA project key for ticket creation | `SE` |
+| `JIRA_SERVER` | Atlassian instance URL (site host) | `mycompany.atlassian.net` |
+| `E2E_TEST_PHONE` | Test user phone number for verification plans | `0000000099` |
+| `E2E_TEST_OTP` | Test user OTP code | `555555` |
+| `E2E_TEST_ORG` | Test organization name | `Arsenal` |
+| `E2E_BASE_URL` | Frontend base URL for Playwright tests | `https://dev.example.io/` |
+| `E2E_GRAPHQL_URL` | GraphQL API URL for curl verification | `https://gql.dev.example.io/graphql` |
+
+If env vars are not available, ask the user to provide them explicitly before proceeding.
+Do not retrieve credentials from repository files or local agent settings.
+
+## Workflow
+
+### Phase 1: Fetch & Analyze the PRD
+
+1. **Fetch the main PRD page** with `include_discussions: true`
+2. **Identify all Epic sub-pages** from the content (look for child page links)
+3. **Fetch all Epic pages** in parallel with `include_discussions: true`
+4. **Fetch full comments** from every page using `notion-get-comments` with `include_all_blocks: true`
+5. **Synthesize decisions and blockers** from the PRD content + all comments:
+   - Decisions already confirmed by the team (look for agreement in comment threads)
+   - Open questions that need product/engineering input
+   - Engineering comments (prefixed with "Engineering:" or wrench emoji) that identify technical constraints
+   - Cross-PRD dependencies (references to other features or shared infrastructure)
+
+### Phase 2: Codebase Research (if needed)
+
+If the session doesn't already have codebase context, explore the repos to understand what exists.
+Use Explore agents for repos not yet examined. Skip repos already explored in the current session.
+
+Key things to look for:
+- Existing entities/modules that overlap with the PRD
+- Patterns to reuse (auth decorators, S3 services, existing UI components)
+- Data model gaps the PRD requires (new fields, new entities)
+- The tech stack per repo (framework, ORM, UI library, deployment)
+
+### Phase 3: Create Epics
+
+Create one Epic per PRD epic using the JIRA project key from config. Each Epic description should include:
+- Summary of the epic from the PRD
+- List of user stories it contains
+- Key decisions from comments (with attribution)
+- Blockers and open questions
+- Dependencies on other epics or PRDs
+
+Use `contentFormat: "markdown"` for all descriptions.
+
+### Phase 4: Create Stories
+
+For each Epic, create Stories:
+- **One "X.0 Setup" story** for data model and infrastructure prerequisites (new entities, migrations, new fields, infrastructure like S3 buckets or SQS queues)
+- **One story per user story** from the PRD (numbered to match the PRD)
+
+**Story naming convention**: Prefix with a short code derived from the PRD title:
+- "Contract Upload" -> `[CU-1.1]`
+- "Squad Planning" -> `[SP-1.1]`
+- Use your judgment for other PRDs
+
+Each story description should include:
+- The user story statement from the PRD
+- Acceptance criteria (from functional requirements)
+- Technical notes from engineering comments
+- Blockers with recommendation + alternatives (if any)
+
+Set `parent` to the Epic key to link stories to their epic.
+
+### Phase 5: Create Sub-tasks
+
+Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency.
+
+Each sub-task MUST:
+1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]`
+2. **Include an Empirical Verification Plan** — real user-like verification, NOT unit tests, linting, or typechecking
+
+**Verification plan examples by stack:**
+- **Backend APIs**: curl GraphQL/REST calls with auth token, database queries, checking audit entries
+- **Frontend web**: Playwright browser tests (login with test user, navigate, interact, screenshot)
+- **Infrastructure**: `cdk synth` / `terraform plan` verification, CLI checks after deploy
+
+Use the test user credentials from config for all verification plans.
+
+Set `parent` to the Story key. Use `issueTypeName: "Sub-task"`.
+
+### Phase 6: Report Results
+
+After all tickets are created, present a summary table to the user:
+- All Epics with keys and URLs
+- All Stories grouped by Epic
+- All Sub-tasks grouped by Story with repo tags
+- Repo distribution (how many tasks per repo)
+- Blockers list with recommendations and alternatives
+- Cross-PRD dependencies
+
+## Handling Ambiguities and Blockers
+
+When you encounter something the PRD + comments + codebase can't resolve:
+
+1. **Don't guess** — mark the ticket with a BLOCKER section
+2. **Include your recommendation** with rationale (what you'd pick and why)
+3. **List 2-3 alternatives** so the user/product can choose
+4. **State what's needed to unblock** (e.g., "Product decision on X", "Sync with Y on Z")
+
+Common blocker categories:
+- Missing data model decisions (field types, entity relationships)
+- Permission model unclear (who can view/edit)
+- UX decisions not finalized (display format, input mechanism)
+- Cross-team dependencies (shared infrastructure, coordinated rollouts)
+- Preset values not defined (enums, tags, labels)
+
+## Agent Prompt Template for Sub-task Creation
+
+When delegating to agents, provide this context:
+
+```text
+Create JIRA sub-tasks in the [PROJECT] project at [CLOUD_ID].
+Use issueTypeName "Sub-task" and set parent to the story key.
+Use contentFormat "markdown".
+
+Test user info: [credentials from config]
+
+Each sub-task must:
+1. Be scoped to ONE repo only
+2. Include an **Empirical Verification Plan** section
+3. Include the repo in brackets in the summary
+
+[Then list all sub-tasks grouped by parent story with details]
+```
+
+## Cross-PRD Shared Infrastructure
+
+Track tickets that are shared across PRDs to avoid duplication.
+When a sub-task overlaps with an existing ticket, reference it instead of creating a duplicate.
+Search JIRA for existing tickets in the project before creating new ones for shared infrastructure.

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.78.8",
+  "version": "1.79.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "1.78.8",
+  "version": "1.79.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "1.78.8",
+  "version": "1.79.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "1.78.8",
+  "version": "1.79.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "1.78.8",
+  "version": "1.79.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -15,13 +15,26 @@ The caller provides pre-computed context:
 
 ## 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
+### Phase 1: Identify gaps
+
+1. 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
+2. Parse the coverage output to identify the specific files and lines with the lowest coverage. Prioritize files with the most uncovered lines/branches.
+3. Read ONE existing test file to learn the project's testing patterns (mocks, imports, assertions). Do not read more than one.
+
+### Phase 2: Write tests incrementally — one file at a time
+
+For each source file with low coverage (starting with the lowest):
+
+4. Read only the uncovered sections of the source file using the coverage report line numbers -- do not explore the codebase broadly
+5. Write a test file targeting the uncovered branches/lines for that source file
+6. Run the test file in isolation (e.g., `npx vitest run tests/my-new-test.test.ts`) to verify it passes before moving on
+7. If the test fails, fix it immediately. Do not move to the next file until the current test passes.
+8. Repeat steps 4-7 for the next source file. Stop once you estimate the proposed thresholds will be met.
+
+### Phase 3: Verify and ship
+
+9. Run the full coverage script to verify the new thresholds pass
+10. Update the thresholds file with the proposed new threshold values
+11. Re-run the coverage script to confirm the updated thresholds pass
+12. Commit all changes (new tests + updated thresholds file) with conventional commit messages
+13. 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

@@ -12,20 +12,18 @@ The caller provides:
 
 ## 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
+1. For each changed source file, find its corresponding test file(s)
+2. 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
+3. Improve the test files with the most impactful changes
+4. Run the full test suite to verify all tests pass
+5. Commit changes with conventional commit messages
+6. 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
+1. Scan the test files to find weak, brittle, or poorly-written tests
+2. Look for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+3. Improve 3-5 test files with the most impactful changes
+4. Run the full test suite to verify all tests pass
+5. Commit changes with conventional commit messages
+6. Create a PR with `gh pr create` summarizing what was improved and why

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

@@ -14,16 +14,15 @@ The caller provides pre-computed context:
 
 ## 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. **Before editing**, check each violating file's total line count (`wc -l`). If a file is within 20 lines of its `max-lines` ESLint limit (typically 300), extract helpers into a **separate companion file** (e.g., `fooHelpers.ts`) instead of adding them to the same file. Extracting functions into the same file adds net lines and can create new max-lines violations.
-5. Fix violations one file at a time. Read only the specific function that violates — do not pre-read all files upfront. Fix it, then move to the next.
-6. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
-7. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
-8. After each file edit, run the project's formatter (e.g., `bun run format` or `npx prettier --write <file>`) to ensure line counts reflect the final formatted state before moving on
-9. Re-run the lint script with the provided package manager to verify all violations are resolved (both the target metric AND max-lines)
-10. Run the TypeScript compiler to catch type errors early: `npx tsc --noEmit 2>&1 | head -30`. If there are type errors, fix them now — do NOT wait until the commit step. Pre-commit hooks run type checking, and discovering errors at commit time wastes turns.
-11. 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
-12. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
-13. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes
+1. Update eslint.thresholds.json with the proposed new threshold values (do NOT change the maxLines threshold)
+2. 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
+3. **Before editing**, check each violating file's total line count (`wc -l`). If a file is within 20 lines of its `max-lines` ESLint limit (typically 300), extract helpers into a **separate companion file** (e.g., `fooHelpers.ts`) instead of adding them to the same file. Extracting functions into the same file adds net lines and can create new max-lines violations.
+4. Fix violations one file at a time. Read only the specific function that violates — do not pre-read all files upfront. Fix it, then move to the next.
+5. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
+6. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
+7. After each file edit, run the project's formatter (e.g., `bun run format` or `npx prettier --write <file>`) to ensure line counts reflect the final formatted state before moving on
+8. Re-run the lint script with the provided package manager to verify all violations are resolved (both the target metric AND max-lines)
+9. Run the TypeScript compiler to catch type errors early: `npx tsc --noEmit 2>&1 | head -30`. If there are type errors, fix them now — do NOT wait until the commit step. Pre-commit hooks run type checking, and discovering errors at commit time wastes turns.
+10. 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
+11. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
+12. 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/notion-to-jira/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: notion-to-jira
+description: >
+  Break down a Notion PRD into JIRA epics, stories, and sub-tasks. Use this skill whenever the user
+  shares a Notion PRD URL and wants it converted into JIRA tickets, or asks to "break down a PRD",
+  "create tickets from a PRD", "turn this PRD into JIRA", or similar. Also trigger when the user
+  mentions creating epics/stories/tasks from a Notion document. This skill handles the full pipeline:
+  fetching the PRD, analyzing comments, researching the codebase, identifying blockers, and creating
+  all tickets with empirical verification plans.
+---
+
+# Notion PRD to JIRA Breakdown
+
+Convert a Notion PRD into a structured JIRA ticket hierarchy: Epics > Stories > Sub-tasks.
+Each sub-task is scoped to exactly one repo and includes an empirical verification plan.
+
+## Input
+
+A Notion PRD URL. The PRD is expected to have:
+- A main page with context, problems, and links to Epic sub-pages
+- Epic sub-pages with User Stories and functional/non-functional requirements
+- Comments/discussions on each page with engineering notes and product decisions
+
+## Configuration
+
+This skill reads project-specific configuration from environment variables. If these are not set,
+ask the user for the values before proceeding.
+
+| Variable | Purpose | Example |
+|----------|---------|---------|
+| `JIRA_PROJECT` | JIRA project key for ticket creation | `SE` |
+| `JIRA_SERVER` | Atlassian instance URL (site host) | `mycompany.atlassian.net` |
+| `E2E_TEST_PHONE` | Test user phone number for verification plans | `0000000099` |
+| `E2E_TEST_OTP` | Test user OTP code | `555555` |
+| `E2E_TEST_ORG` | Test organization name | `Arsenal` |
+| `E2E_BASE_URL` | Frontend base URL for Playwright tests | `https://dev.example.io/` |
+| `E2E_GRAPHQL_URL` | GraphQL API URL for curl verification | `https://gql.dev.example.io/graphql` |
+
+If env vars are not available, ask the user to provide them explicitly before proceeding.
+Do not retrieve credentials from repository files or local agent settings.
+
+## Workflow
+
+### Phase 1: Fetch & Analyze the PRD
+
+1. **Fetch the main PRD page** with `include_discussions: true`
+2. **Identify all Epic sub-pages** from the content (look for child page links)
+3. **Fetch all Epic pages** in parallel with `include_discussions: true`
+4. **Fetch full comments** from every page using `notion-get-comments` with `include_all_blocks: true`
+5. **Synthesize decisions and blockers** from the PRD content + all comments:
+   - Decisions already confirmed by the team (look for agreement in comment threads)
+   - Open questions that need product/engineering input
+   - Engineering comments (prefixed with "Engineering:" or wrench emoji) that identify technical constraints
+   - Cross-PRD dependencies (references to other features or shared infrastructure)
+
+### Phase 2: Codebase Research (if needed)
+
+If the session doesn't already have codebase context, explore the repos to understand what exists.
+Use Explore agents for repos not yet examined. Skip repos already explored in the current session.
+
+Key things to look for:
+- Existing entities/modules that overlap with the PRD
+- Patterns to reuse (auth decorators, S3 services, existing UI components)
+- Data model gaps the PRD requires (new fields, new entities)
+- The tech stack per repo (framework, ORM, UI library, deployment)
+
+### Phase 3: Create Epics
+
+Create one Epic per PRD epic using the JIRA project key from config. Each Epic description should include:
+- Summary of the epic from the PRD
+- List of user stories it contains
+- Key decisions from comments (with attribution)
+- Blockers and open questions
+- Dependencies on other epics or PRDs
+
+Use `contentFormat: "markdown"` for all descriptions.
+
+### Phase 4: Create Stories
+
+For each Epic, create Stories:
+- **One "X.0 Setup" story** for data model and infrastructure prerequisites (new entities, migrations, new fields, infrastructure like S3 buckets or SQS queues)
+- **One story per user story** from the PRD (numbered to match the PRD)
+
+**Story naming convention**: Prefix with a short code derived from the PRD title:
+- "Contract Upload" -> `[CU-1.1]`
+- "Squad Planning" -> `[SP-1.1]`
+- Use your judgment for other PRDs
+
+Each story description should include:
+- The user story statement from the PRD
+- Acceptance criteria (from functional requirements)
+- Technical notes from engineering comments
+- Blockers with recommendation + alternatives (if any)
+
+Set `parent` to the Epic key to link stories to their epic.
+
+### Phase 5: Create Sub-tasks
+
+Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency.
+
+Each sub-task MUST:
+1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]`
+2. **Include an Empirical Verification Plan** — real user-like verification, NOT unit tests, linting, or typechecking
+
+**Verification plan examples by stack:**
+- **Backend APIs**: curl GraphQL/REST calls with auth token, database queries, checking audit entries
+- **Frontend web**: Playwright browser tests (login with test user, navigate, interact, screenshot)
+- **Infrastructure**: `cdk synth` / `terraform plan` verification, CLI checks after deploy
+
+Use the test user credentials from config for all verification plans.
+
+Set `parent` to the Story key. Use `issueTypeName: "Sub-task"`.
+
+### Phase 6: Report Results
+
+After all tickets are created, present a summary table to the user:
+- All Epics with keys and URLs
+- All Stories grouped by Epic
+- All Sub-tasks grouped by Story with repo tags
+- Repo distribution (how many tasks per repo)
+- Blockers list with recommendations and alternatives
+- Cross-PRD dependencies
+
+## Handling Ambiguities and Blockers
+
+When you encounter something the PRD + comments + codebase can't resolve:
+
+1. **Don't guess** — mark the ticket with a BLOCKER section
+2. **Include your recommendation** with rationale (what you'd pick and why)
+3. **List 2-3 alternatives** so the user/product can choose
+4. **State what's needed to unblock** (e.g., "Product decision on X", "Sync with Y on Z")
+
+Common blocker categories:
+- Missing data model decisions (field types, entity relationships)
+- Permission model unclear (who can view/edit)
+- UX decisions not finalized (display format, input mechanism)
+- Cross-team dependencies (shared infrastructure, coordinated rollouts)
+- Preset values not defined (enums, tags, labels)
+
+## Agent Prompt Template for Sub-task Creation
+
+When delegating to agents, provide this context:
+
+```text
+Create JIRA sub-tasks in the [PROJECT] project at [CLOUD_ID].
+Use issueTypeName "Sub-task" and set parent to the story key.
+Use contentFormat "markdown".
+
+Test user info: [credentials from config]
+
+Each sub-task must:
+1. Be scoped to ONE repo only
+2. Include an **Empirical Verification Plan** section
+3. Include the repo in brackets in the summary
+
+[Then list all sub-tasks grouped by parent story with details]
+```
+
+## Cross-PRD Shared Infrastructure
+
+Track tickets that are shared across PRDs to avoid duplication.
+When a sub-task overlaps with an existing ticket, reference it instead of creating a duplicate.
+Search JIRA for existing tickets in the project before creating new ones for shared infrastructure.