@codyswann/lisa 1.66.3 → 1.67.1

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

@@ -0,0 +1,137 @@
+Requirement Verification:
+
+Never assume the person providing instructions has given you complete, correct, or technically precise requirements. Treat every request as potentially underspecified. Before starting any work:
+
+1. Verify the request is specific enough to produce a verifiable outcome. If it is not, stop and ask for clarification.
+2. Verify you can empirically prove the work is done when complete (e.g. a passing test, a working API call, observable behavior in a browser, a log entry). If you cannot define how to prove it, stop and ask for clarification.
+3. If a request contradicts existing code, architecture, or conventions, do not silently comply. Raise the contradiction and confirm intent before proceeding.
+
+DO NOT START WORK if any of the above are unclear. Asking a clarifying question is always cheaper than implementing the wrong thing.
+
+Project Discovery:
+- Determine the project's package manager before installing or running anything.
+- Read the project manifest (e.g. package.json, pyproject.toml, Cargo.toml, go.mod) to understand available scripts and dependencies.
+- Read the project's linting and formatting configuration to understand its standards.
+- Regenerate the lockfile after adding, removing, or updating dependencies.
+- Ignore build output directories (dist, build, out, target, etc.) unless specified otherwise.
+- Ignore configuration linter hints/warnings — only fix actual unused exports/dependencies reported as errors.
+
+Code Quality:
+- Make atomic commits with clear conventional commit messages.
+- Create clear documentation preambles for new code. Update preambles when modifying existing code.
+- Document the "why", not the "what". Code explains what it does; documentation explains why it exists.
+- Add language specifiers to fenced code blocks in Markdown.
+- Use project-relative paths rather than absolute paths in documentation and Markdown.
+- Delete old code completely when replacing it. No deprecation unless specifically requested.
+- Fix bugs and issues properly. Never cover them up or work around them.
+- Test empirically to confirm something worked. Never assume.
+- Never assume test expectations before verifying actual implementation behavior. Run tests to learn the behavior, then adjust expectations to match.
+- Always provide a solution. Never dismiss something as "not related to our changes" or "not relevant to this task".
+
+Git Discipline:
+- Prefix git push with `GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5"`.
+- Never commit directly to an environment branch (dev, staging, main).
+- Never use --no-verify or attempt to bypass a git hook.
+- Never stash changes you cannot commit. Either fix whatever is preventing the commit or fail out and let the human know why.
+- Never add "BREAKING CHANGE" to a commit message unless there is actually a breaking change.
+- When opening a PR, watch the PR. If any status checks fail, fix them. For all bot code reviews, if the feedback is valid, implement it and push the change to the PR. Then resolve the feedback. If the feedback is not valid, reply to the feedback explaining why it's not valid and then resolve the feedback. Do this in a loop until the PR is able to be merged and then merge it.
+- When merging a PR into an environment branch (dev, staging, main), watch the resultant deploy until it fully succeeds. If it fails for any reason, fix the failure and then open a new PR with the fix.
+- When referencing a PR in a response, always include the url
+
+Testing Discipline:
+- Never skip or disable any tests or quality checks.
+- Never add skip directives to a test unless explicitly asked to.
+- Never lower thresholds to pass a pre-push hook. Increase test coverage to make it pass.
+- Never duplicate test helper functions without appropriate lint suppression when duplication is intentional for test isolation.
+
+JIRA Discipline:
+- If working on a JIRA issue, make sure the branch you're working on references and is added to the JIRA issue.
+- If working on a JIRA issue, update the issue as you work through it. For example, if working on a Bug Triage, update the issue with your questions/feedback/suggestions.
+
+Agent Behavior:
+- Never handle tasks yourself when working in a team of agents. Always delegate to a specialized agent.
+
+NEVER:
+- Modify this file directly. To add a memory or learning, use the project's rules file or create a skill.
+- Directly modify files inside dependency directories (e.g. node_modules, .venv, vendor, target).
+- Delete anything that is not tracked in git.
+- Delete anything outside of this project's directory.
+- Create placeholder implementations.
+- Create TODOs.
+- Create versioned copies of files or functions (e.g. V2, Optimized, processNew, handleOld).
+- Write migration code unless explicitly requested.
+- Write functions or methods unless they are needed.
+- Write unhelpful comments like "removed code" or "old implementation".
+- Update CHANGELOG.
+
+ASK FIRST:
+- Before adding a lint suppression comment (e.g. eslint-disable, noqa, #[allow(...)], @SuppressWarnings). These should be a last resort.
+- Before adding a type-checking suppression comment (e.g. ts-ignore, ts-expect-error, ts-nocheck, type: ignore).
+- Lint suppression in test files is acceptable without asking only when comprehensive test coverage requires it (e.g. file length limits) or when intentional duplication improves test isolation. Include matching re-enable comments where applicable.
+
+Bug Triage:
+
+1. Verify you have all information needed to reproduce the bug (authentication requirements, environment information, etc.). Do not make assumptions. If anything is missing, stop and ask before proceeding.
+2. Reproduce the bug. If you cannot reproduce it, stop and report what you tried and what you observed.
+3. Once reproduced, verify you are 100% positive on how to fix it. If not, determine what you need to do to be 100% positive (e.g. add logging, trace the code path, inspect state) and do that first.
+4. Verify you have access to the tools, environments, and permissions needed to deploy and verify this fix (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 starting implementation.
+5. Define the tests you will write to confirm the fix and prevent a regression.
+6. Define the documentation you will create or update to explain this bug so another developer understands the "how" and "what" behind it.
+7. If you can verify your fix before deploying to the target environment (e.g. start the app, invoke the API, open a browser, run the process, check logs), do so before deploying.
+8. Define how you will verify the fix beyond a shadow of a doubt (e.g. deploy to the target environment, invoke the API, open a browser, run the process, check logs).
+
+Bug Implementation:
+
+1. Use the output of Bug Triage as your guide. Do not skip triage.
+
+Task Triage:
+
+1. Verify you have all information needed to implement this task (acceptance criteria, design specs, environment information, dependencies, etc.). Do not make assumptions. If anything is missing, stop and ask before proceeding.
+2. Verify you have a clear understanding of the expected behavior or outcome when the task is complete. If not, stop and clarify before starting.
+3. Identify all dependencies (other tasks, services, APIs, data) that must be in place before you can complete this task. If any are unresolved, stop and raise them before starting implementation.
+4. Verify you have access to the tools, environments, and permissions needed to deploy and verify this task (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 starting implementation.
+5. Define the tests you will write to confirm the task is implemented correctly and prevent regressions.
+6. Define the documentation you will create or update to explain the "how" and "what" behind this task so another developer understands it.
+7. If you can verify your implementation before deploying to the target environment (e.g. start the app, invoke the API, open a browser, run the process, check logs), do so before deploying.
+8. Define how you will verify the task is complete beyond a shadow of a doubt (e.g. deploy to the target environment, invoke the API, open a browser, run the process, check logs).
+
+Task Implementation:
+
+1. Use the output of Task Triage as your guide. Do not skip triage.
+
+Epic Triage:
+
+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).
+
+Epic Implementation:
+
+1. Use the output of Epic Triage 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.
+
+Multi-Repository Awareness:
+
+When working in a microservices architecture, the code you need may span multiple repositories. Watch for these signals that you're missing context:
+
+1. Import paths or package references that don't resolve in the current repository
+2. API calls to internal services where you can't find the contract, schema, or handler
+3. Shared libraries, SDKs, or proto/OpenAPI definitions referenced but not present
+4. Environment variables or config referencing service names you don't have code for
+5. Error messages or stack traces pointing to code outside the current repo
+6. JIRA issues or documentation referencing components in other repositories
+
+When you detect any of the above:
+1. Do NOT guess or make assumptions about what the external code does
+2. Identify which repository contains the missing code
+3. Add that repository to your current session before proceeding
+4. If you cannot determine which repository contains the code, ask — do not proceed without it

package/nestjs/package-lisa/package.lisa.json

@@ -33,7 +33,7 @@
       "security:zap": "bash scripts/zap-baseline.sh",
       "test": "vitest run",
       "test:unit": "vitest run --exclude='**/integration/**'",
-      "test:integration": "vitest run tests/integration --passWithNoTests",
+      "test:integration": "vitest run '.integration.' --passWithNoTests",
       "test:cov": "vitest run --coverage",
       "test:watch": "vitest"
     },

package/package.json

@@ -74,7 +74,7 @@
     "flatted": "^3.4.2"
   },
   "name": "@codyswann/lisa",
