zhongwei/gh-jbabin91-super-claude-plugins-meta
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-29 18:50:09 +08:00
commit afb8ef033a
11 changed files with 3286 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

704
skills/skill-creator/SKILL.md Normal file
View File

@@ -0,0 +1,704 @@
---
name: skill-creator
version: 1.0.0
description: |
Create new Claude Code skills with proper structure, validation, and best practices.
Generates skills that follow Anthropic specifications and community patterns.
Use when you need custom skills for specific workflows, either globally or per-project.
category: meta
tags: [skill-generation, meta, automation, claude-code]
model: sonnet
triggers:
keywords: [create skill, generate skill, new skill, custom skill, skill for]
patterns: ['create.*skill', 'generate.*skill', 'make.*skill']
contexts: [development, skill-creation]
---
# Skill Creator
A meta-skill for generating new Claude Code skills with proper structure and validation.
## When to Use
- Creating project-specific skills (e.g., "Odyssey design system components")
- Building work-related skills (e.g., "SD API client generation")
- Generating custom workflow automations
- Standardizing team practices into reusable skills
- Converting manual processes into automated skills
## Core Workflow
### 1. Gather Requirements
Ask the user:
- **Purpose**: What problem does this skill solve?
- **Triggers**: What keywords/phrases should activate it?
- **Context**: When should it be used (file types, project types)?
- **Location**: Where to save (global or project-local)?
- **Dependencies**: Required tools, packages, or other skills?
### 2. Generate Skill Structure
**Template Reference:** See `templates/skill_template.md` for the complete skill template with all available fields and examples.
Create a properly formatted SKILL.md with:
```yaml
---
# OFFICIAL CLAUDE CODE FIELDS (recognized by Claude Code)
name: skill-identifier # Required: kebab-case
description: | # Required: What it does AND when to activate
Clear description of what it does and when to use it.
IMPORTANT: Include activation triggers in the description itself.
Example: "Generate React components. Use when creating new UI components."
allowed-tools: [] # Optional: Restrict to specific tools
# EXTENDED METADATA (ignored by Claude Code, useful for organization)
version: 1.0.0 # Track changes (skills are files, not packages)
---
# Skill Name
Brief overview (1-2 sentences).
## When to Use
- Concrete trigger 1
- Concrete trigger 2
- Specific scenario 3
## Core Workflow
### 1. First Step
Description and instructions
### 2. Second Step
Description and instructions
## Best Practices
- Practice 1
- Practice 2
## Example Workflows
### Scenario 1: Common Use Case
Step-by-step example
### Scenario 2: Edge Case
How to handle edge cases
## Integration Points
- Works with: [other skills]
- Calls: [agents/tools]
- Required by: [dependent skills]
## Troubleshooting
### Issue 1
Symptom: [description]
Solution: [fix]
### Issue 2
Symptom: [description]
Solution: [fix]
## References
- [External documentation links]
```
### 3. Validate Against Specifications
Ensure the skill follows:
**Anthropic Best Practices:**
- ✅ Clear, actionable instructions
- ✅ Specific triggers (not generic)
- ✅ Real examples (not placeholders)
- ✅ Token-efficient (< 500 lines for core content)
- ✅ Progressive disclosure (link to API_REFERENCE.md if needed)
**RED-GREEN-REFACTOR Ready:**
- ✅ Can be tested without the skill (RED phase)
- ✅ Verifiable compliance (GREEN phase)
- ✅ Hardened against rationalizations (REFACTOR phase)
**Community Patterns:**
- ✅ No TODOs or placeholders in production
- ✅ No "YOUR_KEY_HERE" style configs
- ✅ Specific, not generic labels
- ✅ Context-aware activation
### 4. Save to Appropriate Location
**Global Skills** (general use across all projects):
```txt
~/.claude/skills/super-claude/plugins/[category]/skills/skill-name.md
```
**Project-Local Skills** (specific to one project):
```txt
/path/to/project/.claude/skills/skill-name.md
```
**Note**: Project-local skills are perfect for work-specific or proprietary patterns that shouldn't be shared globally.
### 5. Test the Skill
Provide testing guidance:
- RED: Try the workflow WITHOUT the skill, note failures
- GREEN: Enable the skill, verify it works
- REFACTOR: Identify edge cases, harden the skill
## Skill Types
### Standard Skill (Most Common)
General-purpose automation or guidance for specific tasks.
### Component Generator
Creates code/files following specific patterns.
### Workflow Orchestrator
Coordinates multiple steps or tools.
### Validation/Checker
Ensures code/config meets standards.
### Migration Helper
Assists in moving between technologies.
## Advanced Features
### Progressive Disclosure
If skill exceeds 500 lines, split into:
- **SKILL.md**: Core instructions (< 500 lines)
- **API_REFERENCE.md**: Advanced topics (loaded on-demand)
Link from SKILL.md:
```markdown
For advanced usage, see [API_REFERENCE.md](./API_REFERENCE.md)
```
### Context-Aware Activation
Make skills activate automatically:
```yaml
triggers:
keywords: [specific, technical, terms]
patterns: ['regex.*patterns']
contexts: [file-types, project-types]
```
### Dependencies
Declare requirements:
```yaml
requires:
tools: [git, npm, docker]
skills: [typescript/tsc-validation]
packages: ['@types/node']
```
## Auto-Activation System
### Overview
Skills can auto-activate based on user prompts using the skill-rules.json system. This enables Claude to proactively suggest relevant skills before responding.
**For complete details, see:** [SKILL_ACTIVATION_GUIDE.md](../../docs/SKILL_ACTIVATION_GUIDE.md)
### When to Add Activation Rules
Add skill-rules.json entries when:
- Skill is part of a plugin (not project-local)
- Skill should auto-activate from specific keywords
- Skill addresses a common workflow pattern
- Skill is high-value and frequently needed
**Skip activation rules for:**
- One-off project-specific skills
- Rarely-used experimental skills
- Skills that should only run on explicit user request
### Creating skill-rules.json Entries
**For plugin developers:** Add entries to `plugins/{plugin}/skills/skill-rules.json`
**Schema:**
```json
{
"plugin": {
"name": "plugin-name",
"version": "1.0.0",
"namespace": "namespace"
},
"skills": {
"skill-name": {
"type": "domain",
"enforcement": "suggest",
"priority": "high",
"description": "Brief description of what the skill does",
"promptTriggers": {
"keywords": ["keyword1", "keyword2"],
"intentPatterns": ["pattern1", "pattern2"]
}
}
}
}
```
### Writing Good Keywords
**✅ Good Keywords** (specific, unambiguous):
```json
"keywords": [
"create skill",
"new skill",
"skill template",
"generate skill",
"skill development"
]
```
**❌ Bad Keywords** (too generic):
```json
"keywords": [
"create",
"new",
"help",
"build"
]
```
**Rules for keywords:**
- Minimum 2 words for specificity
- Include the domain (e.g., "skill", "hook", "component")
- Match how users naturally ask for help
- Case-insensitive literal matching
- No regex needed for keywords
### Writing Good Intent Patterns
**✅ Good Patterns** (capture intent, not exact wording):
```json
"intentPatterns": [
"(create|add|generate|build).*?skill",
"how to.*?(create|add|build).*?skill",
"skill.*?(template|generator|builder)",
"need.*?skill.*?(for|to)",
"(make|write).*?skill"
]
```
**❌ Bad Patterns** (too broad or too narrow):
```json
"intentPatterns": [
".*skill.*",
"^create exactly this specific phrase$"
]
```
**Rules for patterns:**
- Use regex with case-insensitive flag (`i`)
- Include action verbs: create, add, generate, build, make
- Include domain terms: skill, hook, component, etc.
- Use `.*?` for flexible matching between keywords
- Capture natural variations of the same intent
### Priority Guidelines
**critical** - Must run for safety/correctness:
```json
"priority": "critical"
// Examples: security validators, syntax checkers
```
**high** - Highly recommended:
```json
"priority": "high"
// Examples: skill-creator, component-generator
```
**medium** - Useful but optional:
```json
"priority": "medium"
// Examples: documentation generators, formatters
```
**low** - Nice-to-have:
```json
"priority": "low"
// Examples: experimental features, rarely-used tools
```
### Example: skill-creator Activation Rules
```json
{
"plugin": {
"name": "meta",
"version": "1.0.0",
"namespace": "claude"
},
"skills": {
"skill-creator": {
"type": "domain",
"enforcement": "suggest",
"priority": "high",
"description": "Generate new Claude Code skills with proper structure and validation",
"promptTriggers": {
"keywords": [
"create skill",
"new skill",
"skill development",
"generate skill",
"skill template"
],
"intentPatterns": [
"(create|add|generate|build).*?skill",
"how to.*?(create|add|build).*?skill",
"skill.*?(template|generator|builder)",
"need.*?skill.*?(for|to)",
"(make|write).*?skill"
]
}
}
}
}
```
### Migration Tool
Use `/generate-skill-rules` to auto-generate entries from existing SKILL.md YAML frontmatter:
```sh
# Preview generated rules
/generate-skill-rules --plugin plugins/tanstack-tools --namespace tanstack
# Write to skill-rules.json
/generate-skill-rules --plugin plugins/api-tools --namespace api --write
```
### Testing Activation Rules
**Test in isolated project:**
```sh
# 1. Create test project
mkdir test-activation && cd test-activation
# 2. Copy hook and rules
mkdir -p .claude/hooks .claude/skills/your-plugin
cp {hook-path}/skill-activation-prompt.ts .claude/hooks/
cp {plugin-path}/skill-rules.json .claude/skills/your-plugin/
# 3. Test with prompts
echo '{"prompt":"create a new skill","cwd":"'$(pwd)'"}' | \
bun run .claude/hooks/skill-activation-prompt.ts
```
**Expected output:**
```txt
============================================================
SKILL ACTIVATION CHECK
============================================================
[RECOMMENDED] SKILLS:
-> skill-creator
ACTION: Use Skill tool BEFORE responding
============================================================
```
### Workflow: Adding Auto-Activation to New Skills
When creating a skill that should auto-activate:
1. **Create the SKILL.md** (as normal)
2. **Identify triggers** by asking:
- What keywords would users type to need this skill?
- What questions or requests indicate this intent?
- How do users naturally express this need?
3. **Add to skill-rules.json**:
```json
{
"skills": {
"new-skill": {
"type": "domain",
"enforcement": "suggest",
"priority": "high",
"description": "What the skill does",
"promptTriggers": {
"keywords": ["keyword1", "keyword2"],
"intentPatterns": ["pattern1", "pattern2"]
}
}
}
}
```
4. **Test the triggers**:
- Try prompts that SHOULD activate it
- Try prompts that should NOT activate it
- Refine keywords/patterns based on results
5. **Document in SKILL.md**:
```markdown
## Auto-Activation
This skill auto-activates when you mention:
- Creating/generating {domain objects}
- Specific workflow requests
- Related keywords
Triggered by: create skill, new skill, generate skill
```
### Project-Level Overrides
Users can customize activation in their projects via `.claude/skills/skill-rules.json`:
```json
{
"version": "1.0",
"overrides": {
"claude/skill-creator": {
"priority": "critical"
}
},
"disabled": ["claude/skill-validator"],
"global": {
"maxSkillsPerPrompt": 3,
"priorityThreshold": "medium"
}
}
```
**Command for users:** `/workflow:configure`
## Example: Creating a Project-Specific Skill
**User Request:**
"Create a skill for generating Odyssey design system components"
**Generated Skill:**
Location: `/path/to/odyssey-project/.claude/skills/odyssey-components.md`
```yaml
---
name: odyssey-components
version: 1.0.0
description: |
Generate components following Odyssey design system guidelines.
Ensures consistency with design tokens, patterns, and accessibility standards.
category: design-system
tags: [odyssey, components, design-system, react]
model: sonnet
requires:
tools: [npm]
packages: ["@odyssey/design-tokens", "@odyssey/components"]
triggers:
keywords: [odyssey, odyssey component, design system]
patterns: ["create.*odyssey", "generate.*odyssey"]
---
# Odyssey Components
Generate React components that follow Odyssey design system standards.
## When to Use
- Creating new Odyssey components
- Ensuring design system compliance
- Maintaining consistency across products
## Component Structure
All components follow this pattern:
\`\`\`
components/
└── ComponentName/
├── ComponentName.tsx
├── ComponentName.stories.tsx
├── ComponentName.test.tsx
└── index.ts
\`\`\`
## Design Token Usage
Always use design tokens from `@odyssey/design-tokens`:
\`\`\`typescript
import { tokens } from '@odyssey/design-tokens'
const styles = {
color: tokens.color.primary.base,
spacing: tokens.spacing.md,
borderRadius: tokens.borderRadius.md
}
\`\`\`
## Accessibility Requirements
All components must:
- Meet WCAG AAA standards
- Include proper ARIA labels
- Support keyboard navigation
- Provide focus indicators
## Example: Button Component
[Detailed example following Odyssey patterns]
```
## Common Skill Patterns
### API Client Generator
```yaml
name: project-api-client
purpose: Generate type-safe API clients from OpenAPI schemas
includes: OpenAPI schema parsing, type generation, RPC helpers
location: project-local (for proprietary APIs)
```
### Component Library Helper
```yaml
name: design-system-components
purpose: Generate components following project design system
includes: Component patterns, theme support, testing
location: project-local (for proprietary design systems)
```
### Database Schema Generator
```yaml
name: drizzle-schema-from-db
purpose: Generate Drizzle schemas from existing Postgres database
includes: Type inference, relationship mapping, migration helpers
location: global (reusable across projects)
```
### Deployment Automation
```yaml
name: coolify-deployment
purpose: Automate deployment to Coolify platform
includes: Docker config, environment setup, rollback procedures
location: global (reusable deployment pattern)
```
## Best Practices
1. **Be Specific**: Don't create "helper" or "utility" skills - be explicit about what they do
2. **Include Examples**: Real, working examples - not placeholders
3. **Test First**: RED-GREEN-REFACTOR methodology ensures quality
4. **Token Efficiency**: Keep core content under 500 lines
5. **Clear Triggers**: Specific keywords that clearly indicate when to activate
6. **Validate**: Always check against Claude Code and Anthropic specs
## Anti-Patterns to Avoid
- ❌ Generic names ("helper", "utils", "tool")
- ❌ TODOs or placeholders in production
- ❌ Narrative examples tied to specific sessions
- ❌ Code embedded in flowcharts
- ❌ Missing activation triggers
- ❌ Over 500 lines without progressive disclosure
- ❌ Untested skills
## Integration with Other Tools
### shadcn CLI Integration
```bash
# Generate skill that wraps shadcn commands
pnpm dlx shadcn@latest add [component]
pnpm dlx shadcn@latest add @coss/[component]
```
### Registry Support
Skills can integrate with component registries:
- shadcn/ui registry
- coss.com/ui registry
- Custom private registries
## Troubleshooting
### Skill Not Activating
**Symptom**: Skill exists but doesn't trigger
**Solution**:
- Check triggers section in YAML frontmatter
- Ensure keywords are specific enough
- Verify file is in correct location
- Check Claude Code loaded the skill (restart if needed)
### Skill Too Generic
**Symptom**: Skill triggers too often or in wrong contexts
**Solution**:
- Make keywords more specific
- Add context restrictions
- Use regex patterns to narrow activation
### Skill Too Large
**Symptom**: Skill exceeds 500 lines
**Solution**:
- Implement progressive disclosure
- Move advanced content to API_REFERENCE.md
- Keep core workflow in SKILL.md
## References
- [Claude Code Skills Documentation](https://docs.claude.com/en/docs/claude-code/skills)
- [Anthropic Best Practices](https://docs.claude.com/en/docs/claude-code)
- [obra/superpowers](https://github.com/obra/superpowers) - Community patterns
- [super-claude CREATING_SKILLS.md](../../docs/CREATING_SKILLS.md) - RED-GREEN-REFACTOR guide

196
skills/skill-creator/templates/skill_template.md Normal file
View File

@@ -0,0 +1,196 @@
---
# ============================================================================
# OFFICIAL CLAUDE CODE FIELDS (recognized by Claude Code)
# Reference: https://docs.claude.com/en/docs/claude-code/skills.md
# ============================================================================
name: skill-identifier # Required: kebab-case, unique identifier
description: | # Required: What it does AND when to activate it
Brief description of what this skill does and when to use it.
IMPORTANT: Include activation triggers in the description itself since
Claude Code only uses the description field for discovery.
Examples: "Use when...", "Activates for...", "Helps with..."
Good: "Generate React components with TypeScript. Use when creating new UI components."
Bad: "Helps with components" (too vague)
allowed-tools: [] # Optional: Restrict to specific tools
# Example: allowed-tools: [Read, Grep, Glob] # Read-only skill
# Available tools: Read, Write, Edit, Bash, Grep, Glob, WebFetch, Task, etc.
# ============================================================================
# EXTENDED METADATA (not used by Claude Code, but useful for humans/tooling)
# These fields are ignored by Claude Code but help with organization
# ============================================================================
version: 1.0.0 # Track changes since skills are files, not versioned packages
---
# Skill Name
Brief overview of what this skill does (1-2 sentences maximum).
## When to Use
- User action or request that triggers this skill
- Specific scenario where this skill is helpful
- Problem this skill solves
## Prerequisites
- Required tools/setup (if any)
- Expected environment or configuration
- Dependencies that must be installed
## Core Workflow
### 1. Step One
Description of first step with details.
```bash
# Example command or code
example-command --flag value
```
### 2. Step Two
Description of second step with examples.
### 3. Step Three
Final steps and completion criteria.
## Best Practices
- Practice 1: Why and when to apply it
- Practice 2: Common pitfall to avoid
- Practice 3: Optimization or efficiency tip
## Example Workflows
### Scenario 1: [Common Use Case]
**User Request:** "Help me do X"
**Steps:**
1. First action
2. Second action
3. Expected outcome
**Example:**
```typescript
// Example code demonstrating the workflow
function example() {
// ...
}
```
### Scenario 2: [Advanced Use Case]
**User Request:** "I need to handle Y edge case"
**Steps:**
1. Handle edge case
2. Validate result
3. Confirm success
## Troubleshooting
### Issue 1: Common Problem
**Symptom:** What the user sees
**Solution:**
- Step 1 to fix
- Step 2 to verify
- Alternative approach if needed
### Issue 2: Another Problem
**Symptom:** What the user sees
**Solution:**
- How to resolve
- How to prevent in future
## References
- [Related Documentation](https://example.com)
- [Official Guide](https://example.com)
- [Community Resources](https://example.com)
---
## Template Notes (Remove before publishing)
### What Claude Code Actually Uses
**Claude Code ONLY recognizes these fields:**
- `name` - Skill identifier (required)
- `description` - What it does AND when to activate (required)
- `allowed-tools` - Tool restrictions (optional)
**Extended metadata (ignored by Claude Code, but useful for humans):**
- `version` - Track changes since skills are files, not versioned packages
Note: Author info is in the plugin's `plugin.json`, not individual skill files.
All activation hints, keywords, and patterns should go directly in the `description` field since that's the only field Claude Code uses for skill discovery.
### File Organization
Skills can have supporting files loaded progressively:
```sh
skill-name/
├── SKILL.md (this file, required)
├── reference.md (optional, advanced topics)
├── examples.md (optional, detailed examples)
├── scripts/ (optional, helper scripts)
└── templates/ (optional, code templates)
```
### Activation Best Practices
**Claude Code only uses the `description` field for discovery!**
Put ALL activation hints directly in the description:
```yaml
description: |
Generate React components with TypeScript and Tailwind CSS.
Use when: creating new components, scaffolding UI elements, building design system.
Activates for: "create component", "new component", "generate component"
```
**Good description examples:**
> "Analyze Excel spreadsheets, generate pivot tables, create charts. Use when working with .xlsx files or data analysis requests."
>
> "Refactor TypeScript imports, organize import statements, remove unused imports. Use when cleaning up imports or seeing import-related errors."
**Bad description (too vague):**
> "Helps with data" ❌ - No activation triggers, no use cases
### Model Selection
Claude Code automatically picks the appropriate model. The `model` field in YAML is ignored.
### Tool Restrictions
Use `allowed-tools` to create read-only or limited-permission skills:
```yaml
allowed-tools: [Read, Grep, Glob] # Read-only, no file modifications
```
Available tools: Read, Write, Edit, Bash, Grep, Glob, WebFetch, Task, etc.