메뉴
Autonomous intent delivery - agent takes over How and Exec. Use when user says "auto", "take it from here", "deliver this", or when brainstorming-grill-me concludes and user confirms autonomous execution. Requires an active intent in INDEX.md.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Wrap, finish, close, or mark an intent Done, delivered or abandoned. Use when completing or abandoning an intent, when a checklist reaches 100 percent and Exec is finished, or when asked to "wrap this up".
Use when diagnosing Plastic installation health, after updates, or when something seems broken. Runs checks and reports findings with fix options.
Use when updating Plastic. Runs the `update` verb, which reads the installed VERSION, derives its channel, queries npm dist-tags, and advances to the next version on that channel (or switches channel with a flag).
Use when merging a feature branch to main and tagging a release, bumping the version, or when the user says "release", "tag", or "ship it"
Use when completing or reviewing intents, reorganizing the index, or when the intent store needs maintenance. Examples: <example>Context: User has finished implementing a feature. user: "This intent is done, clean up the index" assistant: "I'll use the intent-curator to update the intent status and reorganize INDEX.md" <commentary>Intent lifecycle change triggers curator for index maintenance.</commentary></example> <example>Context: The intent store has grown and clusters need review. user: "Organize the intents" assistant: "I'll use the intent-curator to review clusters, flag orphans, and suggest connections" <commentary>Periodic maintenance of the Zettelkasten structure.</commentary></example>
Board a session onto an intent: take the lock FIRST, confirm savepoint state, ask auto or guided ONCE, then resume at the latest delivered station and run the cycle to Done. Use on `continuing --intent {id}`, when a new intent is registered and the user asks to work it, or when the user picks an intent to work. Requires the intent in INDEX `## Active`.
| name | plastic-auto |
| description | Autonomous intent delivery - agent takes over How and Exec. Use when user says "auto", "take it from here", "deliver this", or when brainstorming-grill-me concludes and user confirms autonomous execution. Requires an active intent in INDEX.md. |
| user-invocable | true |
Announce: "Taking over intent [ID] - [name] for autonomous delivery."
Advisory (not a gate). At auto-mode start, recommend once that the user run this
orchestrating main session on the best available thinking model (Fable, Opus, or whatever
supersedes them) for the sharpest gating and synthesis. This is advice only: it changes no
behavior and blocks nothing if ignored. It concerns the human's MAIN session; dispatched
subagents keep their pinned tier and never resolve to Fable, unless an explicit
agents.models.<name> config override names Fable for that role, in which case the override
is honored as written. The two advisors, plastic-advisor and plastic-faux-advisor, are not
lifecycle stage roles: the never-Fable rule governs stage agents only. Neither is ever
dispatched by the auto pipeline; they are consultation roles summoned deliberately by the user
or the main session, and their models are user configuration (fable and opus by default on
Claude Code).
An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found. Create one first with /plastic-intent-creating."
If multiple active intents exist, ask the user which one to deliver (this is the only question auto asks).
Picking work when no intent is specified. If the user says "auto" without naming an intent and none is active, consult the roadmap first (the primary planning surface), then fall back to the dashboard queue. Read the tier's mid-flight roadmap:
ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <tier>/roadmaps
Branch on state:
dispatchable: work its dispatchable_queue in rank order (the head is the next batch
entry). These are the current batch's queued intents, parallel-safe within the batch.in_flight: the frontier batch is still delivering. Report it and wait. Do NOT dispatch a
later batch and do NOT fall through to the dashboard, the roadmap is live.none or exhausted: no roadmap, or nothing left to dispatch. Fall back to the dashboard
queue below. (The global store has no roadmap, so it always reports none and falls back.)Dashboard fallback:
ruby ~/.plastic/scripts/dashboard.rb all --json
Work dispatchable_queue in rank order (these are defer/research dispositions -
safe to deliver autonomously). Leave human_only and next_big_thing for the user - those
are drive/triage items the human should lead. See the plastic-dashboard skill.
QMD-first (when available): when the user describes the work to deliver rather than naming an
intent, before scanning the store with grep/Read run
ruby ~/.plastic/scripts/qmd-sync search "<terms>" to surface candidate, prior, or duplicate
intents, then open the authoritative intent file for the hit you take over. The command is a no-op
when QMD is absent, so fall back to the existing INDEX.md / file scan. (This is discovery; the
reindex step under Completion is separate.)
Auto mode sizes every intent S/M/L at Why, deterministically, then matches agent topology
and artifact depth to that size. Extended walkthrough: references/tiers.md.
actions/ACTION_1.md), never an empty actions/. S may also skip the QMD discovery
deposit when chain and sources are both empty. L: today's full team (## Team Spin-Up
below), one actions/ACTION_N.md per task.outcome.md as truth of delivery, the delivery lock,
worktree isolation, intent creation via skill, INDEX as status truth, the QMD reindex
at End. Lightness is about ceremony, never about these guarantees.Tier: S|M|L at the top of spec.md. Convention-only: read by the
orchestrator, never validated by any gate or by doctor.Immediately after selecting the intent - before any other work - arm auto mode. This writes the session bridge that makes the code-edit gate live, so project code cannot be edited before the plan exists (the gate applies to YOU, the orchestrator):
ruby -r ~/.plastic/scripts/lib/bridge -e \
'codex=ENV["CODEX_THREAD_ID"].to_s.strip; claude=ENV["CLAUDE_CODE_SESSION_ID"].to_s.strip; harness=!codex.empty? ? "codex" : (!claude.empty? ? "claude" : nil); session=!codex.empty? ? codex : (!claude.empty? ? claude : nil); Bridge.arm_auto(session, intent_id: "<ID>", intent_dir: "<STORE>/<dir>", store: "<STORE>", name: "<name>", harness: harness, agent: "plastic-enforcer", thread: (!codex.empty? ? codex : nil))'
Replace <ID>, <STORE> (e.g. ~/.plastic/projects/<slug>/store or ~/.plastic/store),
<dir> (the ID--slug directory), and <name>. The first argument is the session id you
want the bridge keyed by: pass the hook stdin session_id when you have it. The executable
snippet trusts a nonblank CODEX_THREAD_ID as Codex, otherwise a nonblank
CLAUDE_CODE_SESSION_ID as Claude, otherwise leaves harness and thread unknown. Never guess
identity from an absent runtime variable. Arming always succeeds and acquires the
durable delivery.lock in the intent dir. For the resolve_session fallback chain
(why arming never needs a non-empty session env var, and what the lock ownership model
implies for later tool calls) read references/end-tail.md.
Hard rule for the rest of this run: do NOT edit project code (anything outside the
intent directory / ~/.plastic/) until plan.md AND checklist.md exist for the intent.
Honor the cycle: What → Why (spec.md) → How (plan.md + actions/ + checklist.md) → Exec.
--skip-permissions - bypass hard stops on destructive actions on existing projects. Full trust mode. Default: off.This is the L-tier shape (see ## Tiers above); S/M collapse it to one thinker agent.
Auto mode spins up exactly ONE enforcer-led team per intent. The plastic-enforcer IS this orchestrator (you), not a separately dispatched agent, which avoids the who-gates-the-gater regress.
Roster (one role per cycle stage):
## Context + ### Decisionsspec.md)plan.md + actions/ + checklist.md)## Insights)Dispatch rule: sequential, one specialist per stage on one branch (the deliverables share files). Gate each deliverable against the stage's exit criteria before handing off. The How and Exec phases below default to Plastic's native dispatch (plastic-intent-executing) and delegate to the superpowers skills only when they are available or the user asks; do not restate the phase mechanics here.
Spawn preamble (live-state injection): before dispatching any specialist, run scripts/spawn-preamble <intent_dir> --role <role> and PREPEND its output to that specialist's prompt. The preamble is a deterministic, filesystem-only snapshot of the active intent (id, intent line, current stage, and the provisioned code worktree path when one exists on disk) plus the honoring instruction, so every spawned agent boots with accurate live state instead of guessing. This is the authoritative L2 mechanism for harnesses whose sub-agents do not inherit a top-level session event (see docs/reference/harness-adapters.md).
Dispatch-time model contract (belt-and-braces): alongside the preamble, resolve each specialist's model through the config chain (read-config agents.models.<basename> --project <repo>: project override, then global, then the shipped tier default) and pass it explicitly at dispatch. Never rely on the dispatched role's frontmatter alone; a resolved subagent model is never Fable,
unless an explicit agents.models.<name> config override names Fable for that role, in which
case the override is honored as written. The two advisors, plastic-advisor and
plastic-faux-advisor, are not lifecycle stage roles: the never-Fable rule governs stage
agents only. Neither is ever dispatched by the auto pipeline; they are consultation roles
summoned deliberately by the user or the main session, and their models are user configuration
(fable and opus by default on Claude Code).
Completion report (require-then-synthesize): every dispatched specialist MUST end with a structured completion report as its final message. The preamble's REPORT_CONTRACT injects this and the role prompts carry the per-role format (see references/agent-report-contract.md). Because child-agent honor is best-effort across harnesses, this is decision-shaping, not a hard block. When a specialist returns no usable report (it went idle, emitted only a bare ping, or its message was lost to a mid-run interjection), run scripts/agent-report <intent_dir> --role <role> to synthesize a deterministic filesystem-derived report so the handoff account always exists. Use the agent-authored report when present, the synthesized one otherwise.
Final-gate review: dispatch an independent reviewer subagent at the final gate only, not as a standing role.
The enforcer's session owns the delivery lock. Per-stage specialists run in their own sessions and would be denied by the lock gate, so register each one as a delegate before (or when) it needs to write into the intent dir:
CODEX_THREAD_ID for Codex, or CLAUDE_CODE_SESSION_ID for Claude. Use the
specialist/hook identity when known; never infer a harness or model from missing context.ruby ~/.plastic/scripts/plastic-lock delegate --intent-dir <intent-dir> --delegate <specialist-session-id> --harness <specialist-harness-when-known> --agent <role> --model <resolved-model-when-known> --thread <reported-CODEX_THREAD_ID-when-Codex>
Omit --harness, --model, or --thread when that value is unknown; --agent <role> is
always known from the dispatch roster.finished means the specialist returned a usable completion report, whether
agent-authored or synthesized through scripts/agent-report.failed means the specialist returned blocked, errored, or without a usable
completion report that can be synthesized.ruby ~/.plastic/scripts/plastic-lock delegate --intent-dir <intent-dir> \
--delegate <specialist-session-id> --status finished --harness <same-specialist-harness-when-known> \
--agent <same-role> --model <same-resolved-model-when-known> --thread <same-CODEX_THREAD_ID-when-Codex>
ruby ~/.plastic/scripts/plastic-lock delegate --intent-dir <intent-dir> \
--delegate <specialist-session-id> --status failed --harness <same-specialist-harness-when-known> \
--agent <same-role> --model <same-resolved-model-when-known> --thread <same-CODEX_THREAD_ID-when-Codex>
Only the owner can delegate. Delegates cannot re-delegate or release.
Headless manual gate: when running headless or in the background, still enforce gates manually rather than relying on hooks alone. The PostToolUse gate hook reads session_id from hook stdin, and the savepoint ledger write is decoupled from the bridge (derived from the file path, so it fires even with no session id) - these do NOT no-op. What can degrade is the bridge-keyed stage enforcement: if no session id reaches the bridge and no matching bridge is discovered, the stage-gate enforcement step exits without acting, so verify state yourself. The bridge still resolves arming via CLAUDE_CODE_SESSION_ID or the derived-key fallback (see the arm-gate note above).
Solo fallback: if the harness has no subagent dispatch, fall back to a single agent walking the full What, Why, How, Exec cycle yourself. This preserves current behavior.
Read the active intent's savepoint.md FIRST (intent 81): the last line classifies the stage,
and you then verify only that line's artifact before entering. Fall back to the filesystem probe
below only when the ledger is missing (then rebuild it with Bridge.rebuild_savepoint).
| Ledger last line | Enter |
|---|---|
What {id}--{slug}.md (born) or no spec | Start / complete Why (write spec.md) |
Why spec.md created | Enter How |
How plan.md created / How checklist.md created / Exec started | Enter Exec (verify plan + checklist) |
Exec outcome.md created | Exec done; complete the intent |
| `Done delivered | abandoned` |
Filesystem fallback (ledger missing only):
| Check (in order) | Stage |
|---|---|
checklist.md exists with some items checked | Resume Exec from last unchecked item |
plan.md + checklist.md exist (no items checked) | Enter Exec |
spec.md exists, no plan.md | Enter How |
## Context has content in intent file, no spec.md | Complete Why (fill gaps, write spec.md) |
Only ## Intent exists | Start Why from scratch |
Announce which stage you're entering and why.
Notify user (What briefing): brief per references/human-report-contract.md
(State: the work picked up and why it matters now; Risk: scope uncertainty; Call: confirm
this is worth doing, or proceed).
When entering at Why stage:
## Context and ### Decisions from the intent file## Links), web search if needed. NO questions to human.## Context > ### Decisions with rationale## Insights with (autonomous) marker: "Decision: chose X because Y (autonomous)"spec.md - consolidated specificationreferences/human-report-contract.md
(State: the approach chosen, one line; Risk: the main trade-off; Call: the one decision
needed, approve or pick an option).Then proceed to How.
Every tier runs all four steps below (see ## Tiers above). The actions/ directory is
scaffolded (with a .gitkeep) at intent birth; the planner then writes at least one REAL
ACTION_N.md into it at every tier. The tier only changes step 3's granularity: S/M write
one consolidated actions/ACTION_1.md, L writes one actions/ACTION_N.md per task. A
.gitkeep-only or empty actions/ fails the How gate.
superpowers:writing-plans is available as a skill, delegate plan creation to it. Tell it the plan saves to the active intent's directory (not docs/superpowers/plans/).plan.md directly - implementation plan with numbered tasksACTION_N.md into the existing actions/ directory, self-contained (S/M: one consolidated ACTION_1.md; L: one per task)checklist.md - execution registry with checkboxes covering all actionsreferences/human-report-contract.md
(State: the plan shape, task count and what it builds; Risk: the riskiest task or
dependency; Call: approve the plan to build).Then proceed to Exec.
If the plan calls for creating a new project (the intent is an implementation intent that needs a new codebase):
~/.plastic/config.yml project_roots or from intent context"Creating project
<slug>at<path>. Confirm path, or provide alternative."
plastic-project-creating skillsuperpowers:subagent-driven-development or superpowers:executing-plans is available, delegate execution to itplastic-intent-executingchecklist.md as completed## Insights with (autonomous) markerreferences/human-report-contract.md
(State: what got built and the test result; Risk: residual failures or deviations;
Call: go to review, or done).The agent MUST prefer non-destructive routes:
| Instead of... | Do this... |
|---|---|
| Drop table | Rename to _deprecated_<table>, flag for cleanup |
| Delete files | Move to .archive/ or backup branch |
| Alter column | Additive migration - new column + backfill |
| Remove feature | Feature flag off, code stays until human confirms |
| Database migration | Backup before migration, keep rollback path |
--skip-permissions)When a genuinely destructive action on an existing project has NO safe alternative:
## InsightsWith --skip-permissions, the agent logs the action in Insights but proceeds without stopping.
During initial project creation, all decisions are non-destructive by definition (there's nothing to destroy). The agent has full autonomy for greenfield choices - DB engine, framework, gems, architecture.
outcome.md with detailed results, from ${CLAUDE_PLUGIN_ROOT}/templates/outcome.md.
Set the frontmatter disposition: delivered (this is the delivered terminal). outcome.md
is mandatory at every terminal and self-declares its disposition (see the canonical done-marker
and End tail in PLASTIC.md ## Delivery Isolation and the Single-Owner Lock).## Outcome summary in the intent file (1-2 sentences)~/.plastic/projects.yml to find the project slug. If no match, skip to step 5 (default commit-only behavior).~/.plastic/projects/{slug}/project.yml. If the file doesn't exist or has no release key, skip to step 5.release.on_complete:
commit - git add + commit (same as default, proceed to step 5)commit_and_push - git add + commit + pushmanual - skip auto-commit, notify user: "Release configured as manual - commit when ready."release.verify is set, run the verify command (e.g. bundle exec rake test):
release.on_red:
fix_and_retry - attempt to fix the failure, re-run verify (max 2 retries)stop - write savepoint.md with current state, notify user: "Verify failed - savepoint written.", STOPmanual - notify user: "Verify failed: [summary]. Resolve manually."release.on_green has items, invoke plastic-releasing to handle them (tag, changelog, publish, etc.). Do NOT duplicate release logic - delegate entirely.## Insights for observations that should spawn future intents. If any:
plastic-intent-creating conventions)chain in the current intent's frontmatterplastic-intent-ending: it owns steps 1-6 of the Done
procedure (outcome/INDEX/savepoint/commit, disarm, and the QMD reindex last) as ONE
delegation, not five separate one-liners restated here. scripts/end-intent now performs
steps 1-5 itself, INCLUDING disarm (worktree release plus clearing delivery.lock): a
single call closes the intent AND clears its lock, so exit 0 means both are done. Pass
--session (this session's id, or rely on the CLAUDE_CODE_SESSION_ID fallback) so
disarm resolves the right bridge, and --index-note with a rich Completed/Abandoned entry
description (mode/tier, what shipped or why abandoned, suite result):
ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
--session "$CLAUDE_CODE_SESSION_ID" \
--index-note "<mode, tier>; <what shipped>; <suite result>"
--disposition abandoned when the intent is being moved to ## Abandoned.) A
non-zero exit needs attention before moving on: 4 means a live foreign session holds the
lock (back off), 5 means the code worktree is dirty (commit/stash first, or pass
--discard-worktree-changes deliberately), 3 means disarm ran but the lock is still
present (run /plastic-doctor check the lock status), 6 means the structure gate refused
(see the named reason on stderr; fix via the owning tool named above, then re-run). Only
Step 6 (QMD reindex, async, last) remains a separate action after this call succeeds.
Never leave an orphaned worktree; run git worktree prune on a stale reference. If any of
this ever needs to change, change plastic-intent-ending, not this skill.references/human-report-contract.md
(State: the delivered impact; Risk: residual risk; Call: the decision left to you, merge,
release, or accept). See outcome.md for details.If the agent gets stuck (can't resolve a gap, dependency is missing, tests fail persistently):
## Insightssavepoint.md with current statereferences/agent-architecture.md for the full team model (the 5-role enforcer-led team, per-stage handoffs, gate ownership, headless note, solo fallback) and the orchestrator hierarchy (Main Orchestrator, Project Orchestrators, coordination loop) when spinning up the team or understanding autonomous delivery scopereferences/tiers.md for the extended per-tier walkthrough (S/M/L worked examples, the collapsed one-thinker flow, the QMD-skip case for S) and rationalereferences/human-report-contract.md for the human-facing per-stage briefing (the
State/Risk/Call skeleton used at each "Notify user" step above, and how it differs from the
internal agent-report-contract.md)references/end-tail.md for the resolve_session fallback chain and the disarm
ordering / worktree cleanup / QMD reindex rationale referenced above