-  "version": "1.66.3",
+  "version": "1.67.1",
   "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,21 +1,12 @@
 {
   "name": "lisa",
-  "version": "1.66.3",
+  "version": "1.67.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"
   },
   "hooks": {
     "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "find ${CLAUDE_PLUGIN_ROOT}/rules -name '*.md' -exec cat {} \\;"
-          }
-        ]
-      },
       {
         "matcher": "",
         "hooks": [

package/plugins/lisa/agents/verification-specialist.md

@@ -8,7 +8,7 @@ tools: Read, Write, Edit, Bash, Grep, Glob
 
 You are a verification specialist. Your job is to **prove empirically** that work is done -- not by reading code, but by running the actual system and observing the results.
 
-Read `.claude/rules/verfication.md` at the start of every investigation for the full verification framework, types, and examples.
+Read `.claude/rules/verification.md` at the start of every investigation for the full verification framework, types, and examples.
 
 ## Core Philosophy
 

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

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

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

@@ -1,21 +1,9 @@
 {
   "name": "lisa-expo",
-  "version": "1.66.3",
+  "version": "1.67.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"
   },
-  "hooks": {
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "find ${CLAUDE_PLUGIN_ROOT}/rules -name '*.md' -exec cat {} \\;"
-          }
-        ]
-      }
-    ]
-  }
+  "hooks": {}
 }

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

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

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

