// Modify an existing playbook based on conversation context or explicit instructions. Use when user wants to update, fix, extend, or refine a playbook they already have.
Add a memory system to an agent — file awareness, knowledge graph, structured state, or multi-session tracking
Create a new skill or playbook. Guides through requirements gathering and generates the appropriate template based on complexity.
Create an executive chief of staff agent — asks about your tools, team, and priorities, then scaffolds a Trinity-compatible agent for daily briefings, meeting prep, and decision tracking
Scaffold a new Trinity-compatible Claude Code agent from scratch on any topic. Creates directory, CLAUDE.md, skills, and Trinity files — ready for development.
Create a content writer agent — asks about your brand voice, platforms, and topics, then scaffolds a Trinity-compatible ghostwriter agent that writes in your voice
Create a knowledge-base agent — asks a structured 6-question interview about the domain's ontology, then scaffolds a Cornelius-shaped Trinity-compatible KB agent with a typed graph, 7-layer vault, subagents, and scheduled coherence jobs
| name | adjust-playbook |
| description | Modify an existing playbook based on conversation context or explicit instructions. Use when user wants to update, fix, extend, or refine a playbook they already have. |
| disable-model-invocation | false |
| user-invocable | true |
| argument-hint | [playbook-name] [what to change] [--archive] |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion |
| metadata | {"version":"1.4","created":"2025-02-10T00:00:00.000Z","updated":"2026-05-16T00:00:00.000Z","author":"Ability.ai","changelog":["1.4: Add Change Effort/Model and Add Skill-Scoped Hooks adjustments; add Routines note to autonomous validation","1.3: Add single-task scope check to autonomous validation checklist","1.2: Add autonomous validation — cannot add gates to autonomous or change to autonomous with gates","1.1: Added --archive flag and versioning workflow for breaking changes","1.0: Initial version"]} |
Modify existing playbooks while preserving their core structure and functionality.
If $0 (playbook name) provided:
# Check project skills
ls .claude/skills/$0/SKILL.md 2>/dev/null
# Check personal skills
ls ~/.claude/skills/$0/SKILL.md 2>/dev/null
If not provided or not found, list available playbooks:
echo "=== Project Playbooks ==="
for d in .claude/skills/*/; do
[ -f "$d/SKILL.md" ] && grep -l "automation:" "$d/SKILL.md" 2>/dev/null && basename "$d"
done
echo "=== Personal Playbooks ==="
for d in ~/.claude/skills/*/; do
[ -f "$d/SKILL.md" ] && grep -l "automation:" "$d/SKILL.md" 2>/dev/null && basename "$d"
done
Ask user to select if multiple options.
Read the full SKILL.md:
cat [path]/SKILL.md
Parse and display structure:
## Current Playbook: [name]
**Automation**: [level]
**Schedule**: [cron or none]
**Location**: [path]
**State Dependencies**:
[table or "none defined"]
**Process Steps**: [count]
1. [step name]
2. [step name]
...
**Approval Gates**: [count]
**Checklist Items**: [count]
From $ARGUMENTS or conversation context, identify:
| Change Type | Examples |
|---|---|
| Add step | "add a validation step", "include backup" |
| Remove step | "remove the notification", "skip review" |
| Modify step | "change step 3 to...", "update the API call" |
| Change automation | "make it autonomous", "add approval gate" |
| Change schedule | "run daily at 9am", "change to weekly" |
| Add state | "also track X", "read from Y" |
| Update checklist | "add verification for Z" |
| Fix issue | "it's failing because...", "handle the edge case" |
If unclear, ask:
What would you like to change in [playbook-name]?
1. Add/modify process steps
2. Change automation level or schedule
3. Update state dependencies
4. Fix an issue
5. Other (describe)
Show exactly what will change:
## Proposed Changes to [name]
### Changes
1. **[Section]**: [what changes]
Before:
[current content]
After:
[new content]
2. **[Section]**: [what changes]
...
### Unchanged
Everything else remains the same:
- [list preserved sections]
### Impact
- Functionality: [same / enhanced / modified]
- State dependencies: [same / new reads / new writes]
- Automation: [same / changed]
- Breaking: [yes/no] - if yes, recommend archiving
If change is breaking (output format changes, steps removed, args changed):
⚠️ This is a breaking change.
Other playbooks calling /[skill-name] may break.
Recommend: Archive current version before modifying.
Archive as [skill-name]-v[N]? [Y/n]
Ask for approval before making changes.
Options:
Use Edit tool to apply approved changes.
For each change:
Read the updated playbook and confirm:
## Updated: [name]
Changes applied:
- [x] [change 1]
- [x] [change 2]
Verify the playbook works:
/[playbook-name] --dry-run (if supported)
### Before Step N: [New Step Name]
[Instructions for new step]
Insert in the Process section at appropriate position.
⚠️ First, check if playbook is autonomous:
grep "automation:" [path]/SKILL.md
If automation: autonomous, STOP — cannot add approval gates:
⚠️ Cannot add approval gate — playbook is autonomous.
Autonomous playbooks run unattended and would hang waiting for approval
that never comes.
Options:
1. Change to `automation: gated` (then add the gate)
2. Cancel — keep autonomous without this gate
Which would you prefer?
If gated or manual, proceed:
[APPROVAL GATE] - [Description of what needs approval]
Present to user:
- [what to show]
Wait for approval before proceeding.
Update frontmatter:
automation: gated # was: manual
⚠️ If changing TO autonomous:
Autonomous playbooks run unattended — there is no human to approve gates. Before changing to autonomous, verify using the Autonomous Validation Checklist:
[APPROVAL GATE] — must return zero matchesAlternative: For cloud-hosted scheduled execution without a local machine, use Anthropic's Routines (
/schedulein CLI). The projectschedule:field runs locally; Routines run on Anthropic infrastructure.
If existing playbook has approval gates, you MUST either:
[APPROVAL GATE] sections (and their associated user interaction steps)gated/manual# Check for approval gates
grep -c "\[APPROVAL GATE\]" [path]/SKILL.md
# Must return 0 to proceed with autonomous
If gates exist, warn:
⚠️ Cannot change to autonomous — playbook contains [N] approval gate(s).
Autonomous playbooks cannot have approval gates — they run unattended and would
hang waiting for approval that never comes.
Options:
1. Remove the approval gates (will skip those review steps)
2. Keep as gated (human reviews at scheduled time)
3. Cancel change
Which would you prefer?
Update frontmatter:
schedule: "0 9 * * 1-5" # Weekdays at 9am
Provide cron reference if user needs it.
Add row to State Dependencies table:
| [Source] | [Location] | ✓ | ✓ | [Description] |
Add corresponding read in Step 1 and write in final step.
Add item to Completion Checklist:
- [ ] [New verification item]
Update frontmatter to override model or effort level for this skill's invocations:
model: sonnet # or opus, haiku, or a full model ID
effort: high # low / medium / high / xhigh / max
The override applies only while the skill is active; the session model/effort resumes on the next prompt.
Add a hooks: block to frontmatter to run commands on tool events while this skill is active:
hooks:
PostToolUse:
- matcher: "Edit|Write"
hooks:
- type: command
command: "./scripts/lint.sh"
All standard hook events are supported. These hooks fire only while the skill is loaded.
When making significant changes, update metadata:
metadata:
version: "1.1" # increment
updated: 2025-02-10
changelog:
- "1.1: [what changed]"
- "1.0: Initial version"
When changes are breaking (incompatible with existing workflows), archive the current version before modifying:
# Archive current version
cp -r [skill-path] [skill-path]-v[N]
Example:
skills/
data-export/ # Current (will become v3)
data-export-v1/ # Frozen
data-export-v2/ # Frozen
When to archive:
When NOT to archive (just increment version):
If user passes --archive or change is breaking:
# Determine current version from metadata or count existing versions
CURRENT_VERSION=$(ls -d [skill-name]-v* 2>/dev/null | wc -l | tr -d ' ')
NEXT_VERSION=$((CURRENT_VERSION + 1))
# Archive
cp -r [skill-path] [skill-path]-v${NEXT_VERSION}
echo "Archived as [skill-name]-v${NEXT_VERSION}"
Then proceed with modifications to the main (unversioned) skill directory.
For major changes:
cp [path]/SKILL.md [path]/SKILL.md.backup
User can restore if needed.
User: "add email notification to weekly-report"
## Proposed Changes to weekly-report
### Changes
1. **Process**: Add Step 5 before Write State
Adding:
```markdown
### Step 5: Send Notification
Send email summary to stakeholders:
- To: $NOTIFY_EMAIL
- Subject: Weekly Report - [date]
- Body: Summary of report highlights
State Dependencies: Add email service
Adding row: | Email | SMTP/$NOTIFY_EMAIL | | ✓ | Send notifications |
Checklist: Add verification
Adding:
### Example 2: Change Schedule
User: "run daily-backup twice a day"
Frontmatter: Update schedule
Before:
schedule: "0 2 * * *"
After:
schedule: "0 2,14 * * *" # 2am and 2pm
Name: Consider renaming
Current name "daily-backup" implies once daily. Options: a) Keep name (still daily, just twice) b) Rename to "scheduled-backup"
Recommend: (a) keep name
---
## Related Skills
| Skill | Purpose |
|-------|---------|
| [/create-playbook](../create-playbook/) | Create new playbook |
| [/playbook-architect](../playbook-architect/) | Audit and bulk adoption |