adjust-playbook

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.12","created":"2025-02-10T00:00:00.000Z","updated":"2026-08-18T00:00:00.000Z","author":"Ability.ai","changelog":["1.12: Platform-truth refresh (Trinity v0.9.0, tag 93d7ce7c) — headless-fitness checklist + fork note distinguish background shell jobs (still killed at turn-end) from background subagents/forks (waited for since trinity#2127, bounded by execution timeout + 300s idle-finalize); `background: false` stays the rule, now for the right reason","1.11: Add the Make-Callable-by-Other-Agents adjustment (Playbook-Call Rule, fleet convention protocols/playbook-call.md, operator direction 2026-08-16) — one-line invocability, declared args incl. --run <id>, runs-only-itself when called by another agent; no I/O schema","1.10: Schedule note corrected for ent#89 — Trinity materializes template.yaml schedules: at agent creation (disabled unless a literal YAML true, max 20, deduped by name, never re-applied on recreate), and firing also needs the agent's autonomy gate; /trinity:onboard and /trinity:sync remain the reconcile path for a live instance","1.9: Trinity-first docs refresh (verified vs Claude Code 2.1.220) — new Change Invocation & Context Controls adjustment (context: fork / agent / background, paths, user-invocable, disable-model-invocation, disallowed-tools) with two guards: disable-model-invocation: true breaks a scheduled playbook (the scheduler's message reaches the skill via model invocation), and a headless-bound context: fork without background: false loses the fork at turn-end (forks background by default since 2.1.218); autonomous validation checklist gains matching scheduled-invocation + foreground-fork lines; Routines advisory replaced with the Trinity scheduling path (schedule: → template.yaml → create_agent_schedule, message invokes by slash name, timeout ≤ agent cap); Step 1 also scans plugins/*/skills/; model override notes model: inherit","1.8: Add the Promote to Library-Grade adjustment (+ Step 3 change type) — audit a proven agent-local skill against /create-playbook's Library-Grade Rule (requires: frontmatter contract, env-var-only credentials, named missing-key errors, no host-specific assumptions), run the deterministic env-coherence + secret-scan check as a blocker, then prep the contribution to the library repo","1.7: Add the Long-Running-Task line to the Autonomous Validation Checklist — a headless run can't host a >~10-min job (auto-backgrounded past the ~10-min sync Bash ceiling, then reaped at turn-end); such work is decoupled to an OS-level cron/systemd/sidecar + done-marker and the run only triggers + verifies the artifact moved (mirrors /create-playbook 2.8)","1.6: On every change, prepend a newest-first changelog entry, bump metadata.version, and ensure the what's-new banner is present after the H1","1.5: Add Composition Rule support — Compose adjustment (replace inlined logic with a skill call), downstream-caller detection on breaking changes, transitive autonomous check","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"]}

Adjust Playbook

ℹ️ First, set expectations: before anything else, print one short line with this skill's version and its most recent change — the top entry of metadata.changelog above — e.g. adjust-playbook vX.Y — recent: <summary>. Then proceed.

Modify existing playbooks while preserving their core structure and functionality.

When to Use

• User says "update the X playbook"
• User says "add Y to the playbook"
• User says "fix the Z step"
• User says "change the schedule"
• After running a playbook and finding issues

---

Workflow

Step 1: Locate the Playbook

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

# Check plugin skills (when inside a plugin/marketplace repo)
ls plugins/*/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:"  2>/dev/null &&  


 
 d  plugins/*/skills/*/; 
  [ -f  ] && grep -l   2>/dev/null &&