@codyswann/lisa 1.27.0 → 1.29.0

package/all/copy-overwrite/.claude/README.md

@@ -10,9 +10,9 @@ This directory contains Claude Code configuration files that customize AI-assist
 ├── settings.local.json        # Local overrides (gitignored)
 ├── settings.local.json.example # Template for local settings
 ├── agents/                    # Custom agent definitions
-├── commands/                  # Slash command definitions
 ├── hooks/                     # Automation hooks
-└── skills/                    # Skill definitions
+├── rules/                     # Always-on governance rules
+└── skills/                    # Skill definitions (colon-namespaced)
 ```
 
 ## Settings
@@ -109,31 +109,52 @@ Custom agent definitions in `agents/` provide specialized AI personas for differ
 | `slash-command-architect.md` | Command design |
 | `web-search-researcher.md` | Web research tasks |
 
-## Commands
+## Skills
 
-Slash commands in `commands/` provide quick actions:
+Skills use colon-namespaced directories (e.g., `plan:create/`) and are invoked via `/skill-name` in Claude Code.
 
-- `git/` - Git-related commands
-- `jira/` - Jira integration commands
-- `plan/` - Plan utility commands (test coverage, linting, code review, complexity)
-- `pull-request/` - PR workflow commands
-- `rules/` - Rule management commands
-- `sonarqube/` - Code quality commands
+### Plan Skills
 
-## Skills
+| Skill | Purpose |
+|-------|---------|
+| `plan:create` | Create implementation plans from ticket URLs, file paths, or text descriptions |
+| `plan:implement` | Execute an existing plan with an Agent Team |
+| `plan:add-test-coverage` | Increase test coverage to a target threshold |
+| `plan:fix-linter-error` | Fix all violations of specific ESLint rules |
+| `plan:local-code-review` | Review local branch changes against main |
+| `plan:lower-code-complexity` | Reduce cognitive complexity threshold |
+| `plan:reduce-max-lines` | Reduce max file lines threshold |
+| `plan:reduce-max-lines-per-function` | Reduce max function lines threshold |
+
+### Git Skills
 
-Skills in `skills/` provide domain-specific knowledge:
+| Skill | Purpose |
+|-------|---------|
+| `git:commit` | Create conventional commits for current changes |
+| `git:commit-and-submit-pr` | Commit changes and create/update a pull request |
+| `git:submit-pr` | Push changes and create or update a pull request |
+| `git:prune` | Prune local branches deleted on remote |
+
+### Integration Skills
 
 | Skill | Purpose |
 |-------|---------|
-| `jsdoc-best-practices/` | JSDoc documentation standards |
-| `skill-creator/` | Creating new skills |
-| `plan-add-test-coverage/` | Increase test coverage via plan mode |
-| `plan-fix-linter-error/` | Fix ESLint violations via plan mode |
-| `plan-local-code-review/` | Review local branch changes |
-| `plan-lower-code-complexity/` | Reduce cognitive complexity via plan mode |
-| `plan-reduce-max-lines/` | Reduce max file lines via plan mode |
-| `plan-reduce-max-lines-per-function/` | Reduce max function lines via plan mode |
+| `jira:create` | Create JIRA epics, stories, and tasks |
+| `jira:verify` | Verify JIRA ticket meets organizational standards |
+| `jira:sync` | Sync plan progress to linked JIRA tickets |
+| `sonarqube:check` | Check SonarQube/SonarCloud quality gate failures |
+| `sonarqube:fix` | Fix SonarQube quality gate failures |
+| `pull-request:review` | Check and implement PR review comments |
+| `security:zap-scan` | Run OWASP ZAP baseline security scan |
+
+### Utility Skills
+
+| Skill | Purpose |
+|-------|---------|
+| `tasks:load` | Load tasks from project directory into session |
+| `tasks:sync` | Export session tasks to project directory |
+| `skill-creator` | Guide for creating new skills |
+| `jsdoc-best-practices` | JSDoc documentation standards |
 
 See each skill's `SKILL.md` for detailed documentation.
 
@@ -141,31 +162,36 @@ See each skill's `SKILL.md` for detailed documentation.
 
 ### Adding Custom Skills
 
+Skills contain implementation logic and use hyphen-separated naming:
+
 ```bash
