Menu
Analyze a skill issue before implementing — reads the affected SKILL.md, identifies what changes are needed and any risks
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Run a remote Trinity agent task in a sequential, bounded loop — a fixed number of iterations or until a stop signal, with optional response chaining. Fires server-side via run_agent_loop (caller can disconnect), then polls and renders progress. The remote, durable counterpart to Claude Code's local /loop. Add `local` to run the same bounded loop natively in this session instead — inline back-to-back iterations, or a hand-off to the built-in /loop when a cadence is given.
Make any agent a system-aware orchestrator — installs /discover-agents (discover the fleet from live Trinity and/or a repo list into a descriptive fleet/system-map.yaml), /compose-system (turn the map into a Trinity SystemManifest and deploy_system), and /orchestrate (route, fan out, and run ephemeral agents via Trinity MCP). Aligns with Trinity's existing SystemManifest; no parallel standard.
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
Create a personal medical-records agent — bootstraps a profile from your existing health documents, then ingests new files, maintains structured memory, tracks lab trends, prepares doctor visits, and runs an evidence-based nutrition + supplement framework
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
| name | autoplan |
| description | Analyze a skill issue before implementing — reads the affected SKILL.md, identifies what changes are needed and any risks |
| argument-hint | [issue-number] |
| allowed-tools | Bash, Read, Glob |
| user-invocable | true |
| metadata | {"version":"1.0","created":"2026-04-28T00:00:00.000Z","author":"Ability.ai","changelog":["1.0: Initial version — analyzes an open skill issue before implementing, reading the affected SKILL.md to produce a focused plan and surface risks"]} |
ℹ️ 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.changelogabove — e.g.autoplan vX.Y — recent: <summary>. Then proceed.
Analyze an open issue before touching any files. Reads the affected skill's SKILL.md, understands the current behavior, and produces a focused implementation plan. Run this after /claim and before /adjust-playbook or /create-playbook.
| Source | Location | Read | Write | Description |
|---|---|---|---|---|
| GitHub Issues | Current repo | Yes | No | Issue to analyze |
| SKILL.md files | .claude/skills/*/SKILL.md | Yes | No | Current playbook behavior |
| CLAUDE.md | ./CLAUDE.md | Yes | No | Agent identity and constraints |
If $ARGUMENTS provided: load that issue number.
If no argument: find current in-progress issue:
gh issue list --label "status:in-progress" --state open --json number,title,body,labels --limit 1
If none in-progress, ask user to provide an issue number or run /claim first.
gh issue view $NUMBER --json number,title,body,labels
Look for a skill:* label on the issue. Extract the skill name.
If no skill label:
claim)claim. Is that right, or is it project-level?"If project-level (no specific skill): note that and skip to Step 6.
cat .claude/skills/$SKILL_NAME/SKILL.md
If skill doesn't exist yet (this is a new skill issue), note that and skip to Step 5b.
Compare the issue requirements against the current SKILL.md. Identify:
What section(s) change:
Interface impact:
argument-hint change? (affects how users call the skill)name change? (breaking — requires --archive flag in adjust-playbook)automation mode change? (autonomous ↔ manual has significant implications)work-loop routing behavior?Complexity:
/adjust-playbook $SKILL_NAME--archive + new versionIf this is a new skill that doesn't exist yet:
Output a clear, terse implementation plan:
## Autoplan: #$NUMBER — $TITLE
**Skill affected:** `$SKILL_NAME`
**Change type:** [Step edit | New step | Interface change | New skill | Project-level]
**Implement with:** `/adjust-playbook $SKILL_NAME` [or `/create-playbook`]
### What to Change
1. [Specific change 1 — which section, what to add/modify]
2. [Specific change 2]
### Risks / Watch-outs
- [e.g., "Changing argument-hint is a user-visible interface change"]
- [e.g., "This step runs in work-loop — verify autonomous compatibility"]
- [e.g., "None — isolated step edit"]
### Recommended Approach
[One sentence: adjust-playbook with specific instruction, or create-playbook with tier]
| Error | Action |
|---|---|
| No in-progress issue and no argument | Ask for issue number or run /claim |
| Skill directory not found | Note as new skill — plan from scratch |
| Issue has no skill label | Infer from content, confirm with user |