Custom Claude Code plugins for codebase analysis, skill generation, and workflow automation.
Run these commands inside a Claude Code session (they start with /):
/plugin marketplace add slickage/claude-plugins
/plugin install stackgen@slickage
Individual plugins may have additional prerequisites that run in your terminal (e.g.,
brew install). See each plugin's README for details.
Analyzes codebases and generates tailored Claude Code skills. 11 specialized agents with optimized context passing.
- Fast Detection - Single stack-detector (Haiku) analyzes dependencies, configs, structure
- Context Passing - Detector findings passed to analyzers to avoid redundant reads
- Tech Gating - Only spawns analyzers for detected technologies
- 8-File Limits - Each analyzer reads max 8 files for efficiency
| Command | Description |
|---|---|
/stackgen:analyze |
Full codebase analysis and skill generation |
/stackgen:quick |
Quick tech stack overview |
/stackgen:refresh |
Update existing skills |
/stackgen:check |
Audit skills for issues |
Detection (1):
stack-detector- Comprehensive dependency/config/pattern analysis (Haiku)
Core Analyzers (4, always run):
security-analyzer- Security patterns and best practicesarchitecture-analyzer- Code structure and organizationcode-quality-analyzer- Linting, formatting, types, dependenciesperformance-analyzer- Performance optimization
Conditional Analyzers (6, gated by detection):
frontend-analyzer- UI framework patterns (React, Vue, Angular)backend-analyzer- Server patterns (APIs, Server Actions)database-analyzer- ORM/database patternstesting-analyzer- Unit, integration, E2E testsdevops-analyzer- CI/CD, Docker, deploymentmonitoring-analyzer- Logging, error tracking, analytics
.claude/skills/
├── security/
├── architecture/
├── code-quality/
├── performance/
├── frontend/ (if detected)
├── backend/ (if detected)
├── database/ (if detected)
├── testing/ (if detected)
├── devops/ (if detected)
└── monitoring/ (if detected)
Standardizes issue tracking across Linear and Jira. Two skills sharing one provider abstraction: Issue Intake turns requirements into a scaffolded issue with linked sub-issues and BEADS tasks; Issue Lifecycle drives an existing issue from breakdown through implementation to an open PR. BEADS is the source of truth; state syncs one way (BEADS → tracker).
- A tracker MCP: the Linear plugin, or the official Atlassian Remote MCP for Jira (installed + authenticated separately)
- Beads CLI installed (
bdcommand available) - GitHub CLI installed and authenticated (
ghcommand available)
/plugin install issue-lifecycle@slickageNo config file and no persisted state — the skills infer the tracker (Linear vs Jira) and destination (team/project) at runtime from the request, the connected MCP, and the local BEADS db (.beads/) left by prior runs. The BEADS db is the only "memory": a fresh repo (or a wiped .beads/) has nothing to infer from, so Intake asks for team + project; a repo with prior runs reuses that destination silently.
| Skill | Triggers on | Does |
|---|---|---|
| Issue Intake | "turn these requirements into an issue", "scaffold from this PRD" | Creates main issue + 1:1 sub-issues + parent/child BEADS tasks, then offers to hand off |
| Issue Lifecycle | "start ONC-5", "take this issue to a PR", an issue ID | Breakdown (or adopt) → implement every task with a commit each → PR → tracker In Review |
main issue <--1:1--> parent BEADS task (closes last)
sub-issue <--1:1--> child BEADS task claim→In Progress, close→Done
- Resumable single pass — guarded by observable artifacts (branch /
bd list/ taskexternal-ref/gh pr); re-invoke to resume. - Zero mid-run confirmation — autonomous; inspect the scaffold and re-invoke for a review point.
- Adopt human-authored sub-issues 1:1 instead of duplicating; invent a breakdown only when none exist.
- Stop and hold on an unrecoverable test failure — changes kept, task left in-progress, reported.
- Conventional Commits per task; semantic branch from issue label/type (
feat/,fix/,chore/,docs/).
Backlog → In Progress (lifecycle start) → In Review (PR opened) → Done (PR merge)
See the full step-by-step guide for a detailed walkthrough.
stackgen:
- Analyze project:
/stackgen:analyze - Quick context:
/stackgen:quick - After upgrades:
/stackgen:refresh - Maintenance:
/stackgen:check
issue-lifecycle (from requirements):
- Scaffold: "turn these requirements into an issue" → Issue Intake creates the issue + sub-issues + BEADS tasks
- Implement: accept the handoff → Issue Lifecycle runs to an open PR
issue-lifecycle (existing issue):
- Everything: "start ONC-5" → Issue Lifecycle breaks down, implements, and opens the PR in one resumable pass
After cloning the repo, configure Git to use the version-controlled hooks:
git config core.hooksPath bin/hooksThis enables a pre-commit hook that automatically syncs plugin versions from each plugin.json (source of truth) into marketplace.json and README.md.
This section is a comprehensive reference for adding new plugins, slash commands, or agents to this repo. You can paste these instructions into Claude Code to have it build new components for you.
claude-plugins/
├── .claude-plugin/
│ └── marketplace.json # Registry — lists all plugins in this marketplace
├── plugins/
│ └── <plugin-name>/
│ ├── .claude-plugin/
│ │ └── plugin.json # Plugin manifest (name, version, description)
│ ├── README.md # Plugin documentation
│ ├── commands/ # Slash commands (each file = one /command)
│ │ └── <command-name>.md
│ └── agents/ # Subagents (optional, used by commands)
│ └── <agent-name>.md
- Marketplace (
.claude-plugin/marketplace.json) — the top-level registry that tells Claude Code which plugins exist in this repo and where to find them - Plugin (
plugins/<name>/.claude-plugin/plugin.json) — a self-contained package of commands and/or agents - Command (
plugins/<name>/commands/<command>.md) — a markdown file that becomes a/commandthe user can invoke. The filename becomes the command name (e.g.,commit.md→/commit) - Agent (
plugins/<name>/agents/<agent>.md) — a markdown file that defines a subagent. Agents are spawned by commands using the Task tool — they can't be invoked directly by users
This is the simplest contribution. Create a new .md file in the plugin's commands/ directory.
Command file format:
---
description: Short description shown in the command palette
argument-hint: "<REQUIRED_ARG> [optional-arg] [--flag]"
allowed-tools: Bash(git add:*), Bash(git commit:*)
---
## Context
Dynamic values injected at runtime using `!` backtick syntax:
- Current branch: !`git branch --show-current`
- Git status: !`git status`
- Custom check: !`some-cli-command 2>/dev/null || echo "FALLBACK"`
## Instructions
You are doing X. Follow these steps precisely.
### Step 1: Do the first thing
Explain what Claude should do. Use `$ARGUMENTS` to reference user input.
### Step 2: Do the next thing
Include code blocks for commands Claude should run:
```bash
some-command --flag value
```
### Step 3: Present results
```
--- Summary ---
Result: <value>
---------------
```Frontmatter fields:
| Field | Required | Description |
|---|---|---|
description |
Yes | Help text shown when user types / |
argument-hint |
No | Describes expected arguments. Use <REQUIRED> and [optional] |
allowed-tools |
No | Restricts which tools Claude can use. Omit to allow all tools. Format: Bash(pattern:*) |
Key patterns:
$ARGUMENTS— replaced with whatever the user types after the command name!backtick context — shell commands in the Context section run at invocation time and inject their outputAskUserQuestion— use this tool to ask the user for input during execution- MCP tools — reference them by full name (e.g.,
mcp__plugin_linear_linear__get_issue) - Flags — parse from
$ARGUMENTSin a dedicated step. Commands don't have built-in flag parsing — you write instructions for Claude to parse them
Example — a simple deploy command:
---
description: Deploy the current branch to staging
argument-hint: "[--production]"
allowed-tools: Bash(git push:*), Bash(deploy:*)
---
## Context
- Current branch: !`git branch --show-current`
- Last commit: !`git log --oneline -1`
## Instructions
### Step 1: Parse flags
Check if `$ARGUMENTS` contains `--production`. If yes, target is production. Otherwise, target is staging.
### Step 2: Confirm with user
Use `AskUserQuestion` to confirm:
- "Deploy `<branch>` (`<last commit>`) to `<target>`?"
- Options: "Deploy", "Cancel"
### Step 3: Deploy
```bash
deploy --target <target> --branch <branch>
```
### Step 4: Show result
```
--- Deployed ---
Branch: <branch>
Target: <target>
Commit: <last commit>
----------------
```Agents are subagents spawned by commands via the Task tool. They are markdown files with no YAML frontmatter.
Agent file format:
# Agent Name Agent
You are a specialized agent for [purpose].
## Activation Condition
Only activate if [condition from detector/context].
## Your Mission
[What this agent does]
## Constraints
- **Max 8 files**: Focus on the most representative files
- **Prioritize**: [what to focus on]
- **Use context**: Reference findings passed to you, avoid re-scanning
## Analysis Areas
### 1. Area Name
- Point 1
- Point 2
### 2. Another Area
- Point 1
## Output Format
[Template for what the agent should produce]Agents are invoked from commands like this (in the command's markdown):
Spawn the `agent-name` agent with the following context: [data to pass]
Follow these steps:
1. Create the directory structure:
plugins/<plugin-name>/
├── .claude-plugin/
│ └── plugin.json
├── README.md
└── commands/
└── <first-command>.md
2. Write plugin.json:
{
"name": "<plugin-name>",
"version": "1.0.0",
"description": "What this plugin does in one sentence",
"author": {
"name": "<your-name>",
"email": "<your-email>"
},
"homepage": "https://github.com/<org>/claude-plugins",
"repository": "https://github.com/<org>/claude-plugins",
"license": "MIT",
"keywords": ["keyword1", "keyword2"]
}3. Register in the marketplace:
Add an entry to .claude-plugin/marketplace.json in the plugins array:
{
"name": "<plugin-name>",
"source": "./plugins/<plugin-name>",
"description": "Same as plugin.json description",
"version": "1.0.0",
"author": { "name": "<your-name>" },
"repository": "https://github.com/<org>/claude-plugins",
"keywords": ["keyword1", "keyword2"]
}4. Write your commands (see "Adding a New Slash Command" above)
5. Write a README.md with installation instructions, command reference, and usage examples
6. Bump the version in both plugin.json and marketplace.json whenever you make changes
- Be precise — Claude follows your instructions literally. Vague instructions produce vague results.
- Number your steps — sequential steps prevent Claude from skipping or reordering.
- Use conditionals explicitly — "If X, do Y. Otherwise, do Z." Don't leave ambiguity.
- Gate dangerous actions — use
AskUserQuestionbefore destructive operations (deletes, force pushes, etc.) - Inject context — use
!backtick commands to give Claude runtime awareness (branch name, git status, file lists, etc.) - Restrict tools when needed — use
allowed-toolsto prevent Claude from doing things outside the command's scope (e.g., a commit command shouldn't read random files) - Show examples in output — template the exact output format you want Claude to produce
- Don't commit for the user — if the command makes code changes, present results and let the user decide. Separate "implement" from "commit" commands.
- Keep commands focused — one command should do one thing well. Chain commands together for workflows.
Paste this into Claude Code to have it scaffold a new plugin for you:
Create a new Claude Code plugin called "<plugin-name>" in this repo.
It should have the following commands:
- /<command-1>: <what it does>
- /<command-2>: <what it does>
Follow the existing plugin patterns in this repo:
- Create plugins/<plugin-name>/.claude-plugin/plugin.json
- Create plugins/<plugin-name>/commands/<command>.md for each command
- Create plugins/<plugin-name>/README.md with install instructions and usage
- Register in .claude-plugin/marketplace.json
Use the same conventions as the existing plugins:
- YAML frontmatter with description and argument-hint
- Context section with runtime shell commands
- Numbered step-by-step instructions
- Output summaries in fenced code blocks
MIT