@@ -1,22 +1,11 @@
 {
   "name": "lisa-rails",
-  "version": "1.66.3",
+  "version": "1.67.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"
   },
   "hooks": {
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "find ${CLAUDE_PLUGIN_ROOT}/rules -name '*.md' -exec cat {} \\;"
-          }
-        ]
-      }
-    ],
     "PostToolUse": [
       {
         "matcher": "Write|Edit",

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

@@ -1,22 +1,11 @@
 {
   "name": "lisa-typescript",
-  "version": "1.66.3",
+  "version": "1.67.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"
   },
   "hooks": {
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "find ${CLAUDE_PLUGIN_ROOT}/rules -name '*.md' -exec cat {} \\;"
-          }
-        ]
-      }
-    ],
     "PostToolUse": [
       {
         "matcher": "Write|Edit",

package/plugins/src/base/.claude-plugin/plugin.json

@@ -5,15 +5,6 @@
   "author": { "name": "Cody Swann" },
   "hooks": {
     "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "find ${CLAUDE_PLUGIN_ROOT}/rules -name '*.md' -exec cat {} \\;"
-          }
-        ]
-      },
       {
         "matcher": "",
         "hooks": [

package/plugins/src/base/agents/verification-specialist.md

@@ -8,7 +8,7 @@ tools: Read, Write, Edit, Bash, Grep, Glob
 
 You are a verification specialist. Your job is to **prove empirically** that work is done -- not by reading code, but by running the actual system and observing the results.
 
-Read `.claude/rules/verfication.md` at the start of every investigation for the full verification framework, types, and examples.
+Read `.claude/rules/verification.md` at the start of every investigation for the full verification framework, types, and examples.
 
 ## Core Philosophy
 

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

@@ -3,17 +3,6 @@
   "version": "1.0.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": { "name": "Cody Swann" },
-  "hooks": {
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "find ${CLAUDE_PLUGIN_ROOT}/rules -name '*.md' -exec cat {} \\;"
-          }
-        ]
-      }
-    ]
-  }
+  "hooks": {}
+
 }

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

