Plan-first workflow for non-trivial work: plan with done criteria, create a tracking issue, package context as documents on the issue, decide where code live...
Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for levineam/workflow-execution.
Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Workflow Execution" (levineam/workflow-execution) from ClawHub.
Skill page: https://clawhub.ai/levineam/workflow-execution
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.
Command Line
CLI Commands
Use the direct CLI path if you want to install manually and keep every step visible.
Name/description describe a plan-first workflow for non-trivial work; the SKILL.md and reference files only describe creating issues, attaching plan/design/context documents, choosing repo destinations, and spawning executing agents. No unrelated credentials, binaries, or install steps are requested.
✓
Instruction Scope
Runtime instructions stay within the workflow's scope: create/read/update tracking issues, attach documents, spawn or message agents, and update progress. The skill tells agents to read issue bodies, comments, or local plan files (expected for a tracker-based workflow). It does not ask the agent to scan unrelated system files or exfiltrate data.
✓
Install Mechanism
There is no install spec and no code files — lowest-risk model. Everything is instruction-only and will not drop archives or binaries on disk.
ℹ
Credentials
The skill declares no required environment variables or credentials. It references use of tools/APIs (e.g., `gh` CLI, GitHub API, Paperclip API) which in practice require authentication; that is expected for this purpose, but the skill does not request or manage tokens itself.
✓
Persistence & Privilege
always:false (default); the skill may be invoked autonomously (platform default) which is normal for an execution/handoff workflow. The skill does not request persistent agent-level privileges or modify other skills' configs.
Assessment
This skill is coherent and instruction-only, but review operational details before use: (1) The workflow expects you to use trackers and CLIs (GitHub, Paperclip, or local files); those systems will require API tokens—limit token scopes and keep them out of plan documents. (2) Do not put secrets (passwords, private keys, credentials) in issue bodies, comments, or local plan files; treat plan documents as potentially readable by project collaborators. (3) Ensure any executing agent you spawn has least privilege for repo/issue operations and review audit logs for automated actions. (4) Confirm tools the skill references (e.g., gh) are installed and authenticated in your environment; the skill itself won't install or manage those. If you need the skill to perform sensitive automation, validate agent permissions and token scopes in your CI/agent platform first.
Like a lobster shell, security has layers — review code before you run it.
latestvk9701dm5m7k9ayf2xdc277nwh9846xrk
118downloads
0stars
1versions
Updated 3w ago
v1.0.0
MIT-0
Workflow Execution
Run this workflow for any meaningful work. The core loop: plan → track → package context → route → hand off → execute → verify.
Core Principles
Plan before acting. The plan lives on the tracking issue, not in chat.
Package context as documents, not spawn strings. The executing agent should never depend on chat history.
Decide where code lives before writing any code.
Prefer the simplest approach that can pass verification.
Be explicit about proof, not optimism.
Phase 1: Plan
Enter planning before acting when any trigger is true:
Work requires 3 or more concrete steps
Work changes architecture, interfaces, data flow, or shared contracts
Work includes risky edits (security, auth, migrations, destructive operations, production config, or unknown blast radius)
Work will be handed off to another agent or subagent
Plan contents
Goal — one sentence describing what done looks like.
Done criteria — explicit, checkable conditions. Not "it works" but "tests pass, PR merged, deployed."
Constraints — what must not break, budget limits, timeline, dependencies.
Failure modes — what could go wrong and how you'll detect it.
Ordered steps — small, each with a verification method (test, build, smoke check, log proof, diff).
Phase 2: Track
Before implementation starts, create or reference a tracking issue in your project management system.
What to do
Create an issue with a clear title and the goal from Phase 1.
Attach the plan as a document on the issue (key: plan). This is the source of truth — not a chat message, not a comment, a structured document.
Link to parent issues if this work is part of a larger effort.
Why documents, not descriptions
Documents are revisioned — you can see how the plan evolved.
Documents are keyed — plan, design, context each have a clear role.
Documents are agent-readable — any agent that picks up the issue gets the full context.
Documents survive context resets — when a session compacts or a new agent spawns, the context lives on the issue, not in memory.
Tracker reference implementations
This skill is tracker-agnostic. See references/ for how to do this with specific systems:
references/tracker-paperclip.md — Paperclip Issues + Documents API
Attach when the executing agent needs background that isn't obvious from the code:
Prior decisions and their rationale
Relevant code references (files, functions, patterns to follow)
Domain knowledge the agent won't have
Links to related issues or discussions
Packaging principle
Ask: "If a brand new agent picked up this issue with zero chat history, could they do the work?" If not, add more context documents.
Phase 4: Route
Before execution, decide where the code lives.
Decision criteria
Signal
Destination
Work extends an existing project/repo
Existing repo — branch off main
Work is reusable, publishable, or useful to others
New repo — create it, then work there
Work is pure local glue, config, or one-off automation
Local workspace — but document why it's local
Routing rules
Default: existing repo. Most work extends something that already exists.
New repo trigger: If you find yourself thinking "other people could use this" or "this should be a skill/package," it's a new repo.
Local-only justification required. If code stays in the local workspace, document why — it should be because it's genuinely specific to this setup, not because it was easier.
Branch naming: Include the tracking issue identifier in the branch name (e.g., SUP-490/skill-rewrite).
Phase 5: Hand Off
Spawn the executing agent with an issue reference, not inline context.
Dispatch rule
Code handoffs MUST use sessions_spawn, not sessions_send.
sessions_spawn triggers the full enforcement pipeline (Lobster gate, spawn-code-lint, post-spawn PR creation). sessions_send bypasses all of it. Use sessions_send only for non-code work: status checks, coordination, questions.
The test: if the message asks the target agent to write, edit, or move code → sessions_spawn. Everything else → sessions_send is fine.
Handoff protocol
The spawn message includes: the tracking issue identifier, the repo/branch to work in, and any model/thinking preferences.
The executing agent's first step is: read the issue, read attached documents (plan, design, context), then proceed.
The executing agent updates the issue as it works — comments for progress, status changes for state transitions.
Subagent strategy
Spawn by default when work spans multiple files/systems, requires research, or includes long-running operations.
One clear objective per subagent with concrete deliverables.
Prefer fewer, well-scoped subagents over many tiny ones.
Phase 6: Execute
Minimal-impact changes
Implement the smallest change set that satisfies the goal.
Reuse existing patterns before inventing new abstractions.
Keep naming, structure, and style consistent with local code.
Avoid incidental cleanup unless it directly reduces risk.
Failure recovery hierarchy
When something goes wrong during execution, follow this priority order:
Transient provider failure (429, timeout, model overload): OpenClaw's native
model fallback chain handles this automatically. Do not change tracker issue
status. Continue in the same session once the request succeeds.
Context reset or compaction: Re-read the plan, context, and design
documents from the tracking issue. Never reconstruct plan state from in-session
memory after compaction — the issue documents are the source of truth.
Durable blocker (missing dependency, unclear requirements, architectural gap):
Update the tracking issue status to blocked. Add a comment naming the specific
blocker and what needs to resolve it.
The tracker is an audit trail and coordination hub — not the place to manage transient retries.
Do not flip status on transient errors, partial progress, or model fallbacks.
Autonomous bug-fix behavior (guardrailed)
When bugs appear during execution:
Reproduce and isolate the failing path.
Form the smallest plausible fix hypothesis.
Apply minimal-touch patch.
Re-run impacted checks and one nearby regression check.
Repeat until pass or a guardrail is hit.
Stop and escalate when:
Root cause remains unclear after multiple attempts.
Fix requires major architectural change.
Risk of data loss or security impact is non-trivial.
Demand elegance (balanced)
Reject hacks that create hidden fragility or repeat incidents.
Prefer clear structure over clever shortcuts.
Scale sophistication to task size — don't over-engineer obvious fixes.
Phase 7: Verify
Do not mark complete without proof.
Evidence types
Tests: targeted unit/integration/e2e checks.
Static checks: lint, typecheck, build.
Runtime checks: smoke test key affected flows.
Logs/output: command results or excerpts showing success.
Diff sanity: verify only intended files changed.
Governance
Significant code changes: branch + PR + review before merge.
CI must pass before merge.
Fix review comments before closing.
Close the loop
Update the tracking issue status to done.
Add a closing comment with verification evidence.
If the work produced a reusable lesson, capture it durably.
Self-Correction Loop
If the correction cycle was triggered by a context reset or compaction, re-read the issue's plan, context, and design documents before resuming — do not reconstruct plan state from in-session memory.
After any correction cycle (failed check, rework, rollback):
Record what failed and why (brief, concrete).
Extract one reusable lesson/pattern.
Apply that lesson immediately to remaining work.
Capture a durable note when the lesson is broadly reusable.
