e0f8e6471c
- best-practices/: 11 topic files + INDEX.md extracted from cluster-bootstrap and custom-claude-skills (validation, k8s, helm, ansible, secrets, debugging, etc.) - settings.yaml: pipeline config (log retention, tracked projects, max logs per run) - CLAUDE.md: updated with best-practices loading and pipeline documentation - memory/log/: first session log demonstrating the format Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1.4 KiB
1.4 KiB
Claude Code Skills
Skill Structure
- Each skill lives in
skills/<skill-name>/SKILL.md - Skills should be project-agnostic where possible — use dynamic context injection to adapt
- After adding a new skill, run the install script to register it
- Skills only useful for one project should live in that project's
.claude/skills/instead
Authoring Guidelines
- Inline by default — only use
context: forkif the skill genuinely doesn't need conversation history - Pre-fetch context with
!command`` injection to reduce tool calls during execution - Restrict tools with
allowed-toolsto the minimum needed — reduces permission prompts - Use $ARGUMENTS for user input,
$0,$1etc. for positional args - Dynamic commands in
!command`` run at skill load time, not during Claude's execution
!command`` Gotchas
- No
$()command substitution — the permission checker rejects commands containing$() - No complex shell pipelines relying on subshells — keep commands simple and self-contained
allowed-toolspatterns must match the command binary — each binary used in!command`` blocks needs its own pattern- Prefer specific tool patterns over broad ones —
Bash(git log *)is safer thanBash(git *) - Fallback to tool instructions for dynamic paths — if a command needs
$ARGUMENTSto compute a path, use a plain-text instruction telling Claude to use the Read tool instead