@@ -4,17 +4,6 @@
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": { "name": "Cody Swann" },
   "hooks": {
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "find ${CLAUDE_PLUGIN_ROOT}/rules -name '*.md' -exec cat {} \\;"
-          }
-        ]
-      }
-    ],
     "PostToolUse": [
       {
         "matcher": "Write|Edit",

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

@@ -4,17 +4,6 @@
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": { "name": "Cody Swann" },
   "hooks": {
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "find ${CLAUDE_PLUGIN_ROOT}/rules -name '*.md' -exec cat {} \\;"
-          }
-        ]
-      }
-    ],
     "PostToolUse": [
       {
         "matcher": "Write|Edit",

package/typescript/package-lisa/package.lisa.json

@@ -6,7 +6,6 @@
       "format": "prettier --check . --write",
       "test": "vitest run",
       "test:unit": "vitest run --exclude='**/integration/**'",
-      "test:integration": "vitest run tests/integration --passWithNoTests",
       "test:cov": "vitest run --coverage",
       "test:watch": "vitest",
       "lint:fix": "eslint . --fix",
@@ -32,7 +31,8 @@
   "defaults": {
     "scripts": {
       "build": "tsc",
-      "postinstall": "node node_modules/@codyswann/lisa/dist/index.js --yes --skip-git-check . 2>/dev/null || true"
+      "postinstall": "node node_modules/@codyswann/lisa/dist/index.js --yes --skip-git-check . 2>/dev/null || true",
+      "test:integration": "vitest run tests/integration --passWithNoTests"
     },
     "engines": {
       "npm": "please-use-bun",

package/plugins/lisa/rules/README.md

@@ -1,240 +0,0 @@
-# Claude Code Configuration
-
-This directory contains Claude Code configuration files that customize AI-assisted development workflows.
-
-## Directory Structure
-
-```
-.claude/
-├── settings.json              # Main Claude Code settings
-├── settings.local.json        # Local overrides (gitignored)
-├── settings.local.json.example # Template for local settings
-├── agents/                    # Custom agent definitions
-├── hooks/                     # Automation hooks
-├── rules/                     # Always-on governance rules
-└── skills/                    # Skill definitions (colon-namespaced)
-```
-
-## Settings
-
-### Environment Variables
-
-| Variable | Default | Description |
-|----------|---------|-------------|
-| `BASH_DEFAULT_TIMEOUT_MS` | 1800000 (30 min) | Default timeout for bash commands |
-| `BASH_MAX_TIMEOUT_MS` | 7200000 (2 hours) | Maximum allowed timeout |
-
-### Hooks
-
-| Event | Hook | Purpose |
-|-------|------|---------|
-| `SessionStart` | `install-pkgs.sh` | Install dependencies when session starts |
-| `PostToolUse` | `format-on-edit.sh` | Auto-format files after Write/Edit operations |
-| `Notification` | `notify-ntfy.sh` | Send notifications via ntfy.sh |
-| `Stop` | `notify-ntfy.sh` | Notify when session ends |
-
-## Plugins
-
-The `enabledPlugins` section in `settings.json` references Claude Code plugins. These extend Claude Code functionality with additional capabilities.
-
-### Plugin Sources
-
-| Source | Description | Registration |
-|--------|-------------|--------------|
-| `claude-plugins-official` | Official Anthropic plugins | Built-in, no registration needed |
-| `cc-marketplace` | Community marketplace | Available at [Claude Code Marketplace](https://marketplace.claude.ai) |
-
-### Enabled Plugins
-
-| Plugin | Source | Purpose |
-|--------|--------|---------|
-| `typescript-lsp` | `claude-plugins-official` | TypeScript language server integration |
-| `safety-net` | `cc-marketplace` | Backup and safety features |
-| `code-simplifier` | `claude-plugins-official` | Code complexity reduction suggestions |
-| `code-review` | `claude-plugins-official` | Automated code review capabilities |
-| `playwright` | `claude-plugins-official` | Playwright test integration |
-
-### Installing Plugins
-
-1. **Official plugins** are available by default in Claude Code
-2. **Marketplace plugins** can be installed via the Claude Code settings UI
-3. **Third-party plugins** require following their installation instructions
-
-### Plugin Availability
-
-Not all plugins may be available in all Claude Code installations:
-
-- Some plugins require specific Claude Code versions
-- Marketplace plugins require marketplace access
-- Enterprise installations may restrict available plugins
-
-If a plugin is not available, Claude Code will ignore it gracefully.
-
-## Local Settings Override
-
-Create `settings.local.json` to override settings for your local environment:
-
-```json
-{
-  "env": {
-    "CUSTOM_API_KEY": "your-key-here"
-  },
-  "hooks": {
-    "PostToolUse": []
-  },
-  "enabledPlugins": {
-    "playwright": false
-  }
-}
-```
-
-This file should be:
-- Added to `.gitignore`
-- Never committed to version control
-- Used for machine-specific settings
-
-## Agents
-
-Custom agent definitions in `agents/` provide specialized AI personas for different tasks:
-
-| Agent | Purpose |
-|-------|---------|
-| `agent-architect.md` | Agent file design and optimization |
-| `architecture-specialist.md` | Implementation design, dependency mapping, pattern evaluation |
-| `git-history-analyzer.md` | Git history analysis |
-| `hooks-expert.md` | Claude Code hooks expertise |
-| `implementer.md` | Code implementation with TDD enforcement |
-| `learner.md` | Post-implementation learning and skill creation |
-| `performance-specialist.md` | N+1 queries, algorithmic complexity, memory leaks |
-| `product-specialist.md` | User flows, acceptance criteria, UX validation |
-| `quality-specialist.md` | Code correctness, coding philosophy, test coverage review |
-| `security-specialist.md` | Threat modeling (STRIDE), OWASP Top 10, auth/secrets review |
-| `skill-evaluator.md` | Skill quality assessment |
-| `slash-command-architect.md` | Command design |
-| `test-specialist.md` | Test strategy, test writing, coverage analysis |
-| `web-search-researcher.md` | Web research tasks |
-
-## Skills
-
-Skills use colon-namespaced directories (e.g., `plan:create/`) and are invoked via `/skill-name` in Claude Code.
-
-### Plan 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
-
-| 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 |
-|-------|---------|
-| `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 |
-| `agent-design-best-practices` | Best practices for designing agent files |
-| `jsdoc-best-practices` | JSDoc documentation standards |
-
-See each skill's `SKILL.md` for detailed documentation.
-
-## Customization
-
-### Adding Custom Skills
-
-Skills contain implementation logic and use hyphen-separated naming:
-
-```bash
-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"
----
-
-# My Skill
-
-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-namespace
-cat > .claude/commands/my-namespace/my-skill.md << 'EOF'
----
-description: "What this command does"
-allowed-tools: ["Skill"]
-argument-hint: "<arguments>"
----
-
-Use the /my-namespace-my-skill skill to do the thing. $ARGUMENTS
-EOF
-```
-
-### Adding Custom Agents
-
-```bash
-cat > .claude/agents/my-agent.md << 'EOF'
-# My Agent
-
-## Role
-Specialized for specific tasks...
-
-## Capabilities
-- Capability 1
-- Capability 2
-
-## Instructions
-How to behave...
-EOF
-```
-
-## Troubleshooting
-
-### Hooks Not Running
-
-1. Check file permissions: `chmod +x .claude/hooks/*.sh`
-2. Verify `$CLAUDE_PROJECT_DIR` is set correctly
-3. Check hook timeout settings
-
-### Plugins Not Loading
-
-1. Verify plugin is installed in your Claude Code installation
-2. Check marketplace access if using marketplace plugins
-3. Review Claude Code logs for plugin errors
-
-### Skills Not Found
-
-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