ryaneggzandClaude Opus 4.6
5e0f7bc8e7
Move Docker files into docker/ directory, add issue templates for agents/audits/bugs/features/skills/tasks, enhance heartbeat system with config file and per-heartbeat directory, update Makefile and README, and add worktrees scaffolding. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3.1 KiB
3.1 KiB
name, about, title, labels, assignees
| name | about | title | labels | assignees |
|---|---|---|---|---|
| Skill | Create a new Claude Code skill | [SKILL] | skill |
Skill Definition
- Name:
- Description:
- Degrees of Freedom:
Purpose
Examples
Example 1
User: Assistant:
Example 2
User: Assistant:
Skill Structure
Skills are modular instruction packages — NOT agents, NOT slash commands. They live at
.claude/skills/<skill-name>/and follow progressive disclosure: metadata is always loaded, SKILL.md loads when triggered, resources load on demand.
<skill-name>/
├── SKILL.md # Required: frontmatter + instructions
├── scripts/ # Optional: executable code for deterministic tasks
├── references/ # Optional: docs loaded contextually
└── assets/ # Optional: output-ready files (NOT loaded in context)
SKILL.md Format
---
name: <skill-name>
description: |
Triggering info goes HERE in the frontmatter, not in the body.
Describe when and why Claude should apply this skill.
---
# Skill Name
[Brief purpose statement]
## Instructions
[Numbered steps, imperative form ("Analyze the input" not "You should analyze")]
## Examples
[Realistic input/output scenarios]
## Guidelines
[Best practices, gotchas, warnings]
## Reference
[Optional: command tables, API refs, schemas]
Checklist
- Name is lowercase with hyphens only
- Triggering info is in YAML
description, not the body - Instructions use imperative form
- Examples are realistic scenarios (examples > descriptions)
- Content is under 5,000 words
- Degrees of freedom match the task risk level
- Resources (scripts/references/assets) documented if present
- One level of nesting max for references
Agent Assignment
Metadata
Important
: The very first step should ALWAYS be validating this metadata section to maintain a CLEAN development workflow.
agent: "<agent-name>"
branch: "agent/<agent-name>"
worktree_path: "worktrees/<agent-name>"
pull_request: "FROM agent/<agent-name> TO development"
Workflow
# Enter the assigned agent's sandbox
make NAME=<agent-name> shell
claude
# When complete — PR from agent branch to development
cd worktrees/<agent-name>
git add -A && git commit -m "skill(<issue#>): <description>"
git push -u origin agent/<agent-name>
gh pr create --base development --title "skill(<issue#>): <shortdesc>" --body "Closes #<issue#>"
Acceptance Criteria
- Skill directory exists at
.claude/skills/<skill-name>/ - SKILL.md has valid YAML frontmatter
- Skill triggers correctly on matching user requests
- Does not trigger on unrelated requests
- PR targets
developmentbranch