[2.10.1] Fix command collisions and bugs
Fixes: - #40: Add missing `name:` field to heal-skill.md and create-agent-skill.md - #41: Rewrite corrupted prime.md (was containing CLAUDE.md text) - #42: Namespace workflow commands as `compound:*` to avoid collision with built-in `/plan` - #36: Shorten Playwright MCP alias from `playwright` to `pw` (64 char limit) Command renames: - /plan → /compound:plan - /review → /compound:review - /work → /compound:work - /compound → /compound:codify Removed: - Deprecated /codify command (use /compound:codify) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Kieran Klaassen
@@ -25,7 +25,7 @@
|
||||
"browser-automation"
|
||||
],
|
||||
"mcpServers": {
|
||||
"playwright": {
|
||||
"pw": {
|
||||
"type": "stdio",
|
||||
"command": "npx",
|
||||
"args": ["-y", "@playwright/mcp@latest"],
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
---
|
||||
name: create-agent-skill
|
||||
description: Create or edit Claude Code skills with expert guidance on structure and best practices
|
||||
allowed-tools: Skill(create-agent-skills)
|
||||
argument-hint: [skill description or requirements]
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
---
|
||||
name: heal-skill
|
||||
description: Heal skill documentation by applying corrections discovered during execution with approval workflow
|
||||
argument-hint: [optional: specific issue to fix]
|
||||
allowed-tools: [Read, Edit, Bash(ls:*), Bash(git:*)]
|
||||
|
||||
@@ -1,3 +1,95 @@
|
||||
Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused. Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability. Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use backwards-compatibility shims when you can just change the code. Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task. Reuse existing abstractions where possible and follow the DRY principle.
|
||||
---
|
||||
name: prime
|
||||
description: Prime Claude with project context by reading key files and understanding the codebase structure
|
||||
argument-hint: [optional: specific area to focus on]
|
||||
---
|
||||
|
||||
ALWAYS read and understand relevant files before proposing code edits. Do not speculate about code you have not inspected. If the user references a specific file/path, you MUST open and inspect it before explaining or proposing fixes. Be rigorous and persistent in searching code for key facts. Thoroughly review the style, conventions, and abstractions of the codebase before implementing new features or abstractions.
|
||||
# Prime Command
|
||||
|
||||
Prime yourself with essential project context to work effectively in this codebase.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Discover Project Structure
|
||||
|
||||
<task>
|
||||
First, understand the project layout:
|
||||
|
||||
```bash
|
||||
# Find project root indicators
|
||||
ls -la | head -20
|
||||
|
||||
# Check for common config files
|
||||
ls -la *.json *.yml *.yaml *.toml 2>/dev/null | head -10
|
||||
|
||||
# Find source directories
|
||||
ls -d */ 2>/dev/null | head -10
|
||||
```
|
||||
</task>
|
||||
|
||||
### 2. Read Key Documentation
|
||||
|
||||
<task>
|
||||
Read project documentation in this order:
|
||||
|
||||
1. **CLAUDE.md** (if exists) - Project-specific Claude instructions
|
||||
2. **README.md** - Project overview and setup
|
||||
3. **CONTRIBUTING.md** (if exists) - Development guidelines
|
||||
4. **.claude/** directory (if exists) - Custom commands and config
|
||||
</task>
|
||||
|
||||
### 3. Understand Tech Stack
|
||||
|
||||
<task>
|
||||
Identify the technology stack:
|
||||
|
||||
- **Ruby/Rails**: Look for `Gemfile`, `config/routes.rb`
|
||||
- **JavaScript/Node**: Look for `package.json`, `tsconfig.json`
|
||||
- **Python**: Look for `requirements.txt`, `pyproject.toml`, `setup.py`
|
||||
- **Go**: Look for `go.mod`
|
||||
- **Rust**: Look for `Cargo.toml`
|
||||
</task>
|
||||
|
||||
### 4. Map Key Directories
|
||||
|
||||
<task>
|
||||
For the identified stack, explore the structure:
|
||||
|
||||
**Rails projects:**
|
||||
- `app/models/` - Domain models
|
||||
- `app/controllers/` - Request handlers
|
||||
- `app/views/` or `app/components/` - UI layer
|
||||
- `config/` - Configuration
|
||||
- `db/schema.rb` - Database structure
|
||||
|
||||
**Node/JS projects:**
|
||||
- `src/` or `lib/` - Source code
|
||||
- `components/` - UI components
|
||||
- `api/` or `routes/` - API endpoints
|
||||
- `tests/` or `__tests__/` - Test files
|
||||
</task>
|
||||
|
||||
### 5. Summarize Context
|
||||
|
||||
<output>
|
||||
After priming, provide a brief summary:
|
||||
|
||||
## Project Context
|
||||
|
||||
**Name:** [project name]
|
||||
**Stack:** [technologies identified]
|
||||
**Key directories:** [important paths]
|
||||
**Special instructions:** [from CLAUDE.md if present]
|
||||
|
||||
Ready to help with: [list 3-5 things you can now assist with]
|
||||
</output>
|
||||
|
||||
## Focus Areas
|
||||
|
||||
If the user specified a focus area ($ARGUMENTS), prioritize:
|
||||
|
||||
- **"models"** - Focus on data layer and business logic
|
||||
- **"api"** - Focus on endpoints and request handling
|
||||
- **"frontend"** - Focus on UI components and views
|
||||
- **"tests"** - Focus on test structure and patterns
|
||||
- **"config"** - Focus on configuration and environment
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
name: codify
|
||||
description: "[DEPRECATED] Use /compound instead - Document solved problems"
|
||||
argument-hint: "[optional: brief context about the fix]"
|
||||
---
|
||||
|
||||
# /codify is deprecated
|
||||
|
||||
**This command has been renamed to `/compound`.**
|
||||
|
||||
The new name better reflects the compounding engineering philosophy: each documented solution compounds your team's knowledge.
|
||||
|
||||
---
|
||||
|
||||
Tell the user: "Note: `/codify` has been renamed to `/compound`. Please use `/compound` going forward."
|
||||
|
||||
Now run the `/compound` command with the same arguments: #$ARGUMENTS
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: compound
|
||||
name: compound:codify
|
||||
description: Document a recently solved problem to compound your team's knowledge
|
||||
argument-hint: "[optional: brief context about the fix]"
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: plan
|
||||
name: compound:plan
|
||||
description: Transform feature descriptions into well-structured project plans following conventions
|
||||
argument-hint: "[feature description, bug report, or improvement idea]"
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: review
|
||||
name: compound:review
|
||||
description: Perform exhaustive code reviews using multi-agent analysis, ultra-thinking, and worktrees
|
||||
argument-hint: "[PR number, GitHub URL, branch name, or latest]"
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: work
|
||||
name: compound:work
|
||||
description: Execute work plans efficiently while maintaining quality and finishing features
|
||||
argument-hint: "[plan file, specification, or todo file path]"
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user