Install
$ agentstack add skill-zalom-plastic-intent-executing ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Executing a Plan
Overview
Load plan from the active intent's plan.md, execute all tasks, review between tasks, report when complete.
Announce at start: "I'm using the executing-plan skill to implement this plan."
Step 0: Sync Worktree First
Before Step 1 (Load Plan) in either workflow below, sync the code worktree with main first, so no edit lands on a path a merged rename or delete already removed:
git -C fetch origin && git -C merge --ff-only origin/main
After syncing, verify the plan's target files exist at the paths plan.md names. If a named file or directory is missing (renamed or removed upstream), stop and report it rather than editing a stale path.
Mode Selection
Check for superpowers first
If superpowers:subagent-driven-development is available as a skill, delegate to it. If only superpowers:executing-plans is available, delegate to that. If neither is available, use Plastic's own execution engine below.
CRITICAL: when delegating to superpowers:
- Tell the skill that the plan is at
~/.plastic/store/ID--slug/plan.md(notdocs/superpowers/plans/) - Tell the skill that specs live at
~/.plastic/store/ID--slug/spec.md(notdocs/superpowers/specs/) - All meta-artifacts must stay inside
~/.plastic/store/ID--slug/ - Code files go in the project tree as normal
- Superpowers skills respect "user preferences for plan/spec location"; Plastic IS that preference
Subagent-Driven (Default)
Dispatches a fresh subagent per task. Controller never implements, only dispatches, reviews, and tracks progress. Two-stage review after each task: spec compliance first, then code quality.
Inline (Fallback)
Executes tasks sequentially in the current session. Use when subagents aren't available or user explicitly requests inline mode.
To select: user says "inline", "execute inline", or "no subagents".
Subagent-Driven Workflow
Step 1: Load Plan
Run Step 0 (Sync Worktree First) before this step.
- Read the active intent's
plan.md - Extract ALL tasks with their full text, store in memory. Never make subagents read the plan file.
- Create a task list to track progress
Step 2: Execute Each Task
For each task sequentially (never parallel: conflict risk):
a. Dispatch implementer subagent Use the Agent tool with the implementer prompt template. Include:
- Full task text (pasted in, not file reference)
- Project context from CLAUDE.md
- Active intent context from
{ID}--{slug}.md
b. Handle implementer response
- DONE → proceed to spec review
- DONEWITHCONCERNS → note concerns, proceed to spec review
- NEEDS_CONTEXT → provide missing context, re-dispatch
- BLOCKED → stop, report to user, wait for resolution
c. Dispatch spec compliance reviewer Use the Agent tool with spec-reviewer prompt. The reviewer reads actual code and compares against the task requirements. Pass/fail.
- If fail: implementer fixes, spec reviewer re-reviews (loop until pass)
d. Dispatch code quality reviewer Only after spec compliance passes. Reviews clean code, testing, architecture. Pass/fail.
- If fail: implementer fixes, quality reviewer re-reviews (loop until pass)
e. Tick as it lands, then move to next Follow ## Tick-as-you-land below: move the task's checklist item to ## Completed and add a ## Session Log row in the same edit.
Step 3: Final Review
After all tasks complete, dispatch a final reviewer for the entire implementation.
Step 4: Update Intent and Complete
Capture observations in ## Insights. When ALL checklist items are checked:
- Write
outcome.mdwith detailed results in the intent directory, using the${CLAUDE_PLUGIN_ROOT}/templates/outcome.mdform. Set the frontmatterdisposition: delivered(the delivered terminal).outcome.mdis mandatory at every terminal and self-declares its disposition (canonical done-marker in PLASTIC.md). - Write
## Outcomesummary in the intent file (1-2 sentences) - Move intent from
## Activeto## Completedin INDEX.md (with today's date) - Update cluster entries to show
_(completed)_ - Auto-commit:
cd && git add . && git commit -m "feat: complete intent : " - QMD reindex LAST (canonical End tail). As the final End-tail step, after the terminal move and any disarm, ALWAYS refresh the QMD search index for this store (no-op when QMD is absent), running in the background so it never blocks the turn:
ruby ~/.plastic/scripts/qmd-sync reindex --store --async. Completion is the lifecycle event that keeps the search index fresh, and the reindex runs last so the index never references a bridge or lock that is about to disappear (see PLASTIC.md## Delivery Isolation and the Single-Owner Lock).
This is NOT optional. An intent with all checklist items done but no Outcome is a broken state. Complete the intent immediately, do not leave it for later.
Inline Workflow
Step 1: Load and Review Plan
Run Step 0 (Sync Worktree First) before this step.
- Read plan file from active intent
- Review critically, raise concerns before starting
- Create task list to track progress
Step 2: Execute Tasks
For each task:
- Mark as in_progress
- Follow each step exactly
- Run verifications as specified
- Tick as it lands: follow
## Tick-as-you-landbelow
Step 3: Update Intent and Complete
Capture observations in ## Insights. When ALL checklist items are checked:
- Write
outcome.mdwith detailed results in the intent directory, using the${CLAUDE_PLUGIN_ROOT}/templates/outcome.mdform. Set the frontmatterdisposition: delivered(the delivered terminal).outcome.mdis mandatory at every terminal and self-declares its disposition (canonical done-marker in PLASTIC.md). - Write
## Outcomesummary in the intent file (1-2 sentences) - Move intent from
## Activeto## Completedin INDEX.md (with today's date) - Update cluster entries to show
_(completed)_ - Auto-commit:
cd && git add . && git commit -m "feat: complete intent : " - QMD reindex LAST (canonical End tail). As the final End-tail step, after the terminal move and any disarm, ALWAYS refresh the QMD search index for this store (no-op when QMD is absent), running in the background so it never blocks the turn:
ruby ~/.plastic/scripts/qmd-sync reindex --store --async. Completion is the lifecycle event that keeps the search index fresh, and the reindex runs last so the index never references a bridge or lock that is about to disappear (see PLASTIC.md## Delivery Isolation and the Single-Owner Lock).
This is NOT optional. Complete the intent immediately when work is done.
Tick-as-you-land
As each task lands, in the same edit: move its checklist item from ## In Progress to ## Completed in checklist.md, and add one ## Session Log row (Date, Items Completed, Notes). Do not batch several tasks' worth of checklist updates into one later edit; tick the moment the task is verified, before moving to the next task.
Verify before every owner gate
Hard rule: before presenting any completed work to the owner, independently verify it. Grep or run the artifact the work just produced (the test suite, the changed file, the installed output) rather than restating the intended change. Never present an unverified claim to the owner. If verification fails, fix it before the gate, not after.
Methods report (audits and sweeps)
When the work is an audit or a sweep (checking many files or many instances of something rather than building one artifact), deposit a methods report to {intent_dir}/resources/ before the gate: what was checked, how it was checked, and what was found. This lets the owner review the method, not just the conclusion.
Reroute vs dispatch
A human-facing instruction like "run /plastic-intent-speccing" means the user types that slash command themselves; it is never handed to a subagent. Agent-facing dispatch text is a prompt passed to the Agent tool for a subagent to execute. Keep the two separate: do not address a slash command to a subagent, and do not paste a dispatch prompt at the user.
Owner decisions during Exec
When presenting a batch of Exec decisions for the owner to rule, read ~/.plastic/_decision-tables.md and follow the numbered-table procedure, persisting each ruling with --stage Exec.
Gate position
- Before:
plan.mdandchecklist.mdexist; the worktree is armed. - Produces: code changes, a ticked checklist, and (for audits or sweeps) a methods report in
resources/. - Next: intent-ending owns
outcome.md(see intent 161). This skill's own Update-Intent-and-Complete step above is unchanged by this note.
Model Selection for Subagents
Match model to task complexity:
- Mechanical tasks (config files, boilerplate): cheapest available
- Standard implementation: default model
- Architecture, integration, review: most capable model
Prompt Templates
Subagent prompts are in this skill's directory:
implementer-prompt.md: template for implementer subagentsspec-reviewer-prompt.md: template for spec compliance reviewerscode-quality-reviewer-prompt.md: template for code quality reviewers
Read the appropriate template when dispatching each subagent type.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: zalom
- Source: zalom/plastic
- License: MIT
- Homepage: https://github.com/zalom/plastic
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.