-mkdir -p .claude/skills/my-skill
-cat > .claude/skills/my-skill/SKILL.md << 'EOF'
-# My Skill
+mkdir -p .claude/skills/my-namespace-my-skill
+cat > .claude/skills/my-namespace-my-skill/SKILL.md << 'EOF'
+---
+name: my-namespace-my-skill
+description: "What this skill does"
+---
 
-## When to Use
-- Situation 1
-- Situation 2
+# My Skill
 
-## Instructions
-Step-by-step guidance...
+Instructions for the skill...
 EOF
 ```
 
 ### Adding Custom Commands
 
+Commands are user-facing pass-throughs to skills. Directory nesting creates colon-separated names in the UI (e.g., `my-namespace/my-skill.md` becomes `/my-namespace:my-skill`):
+
 ```bash
-mkdir -p .claude/commands/my-category
-cat > .claude/commands/my-category/my-command.md << 'EOF'
+mkdir -p .claude/commands/my-namespace
+cat > .claude/commands/my-namespace/my-skill.md << 'EOF'
 ---
-name: my-command
-description: What this command does
+description: "What this command does"
+allowed-tools: ["Skill"]
+argument-hint: "<arguments>"
 ---
 
-Instructions for the command...
+Use the /my-namespace-my-skill skill to do the thing. $ARGUMENTS
 EOF
 ```
 
@@ -201,8 +227,8 @@ EOF
 2. Check marketplace access if using marketplace plugins
 3. Review Claude Code logs for plugin errors
 
-### Commands Not Found
+### Skills Not Found
 
-1. Ensure command file has correct frontmatter format
-2. Restart Claude Code to reload commands
-3. Check for syntax errors in command definition
+1. Ensure skill directory contains a `SKILL.md` file with correct frontmatter
+2. Restart Claude Code to reload skills
+3. Check for syntax errors in skill definition

package/all/copy-overwrite/.claude/commands/jira/sync.md

@@ -0,0 +1,7 @@
+---
+description: "Sync plan progress to a linked JIRA ticket"
+allowed-tools: ["Skill"]
+argument-hint: "<ticket-id>"
+---
+
+Use the /jira-sync skill to sync plan progress to the linked JIRA ticket. $ARGUMENTS

package/all/copy-overwrite/.claude/commands/plan/add-test-coverage.md

@@ -2,7 +2,6 @@
 description: "Increase test coverage to a specified threshold percentage"
 allowed-tools: ["Skill"]
 argument-hint: "<threshold-percentage>"
-
 ---
 
 Use the /plan-add-test-coverage skill to increase test coverage. $ARGUMENTS

package/all/copy-overwrite/.claude/commands/plan/create.md

@@ -1,6 +1,6 @@
 ---
-description: "Creates an implementation plan for the given prompt"
-argument-hint: "[request]"
+description: "Creates an implementation plan from a ticket URL, file path, or text description"
+argument-hint: "<ticket-url | @file-path | description>"
 ---
 
-Use plan mode to create a plan for $ARGUMENTS
+Use the /plan-create skill to create an implementation plan for $ARGUMENTS

package/all/copy-overwrite/.claude/commands/plan/fix-linter-error.md

@@ -2,7 +2,6 @@
 description: "Fix all violations of one or more ESLint rules across the codebase"
 allowed-tools: ["Skill"]
 argument-hint: "<rule-1> [rule-2] [rule-3] ..."
-
 ---
 
 Use the /plan-fix-linter-error skill to fix linter errors. $ARGUMENTS

package/all/copy-overwrite/.claude/commands/plan/implement.md

@@ -1,6 +1,6 @@
 ---
 description: "Implement a plan"
-argument-hint: "[plan-file]"
+argument-hint: "<plan-file>"
 ---
 
-Implement the requirements in $ARGUMENTS
+Use the /plan-implement skill to implement the plan. $ARGUMENTS

package/all/copy-overwrite/.claude/commands/plan/reduce-max-lines-per-function.md

@@ -2,7 +2,6 @@
 description: "Reduce max lines per function threshold and fix violations"
 allowed-tools: ["Skill"]
 argument-hint: "<max-lines-per-function-value>"
-
 ---
 
 Use the /plan-reduce-max-lines-per-function skill to reduce max function lines. $ARGUMENTS

package/all/copy-overwrite/.claude/commands/plan/reduce-max-lines.md

@@ -2,7 +2,6 @@
 description: "Reduce max file lines threshold and fix violations"
 allowed-tools: ["Skill"]
 argument-hint: "<max-lines-value>"
-
 ---
 
 Use the /plan-reduce-max-lines skill to reduce max lines. $ARGUMENTS

package/all/copy-overwrite/.claude/commands/security/zap-scan.md

@@ -0,0 +1,6 @@
+---
+description: "Run an OWASP ZAP baseline security scan locally using Docker"
+allowed-tools: ["Skill"]
+---
+
+Use the /security-zap-scan skill to run an OWASP ZAP baseline security scan.

package/all/copy-overwrite/.claude/hooks/ticket-sync-reminder.sh

@@ -0,0 +1,20 @@
+#!/usr/bin/env bash
+# Ticket sync reminder hook
+# Runs on TaskUpdate to remind about updating linked tickets
+# Non-blocking (exit 0) - this is a reminder, not enforcement
+
+PLANS_DIR="${CLAUDE_PROJECT_DIR}/plans"
+
+# Find the active plan file (most recently modified .md in plans/)
+ACTIVE_PLAN=$(find "$PLANS_DIR" -maxdepth 1 -name "*.md" -type f 2>/dev/null | head -1)
+
+if [ -z "$ACTIVE_PLAN" ]; then
+  exit 0
+fi
+
+# Check if the plan contains a ticket URL (JIRA, Linear, GitHub Issues)
+if grep -qiE "(https?://.*(atlassian|jira|linear|github\.com/.*/issues))" "$ACTIVE_PLAN" 2>/dev/null; then
+  echo "REMINDER: This plan is linked to a ticket. Consider running /jira:sync to update the ticket with current progress."
+fi
+
+exit 0

package/all/copy-overwrite/.claude/rules/lisa.md

@@ -26,7 +26,7 @@ The following files are managed by Lisa and will be overwritten on every `lisa`
 - `tsconfig.base.json`, `tsconfig.typescript.json`, `tsconfig.expo.json`, `tsconfig.nestjs.json`, `tsconfig.cdk.json`
 - `tsconfig.eslint.json`, `tsconfig.build.json`, `tsconfig.spec.json`
 - `eslint-plugin-code-organization/*`, `eslint-plugin-component-structure/*`, `eslint-plugin-ui-standards/*`
-- `.claude/settings.json`, `.claude/hooks/*`, `.claude/skills/*`, `.claude/commands/*`, `.claude/agents/*`
+- `.claude/settings.json`, `.claude/hooks/*`, `.claude/skills/*` (hyphen-named, e.g. `plan-create`), `.claude/commands/*`, `.claude/agents/*`
 - `.claude/README.md`, `.claude/REFERENCE.md`
 - `.github/workflows/quality.yml`, `.github/workflows/release.yml`, `.github/workflows/claude.yml`
 - `.github/workflows/build.yml`, `.github/workflows/lighthouse.yml` (Expo)

package/all/copy-overwrite/.claude/rules/plan.md

@@ -1,46 +1,88 @@
 # Plan Mode Rules
 
-These rules are enforced whenever Claude is in plan mode. They are loaded at session start via `.claude/rules/` and reinforced on every prompt via the `enforce-plan-rules.sh` `UserPromptSubmit` hook.
+These rules are enforced whenever Claude is in plan mode. Loaded at session start via `.claude/rules/` and reinforced on every prompt via the `enforce-plan-rules.sh` `UserPromptSubmit` hook.
 
 ## Required Behaviors
 
 When making a plan:
 
-- Always determine which skills should be used during execution of the plan and include them in the plan
-- Always make sure you understand the correct versions of third party libraries
-- Always look for code that can be reused for implementation
-- The plan MUST include written instructions to create a task list using TaskCreate for each task (following the Task Creation Specification below). The list should contain items related to the plan and specify that subagents should handle as many in parallel as possible. The following should always be included in the task list:
-  - (unless the plan includes only trivial changes) a task to be run after implementation to review the code with CodeRabbit
-  - (unless the plan includes only trivial changes) a task to be run after implementation to review the code with /plan-local-code-review
-  - (unless the plan includes only trivial changes) a task to be run after all code review to implement valid review suggestions
-  - (unless the plan includes only trivial changes) a task to be run after code review implementation to simplify the implemented code with code simplifier agent
-  - (unless the plan includes only trivial changes) a task to be run after code review implementation to update/add/remove tests, containing the tests that need to get updated, added or removed
-  - (unless the plan includes only trivial changes) a task to be run after code review implementation to update/add/remove documentation (jsdocs, markdown files, etc), containing the documentation that need to get updated, added or removed
-  - (unless the plan includes only trivial changes) a task to be run after code review implementation to verify all of the verification metadata in existing tasks
-  - a task to be run after all other tasks have been completed to archive the plan. This task should explcitly say to:
-    - create a folder named <plan-name> in ./plans/completed
-    - rename this plan to a name befitting the actual plan contents
-    - move it into ./plans/completed/<plan-name>
-    - read the session ids from ./plans/completed/<plan-name>
-    - For each session id, move the ~/.claude/tasks/<session-id> directory to ./plans/completed/<plan-name>/tasks
-    - Update any "in_progress" task in ./plans/completed/<plan-name>/tasks to "completed"
-    - commit changes.
-    - push changes to the PR
-- If you're on a protected branch (dev, staging, main), create a new branch named based on the nature of the project and include in the plan pull requests should go to the protected branch you bracnehd from. 
-- If you're on a non-protected branch with an open pull request, submit pushes to the open pull request
-- If you're on a non-protected branch with no existing PR, clarify which protected branch to open the pull request to. 
-- If referencing a ticket (jira, linear, etc), always include the ticket url in your plan
-- If referencing a ticket (jira, linear, etc), always update the ticket with the branch you're working off of
-- If referencing a ticket (jira, linear, etc), always add a comment to the ticket with the finalized plan
+- Determine which skills are needed and include them in the plan
+- Verify correct versions of third-party libraries
+- Look for reusable code
+- If a decision is left unresolved by the human, use the recommended option
+- The plan MUST include TaskCreate instructions for each task (following the Task Creation Specification below). Specify that subagents should handle as many tasks in parallel as possible.
+
+### Required Tasks
+
+The following tasks are always required unless the plan includes only trivial changes:
+
+- Product/UX review using `product-reviewer` agent (validate feature works from a non-technical perspective)
+- CodeRabbit code review
+- Local code review via `/plan-local-code-review`
+- Technical review using `tech-reviewer` agent (beginner-friendly; correctness, security, performance)
+- Implement valid review suggestions (run after all reviews complete)
+- Simplify code using code simplifier agent (run after review implementation)
+- Update/add/remove tests as needed (run after review implementation)
+- Update/add/remove documentation -- JSDoc, markdown files, etc. (run after review implementation)
+- Verify all verification metadata in existing tasks (run after review implementation)
+- Collect learnings using `learner` agent (run after all reviews and simplification)
+
+The following task is always required regardless of plan size:
+
+- Archive the plan (run after all other tasks). This task must explicitly say to:
+  - Create a folder named `<plan-name>` in `./plans/completed`
+  - Rename the plan to reflect its actual contents
+  - Move it into `./plans/completed/<plan-name>`
+  - Read session IDs from `./plans/completed/<plan-name>`
+  - Move each `~/.claude/tasks/<session-id>` directory to `./plans/completed/<plan-name>/tasks`
+  - Update any "in_progress" task to "completed"
+  - Commit and push changes to the PR
+
+### Branch and PR Rules
+
+- On a protected branch (dev, staging, main): create a new branch and target the PR to the protected branch you branched from
+- On a non-protected branch with an open PR: push to the existing PR
+- On a non-protected branch with no PR: clarify which protected branch to target
 - Open a draft pull request
-- Include the branch name and pull request in the plan
+- Include the branch name and PR link in the plan
 
-IMPORTANT:
-- The `## Sessions` section in plan files is auto-maintained by the `track-plan-sessions.sh` hook — do not manually edit it
+### Ticket Integration
 
-## Task Creation Specification
+When referencing a ticket (JIRA, Linear, etc.):
+
+- Include the ticket URL in the plan
+- Update the ticket with the working branch
+- Add a comment on the ticket with the finalized plan
+
+NOTE: Do NOT include a separate task for linting, type-checking, or formatting. These are handled automatically by PostToolUse hooks (lint-on-edit.sh, format-on-edit.sh) and lint-staged pre-commit hooks (ESLint, Prettier, ast-grep).
+
+IMPORTANT: The `## Sessions` section in plan files is auto-maintained by `track-plan-sessions.sh` -- do not manually edit it.
+
+## Git Workflow
+
+Every plan follows this workflow to keep PRs clean:
+
+1. **First task:** Verify/create branch and open a draft PR (`gh pr create --draft`). No implementation before the draft PR exists.
+2. **During implementation:** Commits only, no pushes. Pre-commit hooks validate lint, format, and typecheck.
+3. **After archive task:** One final `git push`, then mark PR ready (`gh pr ready`), then enable auto-merge (`gh pr merge --auto --merge`).
+
+## Implementation Team Guidance
+
+When plans spawn an Agent Team for implementation, recommend these specialized agents:
+
+| Agent | Use For | Why |
+|-------|---------|-----|
+| `implementer` | Code implementation | Pre-loaded with project conventions, empirical verification |
+| `tech-reviewer` | Technical review | Beginner-friendly findings; covers correctness, security, performance |
+| `product-reviewer` | Product/UX review | Validates from non-technical perspective; runs feature empirically |
+| `learner` | Post-implementation learning | Processes task learnings through `skill-evaluator` to create skills, add rules, or discard |
+| `test-coverage-agent` | Writing tests | Specialized for comprehensive, meaningful test coverage |
+| `code-simplifier` (plugin) | Code simplification | Simplifies and refines for clarity and maintainability |
+| `coderabbit` (plugin) | CodeRabbit review | Automated AI code review |
 
-When plans include TaskCreate instructions, each task must use this format:
+The **team lead** handles git operations (commits, pushes, PR management) -- teammates focus on their specialized work.
+
+## Task Creation Specification
 
 ### Parameters
 
@@ -55,19 +97,41 @@ Every task description must be a markdown document with these sections:
 
 **Description:** Clear description based on type (Bug: symptoms/root cause; Story: Gherkin Given/When/Then; Task: clear goal; Epic: goal with sub-tasks)
 
+### Type-Specific Requirements
+
+When the plan type is determined, apply the corresponding requirements:
+
+#### Bug
+- **Replication step** (mandatory): Reproduce the bug empirically before any fix
+- **Root cause analysis**: Identify why the bug occurs
+- **Regression test**: Write a test that fails without the fix and passes with it
+- **Verification**: Run the replication step again to confirm the fix
+
+#### Story/Feature
+- **UX review**: Product-reviewer agent validates from user perspective
+- **Feature flag consideration**: Should this be behind a flag?
+- **Documentation**: User-facing docs if applicable
+
+#### Task
+- **Standard implementation** with empirical verification
+
+#### Epic
+- **Decompose into sub-tasks** (Stories/Tasks/Bugs)
+- **Each sub-task gets its own type-specific requirements**
+
 **Acceptance Criteria:** Checkbox list of completion criteria
 
-**Relevant Research:** Code references, patterns, architecture constraints extracted from research
+**Relevant Research:** Code references, patterns, architecture constraints
 
-**Skills to Invoke:** `/coding-philosophy` is always required, plus other applicable skills
+**Skills to Invoke:** List applicable skills (coding-philosophy is auto-loaded as a rule)
 
 **Implementation Details:** Files to modify, functions to implement, edge cases
 
-**Testing Requirements:** Unit tests (with `describe/it` structure), Integration tests, E2E tests (or "N/A")
+**Testing Requirements:** Unit tests (with `describe/it` structure), integration tests, E2E tests (or "N/A")
 
 **Verification:** Every task MUST have empirical verification (see `verfication.md` for types). Include: verification type, proof command, and expected output.
 
-**Learnings:** On task completion, use `TaskUpdate` to save discoveries: `metadata: { learnings: ["Learning 1", ...] }`
+**Learnings:** On completion, use `TaskUpdate` to save discoveries: `metadata: { learnings: ["Learning 1", ...] }`
 
 ### Metadata
 
@@ -75,7 +139,7 @@ Every task description must be a markdown document with these sections:
 {
   "plan": "<plan-name>",
   "type": "bug|task|epic|story",
-  "skills": ["/coding-philosophy", ...],
+  "skills": ["..."],
   "verification": {
     "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
     "command": "the proof command",
@@ -87,5 +151,3 @@ Every task description must be a markdown document with these sections:
 ### Task Sizing
 
 Each task must be small enough to have a **single, specific verification**. Ask: "Can I prove this is done with ONE command?" Split tasks that require multiple verifications.
-
-

package/all/copy-overwrite/.claude/rules/verfication.md

@@ -1,6 +1,6 @@
 # Empirical Verification
 
-Every task requires a **proof command** - a single command that empirically demonstrates the work is done.
+Every task and plan requires a **proof command** - a single command that empirically demonstrates the work is done.
 
 ## Core Principle
 
@@ -13,7 +13,7 @@ Never assume something works because the code "looks correct." Run a command, ob
 | `test` | Unit/integration tests | `npm test -- path/to/file.spec.ts` |
 | `api-test` | API endpoints | `curl -s localhost:3000/api/endpoint` |
 | `test-coverage` | Coverage thresholds | `npm run test:cov -- --collectCoverageFrom=...` |
-| `ui-recording` | UI changes | Playwright/Cypress test |
+| `ui-recording` | UI changes | Start local server; recorded session with Playwright/Maestro/Chrome Browser  |
 | `documentation` | Doc changes | `grep "expected" path/to/doc.md` |
 | `manual-check` | Config/setup | `cat config.json \| jq '.setting'` |
 
@@ -23,6 +23,7 @@ Never assume something works because the code "looks correct." Run a command, ob
 2. **Compare output** to expected result
 3. **If verification fails**: Fix and re-run, don't mark complete
 4. **If verification blocked** (missing Docker, services, etc.): Mark as blocked, not complete
+5. **Must not be dependent on CI/CD** if necessary, you may use local deploy methods found in `package.json`, but the verification methods must be listed in the pull request and therefore cannot be dependent on CI/CD completing
 
 ## Example
 

package/all/copy-overwrite/.claude/settings.json

@@ -50,6 +50,11 @@
             "type": "command",
             "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/sync-tasks.sh",
             "timeout": 10
+          },
+          {
+            "type": "command",
+            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/ticket-sync-reminder.sh",
+            "timeout": 5
           }
         ]
       }

package/all/copy-overwrite/.claude/skills/git-commit/SKILL.md

@@ -2,7 +2,6 @@
 name: git-commit
 description: This skill should be used when creating conventional commits for current changes. It groups related changes into logical commits, ensures all files are committed, and verifies the working directory is clean afterward.
 allowed-tools: ["Bash"]
-argument-hint: "[commit-message-hint]"
 ---
 
 # Git Commit Workflow

package/all/copy-overwrite/.claude/skills/git-commit-and-submit-pr/SKILL.md

@@ -1,8 +1,7 @@
 ---
 name: git-commit-and-submit-pr
-description: This skill should be used when creating conventional commits for current changes and then submitting the current branch as a pull request for code review. It combines the git-commit and git-submit-pr skills into a single workflow.
+description: This skill should be used when creating conventional commits for current changes and then submitting the current branch as a pull request for code review. It combines the git:commit and git:submit-pr skills into a single workflow.
 allowed-tools: ["Bash"]
-argument-hint: "[commit-message-hint]"
 ---
 
 1. Run /git-commit $ARGUMENTS

package/all/copy-overwrite/.claude/skills/git-submit-pr/SKILL.md

@@ -2,7 +2,6 @@
 name: git-submit-pr
 description: This skill should be used when pushing changes and creating or updating a pull request. It verifies the branch state, pushes to remote, creates or updates a PR with a comprehensive description, and enables auto-merge.
 allowed-tools: ["Bash", "mcp__github__create_pull_request", "mcp__github__get_pull_request", "mcp__github__update_pull_request"]
-argument-hint: "[pr-title-or-description-hint]"
 ---
 
 # Submit Pull Request Workflow

package/all/copy-overwrite/.claude/skills/jira-create/SKILL.md

@@ -2,7 +2,6 @@
 name: jira-create
 description: This skill should be used when creating JIRA epics, stories, and tasks from code files or descriptions. It analyzes the provided input, determines the appropriate issue hierarchy, and creates issues with comprehensive quality requirements including test-first development and documentation.
 allowed-tools: ["Read", "Glob", "LS", "mcp__atlassian__createJiraIssue", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
-argument-hint: "<file-or-directory-path> [project-key]"
 ---
 
 # Create JIRA Issues from $ARGUMENTS

package/all/copy-overwrite/.claude/skills/jira-sync/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: jira-sync
+description: "Syncs plan progress to a linked JIRA ticket. Posts plan contents, progress updates, branch links, and PR links at key milestones. Use this skill throughout the plan lifecycle to keep tickets in sync."
+allowed-tools: ["mcp__atlassian__*", "Bash", "Read", "Glob", "Grep"]
+---
+
+# JIRA Ticket Sync
+
+Sync current plan progress to JIRA ticket: $ARGUMENTS
+
+If no argument provided, search for a ticket URL in the active plan file (most recently modified `.md` in `plans/`).
+
+## Workflow
+
+### Step 1: Identify Ticket and Context
+
+1. **Parse ticket ID** from `$ARGUMENTS` or extract from the active plan file
+2. **Fetch current ticket state** via JIRA MCP (`mcp__atlassian__getJiraIssue`)
+3. **Determine current milestone** by checking:
+   - Does a plan file exist? → Plan created
+   - Is there a working branch? → Implementation started
+   - Are tasks in progress? → Active implementation
+   - Is there an open PR? → PR ready for review
+   - Is the PR merged? → Complete
+
+### Step 2: Gather Update Content
+
+Based on the current milestone:
+
+| Milestone | Content to Post |
+|-----------|-----------------|
+| **Plan created** | Plan summary, branch name, link to PR (if draft exists) |
+| **Implementation in progress** | Task completion summary (X of Y tasks done), any blockers |
+| **PR ready** | PR link, summary of changes, test results |
+| **PR merged** | Final summary, suggest moving ticket to "Done" |
+
+### Step 3: Post Update
+
+1. **Add a comment** to the ticket with the gathered content via JIRA MCP
+2. **Update ticket fields** if applicable:
+   - Add branch name to a custom field or comment
+   - Add PR link to a custom field or comment
+3. **Report** what was synced to the user
+
+### Step 4: Suggest Status Transition
+
+Based on the milestone, suggest (but don't automatically perform) a status transition:
+
+| Milestone | Suggested Status |
+|-----------|-----------------|
+| Plan created | "In Progress" |
+| PR ready | "In Review" |
+| PR merged | "Done" |
+
+## Important Notes
+
+- **Never auto-transition ticket status** — always suggest and let the user confirm
+- **Idempotent updates** — running sync multiple times at the same milestone should not create duplicate comments
+- **Comment format** — use JIRA markdown with clear headers and bullet points
+
+## Execution
+
+Sync the ticket now.

package/all/copy-overwrite/.claude/skills/jira-verify/SKILL.md

@@ -2,7 +2,6 @@
 name: jira-verify
 description: This skill should be used when verifying that a JIRA ticket meets organizational standards for epic relationships and description quality. It checks epic parent relationships and validates description completeness for coding assistants, developers, and stakeholders.
 allowed-tools: ["mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
-argument-hint: "<TICKET-ID>"
 ---
 
 # Verify JIRA Ticket: $ARGUMENTS

package/all/copy-overwrite/.claude/skills/lisa-review-implementation/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: lisa-review-implementation
 description: This skill should be used when comparing a project's Lisa-managed files against Lisa's source templates to identify drift. It reads the project manifest, locates source templates, generates diffs for drifted files, and offers to upstream improvements back to Lisa.
-argument-hint: "[lisa-dir]"
 ---
 
 # Lisa Implementation Review