{"id":"b5a92b33-1c74-4c97-8757-b9e6ae1051b4","entityType":"agent","slug":"clawhub-kangyishuai-agent-workflow","name":"Agent Workflow","canonicalUrl":"https://www.xpersona.co/agent/clawhub-kangyishuai-agent-workflow","canonicalPath":"/agent/clawhub-kangyishuai-agent-workflow","generatedAt":"2026-10-09T20:30:09.012Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T19:15:37.133Z","emptyReason":null},"description":"A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project... Skill: Agent Workflow Owner: kangyishuai Summary: A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project... Tags: latest:1.1.0 Version history: v1.1.0 | 2026-06-04T03:33:02.695Z | user Security audit fixes: narrowed trigger scopes for all skills (SQP-1), removed forced 1% activation threshold, added explicit user con","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2.1K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17fmah22ce1z7x3h81hqbdp9n83kkdx:agent-workflow","sourceUrl":"https://clawhub.ai/kangyishuai/agent-workflow","homepage":"https://clawhub.ai/kangyishuai/skills/agent-workflow","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/kangyishuai/agent-workflow","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/kangyishuai/skills/agent-workflow","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":43,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project... "},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T19:15:37.133Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T19:15:37.133Z","emptyReason":null},"stars":null,"forks":null,"downloads":2088,"packageName":null,"latestVersion":"1.1.0","tractionLabel":"2.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T19:15:37.133Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T19:15:37.133Z","lastCrawledAt":"2026-10-09T19:15:37.133Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T19:15:37.133Z","lastVerifiedAt":null,"highlights":[{"version":"1.1.0","createdAt":"2026-06-04T03:33:02.695Z","changelog":"Security audit fixes: narrowed trigger scopes for all skills (SQP-1), removed forced 1% activation threshold, added explicit user confirmation for file writes and cleanup (SDI-1, SQP-2), replaced absolute tone bans with proportional guidance (SQP-3)","fileCount":33,"zipByteSize":120573},{"version":"1.0.0","createdAt":"2026-03-27T01:37:56.608Z","changelog":"Agent Workflow v1.0.0 — Initial release. A structured workflow plugin for OpenClaw agents. Migrated and adapted from the superpowers workflow system (originally designed for Claude Code) into a general-purpose, code-agnostic workflow engine. Features: full workflow state machine (brainstorm → plan → execute → verify → deliver), persistent state across sessions, multi-project concurrency, branch support, context-plugins for parallel forks, soft-guard goto, and 11 bundled Skills covering the full workflow lifecycle. Includes agent_workflow tool with actions: start, status, next, goto, complete, fork, join, getSkill, list, abandon.","fileCount":24,"zipByteSize":105647}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17fmah22ce1z7x3h81hqbdp9n83kkdx:agent-workflow","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T20:30:09.010Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kangyishuai-agent-workflow/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T19:15:37.133Z","emptyReason":null},"readme":"Skill: Agent Workflow\n\nOwner: kangyishuai\n\nSummary: A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project...\n\nTags: latest:1.1.0\n\nVersion history:\n\nv1.1.0 | 2026-06-04T03:33:02.695Z | user\n\nSecurity audit fixes: narrowed trigger scopes for all skills (SQP-1), removed forced 1% activation threshold, added explicit user confirmation for file writes and cleanup (SDI-1, SQP-2), replaced absolute tone bans with proportional guidance (SQP-3)\n\nv1.0.0 | 2026-03-27T01:37:56.608Z | user\n\nAgent Workflow v1.0.0 — Initial release. A structured workflow plugin for OpenClaw agents. Migrated and adapted from the superpowers workflow system (originally designed for Claude Code) into a general-purpose, code-agnostic workflow engine. Features: full workflow state machine (brainstorm → plan → execute → verify → deliver), persistent state across sessions, multi-project concurrency, branch support, context-plugins for parallel forks, soft-guard goto, and 11 bundled Skills covering the full workflow lifecycle. Includes agent_workflow tool with actions: start, status, next, goto, complete, fork, join, getSkill, list, abandon.\n\nArchive index:\n\nArchive v1.1.0: 33 files, 120573 bytes\n\nFiles: _meta.json (133b), dist/index.d.ts (429b), dist/index.js (10066b), dist/src/skill-loader.d.ts (400b), dist/src/skill-loader.js (2127b), dist/src/state-store.d.ts (1919b), dist/src/state-store.js (6965b), dist/src/workflow-engine.d.ts (2422b), dist/src/workflow-engine.js (19365b), dist/src/workflow-graph.d.ts (1027b), dist/src/workflow-graph.js (7576b), index.ts (8310b), package-lock.json (260597b), package.json (618b), skill-card.md (2235b), SKILL.md (3256b), skills/brainstorming/SKILL.md (5741b), skills/dispatching-parallel-agents/SKILL.md (4829b), skills/executing-plans/SKILL.md (2382b), skills/finishing-work/SKILL.md (4624b), skills/receiving-review/SKILL.md (5283b), skills/requesting-review/SKILL.md (3192b), skills/subagent-driven-execution/SKILL.md (7565b), skills/systematic-problem-solving/SKILL.md (8839b), skills/using-agent-workflow/SKILL.md (3641b), skills/verification-before-completion/SKILL.md (3876b), skills/writing-plans/SKILL.md (5398b), skills/writing-skills/SKILL.md (5825b), src/skill-loader.ts (2241b), src/state-store.ts (8439b), src/workflow-engine.ts (20477b), src/workflow-graph.ts (7931b), tsconfig.json (392b)\n\nFile v1.1.0:SKILL.md\n\n---\nname: agent-workflow\ndescription: \"A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project support. Trigger ONLY when the user explicitly requests a structured workflow (e.g. 'start a workflow', 'use agent-workflow', 'plan this project'). Do NOT trigger for: simple questions, one-off tasks, quick edits, routine conversations, or any task where the user has not requested workflow management.\"\n---\n\n# Agent Workflow\n\nA structured workflow engine for OpenClaw agents. Migrated and generalized from the [superpowers](https://github.com/anthropics/claude-code-superpowers) workflow system into a code-agnostic, general-purpose workflow plugin.\n\n## What it does\n\nProvides a persistent state machine that guides your agent through a complete work lifecycle:\n\n```\nbrainstorming → writing-plans → [execute] → verification → finishing-work\n                                     ↓\n                          subagent-driven-execution\n                               OR\n                          executing-plans\n```\n\nWith support for:\n- **Persistent state** — workflow survives session restarts\n- **Multi-project** — run multiple workflows concurrently\n- **Branching** — choose execution strategy at branch points\n- **Context-plugins** — fork into review/parallel-agents without leaving main flow\n- **Soft-guard goto** — jump to any step with warnings about skipped prerequisites\n- **11 bundled Skills** — covering the full workflow lifecycle\n\n## Installation\n\nThis is a **Plugin**, not a plain Skill. Install via:\n\n```bash\nopenclaw plugins install clawhub:agent-workflow\nopenclaw gateway restart\n```\n\nThen enable in your `~/.openclaw/openclaw.json`:\n\n```json\n{\n  \"plugins\": {\n    \"allow\": [\"agent-workflow\"]\n  },\n  \"tools\": {\n    \"allow\": [\"agent_workflow\"]\n  }\n}\n```\n\n## Usage\n\nIn your agent (via Feishu, Discord, or any channel):\n\n```\nStart a new workflow for my Q2 planning project\n```\n\nThe agent will call `agent_workflow` with `action: \"start\"` and guide you through the workflow.\n\n## Tool: `agent_workflow`\n\n| Action | Description |\n|--------|-------------|\n| `start` | Begin a new workflow |\n| `status` | View current state (all active workflows if no ID given) |\n| `next` | Advance to the next step |\n| `goto` | Jump to any node (soft-guard warns about skipped steps) |\n| `complete` | Mark current node done |\n| `fork` | Activate a context-plugin without leaving main flow |\n| `join` | Complete a fork and return |\n| `getSkill` | Load full SKILL.md for the current node |\n| `list` | List all workflows |\n| `abandon` | Abandon a workflow |\n\n## Bundled Skills\n\n- `brainstorming` — Turn ideas into specs\n- `writing-plans` — Break specs into tasks\n- `executing-plans` — Sequential execution\n- `subagent-driven-execution` — Parallel subagent execution\n- `verification-before-completion` — Evidence before claims\n- `finishing-work` — Delivery options\n- `dispatching-parallel-agents` — Fork independent tasks\n- `requesting-review` — Dispatch reviewer subagent\n- `receiving-review` — Evaluate feedback rigorously\n- `systematic-problem-solving` — Root-cause diagnosis\n- `writing-skills` — Create/improve Skills\n\nFile v1.1.0:skills/brainstorming/SKILL.md\n\n---\nname: brainstorming\ndescription: \"Use when the user explicitly requests design exploration, brainstorming, or says they want to discuss approaches before building. Explores user intent, requirements, and design through collaborative dialogue. Trigger ONLY when the user asks to brainstorm, explore options, or design a solution. Do NOT trigger for: simple questions, direct instructions, quick edits, routine tasks, feedback responses, mid-task interactions, or when the user wants immediate action.\"\n---\n\n# Brainstorming Ideas Into Designs\n\nHelp turn ideas into fully formed designs and specs through natural collaborative dialogue.\n\nStart by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.\n\n<HARD-GATE>\nDo NOT invoke any execution skill, take any implementation action, or start producing deliverables until you have presented a design and the user has approved it. This applies to EVERY task regardless of perceived simplicity.\n</HARD-GATE>\n\n## Anti-Pattern: \"This Is Too Simple To Need A Design\"\n\nEvery task goes through this process. A short document, a minor change, a config tweak — all of them. \"Simple\" tasks are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple tasks), but you MUST present it and get approval.\n\n## Checklist\n\nYou MUST create a task for each of these items and complete them in order:\n\n1. **Explore project context** — check existing files, docs, prior work\n2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria\n3. **Propose 2-3 approaches** — with trade-offs and your recommendation\n4. **Present design** — in sections scaled to their complexity, get user approval after each section\n5. **Confirm next step with user** — ask the user if they want a written spec saved to disk, or if the conversation summary is sufficient\n6. **Write design doc (if requested)** — only if user confirms, save to `docs/specs/YYYY-MM-DD-<topic>-design.md`\n7. **Spec self-review (if written)** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)\n8. **User reviews written spec** — ask user to review the spec file before proceeding\n9. **Ask user about next step** — ask if user wants to proceed to execution planning; do NOT automatically invoke other skills\n\n## Process Flow\n\n```dot\ndigraph brainstorming {\n    \"Explore project context\" [shape=box];\n    \"Ask clarifying questions\" [shape=box];\n    \"Propose 2-3 approaches\" [shape=box];\n    \"Present design sections\" [shape=box];\n    \"User approves design?\" [shape=diamond];\n    \"User wants written spec?\" [shape=diamond];\n    \"Write design doc\" [shape=box];\n    \"Spec self-review\\n(fix inline)\" [shape=box];\n    \"User reviews spec?\" [shape=diamond];\n    \"Ask user about next step\" [shape=doublecircle];\n\n    \"Explore project context\" -> \"Ask clarifying questions\";\n    \"Ask clarifying questions\" -> \"Propose 2-3 approaches\";\n    \"Propose 2-3 approaches\" -> \"Present design sections\";\n    \"Present design sections\" -> \"User approves design?\";\n    \"User approves design?\" -> \"Present design sections\" [label=\"no, revise\"];\n    \"User approves design?\" -> \"User wants written spec?\" [label=\"yes\"];\n    \"User wants written spec?\" -> \"Write design doc\" [label=\"yes\"];\n    \"User wants written spec?\" -> \"Ask user about next step\" [label=\"no\"];\n    \"Write design doc\" -> \"Spec self-review\\n(fix inline)\";\n    \"Spec self-review\\n(fix inline)\" -> \"User reviews spec?\";\n    \"User reviews spec?\" -> \"Ask user about next step\" [label=\"approved\"];\n    \"User reviews spec?\" -> \"Write design doc\" [label=\"needs changes\"];\n}\n```\n\n## Clarifying Questions\n\nAsk one question at a time. Do NOT ask multiple questions in one message.\n\n**Good questions:**\n- \"What problem does this solve for the user?\"\n- \"What does success look like for this?\"\n- \"Are there any constraints I should know about?\"\n- \"Who is the audience for this?\"\n\n**Bad questions:**\n- \"What's the goal, what are the constraints, and who uses this?\" (too many at once)\n\n## Proposing Approaches\n\nAfter gathering enough context, propose 2-3 distinct approaches:\n\n```\nApproach 1: [Name]\n- How it works: ...\n- Trade-offs: ...\n\nApproach 2: [Name]\n- How it works: ...\n- Trade-offs: ...\n\nMy recommendation: Approach N, because ...\n```\n\nDon't just list options — give a recommendation with reasoning.\n\n## Spec Self-Review\n\nAfter writing the spec, check it yourself before asking the user to review:\n\n1. **Completeness** — Does every stated goal have a corresponding section?\n2. **Placeholder scan** — Any \"TBD\", \"TODO\", \"fill in later\"? Fix them.\n3. **Contradiction check** — Do any two sections conflict?\n4. **Scope check** — Is anything in the spec out of scope for this task?\n\nFix issues inline. Then ask user to review.\n\n## Transition to Execution\n\nAfter user approves the spec, ask before proceeding:\n\n```\nSpec approved. Would you like me to create an execution plan using agent-workflow:writing-plans?\n```\n\nWait for explicit user confirmation before invoking any other skill or writing any file.\n\n## Common Mistakes\n\n**Skipping the design for \"simple\" tasks**\n- Problem: Unexamined assumptions cause rework\n- Fix: Always present a design, even if brief\n\n**Asking multiple questions at once**\n- Problem: Overwhelming, hard to answer\n- Fix: One question per message\n\n**Presenting a design without trade-offs**\n- Problem: User can't make informed choice\n- Fix: Always include trade-offs and a recommendation\n\n**Starting execution before approval**\n- Problem: Wasted work if direction changes\n- Fix: Hard gate — no action before approval\n\nFile v1.1.0:skills/dispatching-parallel-agents/SKILL.md\n\n---\nname: dispatching-parallel-agents\ndescription: \"Use when facing 2 or more independent tasks that can be worked on without shared state or sequential dependencies. Trigger when multiple independent problems or tasks need to be investigated or executed simultaneously. Do not trigger when tasks share state, when one depends on another's output, or when you need full context to understand the overall situation first.\"\n---\n\n# Dispatching Parallel Agents\n\n## Overview\n\nYou delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.\n\nWhen you have multiple unrelated tasks (different topics, different areas, different problems), working on them sequentially wastes time. Each task is independent and can happen in parallel.\n\n**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.\n\n## When to Use\n\n```dot\ndigraph when_to_use {\n    \"Multiple tasks?\" [shape=diamond];\n    \"Are they independent?\" [shape=diamond];\n    \"Single agent handles all\" [shape=box];\n    \"One agent per task domain\" [shape=box];\n    \"Can they work in parallel?\" [shape=diamond];\n    \"Sequential agents\" [shape=box];\n    \"Parallel dispatch\" [shape=box];\n\n    \"Multiple tasks?\" -> \"Are they independent?\" [label=\"yes\"];\n    \"Are they independent?\" -> \"Single agent handles all\" [label=\"no - related\"];\n    \"Are they independent?\" -> \"Can they work in parallel?\" [label=\"yes\"];\n    \"Can they work in parallel?\" -> \"Parallel dispatch\" [label=\"yes\"];\n    \"Can they work in parallel?\" -> \"Sequential agents\" [label=\"no - shared state\"];\n}\n```\n\n**Use when:**\n- 3+ independent tasks with different domains\n- Multiple areas broken independently\n- Each task can be understood without context from others\n- No shared state between tasks\n\n**Don't use when:**\n- Tasks are related (completing one might affect others)\n- Need to understand full project state first\n- Agents would interfere with each other (editing same files, using same resources)\n\n## The Pattern\n\n### 1. Identify Independent Domains\n\nGroup tasks by what's involved:\n- Task A: Research topic X\n- Task B: Draft section Y\n- Task C: Review document Z\n\nEach domain is independent — researching X doesn't affect drafting Y.\n\n### 2. Create Focused Agent Tasks\n\nEach agent gets:\n- **Specific scope:** One task or domain\n- **Clear goal:** What to produce\n- **Constraints:** What NOT to do\n- **Expected output:** Summary of what was found/produced\n\n### 3. Dispatch in Parallel\n\n```\nAgent 1 → Task A: Research topic X\nAgent 2 → Task B: Draft section Y\nAgent 3 → Task C: Review document Z\n// All three run concurrently\n```\n\n### 4. Review and Integrate\n\nWhen agents return:\n- Read each summary\n- Verify outputs don't conflict\n- Integrate all results\n- Verify the combined output meets overall goals\n\n## Agent Prompt Structure\n\nGood agent prompts are:\n1. **Focused** — One clear task domain\n2. **Self-contained** — All context needed to understand the task\n3. **Specific about output** — What should the agent return?\n\n```markdown\n[Task description with full context]\n\nYour task:\n1. [Step 1]\n2. [Step 2]\n3. [Step 3]\n\nDo NOT [constraint — what to avoid].\n\nReturn: [Exact summary format expected]\n```\n\n## Common Mistakes\n\n**❌ Too broad:** \"Handle all the tasks\" — agent gets lost\n**✅ Specific:** \"Research topic X only\" — focused scope\n\n**❌ No context:** \"Fix the problem\" — agent doesn't know where\n**✅ Context:** Paste the relevant background and exact task description\n\n**❌ No constraints:** Agent might do too much\n**✅ Constraints:** \"Do NOT change Y\" or \"Focus only on Z\"\n\n**❌ Vague output:** \"Do it\" — you don't know what changed\n**✅ Specific:** \"Return summary of findings and decisions made\"\n\n## When NOT to Use\n\n**Related tasks:** Completing one might affect others — handle together first\n**Need full context:** Understanding requires seeing the entire project\n**Exploratory work:** You don't know what's needed yet\n**Shared state:** Agents would interfere (editing same files, using same resources)\n\n## Verification\n\nAfter agents return:\n1. **Review each summary** — Understand what was produced\n2. **Check for conflicts** — Did agents produce contradictory results?\n3. **Verify combined output** — Do all results work together?\n4. **Spot check** — Agents can make systematic errors\n\n## Key Benefits\n\n1. **Parallelization** — Multiple tasks happen simultaneously\n2. **Focus** — Each agent has narrow scope, less context to track\n3. **Independence** — Agents don't interfere with each other\n4. **Speed** — 3 tasks solved in time of 1\n\nFile v1.1.0:skills/executing-plans/SKILL.md\n\n---\nname: executing-plans\ndescription: \"Use when you have a written plan to execute, working through tasks sequentially with review checkpoints. Trigger when a plan document exists and the user wants to execute it in the current session. Do not trigger without an existing plan document. If subagents are available, prefer agent-workflow:subagent-driven-execution instead.\"\n---\n\n# Executing Plans\n\n## Overview\n\nLoad plan, review critically, execute all tasks, report when complete.\n\n**Announce at start:** \"I'm using the executing-plans skill to implement this plan.\"\n\n**Note:** This skill works much better with subagent support. If subagents are available, use `agent-workflow:subagent-driven-execution` instead — it provides higher quality through fresh context per task and two-stage review.\n\n## The Process\n\n### Step 1: Load and Review Plan\n\n1. Read plan file\n2. Review critically — identify any questions or concerns about the plan\n3. If concerns: Raise them with the user before starting\n4. If no concerns: Create task list and proceed\n\n### Step 2: Execute Tasks\n\nFor each task:\n1. Mark as in_progress\n2. Follow each step exactly (plan has bite-sized steps)\n3. Run verifications as specified\n4. Mark as completed\n\n### Step 3: Complete Work\n\nAfter all tasks complete and verified:\n- Announce: \"I'm using the finishing-work skill to complete this work.\"\n- **REQUIRED SUB-SKILL:** Use `agent-workflow:finishing-work`\n- Follow that skill to verify outputs, present options, execute choice\n\n## When to Stop and Ask for Help\n\n**STOP executing immediately when:**\n- Hit a blocker (missing input, verification fails, instruction unclear)\n- Plan has critical gaps preventing starting\n- You don't understand an instruction\n- Verification fails repeatedly\n\n**Ask for clarification rather than guessing.**\n\n## When to Revisit Earlier Steps\n\n**Return to Review (Step 1) when:**\n- User updates the plan based on your feedback\n- Fundamental approach needs rethinking\n\n**Don't force through blockers** — stop and ask.\n\n## Remember\n- Review plan critically first\n- Follow plan steps exactly\n- Don't skip verifications\n- Reference skills when plan says to\n- Stop when blocked, don't guess\n\n## Integration\n\n**Required workflow skills:**\n- `agent-workflow:writing-plans` — Creates the plan this skill executes\n- `agent-workflow:finishing-work` — Complete work after all tasks are done\n\nFile v1.1.0:skills/finishing-work/SKILL.md\n\n---\nname: finishing-work\ndescription: \"Use when a task or project phase is complete and you need to decide how to deliver or integrate the work. Trigger after all tasks are done and verified. Do not trigger before verification is complete or while tasks are still in progress.\"\n---\n\n# Finishing Work\n\n## Safety Notice\n\n**This skill includes options that may permanently delete drafts, temporary files, or working copies.** All destructive actions (Option 4: Discard, and cleanup steps) require explicit user confirmation before execution. Only clearly identified temporary files created during this workflow will be removed — user-created artifacts are never deleted without specific confirmation.\n\n## Overview\n\nGuide completion of a work phase by presenting clear options and handling the chosen delivery workflow.\n\n**Core principle:** Verify work → Present options → Execute choice → Clean up.\n\n**Announce at start:** \"I'm using the finishing-work skill to complete this work.\"\n\n## The Process\n\n### Step 1: Verify Work\n\n**Before presenting options, verify the work is complete:**\n\nCheck each of the following:\n- All planned tasks are done\n- All acceptance criteria are met\n- No known issues remain unaddressed\n\n**If verification fails:**\n```\nWork incomplete or issues remain:\n\n[Show what's missing or broken]\n\nCannot proceed with delivery until work is verified complete.\n```\n\nStop. Don't proceed to Step 2.\n\n**If verification passes:** Continue to Step 2.\n\n### Step 2: Confirm Delivery Target\n\nAsk or confirm: \"Where does this work go? Who receives it?\"\n\nExamples:\n- Integrate into main project\n- Submit to stakeholder for review\n- Keep as draft for later\n- Discard\n\n### Step 3: Present Options\n\nPresent exactly these 4 options:\n\n```\nWork complete. What would you like to do?\n\n1. Integrate into main project directly\n2. Submit for review / deliver to stakeholder\n3. Keep as-is (I'll handle it later)\n4. Discard this work\n\nWhich option?\n```\n\n**Don't add explanation** — keep options concise.\n\n### Step 4: Execute Choice\n\n#### Option 1: Integrate Directly\n\n1. Merge or apply the work into the main project\n2. Verify the integrated result still meets requirements\n3. Clean up any working drafts or temporary files\n4. Confirm integration complete\n\n#### Option 2: Submit for Review / Deliver\n\n1. Package or prepare the output for delivery\n2. Send to stakeholder or submit for review\n3. Note any context the reviewer needs\n4. Keep working copy until review is complete\n\nThen: Clean up workspace (Step 5)\n\n#### Option 3: Keep As-Is\n\nReport: \"Keeping work in progress at [location]. No delivery action taken.\"\n\n**Don't clean up.**\n\n#### Option 4: Discard\n\n**Confirm first:**\n```\nThis will permanently delete:\n- [Description of what will be deleted]\n- [Any associated drafts or working files]\n\nType 'discard' to confirm.\n```\n\nWait for exact confirmation.\n\nIf confirmed: Remove the work and working files.\n\nThen: Clean up workspace (Step 5)\n\n### Step 5: Clean Up Workspace\n\n**For Options 1, 2, 4:**\n\nBefore removing any files, list what will be deleted and get explicit user confirmation:\n\n```\nThe following temporary/working files will be removed:\n- [file 1]\n- [file 2]\n\nConfirm cleanup? (yes/no)\n```\n\nOnly remove files that were explicitly created as temporary working artifacts during this workflow. Never remove files that existed before the workflow started or that the user created independently.\n\n**For Option 3:** Keep everything.\n\n## Quick Reference\n\n| Option | Integrate | Deliver | Keep Working Copy | Clean Up |\n|--------|-----------|---------|-------------------|----------|\n| 1. Integrate directly | ✓ | — | — | ✓ |\n| 2. Submit for review | — | ✓ | ✓ | After review |\n| 3. Keep as-is | — | — | ✓ | — |\n| 4. Discard | — | — | — | ✓ |\n\n## Common Mistakes\n\n**Skipping verification**\n- Problem: Delivering incomplete or broken work\n- Fix: Always verify before offering options\n\n**Open-ended questions**\n- Problem: \"What should I do next?\" → ambiguous\n- Fix: Present exactly 4 structured options\n\n**No confirmation for discard**\n- Problem: Accidentally delete work\n- Fix: Require typed \"discard\" confirmation\n\n## Red Flags\n\n**Never:**\n- Deliver without verifying work is complete\n- Delete work without confirmation\n- Skip the options presentation\n\n**Always:**\n- Verify work before offering options\n- Present exactly 4 options\n- Get typed confirmation for Option 4\n- Clean up workspace for Options 1 and 4 only\n\n## Integration\n\n**Called by:**\n- `agent-workflow:subagent-driven-execution` — After all tasks complete\n- `agent-workflow:executing-plans` — After all tasks complete\n\nFile v1.1.0:skills/receiving-review/SKILL.md\n\n---\nname: receiving-review\ndescription: \"Use when receiving technical review feedback on completed work that contains disputed, unclear, or questionable suggestions. Helps evaluate feedback rigorously before implementing. Trigger ONLY when review feedback requires careful evaluation (e.g. code review with contested points, complex technical feedback). Do NOT trigger for: casual feedback, user preference discussions, simple corrections, routine edits, or positive acknowledgments.\"\n---\n\n# Receiving Review Feedback\n\n## Overview\n\nReview feedback requires technical evaluation, not emotional performance.\n\n**Core principle:** Verify before implementing. Ask before assuming. Correctness over social comfort.\n\n## The Response Pattern\n\n```\nWHEN receiving review feedback:\n\n1. READ: Complete feedback without reacting\n2. UNDERSTAND: Restate requirement in own words (or ask)\n3. VERIFY: Check against actual work\n4. EVALUATE: Is this technically sound for THIS project?\n5. RESPOND: Technical acknowledgment or reasoned pushback\n6. IMPLEMENT: One item at a time, verify each\n```\n\n## Forbidden Responses\n\n**NEVER:**\n- \"You're absolutely right!\" (performative)\n- \"Great point!\" / \"Excellent feedback!\" (performative)\n- \"Let me implement that now\" (before verification)\n\n**INSTEAD:**\n- Restate the requirement in technical terms\n- Ask clarifying questions\n- Push back with reasoning if the feedback is wrong\n- Just start working (actions > words)\n\n## Handling Unclear Feedback\n\n```\nIF any item is unclear:\n  STOP — do not implement anything yet\n  ASK for clarification on unclear items\n\nWHY: Items may be related. Partial understanding = wrong implementation.\n```\n\n**Example:**\n```\nReviewer: \"Fix items 1-6\"\nYou understand 1, 2, 3, 6. Unclear on 4, 5.\n\n❌ WRONG: Implement 1, 2, 3, 6 now, ask about 4, 5 later\n✅ RIGHT: \"I understand items 1, 2, 3, 6. Need clarification on 4 and 5 before proceeding.\"\n```\n\n## Source-Specific Handling\n\n### From the user / project owner\n- **Trusted** — implement after understanding\n- **Still ask** if scope unclear\n- **No performative agreement**\n- **Skip to action** or technical acknowledgment\n\n### From external reviewers\n```\nBEFORE implementing:\n  1. Check: Is this correct for THIS project?\n  2. Check: Does it break existing work?\n  3. Check: Is there a reason for the current approach?\n  4. Check: Does reviewer understand full context?\n\nIF suggestion seems wrong:\n  Push back with clear reasoning\n\nIF can't easily verify:\n  Say so: \"I can't verify this without [X]. Should I [investigate/ask/proceed]?\"\n\nIF conflicts with project owner's prior decisions:\n  Stop and discuss with project owner first\n```\n\n## Necessity Check for Suggested Features\n\n```\nIF reviewer suggests adding something new:\n  Check: Is this actually needed?\n\n  IF not needed: \"This isn't used anywhere. Skip it (YAGNI)?\"\n  IF needed: Then implement it\n```\n\n**Rule:** \"You and reviewer both report to the project owner. If we don't need this, don't add it.\"\n\n## Implementation Order\n\n```\nFOR multi-item feedback:\n  1. Clarify anything unclear FIRST\n  2. Then implement in this order:\n     - Blocking issues (wrong, broken)\n     - Simple fixes (minor errors, omissions)\n     - Complex fixes (restructuring, rework)\n  3. Verify each fix individually\n  4. Confirm no regressions\n```\n\n## When To Push Back\n\nPush back when:\n- Suggestion breaks existing work\n- Reviewer lacks full project context\n- Adding something not needed (YAGNI)\n- Suggestion is factually incorrect for this domain\n- Conflicts with project owner's decisions\n\n**How to push back:**\n- Use clear reasoning, not defensiveness\n- Ask specific questions\n- Reference existing work as evidence\n- Involve project owner if it's a strategic decision\n\n## Acknowledging Correct Feedback\n\nWhen feedback IS correct:\n```\n✅ \"Fixed. [Brief description of what changed]\"\n✅ \"Good catch — [specific issue]. Fixed in [location].\"\n✅ [Just fix it and show the result]\n✅ Brief, context-appropriate acknowledgment\n\n❌ Empty performative agreement without substance\n❌ Extended praise that delays action\n```\n\n**Principle:** Prioritize substance over ceremony. A brief acknowledgment is fine; what matters is that you verify the feedback and act on it rather than performing agreement without understanding.\n\n## Gracefully Correcting Your Pushback\n\nIf you pushed back and were wrong:\n```\n✅ \"You were right — I checked [X] and it does [Y]. Implementing now.\"\n✅ \"Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing.\"\n\n❌ Long apology\n❌ Defending why you pushed back\n❌ Over-explaining\n```\n\nState the correction factually and move on.\n\n## Common Mistakes\n\n| Mistake | Fix |\n|---------|-----|\n| Performative agreement | State requirement or just act |\n| Blind implementation | Verify against actual work first |\n| Batch without verifying | One at a time, verify each |\n| Assuming reviewer is right | Check if it breaks things |\n| Avoiding pushback | Correctness > comfort |\n| Partial implementation | Clarify all items first |\n| Can't verify, proceed anyway | State limitation, ask for direction |\n\n## The Bottom Line\n\n**External feedback = suggestions to evaluate, not orders to follow.**\n\nVerify. Question. Then implement.\n\nNo performative agreement. Reasoned rigor always.\n\nFile v1.1.0:skills/requesting-review/SKILL.md\n\n---\nname: requesting-review\ndescription: \"Use when completing significant work to verify it meets requirements before delivery. Trigger after finishing a major task, completing a project phase, or before submitting results to a stakeholder. Do not trigger for minor or trivial tasks where review would be disproportionate.\"\n---\n\n# Requesting Review\n\nDispatch a reviewer subagent to catch issues before delivery. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.\n\n**Core principle:** Review early, review often.\n\n## When to Request Review\n\n**Mandatory:**\n- After each task in subagent-driven execution\n- After completing a major deliverable\n- Before final delivery to stakeholder\n\n**Optional but valuable:**\n- When stuck (fresh perspective)\n- Before significant rework (baseline check)\n- After resolving a complex problem\n\n## How to Request\n\n**1. Define scope of work to review:**\n- What was produced\n- What it should accomplish (spec or requirements)\n- Any specific concerns to check\n\n**2. Dispatch reviewer subagent:**\n\nUse the following template:\n\n```markdown\n## Review Request\n\n### What Was Produced\n[Description of the output — what it is and where it lives]\n\n### Requirements / Spec\n[What the output is supposed to accomplish]\n\n### Specific Concerns (optional)\n[Any areas you're unsure about]\n\n### Your Task\nReview the output against the requirements.\n\nReport:\n- **Critical:** Issues that must be fixed before delivery (wrong, missing, broken)\n- **Important:** Issues that should be fixed soon (gaps, inconsistencies)\n- **Minor:** Nice-to-have improvements\n- **Assessment:** Ready to deliver / Needs fixes\n```\n\n**3. Act on feedback:**\n- Fix Critical issues immediately\n- Fix Important issues before proceeding\n- Note Minor issues for later\n- Push back if reviewer is wrong (with reasoning)\n\n## Example\n\n```\n[Just completed Task 2: Draft executive summary]\n\nYou: Let me request review before proceeding.\n\n[Dispatch reviewer subagent]\n  WHAT_WAS_PRODUCED: Executive summary for Q1 report\n  REQUIREMENTS: Task 2 from docs/plans/q1-report-plan.md\n  SPECIFIC_CONCERNS: Not sure if the tone matches the audience\n\n[Subagent returns]:\n  Strengths: Clear structure, covers all key points\n  Issues:\n    Important: Tone is too technical for executive audience\n    Minor: Missing one metric from requirements\n  Assessment: Needs fixes before delivery\n\n[Fix tone and add missing metric]\n[Continue to Task 3]\n```\n\n## Integration with Workflows\n\n**Subagent-Driven Execution:**\n- Review after EACH task\n- Catch issues before they compound\n- Fix before moving to next task\n\n**Executing Plans:**\n- Review after each checkpoint\n- Get feedback, apply, continue\n\n**Ad-Hoc Work:**\n- Review before final delivery\n- Review when stuck\n\n## Red Flags\n\n**Never:**\n- Skip review because \"it's simple\"\n- Ignore Critical issues\n- Proceed with unfixed Critical or Important issues\n- Argue with valid feedback\n\n**If reviewer is wrong:**\n- Push back with clear reasoning\n- Show evidence that the output meets requirements\n- Request clarification\n\nFile v1.1.0:skills/subagent-driven-execution/SKILL.md\n\n---\nname: subagent-driven-execution\ndescription: \"Use when executing a plan with independent tasks in the current session. Trigger when a plan is ready and tasks can be delegated to specialized subagents for parallel or sequential execution with review after each task. Do not trigger without a written plan, or when tasks are tightly coupled and must be done sequentially by the same agent without review checkpoints.\"\n---\n\n# Subagent-Driven Execution\n\nExecute a plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance review first, then quality review.\n\n**Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.\n\n**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.\n\n## When to Use\n\n```dot\ndigraph when_to_use {\n    \"Have execution plan?\" [shape=diamond];\n    \"Tasks mostly independent?\" [shape=diamond];\n    \"Stay in this session?\" [shape=diamond];\n    \"subagent-driven-execution\" [shape=box];\n    \"executing-plans\" [shape=box];\n    \"Manual execution or brainstorm first\" [shape=box];\n\n    \"Have execution plan?\" -> \"Tasks mostly independent?\" [label=\"yes\"];\n    \"Have execution plan?\" -> \"Manual execution or brainstorm first\" [label=\"no\"];\n    \"Tasks mostly independent?\" -> \"Stay in this session?\" [label=\"yes\"];\n    \"Tasks mostly independent?\" -> \"Manual execution or brainstorm first\" [label=\"no - tightly coupled\"];\n    \"Stay in this session?\" -> \"subagent-driven-execution\" [label=\"yes\"];\n    \"Stay in this session?\" -> \"executing-plans\" [label=\"no - separate session\"];\n}\n```\n\n## The Process\n\n```dot\ndigraph process {\n    rankdir=TB;\n\n    subgraph cluster_per_task {\n        label=\"Per Task\";\n        \"Dispatch executor subagent\" [shape=box];\n        \"Executor subagent asks questions?\" [shape=diamond];\n        \"Answer questions, provide context\" [shape=box];\n        \"Executor subagent executes, verifies, self-reviews\" [shape=box];\n        \"Dispatch spec reviewer subagent\" [shape=box];\n        \"Spec reviewer confirms output matches spec?\" [shape=diamond];\n        \"Executor subagent fixes spec gaps\" [shape=box];\n        \"Dispatch quality reviewer subagent\" [shape=box];\n        \"Quality reviewer approves?\" [shape=diamond];\n        \"Executor subagent fixes quality issues\" [shape=box];\n        \"Mark task complete\" [shape=box];\n    }\n\n    \"Read plan, extract all tasks, note context, create task list\" [shape=box];\n    \"More tasks remain?\" [shape=diamond];\n    \"Dispatch final reviewer subagent for entire output\" [shape=box];\n    \"Use agent-workflow:finishing-work\" [shape=box style=filled fillcolor=lightgreen];\n\n    \"Read plan, extract all tasks, note context, create task list\" -> \"Dispatch executor subagent\";\n    \"Dispatch executor subagent\" -> \"Executor subagent asks questions?\";\n    \"Executor subagent asks questions?\" -> \"Answer questions, provide context\" [label=\"yes\"];\n    \"Answer questions, provide context\" -> \"Dispatch executor subagent\";\n    \"Executor subagent asks questions?\" -> \"Executor subagent executes, verifies, self-reviews\" [label=\"no\"];\n    \"Executor subagent executes, verifies, self-reviews\" -> \"Dispatch spec reviewer subagent\";\n    \"Dispatch spec reviewer subagent\" -> \"Spec reviewer confirms output matches spec?\";\n    \"Spec reviewer confirms output matches spec?\" -> \"Executor subagent fixes spec gaps\" [label=\"no\"];\n    \"Executor subagent fixes spec gaps\" -> \"Dispatch spec reviewer subagent\" [label=\"re-review\"];\n    \"Spec reviewer confirms output matches spec?\" -> \"Dispatch quality reviewer subagent\" [label=\"yes\"];\n    \"Dispatch quality reviewer subagent\" -> \"Quality reviewer approves?\";\n    \"Quality reviewer approves?\" -> \"Executor subagent fixes quality issues\" [label=\"no\"];\n    \"Executor subagent fixes quality issues\" -> \"Dispatch quality reviewer subagent\" [label=\"re-review\"];\n    \"Quality reviewer approves?\" -> \"Mark task complete\" [label=\"yes\"];\n    \"Mark task complete\" -> \"More tasks remain?\";\n    \"More tasks remain?\" -> \"Dispatch executor subagent\" [label=\"yes\"];\n    \"More tasks remain?\" -> \"Dispatch final reviewer subagent for entire output\" [label=\"no\"];\n    \"Dispatch final reviewer subagent for entire output\" -> \"Use agent-workflow:finishing-work\";\n}\n```\n\n## Model Selection\n\nUse the least powerful model that can handle each role to conserve cost and increase speed.\n\n**Mechanical execution tasks** (isolated, clear specs, narrow scope): use a fast, cheap model. Most tasks are mechanical when the plan is well-specified.\n\n**Integration and judgment tasks** (multi-area coordination, pattern matching, problem-solving): use a standard model.\n\n**Design, review, and quality tasks**: use the most capable available model.\n\n**Task complexity signals:**\n- Touches 1-2 areas with a complete spec → cheap model\n- Touches multiple areas with integration concerns → standard model\n- Requires design judgment or broad project understanding → most capable model\n\n## Executor Subagent Prompt Structure\n\nCraft each executor prompt to be:\n1. **Self-contained** — all context needed to complete the task\n2. **Scoped** — one task only, clear boundaries\n3. **Verifiable** — explicit acceptance criteria\n4. **Output-specified** — exactly what to produce and where\n\n```markdown\n## Task: [Task Name from Plan]\n\n### Context\n[Project background, relevant prior work, conventions to follow]\n\n### Your Task\n[Exact description from plan, including all steps]\n\n### Acceptance Criteria\n- [ ] Criterion A\n- [ ] Criterion B\n\n### Output\nProduce: [exact output description]\nSave to: [location]\n\n### Self-Review\nBefore reporting complete, verify each criterion above is met.\nReport: summary of what you did and any decisions made.\n```\n\n## Spec Reviewer Prompt Structure\n\n```markdown\n## Review: Does output match spec?\n\n### Spec / Plan Task\n[Paste the task from the plan]\n\n### Output Produced\n[Summary or location of what the executor produced]\n\n### Your Job\nCheck each requirement in the spec against the output.\nReport:\n- PASS: output matches spec\n- FAIL: list specific gaps with exact locations\n```\n\n## Quality Reviewer Prompt Structure\n\n```markdown\n## Review: Quality check\n\n### Output\n[Location or summary of what was produced]\n\n### Your Job\nReview for quality issues:\n- Clarity and completeness\n- Consistency with project conventions\n- Any obvious errors or omissions\n\nReport:\n- APPROVE: output is ready\n- REVISE: list specific issues with suggested fixes\n```\n\n## Common Mistakes\n\n**Too broad executor scope:** \"Do everything in the plan\" — executor gets lost\n**Specific is better:** \"Complete Task 3 only: [paste task]\"\n\n**No context in prompt:** Executor doesn't know project conventions\n**Include context:** Paste relevant background, prior decisions\n\n**No acceptance criteria:** Executor doesn't know when done\n**Always include:** Explicit criteria the executor checks before reporting\n\n**Trusting executor self-report:** Always run spec review after\n**Always dispatch:** Spec reviewer after every executor\n\n## Integration\n\n**Called by:**\n- `agent-workflow:writing-plans` — After plan is created and execution mode chosen\n\n**Calls:**\n- `agent-workflow:finishing-work` — After all tasks complete and final review passes\n- `agent-workflow:requesting-review` — Optional: request review after each task\n\nFile v1.1.0:skills/systematic-problem-solving/SKILL.md\n\n---\nname: systematic-problem-solving\ndescription: \"Use when actively debugging a reproducible problem — errors, regressions, or failed outputs that need root-cause diagnosis. Trigger ONLY when the user is troubleshooting a concrete, reproducible issue (e.g. error messages, test failures, broken behavior). Do NOT trigger for: planning, brainstorming, creative tasks, straightforward one-step tasks, general questions, or situations where the user wants immediate simple fixes.\"\n---\n\n# Systematic Problem Solving\n\n## Overview\n\nRandom fixes waste time and create new problems. Quick patches mask underlying issues.\n\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\n\n**Violating the letter of this process is violating the spirit of problem-solving.**\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\nIf you haven't completed Phase 1, you cannot propose fixes.\n\n## When to Use\n\nUse for ANY unexpected situation:\n- Task produces wrong output\n- Process breaks or stalls\n- Unexpected behavior from a tool or system\n- Results don't match expectations\n- A previous fix didn't work\n\n**Use this ESPECIALLY when:**\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You've already tried multiple fixes\n- Previous fix didn't work\n- You don't fully understand the issue\n\n**Don't skip when:**\n- Issue seems simple (simple problems have root causes too)\n- You're in a hurry (rushing guarantees rework)\n- Someone wants it fixed NOW (systematic is faster than thrashing)\n\n## The Four Phases\n\nYou MUST complete each phase before proceeding to the next.\n\n### Phase 1: Root Cause Investigation\n\n**BEFORE attempting ANY fix:**\n\n1. **Read Error Messages or Failure Signals Carefully**\n   - Don't skip past errors or warnings\n   - They often contain the exact solution\n   - Note specific locations, codes, or descriptions\n\n2. **Reproduce Consistently**\n   - Can you trigger it reliably?\n   - What are the exact conditions?\n   - Does it happen every time?\n   - If not reproducible → gather more data, don't guess\n\n3. **Check Recent Changes**\n   - What changed that could cause this?\n   - New inputs, config changes, environmental differences\n   - What was different when it last worked?\n\n4. **Gather Evidence in Multi-Component Systems**\n\n   **WHEN the system has multiple components (e.g., input → process → output, API → service → storage):**\n\n   **BEFORE proposing fixes, add diagnostic instrumentation:**\n   ```\n   For EACH component boundary:\n     - Log what data enters the component\n     - Log what data exits the component\n     - Verify config/state propagation\n     - Check state at each layer\n\n   Run once to gather evidence showing WHERE it breaks\n   THEN analyze evidence to identify the failing component\n   THEN investigate that specific component\n   ```\n\n   **Example (multi-layer process):**\n   ```\n   Layer 1: Input received?\n   → Log: \"Input value: [X]\"\n\n   Layer 2: Processing step applied correctly?\n   → Log: \"After step A: [Y]\"\n\n   Layer 3: Output produced correctly?\n   → Log: \"Final output: [Z], expected: [W]\"\n   ```\n\n   **This reveals:** Which layer fails (input ✓, processing ✗, output not reached)\n\n5. **Trace Data Flow**\n\n   **WHEN the error is deep in a process:**\n   - Where does the bad value or wrong result originate?\n   - What produced this with the wrong value?\n   - Keep tracing back until you find the source\n   - Fix at source, not at symptom\n\n### Phase 2: Pattern Analysis\n\n**Find the pattern before fixing:**\n\n1. **Find Working Examples**\n   - Locate similar working cases in the same project\n   - What works that's similar to what's broken?\n\n2. **Compare Against References**\n   - If implementing a pattern, read the reference COMPLETELY\n   - Don't skim — read every detail\n   - Understand the pattern fully before applying\n\n3. **Identify Differences**\n   - What's different between working and broken?\n   - List every difference, however small\n   - Don't assume \"that can't matter\"\n\n4. **Understand Dependencies**\n   - What does this component depend on?\n   - What settings, config, or inputs does it assume?\n\n### Phase 3: Hypothesis and Testing\n\n**Scientific method:**\n\n1. **Form Single Hypothesis**\n   - State clearly: \"I think X is the root cause because Y\"\n   - Write it down\n   - Be specific, not vague\n\n2. **Test Minimally**\n   - Make the SMALLEST possible change to test hypothesis\n   - One variable at a time\n   - Don't fix multiple things at once\n\n3. **Verify Before Continuing**\n   - Did it work? Yes → Phase 4\n   - Didn't work? Form NEW hypothesis\n   - DON'T add more fixes on top\n\n4. **When You Don't Know**\n   - Say \"I don't understand X\"\n   - Don't pretend to know\n   - Ask for help or research more\n\n### Phase 4: Implementation\n\n**Fix the root cause, not the symptom:**\n\n1. **Define a Verification Case**\n   - Simplest possible reproduction of the problem\n   - Must be checkable before and after fix\n   - MUST have this before fixing\n\n2. **Implement Single Fix**\n   - Address the root cause identified\n   - ONE change at a time\n   - No \"while I'm here\" improvements\n   - No bundled changes\n\n3. **Verify Fix**\n   - Problem resolved now?\n   - No other things broken?\n   - Issue actually gone?\n\n4. **If Fix Doesn't Work**\n   - STOP\n   - Count: How many fixes have you tried?\n   - If < 3: Return to Phase 1, re-analyze with new information\n   - **If ≥ 3: STOP and question the approach (step 5 below)**\n   - DON'T attempt Fix #4 without discussing the approach\n\n5. **If 3+ Fixes Failed: Question the Approach**\n\n   **Pattern indicating a structural problem:**\n   - Each fix reveals new coupling or dependency in a different place\n   - Fixes require large-scale changes to implement\n   - Each fix creates new symptoms elsewhere\n\n   **STOP and question fundamentals:**\n   - Is this approach fundamentally sound?\n   - Are we \"sticking with it through sheer inertia\"?\n   - Should we reconsider the approach vs. continue fixing symptoms?\n\n   **Discuss with the user before attempting more fixes.**\n\n## Red Flags — STOP and Follow Process\n\nIf you catch yourself thinking:\n- \"Quick fix for now, investigate later\"\n- \"Just try changing X and see if it works\"\n- \"Add multiple changes, check results\"\n- \"It's probably X, let me fix that\"\n- \"I don't fully understand but this might work\"\n- \"Here are the main problems: [lists fixes without investigation]\"\n- Proposing solutions before tracing the issue\n- **\"One more fix attempt\" (when already tried 2+)**\n- **Each fix reveals a new problem in a different place**\n\n**ALL of these mean: STOP. Return to Phase 1.**\n\n**If 3+ fixes failed:** Question the approach (see Phase 4.5)\n\n## User Signals You're Doing It Wrong\n\n**Watch for these redirections:**\n- \"Is that not happening?\" — You assumed without verifying\n- \"Will it show us...?\" — You should have added evidence gathering\n- \"Stop guessing\" — You're proposing fixes without understanding\n- \"We're stuck?\" (frustrated) — Your approach isn't working\n\n**When you see these:** STOP. Return to Phase 1.\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. Process is fast for simple problems. |\n| \"Emergency, no time for process\" | Systematic problem-solving is FASTER than guess-and-check thrashing. |\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\n| \"Multiple fixes at once saves time\" | Can't isolate what worked. Causes new problems. |\n| \"I see the problem, let me fix it\" | Seeing symptoms ≠ understanding root cause. |\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = structural problem. Question approach, don't fix again. |\n\n## Quick Reference\n\n| Phase | Key Activities | Success Criteria |\n|-------|---------------|------------------|\n| **1. Root Cause** | Read signals, reproduce, check changes, gather evidence | Understand WHAT and WHY |\n| **2. Pattern** | Find working examples, compare | Identify differences |\n| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |\n| **4. Implementation** | Define verification case, fix, verify | Problem resolved |\n\n## When Process Reveals \"No Root Cause\"\n\nIf systematic investigation reveals the issue is truly environmental, timing-dependent, or external:\n\n1. You've completed the process\n2. Document what you investigated\n3. Implement appropriate handling (retry, fallback, error message)\n4. Add monitoring or logging for future investigation\n\n**But:** 95% of \"no root cause\" cases are incomplete investigation.\n\n## Real-World Impact\n\n- Systematic approach: 15-30 minutes to resolve\n- Random fixes approach: 2-3 hours of thrashing\n- First-time resolution rate: 95% vs 40%\n- New problems introduced: Near zero vs common\n\nFile v1.1.0:skills/using-agent-workflow/SKILL.md\n\n---\nname: using-agent-workflow\ndescription: \"Reference for how agent-workflow skills are discovered and invoked. Trigger ONLY when the user explicitly asks how agent-workflow skills work, or asks about skill usage/discovery. Do NOT trigger at the start of ordinary conversations, for routine tasks, or mid-task unless the user specifically asks about skill mechanics.\"\n---\n\n## Skill Invocation Guidelines\n\nWhen a skill is clearly and directly relevant to the current task, invoke it before proceeding. If relevance is uncertain, you may ask the user or proceed without it — do not force skill invocation on speculative grounds.\n\n**User instructions always take precedence over skill behavior.**\n\n## Instruction Priority\n\nAgent-workflow skills override default behavior, but **user instructions always take precedence**:\n\n1. **User's explicit instructions** (project config files, direct requests) — highest priority\n2. **Agent-workflow skills** — override default behavior where they conflict\n3. **Default behavior** — lowest priority\n\n## How to Access Skills\n\nUse the platform's skill invocation mechanism. When you invoke a skill, its content is loaded and presented to you — follow it directly.\n\n# Using Skills\n\n## The Rule\n\n**Invoke skills when they are clearly relevant to the current task.** If a skill directly matches what the user is asking for, invoke it. If relevance is uncertain, ask the user or proceed normally — the agent should not be blocked from responding by speculative skill checks.\n\n```dot\ndigraph skill_flow {\n    \"User message received\" [shape=doublecircle];\n    \"Skill clearly relevant?\" [shape=diamond];\n    \"Invoke skill\" [shape=box];\n    \"Announce: 'Using [skill] to [purpose]'\" [shape=box];\n    \"Has checklist?\" [shape=diamond];\n    \"Create todo per item\" [shape=box];\n    \"Follow skill exactly\" [shape=box];\n    \"Respond normally\" [shape=doublecircle];\n\n    \"User message received\" -> \"Skill clearly relevant?\";\n    \"Skill clearly relevant?\" -> \"Invoke skill\" [label=\"yes\"];\n    \"Skill clearly relevant?\" -> \"Respond normally\" [label=\"no or uncertain\"];\n    \"Invoke skill\" -> \"Announce: 'Using [skill] to [purpose]'\";\n    \"Announce: 'Using [skill] to [purpose]'\" -> \"Has checklist?\";\n    \"Has checklist?\" -> \"Create todo per item\" [label=\"yes\"];\n    \"Has checklist?\" -> \"Follow skill exactly\" [label=\"no\"];\n    \"Create todo per item\" -> \"Follow skill exactly\";\n}\n```\n\n## Red Flags\n\nThese thoughts indicate you may be forcing a skill where it doesn't belong:\n\n| Thought | Guidance |\n|---------|----------|\n| \"This might apply even though user didn't ask\" | If it's not clearly relevant, skip it or ask the user |\n| \"I must invoke before responding\" | You can clarify, ask questions, or respond directly first |\n| \"Every task needs a skill\" | Most tasks don't. Only invoke when clearly applicable |\n\n## Skill Priority\n\nWhen multiple skills could apply, use this order:\n\n1. **Process skills first** (brainstorming, systematic-problem-solving) — these determine HOW to approach the task\n2. **Execution skills second** (writing-plans, subagent-driven-execution) — these guide execution\n\n\"Let's do X\" → brainstorming first, then execution skills.\n\"Something went wrong\" → systematic-problem-solving first, then domain-specific skills.\n\n## Skill Types\n\n**Rigid** (systematic-problem-solving, verification-before-completion): Follow exactly. Don't adapt away the discipline.\n\n**Flexible** (brainstorming, writing-plans): Adapt principles to context.\n\nThe skill itself tells you which type it is.\n\n## User Instructions\n\nInstructions say WHAT, not HOW. \"Do X\" or \"Fix Y\" doesn't mean skip workflows.\n\nFile v1.1.0:skills/verification-before-completion/SKILL.md\n\n---\nname: verification-before-completion\ndescription: \"Use before claiming any work is complete, correct, or passing. Requires running verification steps and confirming output before making success claims. Trigger before wrapping up any task, delivering results, or reporting completion. Do not skip verification even for simple tasks.\"\n---\n\n# Verification Before Completion\n\n## Overview\n\nClaiming work is complete without verification is dishonesty, not efficiency.\n\n**Core principle:** Evidence before claims, always.\n\n**Violating the letter of this rule is violating the spirit of this rule.**\n\n## The Iron Law\n\n```\nNO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE\n```\n\nIf you haven't run the verification step in this message, you cannot claim it passes.\n\n## The Gate Function\n\n```\nBEFORE claiming any status or expressing satisfaction:\n\n1. IDENTIFY: What step proves this claim?\n2. RUN: Execute the FULL verification (fresh, complete)\n3. READ: Full output, check result, count failures\n4. VERIFY: Does output confirm the claim?\n   - If NO: State actual status with evidence\n   - If YES: State claim WITH evidence\n5. ONLY THEN: Make the claim\n\nSkip any step = asserting without verifying\n```\n\n## Common Failures\n\n| Claim | Requires | Not Sufficient |\n|-------|----------|----------------|\n| Task complete | Checklist verified: all criteria met | \"I think it's done\" |\n| Output correct | Output reviewed against spec | \"Looks right\" |\n| Requirements met | Line-by-line checklist against spec | \"Everything seems covered\" |\n| Problem fixed | Original symptom re-tested: resolved | \"Should be fixed now\" |\n| Subagent completed | Actual output inspected | Subagent reports \"success\" |\n| Quality good | Reviewer approved | \"Seems high quality\" |\n\n## Red Flags — STOP\n\n- Using \"should\", \"probably\", \"seems to\"\n- Expressing satisfaction before verification (\"Great!\", \"Perfect!\", \"Done!\", etc.)\n- About to deliver/report without verification\n- Trusting subagent success reports without checking output\n- Relying on partial verification\n- Thinking \"just this once\"\n- **ANY wording implying success without having run verification**\n\n## Rationalization Prevention\n\n| Excuse | Reality |\n|--------|---------|\n| \"Should work now\" | RUN the verification |\n| \"I'm confident\" | Confidence ≠ evidence |\n| \"Just this once\" | No exceptions |\n| \"Subagent said success\" | Verify output independently |\n| \"Partial check is enough\" | Partial proves nothing |\n| \"Different words so rule doesn't apply\" | Spirit over letter |\n\n## Key Patterns\n\n**Task completion:**\n```\n✅ [Run checklist] [See: all criteria met] \"Task complete\"\n❌ \"Should be done\" / \"Looks correct\"\n```\n\n**Requirements coverage:**\n```\n✅ Re-read spec → Create checklist → Verify each → Report gaps or completion\n❌ \"Output produced, task complete\"\n```\n\n**Subagent delegation:**\n```\n✅ Subagent reports success → Inspect actual output → Verify criteria → Report actual state\n❌ Trust subagent report alone\n```\n\n**Problem resolution:**\n```\n✅ Re-test original symptom: passes → \"Issue resolved\"\n❌ \"Changed X, should be fixed\"\n```\n\n## Why This Matters\n\n- Trust is broken when claims are made without evidence\n- Incomplete output gets delivered\n- Time wasted on false completion → redirect → rework\n- Honesty is a core value. Claiming completion without verification is a lie.\n\n## When To Apply\n\n**ALWAYS before:**\n- ANY variation of success/completion claims\n- ANY expression of satisfaction\n- ANY positive statement about work state\n- Delivering, reporting, or moving to next task\n- Delegating to subagents\n\n**Rule applies to:**\n- Exact phrases\n- Paraphrases and synonyms\n- Implications of success\n- ANY communication suggesting completion or correctness\n\n## The Bottom Line\n\n**No shortcuts for verification.**\n\nRun the check. Read the output. THEN claim the result.\n\nThis is non-negotiable.\n\nFile v1.1.0:skills/writing-plans/SKILL.md\n\n---\nname: writing-plans\ndescription: \"Use when you have a spec or requirements for a multi-step task, before starting execution. Trigger when a design document or spec is ready and needs to be broken into actionable steps. Do not trigger without a prior design or spec, and do not trigger during execution.\"\n---\n\n# Writing Plans\n\n## Overview\n\nWrite comprehensive execution plans assuming the executor has zero context about this project and unfamiliar with its conventions. Document everything they need to know: which areas to touch for each task, what to produce, what to verify, how to confirm success. Give them the whole plan as bite-sized tasks. Avoid redundancy. Only do what's necessary. Define acceptance criteria before execution.\n\nAssume they are capable, but know almost nothing about this project's domain or toolset.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the execution plan.\"\n\n**Context:** This should be run after a design spec has been approved (created by the brainstorming skill).\n\n**Save plans to:** `docs/plans/YYYY-MM-DD-<task-name>.md`\n- (User preferences for plan location override this default)\n\n## Scope Check\n\nIf the spec covers multiple independent areas, it should have been broken into sub-specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per area. Each plan should produce working, verifiable output on its own.\n\n## Work Structure\n\nBefore defining tasks, map out which areas will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.\n\n- Design units with clear boundaries and well-defined interfaces. Each area should have one clear responsibility.\n- Prefer smaller, focused deliverables over large ones that do too much.\n- Areas that change together should be planned together. Split by responsibility, not by technical layer.\n- In existing projects, follow established patterns.\n\nThis structure informs the task decomposition. Each task should produce self-contained output that makes sense independently.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Define the acceptance criteria for this output\" — step\n- \"Produce the minimal output that meets the criteria\" — step\n- \"Verify output against criteria\" — step\n- \"Record progress / save result\" — step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Task Name] Execution Plan\n\n> **For executors:** Use agent-workflow:subagent-driven-execution (recommended) or agent-workflow:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.\n\n**Goal:** [One sentence describing what this produces]\n\n**Approach:** [2-3 sentences about the approach]\n\n**Key Resources:** [Key references, tools, or inputs needed]\n\n---\n```\n\n## Task Structure\n\n```markdown\n### Task N: [Component Name]\n\n**Produces:**\n- `exact/path/or/description/of/output`\n\n**Inputs / References:**\n- [What this task needs to get started]\n\n- [ ] **Step 1: Define acceptance criteria**\n\nWhat does \"done\" look like for this task?\n- Criterion A: ...\n- Criterion B: ...\n\n- [ ] **Step 2: Produce output**\n\n[Exact description of what to create/write/do, with enough detail that no guessing is needed]\n\n- [ ] **Step 3: Verify against criteria**\n\nCheck each criterion:\n- [ ] Criterion A met?\n- [ ] Criterion B met?\n\n- [ ] **Step 4: Record progress**\n\nSave result to [location]. Note any decisions made.\n```\n\n## No Placeholders\n\nEvery step must contain the actual content an executor needs. These are **plan failures** — never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate handling\" / \"handle edge cases\" (without specifying which)\n- \"Similar to Task N\" (repeat the content — the executor may be reading tasks out of order)\n- Steps that describe what to do without showing how\n- References to outputs not defined in any task\n\n## Remember\n- Exact locations always\n- Complete content in every step — if a step produces output, describe it fully\n- Exact verification steps with expected outcomes\n- Avoid redundancy. Only do what's necessary. Define acceptance criteria first.\n\n## Self-Review\n\nAfter writing the complete plan, look at the spec with fresh eyes and check the plan against it.\n\n**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that addresses it? List any gaps.\n\n**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the \"No Placeholders\" section above. Fix them.\n\n**3. Consistency check:** Do the names, formats, and references you used in later tasks match what you defined in earlier tasks?\n\nIf you find issues, fix them inline. No need to re-review — just fix and move on.\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:**\n\n**1. Subagent-Driven (recommended)** — Dispatch a fresh subagent per task, review between tasks, fast iteration\n\n**2. Sequential Execution** — Execute tasks in this session using executing-plans, with checkpoints for review\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:**\n- **REQUIRED SUB-SKILL:** Use `agent-workflow:subagent-driven-execution`\n\n**If Sequential Execution chosen:**\n- **REQUIRED SUB-SKILL:** Use `agent-workflow:executing-plans`\n\nArchive v1.0.0: 24 files, 105647 bytes\n\nFiles: index.ts (8310b), openclaw.plugin.json (745b), package-lock.json (260597b), package.json (684b), skill-card.md (2845b), SKILL.md (3288b), skills/brainstorming/SKILL.md (5226b), skills/dispatching-parallel-agents/SKILL.md (4829b), skills/executing-plans/SKILL.md (2382b), skills/finishing-work/SKILL.md (3910b), skills/receiving-review/SKILL.md (4941b), skills/requesting-review/SKILL.md (3192b), skills/subagent-driven-execution/SKILL.md (7565b), skills/systematic-problem-solving/SKILL.md (8692b), skills/using-agent-workflow/SKILL.md (4464b), skills/verification-before-completion/SKILL.md (3876b), skills/writing-plans/SKILL.md (5398b), skills/writing-skills/SKILL.md (5825b), src/skill-loader.ts (2241b), src/state-store.ts (8439b), src/workflow-engine.ts (20477b), src/workflow-graph.ts (7931b), tsconfig.json (392b), _meta.json (133b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: agent-workflow\ndescription: \"A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state, branching, parallel context-plugins, and multi-project support. Trigger when the user wants to start a new project, follow a structured workflow, manage multiple concurrent projects, or navigate between workflow steps. Install as a Plugin (not a Skill) for full functionality including the agent_workflow tool. Do not trigger for simple one-off tasks.\"\n---\n\n# Agent Workflow\n\nA structured workflow engine for OpenClaw agents. Migrated and generalized from the [superpowers](https://github.com/anthropics/claude-code-superpowers) workflow system into a code-agnostic, general-purpose workflow plugin.\n\n## What it does\n\nProvides a persistent state machine that guides your agent through a complete work lifecycle:\n\n```\nbrainstorming → writing-plans → [execute] → verification → finishing-work\n                                     ↓\n                          subagent-driven-execution\n                               OR\n                          executing-plans\n```\n\nWith support for:\n- **Persistent state** — workflow survives session restarts\n- **Multi-project** — run multiple workflows concurrently\n- **Branching** — choose execution strategy at branch points\n- **Context-plugins** — fork into review/parallel-agents without leaving main flow\n- **Soft-guard goto** — jump to any step with warnings about skipped prerequisites\n- **11 bundled Skills** — covering the full workflow lifecycle\n\n## Installation\n\nThis is a **Plugin**, not a plain Skill. Install via:\n\n```bash\nopenclaw plugins install clawhub:agent-workflow\nopenclaw gateway restart\n```\n\nThen enable in your `~/.openclaw/openclaw.json`:\n\n```json\n{\n  \"plugins\": {\n    \"allow\": [\"agent-workflow\"]\n  },\n  \"tools\": {\n    \"allow\": [\"agent_workflow\"]\n  }\n}\n```\n\n## Usage\n\nIn your agent (via Feishu, Discord, or any channel):\n\n```\nStart a new workflow for my Q2 planning project\n```\n\nThe agent will call `agent_workflow` with `action: \"start\"` and guide you through the workflow.\n\n## Tool: `agent_workflow`\n\n| Action | Description |\n|--------|-------------|\n| `start` | Begin a new workflow |\n| `status` | View current state (all active workflows if no ID given) |\n| `next` | Advance to the next step |\n| `goto` | Jump to any node (soft-guard warns about skipped steps) |\n| `complete` | Mark current node done |\n| `fork` | Activate a context-plugin without leaving main flow |\n| `join` | Complete a fork and return |\n| `getSkill` | Load full SKILL.md for the current node |\n| `list` | List all workflows |\n| `abandon` | Abandon a workflow |\n\n## Bundled Skills\n\n- `brainstorming` — Turn ideas into specs\n- `writing-plans` — Break specs into tasks\n- `executing-plans` — Sequential execution\n- `subagent-driven-execution` — Parallel subagent execution\n- `verification-before-completion` — Evidence before claims\n- `finishing-work` — Delivery options\n- `dispatching-parallel-agents` — Fork independent tasks\n- `requesting-review` — Dispatch reviewer subagent\n- `receiving-review` — Evaluate feedback rigorously\n- `systematic-problem-solving` — Root-cause diagnosis\n- `writing-skills` — Create/improve Skills\n\nFile v1.0.0:skills/brainstorming/SKILL.md\n\n---\nname: brainstorming\ndescription: \"Use before starting any significant task — creating features, writing content, designing solutions, planning projects, or making changes. Explores user intent, requirements, and design through collaborative dialogue before taking action. Trigger when a new task is described or when the scope of work is unclear. Do not trigger when the user is asking a simple question, giving feedback mid-task, or when a design has already been approved.\"\n---\n\n# Brainstorming Ideas Into Designs\n\nHelp turn ideas into fully formed designs and specs through natural collaborative dialogue.\n\nStart by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.\n\n<HARD-GATE>\nDo NOT invoke any execution skill, take any implementation action, or start producing deliverables until you have presented a design and the user has approved it. This applies to EVERY task regardless of perceived simplicity.\n</HARD-GATE>\n\n## Anti-Pattern: \"This Is Too Simple To Need A Design\"\n\nEvery task goes through this process. A short document, a minor change, a config tweak — all of them. \"Simple\" tasks are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple tasks), but you MUST present it and get approval.\n\n## Checklist\n\nYou MUST create a task for each of these items and complete them in order:\n\n1. **Explore project context** — check existing files, docs, prior work\n2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria\n3. **Propose 2-3 approaches** — with trade-offs and your recommendation\n4. **Present design** — in sections scaled to their complexity, get user approval after each section\n5. **Write design doc** — save to `docs/specs/YYYY-MM-DD-<topic>-design.md`\n6. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)\n7. **User reviews written spec** — ask user to review the spec file before proceeding\n8. **Transition to execution** — invoke `agent-workflow:writing-plans` skill to create an execution plan\n\n## Process Flow\n\n```dot\ndigraph brainstorming {\n    \"Explore project context\" [shape=box];\n    \"Ask clarifying questions\" [shape=box];\n    \"Propose 2-3 approaches\" [shape=box];\n    \"Present design sections\" [shape=box];\n    \"User approves design?\" [shape=diamond];\n    \"Write design doc\" [shape=box];\n    \"Spec self-review\\n(fix inline)\" [shape=box];\n    \"User reviews spec?\" [shape=diamond];\n    \"Invoke writing-plans skill\" [shape=doublecircle];\n\n    \"Explore project context\" -> \"Ask clarifying questions\";\n    \"Ask clarifying questions\" -> \"Propose 2-3 approaches\";\n    \"Propose 2-3 approaches\" -> \"Present design sections\";\n    \"Present design sections\" -> \"User approves design?\";\n    \"User approves design?\" -> \"Present design sections\" [label=\"no, revise\"];\n    \"User approves design?\" -> \"Write design doc\" [label=\"yes\"];\n    \"Write design doc\" -> \"Spec self-review\\n(fix inline)\";\n    \"Spec self-review\\n(fix inline)\" -> \"User reviews spec?\";\n    \"User reviews spec?\" -> \"Invoke writing-plans skill\" [label=\"approved\"];\n    \"User reviews spec?\" -> \"Write design doc\" [label=\"needs changes\"];\n}\n```\n\n## Clarifying Questions\n\nAsk one question at a time. Do NOT ask multiple questions in one message.\n\n**Good questions:**\n- \"What problem does this solve for the user?\"\n- \"What does success look like for this?\"\n- \"Are there any constraints I should know about?\"\n- \"Who is the audience for this?\"\n\n**Bad questions:**\n- \"What's the goal, what are the constraints, and who uses this?\" (too many at once)\n\n## Proposing Approaches\n\nAfter gathering enough context, propose 2-3 distinct approaches:\n\n```\nApproach 1: [Name]\n- How it works: ...\n- Trade-offs: ...\n\nApproach 2: [Name]\n- How it works: ...\n- Trade-offs: ...\n\nMy recommendation: Approach N, because ...\n```\n\nDon't just list options — give a recommendation with reasoning.\n\n## Spec Self-Review\n\nAfter writing the spec, check it yourself before asking the user to review:\n\n1. **Completeness** — Does every stated goal have a corresponding section?\n2. **Placeholder scan** — Any \"TBD\", \"TODO\", \"fill in later\"? Fix them.\n3. **Contradiction check** — Do any two sections conflict?\n4. **Scope check** — Is anything in the spec out of scope for this task?\n\nFix issues inline. Then ask user to review.\n\n## Transition to Execution\n\nAfter user approves the spec:\n\n```\nSpec approved. Ready to create an execution plan.\n\nInvoking agent-workflow:writing-plans to break this into actionable steps.\n```\n\n## Common Mistakes\n\n**Skipping the design for \"simple\" tasks**\n- Problem: Unexamined assumptions cause rework\n- Fix: Always present a design, even if brief\n\n**Asking multiple questions at once**\n- Problem: Overwhelming, hard to answer\n- Fix: One question per message\n\n**Presenting a design without trade-offs**\n- Problem: User can't make informed choice\n- Fix: Always include trade-offs and a recommendation\n\n**Starting execution before approval**\n- Problem: Wasted work if direction changes\n- Fix: Hard gate — no action before approval\n\nFile v1.0.0:skills/dispatching-parallel-agents/SKILL.md\n\n---\nname: dispatching-parallel-agents\ndescription: \"Use when facing 2 or more independent tasks that can be worked on without shared state or sequential dependencies. Trigger when multiple independent problems or tasks need to be investigated or executed simultaneously. Do not trigger when tasks share state, when one depends on another's output, or when you need full context to understand the overall situation first.\"\n---\n\n# Dispatching Parallel Agents\n\n## Overview\n\nYou delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.\n\nWhen you have multiple unrelated tasks (different topics, different areas, different problems), working on them sequentially wastes time. Each task is independent and can happen in parallel.\n\n**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.\n\n## When to Use\n\n```dot\ndigraph when_to_use {\n    \"Multiple tasks?\" [shape=diamond];\n    \"Are they independent?\" [shape=diamond];\n    \"Single agent handles all\" [shape=box];\n    \"One agent per task domain\" [shape=box];\n    \"Can they work in parallel?\" [shape=diamond];\n    \"Sequential agents\" [shape=box];\n    \"Parallel dispatch\" [shape=box];\n\n    \"Multiple tasks?\" -> \"Are they independent?\" [label=\"yes\"];\n    \"Are they independent?\" -> \"Single agent handles all\" [label=\"no - related\"];\n    \"Are they independent?\" -> \"Can they work in parallel?\" [label=\"yes\"];\n    \"Can they work in parallel?\" -> \"Parallel dispatch\" [label=\"yes\"];\n    \"Can they work in parallel?\" -> \"Sequential agents\" [label=\"no - shared state\"];\n}\n```\n\n**Use when:**\n- 3+ independent tasks with different domains\n- Multiple areas broken independently\n- Each task can be understood without context from others\n- No shared state between tasks\n\n**Don't use when:**\n- Tasks are related (completing one might affect others)\n- Need to understand full project state first\n- Agents would interfere with each other (editing same files, using same resources)\n\n## The Pattern\n\n### 1. Identify Independent Domains\n\nGroup tasks by what's involved:\n- Task A: Research topic X\n- Task B: Draft section Y\n- Task C: Review document Z\n\nEach domain is independent — researching X doesn't affect drafting Y.\n\n### 2. Create Focused Agent Tasks\n\nEach agent gets:\n- **Specific scope:** One task or domain\n- **Clear goal:** What to produce\n- **Constraints:** What NOT to do\n- **Expected output:** Summary of what was found/produced\n\n### 3. Dispatch in Parallel\n\n```\nAgent 1 → Task A: Research topic X\nAgent 2 → Task B: Draft section Y\nAgent 3 → Task C: Review document Z\n// All three run concurrently\n```\n\n### 4. Review and Integrate\n\nWhen agents return:\n- Read each summary\n- Verify outputs don't conflict\n- Integrate all results\n- Verify the combined output meets overall goals\n\n## Agent Prompt Structure\n\nGood agent prompts are:\n1. **Focused** — One clear task domain\n2. **Self-contained** — All context needed to understand the task\n3. **Specific about output** — What should the agent return?\n\n```markdown\n[Task description with full context]\n\nYour task:\n1. [Step 1]\n2. [Step 2]\n3. [Step 3]\n\nDo NOT [constraint — what to avoid].\n\nReturn: [Exact summary format expected]\n```\n\n## Common Mistakes\n\n**❌ Too broad:** \"Handle all the tasks\" — agent gets lost\n**✅ Specific:** \"Research topic X only\" — focused scope\n\n**❌ No context:** \"Fix the problem\" — agent doesn't know where\n**✅ Context:** Paste the relevant background and exact task description\n\n**❌ No constraints:** Agent might do too much\n**✅ Constraints:** \"Do NOT change Y\" or \"Focus only on Z\"\n\n**❌ Vague output:** \"Do it\" — you don't know what changed\n**✅ Specific:** \"Return summary of findings and decisions made\"\n\n## When NOT to Use\n\n**Related tasks:** Completing one might affect others — handle together first\n**Need full context:** Understanding requires seeing the entire project\n**Exploratory work:** You don't know what's needed yet\n**Shared state:** Agents would interfere (editing same files, using same resources)\n\n## Verification\n\nAfter agents return:\n1. **Review each summary** — Understand what was produced\n2. **Check for conflicts** — Did agents produce contradictory results?\n3. **Verify combined output** — Do all results work together?\n4. **Spot check** — Agents can make systematic errors\n\n## Key Benefits\n\n1. **Parallelization** — Multiple tasks happen simultaneously\n2. **Focus** — Each agent has narrow scope, less context to track\n3. **Independence** — Agents don't interfere with each other\n4. **Speed** — 3 tasks solved in time of 1\n\nFile v1.0.0:skills/executing-plans/SKILL.md\n\n---\nname: executing-plans\ndescription: \"Use when you have a written plan to execute, working through tasks sequentially with review checkpoints. Trigger when a plan document exists and the user wants to execute it in the current session. Do not trigger without an existing plan document. If subagents are available, prefer agent-workflow:subagent-driven-execution instead.\"\n---\n\n# Executing Plans\n\n## Overview\n\nLoad plan, review critically, execute all tasks, report when complete.\n\n**Announce at start:** \"I'm using the executing-plans skill to implement this plan.\"\n\n**Note:** This skill works much better with subagent support. If subagents are available, use `agent-workflow:subagent-driven-execution` instead — it provides higher quality through fresh context per task and two-stage review.\n\n## The Process\n\n### Step 1: Load and Review Plan\n\n1. Read plan file\n2. Review critically — identify any questions or concerns about the plan\n3. If concerns: Raise them with the user before starting\n4. If no concerns: Create task list and proceed\n\n### Step 2: Execute Tasks\n\nFor each task:\n1. Mark as in_progress\n2. Follow each step exactly (plan has bite-sized steps)\n3. Run verifications as specified\n4. Mark as completed\n\n### Step 3: Complete Work\n\nAfter all tasks complete and verified:\n- Announce: \"I'm using the finishing-work skill to complete this work.\"\n- **REQUIRED SUB-SKILL:** Use `agent-workflow:finishing-work`\n- Follow that skill to verify outputs, present options, execute choice\n\n## When to Stop and Ask for Help\n\n**STOP executing immediately when:**\n- Hit a blocker (missing input, verification fails, instruction unclear)\n- Plan has critical gaps preventing starting\n- You don't understand an instruction\n- Verification fails repeatedly\n\n**Ask for clarification rather than guessing.**\n\n## When to Revisit Earlier Steps\n\n**Return to Review (Step 1) when:**\n- User updates the plan based on your feedback\n- Fundamental approach needs rethinking\n\n**Don't force through blockers** — stop and ask.\n\n## Remember\n- Review plan critically first\n- Follow plan steps exactly\n- Don't skip verifications\n- Reference skills when plan says to\n- Stop when blocked, don't guess\n\n## Integration\n\n**Required workflow skills:**\n- `agent-workflow:writing-plans` — Creates the plan this skill executes\n- `agent-workflow:finishing-work` — Complete work after all tasks are done\n\nFile v1.0.0:skills/finishing-work/SKILL.md\n\n---\nname: finishing-work\ndescription: \"Use when a task or project phase is complete and you need to decide how to deliver or integrate the work. Trigger after all tasks are done and verified. Do not trigger before verification is complete or while tasks are still in progress.\"\n---\n\n# Finishing Work\n\n## Overview\n\nGuide completion of a work phase by presenting clear options and handling the chosen delivery workflow.\n\n**Core principle:** Verify work → Present options → Execute choice → Clean up.\n\n**Announce at start:** \"I'm using the finishing-work skill to complete this work.\"\n\n## The Process\n\n### Step 1: Verify Work\n\n**Before presenting options, verify the work is complete:**\n\nCheck each of the following:\n- All planned tasks are done\n- All acceptance criteria are met\n- No known issues remain unaddressed\n\n**If verification fails:**\n```\nWork incomplete or issues remain:\n\n[Show what's missing or broken]\n\nCannot proceed with delivery until work is verified complete.\n```\n\nStop. Don't proceed to Step 2.\n\n**If verification passes:** Continue to Step 2.\n\n### Step 2: Confirm Delivery Target\n\nAsk or confirm: \"Where does this work go? Who receives it?\"\n\nExamples:\n- Integrate into main project\n- Submit to stakeholder for review\n- Keep as draft for later\n- Discard\n\n### Step 3: Present Options\n\nPresent exactly these 4 options:\n\n```\nWork complete. What would you like to do?\n\n1. Integrate into main project directly\n2. Submit for review / deliver to stakeholder\n3. Keep as-is (I'll handle it later)\n4. Discard this work\n\nWhich option?\n```\n\n**Don't add explanation** — keep options concise.\n\n### Step 4: Execute Choice\n\n#### Option 1: Integrate Directly\n\n1. Merge or apply the work into the main project\n2. Verify the integrated result still meets requirements\n3. Clean up any working drafts or temporary files\n4. Confirm integration complete\n\n#### Option 2: Submit for Review / Deliver\n\n1. Package or prepare the output for delivery\n2. Send to stakeholder or submit for review\n3. Note any context the reviewer needs\n4. Keep working copy until review is complete\n\nThen: Clean up workspace (Step 5)\n\n#### Option 3: Keep As-Is\n\nReport: \"Keeping work in progress at [location]. No delivery action taken.\"\n\n**Don't clean up.**\n\n#### Option 4: Discard\n\n**Confirm first:**\n```\nThis will permanently delete:\n- [Description of what will be deleted]\n- [Any associated drafts or working files]\n\nType 'discard' to confirm.\n```\n\nWait for exact confirmation.\n\nIf confirmed: Remove the work and working files.\n\nThen: Clean up workspace (Step 5)\n\n### Step 5: Clean Up Workspace\n\n**For Options 1, 2, 4:**\n\nRemove any temporary working files, drafts, or working copies that are no longer needed.\n\n**For Option 3:** Keep everything.\n\n## Quick Reference\n\n| Option | Integrate | Deliver | Keep Working Copy | Clean Up |\n|--------|-----------|---------|-------------------|----------|\n| 1. Integrate directly | ✓ | — | — | ✓ |\n| 2. Submit for review | — | ✓ | ✓ | After review |\n| 3. Keep as-is | — | — | ✓ | — |\n| 4. Discard | — | — | — | ✓ |\n\n## Common Mistakes\n\n**Skipping verification**\n- Problem: Delivering incomplete or broken work\n- Fix: Always verify before offering options\n\n**Open-ended questions**\n- Problem: \"What should I do next?\" → ambiguous\n- Fix: Present exactly 4 structured options\n\n**No confirmation for discard**\n- Problem: Accidentally delete work\n- Fix: Require typed \"discard\" confirmation\n\n## Red Flags\n\n**Never:**\n- Deliver without verifying work is complete\n- Delete work without confirmation\n- Skip the options presentation\n\n**Always:**\n- Verify work before offering options\n- Present exactly 4 options\n- Get typed confirmation for Option 4\n- Clean up workspace for Options 1 and 4 only\n\n## Integration\n\n**Called by:**\n- `agent-workflow:subagent-driven-execution` — After all tasks complete\n- `agent-workflow:executing-plans` — After all tasks complete\n\nFile v1.0.0:skills/receiving-review/SKILL.md\n\n---\nname: receiving-review\ndescription: \"Use when receiving feedback on completed work, before implementing suggestions. Applies especially when feedback seems unclear or questionable — requires reasoned evaluation, not performative agreement or blind implementation.\"\n---\n\n# Receiving Review Feedback\n\n## Overview\n\nReview feedback requires technical evaluation, not emotional performance.\n\n**Core principle:** Verify before implementing. Ask before assuming. Correctness over social comfort.\n\n## The Response Pattern\n\n```\nWHEN receiving review feedback:\n\n1. READ: Complete feedback without reacting\n2. UNDERSTAND: Restate requirement in own words (or ask)\n3. VERIFY: Check against actual work\n4. EVALUATE: Is this technically sound for THIS project?\n5. RESPOND: Technical acknowledgment or reasoned pushback\n6. IMPLEMENT: One item at a time, verify each\n```\n\n## Forbidden Responses\n\n**NEVER:**\n- \"You're absolutely right!\" (performative)\n- \"Great point!\" / \"Excellent feedback!\" (performative)\n- \"Let me implement that now\" (before verification)\n\n**INSTEAD:**\n- Restate the requirement in technical terms\n- Ask clarifying questions\n- Push back with reasoning if the feedback is wrong\n- Just start working (actions > words)\n\n## Handling Unclear Feedback\n\n```\nIF any item is unclear:\n  STOP — do not implement anything yet\n  ASK for clarification on unclear items\n\nWHY: Items may be related. Partial understanding = wrong implementation.\n```\n\n**Example:**\n```\nReviewer: \"Fix items 1-6\"\nYou understand 1, 2, 3, 6. Unclear on 4, 5.\n\n❌ WRONG: Implement 1, 2, 3, 6 now, ask about 4, 5 later\n✅ RIGHT: \"I understand items 1, 2, 3, 6. Need clarification on 4 and 5 before proceeding.\"\n```\n\n## Source-Specific Handling\n\n### From the user / project owner\n- **Trusted** — implement after understanding\n- **Still ask** if scope unclear\n- **No performative agreement**\n- **Skip to action** or technical acknowledgment\n\n### From external reviewers\n```\nBEFORE implementing:\n  1. Check: Is this correct for THIS project?\n  2. Check: Does it break existing work?\n  3. Check: Is there a reason for the current approach?\n  4. Check: Does reviewer understand full context?\n\nIF suggestion seems wrong:\n  Push back with clear reasoning\n\nIF can't easily verify:\n  Say so: \"I can't verify this without [X]. Should I [investigate/ask/proceed]?\"\n\nIF conflicts with project owner's prior decisions:\n  Stop and discuss with project owner first\n```\n\n## Necessity Check for Suggested Features\n\n```\nIF reviewer suggests adding something new:\n  Check: Is this actually needed?\n\n  IF not needed: \"This isn't used anywhere. Skip it (YAGNI)?\"\n  IF needed: Then implement it\n```\n\n**Rule:** \"You and reviewer both report to the project owner. If we don't need this, don't add it.\"\n\n## Implementation Order\n\n```\nFOR multi-item feedback:\n  1. Clarify anything unclear FIRST\n  2. Then implement in this order:\n     - Blocking issues (wrong, broken)\n     - Simple fixes (minor errors, omissions)\n     - Complex fixes (restructuring, rework)\n  3. Verify each fix individually\n  4. Confirm no regressions\n```\n\n## When To Push Back\n\nPush back when:\n- Suggestion breaks existing work\n- Reviewer lacks full project context\n- Adding something not needed (YAGNI)\n- Suggestion is factually incorrect for this domain\n- Conflicts with project owner's decisions\n\n**How to push back:**\n- Use clear reasoning, not defensiveness\n- Ask specific questions\n- Reference existing work as evidence\n- Involve project owner if it's a strategic decision\n\n## Acknowledging Correct Feedback\n\nWhen feedback IS correct:\n```\n✅ \"Fixed. [Brief description of what changed]\"\n✅ \"Good catch — [specific issue]. Fixed in [location].\"\n✅ [Just fix it and show the result]\n\n❌ \"You're absolutely right!\"\n❌ \"Great point!\"\n❌ \"Thanks for catching that!\"\n❌ ANY gratitude expression\n```\n\n**Why no thanks:** Actions speak. Just fix it. The result itself shows you heard the feedback.\n\n## Gracefully Correcting Your Pushback\n\nIf you pushed back and were wrong:\n```\n✅ \"You were right — I checked [X] and it does [Y]. Implementing now.\"\n✅ \"Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing.\"\n\n❌ Long apology\n❌ Defending why you pushed back\n❌ Over-explaining\n```\n\nState the correction factually and move on.\n\n## Common Mistakes\n\n| Mistake | Fix |\n|---------|-----|\n| Performative agreement | State requirement or just act |\n| Blind implementation | Verify against actual work first |\n| Batch without verifying | One at a time, verify each |\n| Assuming reviewer is right | Check if it breaks things |\n| Avoiding pushback | Correctness > comfort |\n| Partial implementation | Clarify all items first |\n| Can't verify, proceed anyway | State limitation, ask for direction |\n\n## The Bottom Line\n\n**External feedback = suggestions to evaluate, not orders to follow.**\n\nVerify. Question. Then implement.\n\nNo performative agreement. Reasoned rigor always.\n\nFile v1.0.0:skills/requesting-review/SKILL.md\n\n---\nname: requesting-review\ndescription: \"Use when completing significant work to verify it meets requirements before delivery. Trigger after finishing a major task, completing a project phase, or before submitting results to a stakeholder. Do not trigger for minor or trivial tasks where review would be disproportionate.\"\n---\n\n# Requesting Review\n\nDispatch a reviewer subagent to catch issues before delivery. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.\n\n**Core principle:** Review early, review often.\n\n## When to Request Review\n\n**Mandatory:**\n- After each task in subagent-driven execution\n- After completing a major deliverable\n- Before final delivery to stakeholder\n\n**Optional but valuable:**\n- When stuck (fresh perspective)\n- Before significant rework (baseline check)\n- After resolving a complex problem\n\n## How to Request\n\n**1. Define scope of work to review:**\n- What was produced\n- What it should accomplish (spec or requirements)\n- Any specific concerns to check\n\n**2. Dispatch reviewer subagent:**\n\nUse the following template:\n\n```markdown\n## Review Request\n\n### What Was Produced\n[Description of the output — what it is and where it lives]\n\n### Requirements / Spec\n[What the output is supposed to accomplish]\n\n### Specific Concerns (optional)\n[Any areas you're unsure about]\n\n### Your Task\nReview the output against the requirements.\n\nReport:\n- **Critical:** Issues that must be fixed before delivery (wrong, missing, broken)\n- **Important:** Issues that should be fixed soon (gaps, inconsistencies)\n- **Minor:** Nice-to-have improvements\n- **Assessment:** Ready to deliver / Needs fixes\n```\n\n**3. Act on feedback:**\n- Fix Critical issues immediately\n- Fix Important issues before proceeding\n- Note Minor issues for later\n- Push back if reviewer is wrong (with reasoning)\n\n## Example\n\n```\n[Just completed Task 2: Draft executive summary]\n\nYou: Let me request review before proceeding.\n\n[Dispatch reviewer subagent]\n  WHAT_WAS_PRODUCED: Executive summary for Q1 report\n  REQUIREMENTS: Task 2 from docs/plans/q1-report-plan.md\n  SPECIFIC_CONCERNS: Not sure if the tone matches the audience\n\n[Subagent returns]:\n  Strengths: Clear structure, covers all key points\n  Issues:\n    Important: Tone is too technical for executive audience\n    Minor: Missing one metric from requirements\n  Assessment: Needs fixes before delivery\n\n[Fix tone and add missing metric]\n[Continue to Task 3]\n```\n\n## Integration with Workflows\n\n**Subagent-Driven Execution:**\n- Review after EACH task\n- Catch issues before they compound\n- Fix before moving to next task\n\n**Executing Plans:**\n- Review after each checkpoint\n- Get feedback, apply, continue\n\n**Ad-Hoc Work:**\n- Review before final delivery\n- Review when stuck\n\n## Red Flags\n\n**Never:**\n- Skip review because \"it's simple\"\n- Ignore Critical issues\n- Proceed with unfixed Critical or Important issues\n- Argue with valid feedback\n\n**If reviewer is wrong:**\n- Push back with clear reasoning\n- Show evidence that the output meets requirements\n- Request clarification\n\nFile v1.0.0:skills/subagent-driven-execution/SKILL.md\n\n---\nname: subagent-driven-execution\ndescription: \"Use when executing a plan with independent tasks in the current session. Trigger when a plan is ready and tasks can be delegated to specialized subagents for parallel or sequential execution with review after each task. Do not trigger without a written plan, or when tasks are tightly coupled and must be done sequentially by the same agent without review checkpoints.\"\n---\n\n# Subagent-Driven Execution\n\nExecute a plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance review first, then quality review.\n\n**Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.\n\n**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.\n\n## When to Use\n\n```dot\ndigraph when_to_use {\n    \"Have execution plan?\" [shape=diamond];\n    \"Tasks mostly independent?\" [shape=diamond];\n    \"Stay in this session?\" [shape=diamond];\n    \"subagent-driven-execution\" [shape=box];\n    \"executing-plans\" [shape=box];\n    \"Manual execution or brainstorm first\" [shape=box];\n\n    \"Have execution plan?\" -> \"Tasks mostly independent?\" [label=\"yes\"];\n    \"Have execution plan?\" -> \"Manual execution or brainstorm first\" [label=\"no\"];\n    \"Tasks mostly independent?\" -> \"Stay in this session?\" [label=\"yes\"];\n    \"Tasks mostly independent?\" -> \"Manual execution or brainstorm first\" [label=\"no - tightly coupled\"];\n    \"Stay in this session?\" -> \"subagent-driven-execution\" [label=\"yes\"];\n    \"Stay in this session?\" -> \"executing-plans\" [label=\"no - separate session\"];\n}\n```\n\n## The Process\n\n```dot\ndigraph process {\n    rankdir=TB;\n\n    subgraph cluster_per_task {\n        label=\"Per Task\";\n        \"Dispatch executor subagent\" [shape=box];\n        \"Executor subagent asks questions?\" [shape=diamond];\n        \"Answer questions, provide context\" [shape=box];\n        \"Executor subagent executes, verifies, self-reviews\" [shape=box];\n        \"Dispatch spec reviewer subagent\" [shape=box];\n        \"Spec reviewer confirms output matches spec?\" [shape=diamond];\n        \"Executor subagent fixes spec gaps\" [shape=box];\n        \"Dispatch quality reviewer subagent\" [shape=box];\n        \"Quality reviewer approves?\" [shape=diamond];\n        \"Executor subagent fixes quality issues\" [shape=box];\n        \"Mark task complete\" [shape=box];\n    }\n\n    \"Read plan, extract all tasks, note context, create task list\" [shape=box];\n    \"More tasks remain?\" [shape=diamond];\n    \"Dispatch final reviewer subagent for entire output\" [shape=box];\n    \"Use agent-workflow:finishing-work\" [shape=box style=filled fillcolor=lightgreen];\n\n    \"Read plan, extract all tasks, note context, create task list\" -> \"Dispatch executor subagent\";\n    \"Dispatch executor subagent\" -> \"Executor subagent asks questions?\";\n    \"Executor subagent asks questions?\" -> \"Answer questions, provide context\" [label=\"yes\"];\n    \"Answer questions, provide context\" -> \"Dispatch executor subagent\";\n    \"Executor subagent asks questions?\" -> \"Executor subagent executes, verifies, self-reviews\" [label=\"no\"];\n    \"Executor subagent executes, verifies, self-reviews\" -> \"Dispatch spec reviewer subagent\";\n    \"Dispatch spec reviewer subagent\" -> \"Spec reviewer confirms output matches spec?\";\n    \"Spec reviewer confirms output matches spec?\" -> \"Executor subagent fixes spec gaps\" [label=\"no\"];\n    \"Executor subagent fixes spec gaps\" -> \"Dispatch spec reviewer subagent\" [label=\"re-review\"];\n    \"Spec reviewer confirms output matches spec?\" -> \"Dispatch quality reviewer subagent\" [label=\"yes\"];\n    \"Dispatch quality reviewer subagent\" -> \"Quality reviewer approves?\";\n    \"Quality reviewer approves?\" -> \"Executor subagent fixes quality issues\" [label=\"no\"];\n    \"Executor subagent fixes quality issues\" -> \"Dispatch quality reviewer subagent\" [label=\"re-review\"];\n    \"Quality reviewer approves?\" -> \"Mark task complete\" [label=\"yes\"];\n    \"Mark task complete\" -> \"More tasks remain?\";\n    \"More tasks remain?\" -> \"Dispatch executor subagent\" [label=\"yes\"];\n    \"More tasks remain?\" -> \"Dispatch final reviewer subagent for entire output\" [label=\"no\"];\n    \"Dispatch final reviewer subagent for entire output\" -> \"Use agent-workflow:finishing-work\";\n}\n```\n\n## Model Selection\n\nUse the least powerful model that can handle each role to conserve cost and increase speed.\n\n**Mechanical execution tasks** (isolated, clear specs, narrow scope): use a fast, cheap model. Most tasks are mechanical when the plan is well-specified.\n\n**Integration and judgment tasks** (multi-area coordination, pattern matching, problem-solving): use a standard model.\n\n**Design, review, and quality tasks**: use the most capable available model.\n\n**Task complexity signals:**\n- Touches 1-2 areas with a complete spec → cheap model\n- Touches multiple areas with integration concerns → standard model\n- Requires design judgment or broad project understanding → most capable model\n\n## Executor Subagent Prompt Structure\n\nCraft each executor prompt to be:\n1. **Self-contained** — all context needed to complete the task\n2. **Scoped** — one task only, clear boundaries\n3. **Verifiable** — explicit acceptance criteria\n4. **Output-specified** — exactly what to produce and where\n\n```markdown\n## Task: [Task Name from Plan]\n\n### Context\n[Project background, relevant prior work, conventions to follow]\n\n### Your Task\n[Exact description from plan, including all steps]\n\n### Acceptance Criteria\n- [ ] Criterion A\n- [ ] Criterion B\n\n### Output\nProduce: [exact output description]\nSave to: [location]\n\n### Self-Review\nBefore reporting complete, verify each criterion above is met.\nReport: summary of what you did and any decisions made.\n```\n\n## Spec Reviewer Prompt Structure\n\n```markdown\n## Review: Does output match spec?\n\n### Spec / Plan Task\n[Paste the task from the plan]\n\n### Output Produced\n[Summary or location of what the executor produced]\n\n### Your Job\nCheck each requirement in the spec against the output.\nReport:\n- PASS: output matches spec\n- FAIL: list specific gaps with exact locations\n```\n\n## Quality Reviewer Prompt Structure\n\n```markdown\n## Review: Quality check\n\n### Output\n[Location or summary of what was produced]\n\n### Your Job\nReview for quality issues:\n- Clarity and completeness\n- Consistency with project conventions\n- Any obvious errors or omissions\n\nReport:\n- APPROVE: output is ready\n- REVISE: list specific issues with suggested fixes\n```\n\n## Common Mistakes\n\n**Too broad executor scope:** \"Do everything in the plan\" — executor gets lost\n**Specific is better:** \"Complete Task 3 only: [paste task]\"\n\n**No context in prompt:** Executor doesn't know project conventions\n**Include context:** Paste relevant background, prior decisions\n\n**No acceptance criteria:** Executor doesn't know when done\n**Always include:** Explicit criteria the executor checks before reporting\n\n**Trusting executor self-report:** Always run spec review after\n**Always dispatch:** Spec reviewer after every executor\n\n## Integration\n\n**Called by:**\n- `agent-workflow:writing-plans` — After plan is created and execution mode chosen\n\n**Calls:**\n- `agent-workflow:finishing-work` — After all tasks complete and final review passes\n- `agent-workflow:requesting-review` — Optional: request review after each task\n\nFile v1.0.0:skills/systematic-problem-solving/SKILL.md\n\n---\nname: systematic-problem-solving\ndescription: \"Use when encountering any problem, failure, or unexpected outcome, before proposing solutions. Trigger when something isn't working as expected, a task produces wrong results, or a process breaks down. Do not trigger for planning or creative tasks — only for diagnosing problems.\"\n---\n\n# Systematic Problem Solving\n\n## Overview\n\nRandom fixes waste time and create new problems. Quick patches mask underlying issues.\n\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\n\n**Violating the letter of this process is violating the spirit of problem-solving.**\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\nIf you haven't completed Phase 1, you cannot propose fixes.\n\n## When to Use\n\nUse for ANY unexpected situation:\n- Task produces wrong output\n- Process breaks or stalls\n- Unexpected behavior from a tool or system\n- Results don't match expectations\n- A previous fix didn't work\n\n**Use this ESPECIALLY when:**\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You've already tried multiple fixes\n- Previous fix didn't work\n- You don't fully understand the issue\n\n**Don't skip when:**\n- Issue seems simple (simple problems have root causes too)\n- You're in a hurry (rushing guarantees rework)\n- Someone wants it fixed NOW (systematic is faster than thrashing)\n\n## The Four Phases\n\nYou MUST complete each phase before proceeding to the next.\n\n### Phase 1: Root Cause Investigation\n\n**BEFORE attempting ANY fix:**\n\n1. **Read Error Messages or Failure Signals Carefully**\n   - Don't skip past errors or warnings\n   - They often contain the exact solution\n   - Note specific locations, codes, or descriptions\n\n2. **Reproduce Consistently**\n   - Can you trigger it reliably?\n   - What are the exact conditions?\n   - Does it happen every time?\n   - If not reproducible → gather more data, don't guess\n\n3. **Check Recent Changes**\n   - What changed that could cause this?\n   - New inputs, config changes, environmental differences\n   - What was different when it last worked?\n\n4. **Gather Evidence in Multi-Component Systems**\n\n   **WHEN the system has multiple components (e.g., input → process → output, API → service → storage):**\n\n   **BEFORE proposing fixes, add diagnostic instrumentation:**\n   ```\n   For EACH component boundary:\n     - Log what data enters the component\n     - Log what data exits the component\n     - Verify config/state propagation\n     - Check state at each layer\n\n   Run once to gather evidence showing WHERE it breaks\n   THEN analyze evidence to identify the failing component\n   THEN investigate that specific component\n   ```\n\n   **Example (multi-layer process):**\n   ```\n   Layer 1: Input received?\n   → Log: \"Input value: [X]\"\n\n   Layer 2: Processing step applied correctly?\n   → Log: \"After step A: [Y]\"\n\n   Layer 3: Output produced correctly?\n   → Log: \"Final output: [Z], expected: [W]\"\n   ```\n\n   **This reveals:** Which layer fails (input ✓, processing ✗, output not reached)\n\n5. **Trace Data Flow**\n\n   **WHEN the error is deep in a process:**\n   - Where does the bad value or wrong result originate?\n   - What produced this with the wrong value?\n   - Keep tracing back until you find the source\n   - Fix at source, not at symptom\n\n### Phase 2: Pattern Analysis\n\n**Find the pattern before fixing:**\n\n1. **Find Working Examples**\n   - Locate similar working cases in the same project\n   - What works that's similar to what's broken?\n\n2. **Compare Against References**\n   - If implementing a pattern, read the reference COMPLETELY\n   - Don't skim — read every detail\n   - Understand the pattern fully before applying\n\n3. **Identify Differences**\n   - What's different between working and broken?\n   - List every difference, however small\n   - Don't assume \"that can't matter\"\n\n4. **Understand Dependencies**\n   - What does this component depend on?\n   - What settings, config, or inputs does it assume?\n\n### Phase 3: Hypothesis and Testing\n\n**Scientific method:**\n\n1. **Form Single Hypothesis**\n   - State clearly: \"I think X is the root cause because Y\"\n   - Write it down\n   - Be specific, not vague\n\n2. **Test Minimally**\n   - Make the SMALLEST possible change to test hypothesis\n   - One variable at a time\n   - Don't fix multiple things at once\n\n3. **Verify Before Continuing**\n   - Did it work? Yes → Phase 4\n   - Didn't work? Form NEW hypothesis\n   - DON'T add more fixes on top\n\n4. **When You Don't Know**\n   - Say \"I don't understand X\"\n   - Don't pretend to know\n   - Ask for help or research more\n\n### Phase 4: Implementation\n\n**Fix the root cause, not the symptom:**\n\n1. **Define a Verification Case**\n   - Simplest possible reproduction of the problem\n   - Must be checkable before and after fix\n   - MUST have this before fixing\n\n2. **Implement Single Fix**\n   - Address the root cause identified\n   - ONE change at a time\n   - No \"while I'm here\" improvements\n   - No bundled changes\n\n3. **Verify Fix**\n   - Problem resolved now?\n   - No other things broken?\n   - Issue actually gone?\n\n4. **If Fix Doesn't Work**\n   - STOP\n   - Count: How many fixes have you tried?\n   - If < 3: Return to Phase 1, re-analyze with new information\n   - **If ≥ 3: STOP and question the approach (step 5 below)**\n   - DON'T attempt Fix #4 without discussing the approach\n\n5. **If 3+ Fixes Failed: Question the Approach**\n\n   **Pattern indicating a structural problem:**\n   - Each fix reveals new coupling or dependency in a different place\n   - Fixes require large-scale changes to implement\n   - Each fix creates new symptoms elsewhere\n\n   **STOP and question fundamentals:**\n   - Is this approach fundamentally sound?\n   - Are we \"sticking with it through sheer inertia\"?\n   - Should we reconsider the approach vs. continue fixing symptoms?\n\n   **Discuss with the user before attempting more fixes.**\n\n## Red Flags — STOP and Follow Process\n\nIf you catch yourself thinking:\n- \"Quick fix for now, investigate later\"\n- \"Just try changing X and see if it works\"\n- \"Add multiple changes, check results\"\n- \"It's probably X, let me fix that\"\n- \"I don't fully understand but this might work\"\n- \"Here are the main problems: [lists fixes without investigation]\"\n- Proposing solutions before tracing the issue\n- **\"One more fix attempt\" (when already tried 2+)**\n- **Each fix reveals a new problem in a different place**\n\n**ALL of these mean: STOP. Return to Phase 1.**\n\n**If 3+ fixes failed:** Question the approach (see Phase 4.5)\n\n## User Signals You're Doing It Wrong\n\n**Watch for these redirections:**\n- \"Is that not happening?\" — You assumed without verifying\n- \"Will it show us...?\" — You should have added evidence gathering\n- \"Stop guessing\" — You're proposing fixes without understanding\n- \"We're stuck?\" (frustrated) — Your approach isn't working\n\n**When you see these:** STOP. Return to Phase 1.\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. Process is fast for simple problems. |\n| \"Emergency, no time for process\" | Systematic problem-solving is FASTER than guess-and-check thrashing. |\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\n| \"Multiple fixes at once saves time\" | Can't isolate what worked. Causes new problems. |\n| \"I see the problem, let me fix it\" | Seeing symptoms ≠ understanding root cause. |\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = structural problem. Question approach, don't fix again. |\n\n## Quick Reference\n\n| Phase | Key Activities | Success Criteria |\n|-------|---------------|------------------|\n| **1. Root Cause** | Read signals, reproduce, check changes, gather evidence | Understand WHAT and WHY |\n| **2. Pattern** | Find working examples, compare | Identify differences |\n| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |\n| **4. Implementation** | Define verification case, fix, verify | Problem resolved |\n\n## When Process Reveals \"No Root Cause\"\n\nIf systematic investigation reveals the issue is truly environmental, timing-dependent, or external:\n\n1. You've completed the process\n2. Document what you investigated\n3. Implement appropriate handling (retry, fallback, error message)\n4. Add monitoring or logging for future investigation\n\n**But:** 95% of \"no root cause\" cases are incomplete investigation.\n\n## Real-World Impact\n\n- Systematic approach: 15-30 minutes to resolve\n- Random fixes approach: 2-3 hours of thrashing\n- First-time resolution rate: 95% vs 40%\n- New problems introduced: Near zero vs common\n\nFile v1.0.0:skills/using-agent-workflow/SKILL.md\n\n---\nname: using-agent-workflow\ndescription: \"Use at the start of any conversation to establish how to find and invoke skills. Trigger when a new session begins or when the user asks how agent-workflow skills work. Covers skill discovery, invocation rules, and priority ordering. Do not trigger mid-task unless the user explicitly asks about skill usage.\"\n---\n\n<EXTREMELY-IMPORTANT>\nIf you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.\n\nIF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.\n\nThis is not negotiable. This is not optional. You cannot rationalize your way out of this.\n</EXTREMELY-IMPORTANT>\n\n## Instruction Priority\n\nAgent-workflow skills override default behavior, but **user instructions always take precedence**:\n\n1. **User's explicit instructions** (project config files, direct requests) — highest priority\n2. **Agent-workflow skills** — override default behavior where they conflict\n3. **Default behavior** — lowest priority\n\n## How to Access Skills\n\nUse the platform's skill invocation mechanism. When you invoke a skill, its content is loaded and presented to you — follow it directly.\n\n# Using Skills\n\n## The Rule\n\n**Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.\n\n```dot\ndigraph skill_flow {\n    \"User message received\" [shape=doublecircle];\n    \"About to plan?\" [shape=doublecircle];\n    \"Already brainstormed?\" [shape=diamond];\n    \"Invoke brainstorming skill\" [shape=box];\n    \"Might any skill apply?\" [shape=diamond];\n    \"Invoke skill\" [shape=box];\n    \"Announce: 'Using [skill] to [purpose]'\" [shape=box];\n    \"Has checklist?\" [shape=diamond];\n    \"Create todo per item\" [shape=box];\n    \"Follow skill exactly\" [shape=box];\n    \"Respond (including clarifications)\" [shape=doublecircle];\n\n    \"About to plan?\" -> \"Already brainstormed?\";\n    \"Already brainstormed?\" -> \"Invoke brainstorming skill\" [label=\"no\"];\n    \"Already brainstormed?\" -> \"Might any skill apply?\" [label=\"yes\"];\n    \"Invoke brainstorming skill\" -> \"Might any skill apply?\";\n\n    \"User message received\" -> \"Might any skill apply?\";\n    \"Might any skill apply?\" -> \"Invoke skill\" [label=\"yes, even 1%\"];\n    \"Might any skill apply?\" -> \"Respond (including clarifications)\" [label=\"definitely not\"];\n    \"Invoke skill\" -> \"Announce: 'Using [skill] to [purpose]'\";\n    \"Announce: 'Using [skill] to [purpose]'\" -> \"Has checklist?\";\n    \"Has checklist?\" -> \"Create todo per item\" [label=\"yes\"];\n    \"Has checklist?\" -> \"Follow skill exactly\" [label=\"no\"];\n    \"Create todo per item\" -> \"Follow skill exactly\";\n}\n```\n\n## Red Flags\n\nThese thoughts mean STOP — you're rationalizing:\n\n| Thought | Reality |\n|---------|---------|\n| \"This is just a simple question\" | Questions are tasks. Check for skills. |\n| \"I need more context first\" | Skill check comes BEFORE clarifying questions. |\n| \"Let me gather information first\" | Skills tell you HOW to gather information. |\n| \"This doesn't need a formal skill\" | If a skill exists, use it. |\n| \"I remember this skill\" | Skills evolve. Read current version. |\n| \"This doesn't count as a task\" | Action = task. Check for skills. |\n| \"The skill is overkill\" | Simple things become complex. Use it. |\n| \"I'll just do this one thing first\" | Check BEFORE doing anything. |\n| \"This feels productive\" | Undisciplined action wastes time. Skills prevent this. |\n| \"I know what that means\" | Knowing the concept ≠ using the skill. Invoke it. |\n\n## Skill Priority\n\nWhen multiple skills could apply, use this order:\n\n1. **Process skills first** (brainstorming, systematic-problem-solving) — these determine HOW to approach the task\n2. **Execution skills second** (writing-plans, subagent-driven-execution) — these guide execution\n\n\"Let's do X\" → brainstorming first, then execution skills.\n\"Something went wrong\" → systematic-problem-solving first, then domain-specific skills.\n\n## Skill Types\n\n**Rigid** (systematic-problem-solving, verification-before-completion): Follow exactly. Don't adapt away the discipline.\n\n**Flexible** (brainstorming, writing-plans): Adapt principles to context.\n\nThe skill itself tells you which type it is.\n\n## User Instructions\n\nInstructions say WHAT, not HOW. \"Do X\" or \"Fix Y\" doesn't mean skip workflows.\n\nFile v1.0.0:skills/verification-before-completion/SKILL.md\n\n---\nname: verification-before-completion\ndescription: \"Use before claiming any work is complete, correct, or passing. Requires running verification steps and confirming output before making success claims. Trigger before wrapping up any task, delivering results, or reporting completion. Do not skip verification even for simple tasks.\"\n---\n\n# Verification Before Completion\n\n## Overview\n\nClaiming work is complete without verification is dishonesty, not efficiency.\n\n**Core principle:** Evidence before claims, always.\n\n**Violating the letter of this rule is violating the spirit of this rule.**\n\n## The Iron Law\n\n```\nNO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE\n```\n\nIf you haven't run the verification step in this message, you cannot claim it passes.\n\n## The Gate Function\n\n```\nBEFORE claiming any status or expressing satisfaction:\n\n1. IDENTIFY: What step proves this claim?\n2. RUN: Execute the FULL verification (fresh, complete)\n3. READ: Full output, check result, count failures\n4. VERIFY: Does output confirm the claim?\n   - If NO: State actual status with evidence\n   - If YES: State claim WITH evidence\n5. ONLY THEN: Make the claim\n\nSkip any step = asserting without verifying\n```\n\n## Common Failures\n\n| Claim | Requires | Not Sufficient |\n|-------|----------|----------------|\n| Task complete | Checklist verified: all criteria met | \"I think it's done\" |\n| Output correct | Output reviewed against spec | \"Looks right\" |\n| Requirements met | Line-by-line checklist against spec | \"Everything seems covered\" |\n| Problem fixed | Original symptom re-tested: resolved | \"Should be fixed now\" |\n| Subagent completed | Actual output inspected | Subagent reports \"success\" |\n| Quality good | Reviewer approved | \"Seems high quality\" |\n\n## Red Flags — STOP\n\n- Using \"should\", \"probably\", \"seems to\"\n- Expressing satisfaction before verification (\"Great!\", \"Perfect!\", \"Done!\", etc.)\n- About to deliver/report without verification\n- Trusting subagent success reports without checking output\n- Relying on partial verification\n- Thinking \"just this once\"\n- **ANY wording implying success without having run verification**\n\n## Rationalization Prevention\n\n| Excuse | Reality |\n|--------|---------|\n| \"Should work now\" | RUN the verification |\n| \"I'm confident\" | Confidence ≠ evidence |\n| \"Just this once\" | No exceptions |\n| \"Subagent said success\" | Verify output independently |\n| \"Partial check is enough\" | Partial proves nothing |\n| \"Different words so rule doesn't apply\" | Spirit over letter |\n\n## Key Patterns\n\n**Task completion:**\n```\n✅ [Run checklist] [See: all criteria met] \"Task complete\"\n❌ \"Should be done\" / \"Looks correct\"\n```\n\n**Requirements coverage:**\n```\n✅ Re-read spec → Create checklist → Verify each → Report gaps or completion\n❌ \"Output produced, task complete\"\n```\n\n**Subagent delegation:**\n```\n✅ Subagent reports success → Inspect actual output → Verify criteria → Report actual state\n❌ Trust subagent report alone\n```\n\n**Problem resolution:**\n```\n✅ Re-test original symptom: passes → \"Issue resolved\"\n❌ \"Changed X, should be fixed\"\n```\n\n## Why This Matters\n\n- Trust is broken when claims are made without evidence\n- Incomplete output gets delivered\n- Time wasted on false completion → redirect → rework\n- Honesty is a core value. Claiming completion without verification is a lie.\n\n## When To Apply\n\n**ALWAYS before:**\n- ANY variation of success/completion claims\n- ANY expression of satisfaction\n- ANY positive statement about work state\n- Delivering, reporting, or moving to next task\n- Delegating to subagents\n\n**Rule applies to:**\n- Exact phrases\n- Paraphrases and synonyms\n- Implications of success\n- ANY communication suggesting completion or correctness\n\n## The Bottom Line\n\n**No shortcuts for verification.**\n\nRun the check. Read the output. THEN claim the result.\n\nThis is non-negotiable.\n\nFile v1.0.0:skills/writing-plans/SKILL.md\n\n---\nname: writing-plans\ndescription: \"Use when you have a spec or requirements for a multi-step task, before starting execution. Trigger when a design document or spec is ready and needs to be broken into actionable steps. Do not trigger without a prior design or spec, and do not trigger during execution.\"\n---\n\n# Writing Plans\n\n## Overview\n\nWrite comprehensive execution plans assuming the executor has zero context about this project and unfamiliar with its conventions. Document everything they need to know: which areas to touch for each task, what to produce, what to verify, how to confirm success. Give them the whole plan as bite-sized tasks. Avoid redundancy. Only do what's necessary. Define acceptance criteria before execution.\n\nAssume they are capable, but know almost nothing about this project's domain or toolset.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the execution plan.\"\n\n**Context:** This should be run after a design spec has been approved (created by the brainstorming skill).\n\n**Save plans to:** `docs/plans/YYYY-MM-DD-<task-name>.md`\n- (User preferences for plan location override this default)\n\n## Scope Check\n\nIf the spec covers multiple independent areas, it should have been broken into sub-specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per area. Each plan should produce working, verifiable output on its own.\n\n## Work Structure\n\nBefore defining tasks, map out which areas will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.\n\n- Design units with clear boundaries and well-defined interfaces. Each area should have one clear responsibility.\n- Prefer smaller, focused deliverables over large ones that do too much.\n- Areas that change together should be planned together. Split by responsibility, not by technical layer.\n- In existing projects, follow established patterns.\n\nThis structure informs the task decomposition. Each task should produce self-contained output that makes sense independently.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Define the acceptance criteria for this output\" — step\n- \"Produce the minimal output that meets the criteria\" — step\n- \"Verify output against criteria\" — step\n- \"Record progress / save result\" — step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Task Name] Execution Plan\n\n> **For executors:** Use agent-workflow:subagent-driven-execution (recommended) or agent-workflow:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.\n\n**Goal:** [One sentence describing what this produces]\n\n**Approach:** [2-3 sentences about the approach]\n\n**Key Resources:** [Key references, tools, or inputs needed]\n\n---\n```\n\n## Task Structure\n\n```markdown\n### Task N: [Component Name]\n\n**Produces:**\n- `exact/path/or/description/of/output`\n\n**Inputs / References:**\n- [What this task needs to get started]\n\n- [ ] **Step 1: Define acceptance criteria**\n\nWhat does \"done\" look like for this task?\n- Criterion A: ...\n- Criterion B: ...\n\n- [ ] **Step 2: Produce output**\n\n[Exact description of what to create/write/do, with enough detail that no guessing is needed]\n\n- [ ] **Step 3: Verify against criteria**\n\nCheck each criterion:\n- [ ] Criterion A met?\n- [ ] Criterion B met?\n\n- [ ] **Step 4: Record progress**\n\nSave result to [location]. Note any decisions made.\n```\n\n## No Placeholders\n\nEvery step must contain the actual content an executor needs. These are **plan failures** — never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate handling\" / \"handle edge cases\" (without specifying which)\n- \"Similar to Task N\" (repeat the content — the executor may be reading tasks out of order)\n- Steps that describe what to do without showing how\n- References to outputs not defined in any task\n\n## Remember\n- Exact locations always\n- Complete content in every step — if a step produces output, describe it fully\n- Exact verification steps with expected outcomes\n- Avoid redundancy. Only do what's necessary. Define acceptance criteria first.\n\n## Self-Review\n\nAfter writing the complete plan, look at the spec with fresh eyes and check the plan against it.\n\n**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that addresses it? List any gaps.\n\n**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the \"No Placeholders\" section above. Fix them.\n\n**3. Consistency check:** Do the names, formats, and references you used in later tasks match what you defined in earlier tasks?\n\nIf you find issues, fix them inline. No need to re-review — just fix and move on.\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:**\n\n**1. Subagent-Driven (recommended)** — Dispatch a fresh subagent per task, review between tasks, fast iteration\n\n**2. Sequential Execution** — Execute tasks in this session using executing-plans, with checkpoints for review\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:**\n- **REQUIRED SUB-SKILL:** Use `agent-workflow:subagent-driven-execution`\n\n**If Sequential Execution chosen:**\n- **REQUIRED SUB-SKILL:** Use `agent-workflow:executing-plans`","readmeExcerpt":"Skill: Agent Workflow Owner: kangyishuai Summary: A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project... Tags: latest:1.1.0 Version history: v1.1.0 | 2026-06-04T03:33:02.695Z | user Security audit fixes: narrowed trigger scopes for all skills (SQP-1), removed forced 1% activation threshold, added explicit user con","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"brainstorming → writing-plans → [execute] → verification → finishing-work\n                                     ↓\n                          subagent-driven-execution\n                               OR\n                          executing-plans"},{"language":"bash","snippet":"openclaw plugins install clawhub:agent-workflow\nopenclaw gateway restart"},{"language":"json","snippet":"{\n  \"plugins\": {\n    \"allow\": [\"agent-workflow\"]\n  },\n  \"tools\": {\n    \"allow\": [\"agent_workflow\"]\n  }\n}"},{"language":"text","snippet":"Start a new workflow for my Q2 planning project"},{"language":"dot","snippet":"digraph brainstorming {\n    \"Explore project context\" [shape=box];\n    \"Ask clarifying questions\" [shape=box];\n    \"Propose 2-3 approaches\" [shape=box];\n    \"Present design sections\" [shape=box];\n    \"User approves design?\" [shape=diamond];\n    \"User wants written spec?\" [shape=diamond];\n    \"Write design doc\" [shape=box];\n    \"Spec self-review\\n(fix inline)\" [shape=box];\n    \"User reviews spec?\" [shape=diamond];\n    \"Ask user about next step\" [shape=doublecircle];\n\n    \"Explore project context\" -> \"Ask clarifying questions\";\n    \"Ask clarifying questions\" -> \"Propose 2-3 approaches\";\n    \"Propose 2-3 approaches\" -> \"Present design sections\";\n    \"Present design sections\" -> \"User approves design?\";\n    \"User approves design?\" -> \"Present design sections\" [label=\"no, revise\"];\n    \"User approves design?\" -> \"User wants written spec?\" [label=\"yes\"];\n    \"User wants written spec?\" -> \"Write design doc\" [label=\"yes\"];\n    \"User wants written spec?\" -> \"Ask user about next step\" [label=\"no\"];\n    \"Write design doc\" -> \"Spec self-review\\n(fix inline)\";\n    \"Spec self-review\\n(fix inline)\" -> \"User reviews spec?\";\n    \"User reviews spec?\" -> \"Ask user about next step\" [label=\"approved\"];\n    \"User reviews spec?\" -> \"Write design doc\" [label=\"needs changes\"];\n}"},{"language":"text","snippet":"Approach 1: [Name]\n- How it works: ...\n- Trade-offs: ...\n\nApproach 2: [Name]\n- How it works: ...\n- Trade-offs: ...\n\nMy recommendation: Approach N, because ..."}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: agent-workflow\ndescription: \"A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project support. Trigger ONLY when the user explicitly requests a structured workflow (e.g. 'start a workflow', 'use agent-workflow', 'plan this project'). Do NOT trigger for: simple questions, one-off tasks, quick edits, routine conversations, or any task where the user has not requested workflow management.\"\n---\n\n# Agent Workflow\n\nA structured workflow engine for OpenClaw agents. Migrated and generalized from the [superpowers](https://github.com/anthropics/claude-code-superpowers) workflow system into a code-agnostic, general-purpose workflow plugin.\n\n## What it does\n\nProvides a persistent state machine that guides your agent through a complete work lifecycle:\n\n```\nbrainstorming → writing-plans → [execute] → verification → finishing-work\n                                     ↓\n                          subagent-driven-execution\n                               OR\n                          executing-plans\n```\n\nWith support for:\n- **Persistent state** — workflow survives session restarts\n- **Multi-project** — run multiple workflows concurrently\n- **Branching** — choose execution strategy at branch points\n- **Context-plugins** — fork into review/parallel-agents without leaving main flow\n- **Soft-guard goto** — jump to any step with warnings about skipped prerequisites\n- **11 bundled Skills** — covering the full workflow lifecycle\n\n## Installation\n\nThis is a **Plugin**, not a plain Skill. Install via:\n\n```bash\nopenclaw plugins install clawhub:agent-workflow\nopenclaw gateway restart\n```\n\nThen enable in your `~/.openclaw/openclaw.json`:\n\n```json\n{\n  \"plugins\": {\n    \"allow\": [\"agent-workflow\"]\n  },\n  \"tools\": {\n    \"allow\": [\"agent_workflow\"]\n  }\n}\n```\n\n## Usage\n\nIn your agent (via Feishu, Discord, or any channel):\n\n```\nStart a new workflow for my Q2 planning project\n```\n\nThe agent will call `agent_workflow` with `action: \"start\"` and guide you through the workflow.\n\n## Tool: `agent_workflow`\n\n| Action | Description |\n|--------|-------------|\n| `start` | Begin a new workflow |\n| `status` | View current state (all active workflows if no ID given) |\n| `next` | Advance to the next step |\n| `goto` | Jump to any node (soft-guard warns about skipped steps) |\n| `complete` | Mark current node done |\n| `fork` | Activate a context-plugin without leaving main flow |\n| `join` | Complete a fork and return |\n| `getSkill` | Load full SKILL.md for the current node |\n| `list` | List all workflows |\n| `abandon` | Abandon a workflow |\n\n## Bundled Skills\n\n- `brainstorming` — Turn ideas into specs\n- `writing-plans` — Break specs into tasks\n- `executing-plans` — Sequential execution\n- `subagent-driven-execution` — Parallel subagent execution\n- `verification-before-completion` — Evidence before claims\n- `finishing-work` — Delivery options\n- `dispatching-parallel-agents` — Fork independent ta"},{"path":"skills/brainstorming/SKILL.md","content":"---\nname: brainstorming\ndescription: \"Use when the user explicitly requests design exploration, brainstorming, or says they want to discuss approaches before building. Explores user intent, requirements, and design through collaborative dialogue. Trigger ONLY when the user asks to brainstorm, explore options, or design a solution. Do NOT trigger for: simple questions, direct instructions, quick edits, routine tasks, feedback responses, mid-task interactions, or when the user wants immediate action.\"\n---\n\n# Brainstorming Ideas Into Designs\n\nHelp turn ideas into fully formed designs and specs through natural collaborative dialogue.\n\nStart by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.\n\n<HARD-GATE>\nDo NOT invoke any execution skill, take any implementation action, or start producing deliverables until you have presented a design and the user has approved it. This applies to EVERY task regardless of perceived simplicity.\n</HARD-GATE>\n\n## Anti-Pattern: \"This Is Too Simple To Need A Design\"\n\nEvery task goes through this process. A short document, a minor change, a config tweak — all of them. \"Simple\" tasks are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple tasks), but you MUST present it and get approval.\n\n## Checklist\n\nYou MUST create a task for each of these items and complete them in order:\n\n1. **Explore project context** — check existing files, docs, prior work\n2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria\n3. **Propose 2-3 approaches** — with trade-offs and your recommendation\n4. **Present design** — in sections scaled to their complexity, get user approval after each section\n5. **Confirm next step with user** — ask the user if they want a written spec saved to disk, or if the conversation summary is sufficient\n6. **Write design doc (if requested)** — only if user confirms, save to `docs/specs/YYYY-MM-DD-<topic>-design.md`\n7. **Spec self-review (if written)** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)\n8. **User reviews written spec** — ask user to review the spec file before proceeding\n9. **Ask user about next step** — ask if user wants to proceed to execution planning; do NOT automatically invoke other skills\n\n## Process Flow\n\n```dot\ndigraph brainstorming {\n    \"Explore project context\" [shape=box];\n    \"Ask clarifying questions\" [shape=box];\n    \"Propose 2-3 approaches\" [shape=box];\n    \"Present design sections\" [shape=box];\n    \"User approves design?\" [shape=diamond];\n    \"User wants written spec?\" [shape=diamond];\n    \"Write design doc\" [shape=box];\n    \"Spec self-review\\n(fix inline)\" [shape=box];\n    \"User reviews spec?\" [shape=diamond];\n    \"Ask user about next step\" [shape=doublecircle];\n\n    \"Explore project context\" -> \"Ask clarifying questions\";\n "},{"path":"skills/dispatching-parallel-agents/SKILL.md","content":"---\nname: dispatching-parallel-agents\ndescription: \"Use when facing 2 or more independent tasks that can be worked on without shared state or sequential dependencies. Trigger when multiple independent problems or tasks need to be investigated or executed simultaneously. Do not trigger when tasks share state, when one depends on another's output, or when you need full context to understand the overall situation first.\"\n---\n\n# Dispatching Parallel Agents\n\n## Overview\n\nYou delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.\n\nWhen you have multiple unrelated tasks (different topics, different areas, different problems), working on them sequentially wastes time. Each task is independent and can happen in parallel.\n\n**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.\n\n## When to Use\n\n```dot\ndigraph when_to_use {\n    \"Multiple tasks?\" [shape=diamond];\n    \"Are they independent?\" [shape=diamond];\n    \"Single agent handles all\" [shape=box];\n    \"One agent per task domain\" [shape=box];\n    \"Can they work in parallel?\" [shape=diamond];\n    \"Sequential agents\" [shape=box];\n    \"Parallel dispatch\" [shape=box];\n\n    \"Multiple tasks?\" -> \"Are they independent?\" [label=\"yes\"];\n    \"Are they independent?\" -> \"Single agent handles all\" [label=\"no - related\"];\n    \"Are they independent?\" -> \"Can they work in parallel?\" [label=\"yes\"];\n    \"Can they work in parallel?\" -> \"Parallel dispatch\" [label=\"yes\"];\n    \"Can they work in parallel?\" -> \"Sequential agents\" [label=\"no - shared state\"];\n}\n```\n\n**Use when:**\n- 3+ independent tasks with different domains\n- Multiple areas broken independently\n- Each task can be understood without context from others\n- No shared state between tasks\n\n**Don't use when:**\n- Tasks are related (completing one might affect others)\n- Need to understand full project state first\n- Agents would interfere with each other (editing same files, using same resources)\n\n## The Pattern\n\n### 1. Identify Independent Domains\n\nGroup tasks by what's involved:\n- Task A: Research topic X\n- Task B: Draft section Y\n- Task C: Review document Z\n\nEach domain is independent — researching X doesn't affect drafting Y.\n\n### 2. Create Focused Agent Tasks\n\nEach agent gets:\n- **Specific scope:** One task or domain\n- **Clear goal:** What to produce\n- **Constraints:** What NOT to do\n- **Expected output:** Summary of what was found/produced\n\n### 3. Dispatch in Parallel\n\n```\nAgent 1 → Task A: Research topic X\nAgent 2 → Task B: Draft section Y\nAgent 3 → Task C: Review document Z\n// All three run concurrently\n```\n\n### 4. Review and Integrate\n\nWhen agents return:\n- Read each summary\n- Verify outputs don't conflict\n- Integrate all results\n- Verify the combined "},{"path":"skills/executing-plans/SKILL.md","content":"---\nname: executing-plans\ndescription: \"Use when you have a written plan to execute, working through tasks sequentially with review checkpoints. Trigger when a plan document exists and the user wants to execute it in the current session. Do not trigger without an existing plan document. If subagents are available, prefer agent-workflow:subagent-driven-execution instead.\"\n---\n\n# Executing Plans\n\n## Overview\n\nLoad plan, review critically, execute all tasks, report when complete.\n\n**Announce at start:** \"I'm using the executing-plans skill to implement this plan.\"\n\n**Note:** This skill works much better with subagent support. If subagents are available, use `agent-workflow:subagent-driven-execution` instead — it provides higher quality through fresh context per task and two-stage review.\n\n## The Process\n\n### Step 1: Load and Review Plan\n\n1. Read plan file\n2. Review critically — identify any questions or concerns about the plan\n3. If concerns: Raise them with the user before starting\n4. If no concerns: Create task list and proceed\n\n### Step 2: Execute Tasks\n\nFor each task:\n1. Mark as in_progress\n2. Follow each step exactly (plan has bite-sized steps)\n3. Run verifications as specified\n4. Mark as completed\n\n### Step 3: Complete Work\n\nAfter all tasks complete and verified:\n- Announce: \"I'm using the finishing-work skill to complete this work.\"\n- **REQUIRED SUB-SKILL:** Use `agent-workflow:finishing-work`\n- Follow that skill to verify outputs, present options, execute choice\n\n## When to Stop and Ask for Help\n\n**STOP executing immediately when:**\n- Hit a blocker (missing input, verification fails, instruction unclear)\n- Plan has critical gaps preventing starting\n- You don't understand an instruction\n- Verification fails repeatedly\n\n**Ask for clarification rather than guessing.**\n\n## When to Revisit Earlier Steps\n\n**Return to Review (Step 1) when:**\n- User updates the plan based on your feedback\n- Fundamental approach needs rethinking\n\n**Don't force through blockers** — stop and ask.\n\n## Remember\n- Review plan critically first\n- Follow plan steps exactly\n- Don't skip verifications\n- Reference skills when plan says to\n- Stop when blocked, don't guess\n\n## Integration\n\n**Required workflow skills:**\n- `agent-workflow:writing-plans` — Creates the plan this skill executes\n- `agent-workflow:finishing-work` — Complete work after all tasks are done"},{"path":"skills/finishing-work/SKILL.md","content":"---\nname: finishing-work\ndescription: \"Use when a task or project phase is complete and you need to decide how to deliver or integrate the work. Trigger after all tasks are done and verified. Do not trigger before verification is complete or while tasks are still in progress.\"\n---\n\n# Finishing Work\n\n## Safety Notice\n\n**This skill includes options that may permanently delete drafts, temporary files, or working copies.** All destructive actions (Option 4: Discard, and cleanup steps) require explicit user confirmation before execution. Only clearly identified temporary files created during this workflow will be removed — user-created artifacts are never deleted without specific confirmation.\n\n## Overview\n\nGuide completion of a work phase by presenting clear options and handling the chosen delivery workflow.\n\n**Core principle:** Verify work → Present options → Execute choice → Clean up.\n\n**Announce at start:** \"I'm using the finishing-work skill to complete this work.\"\n\n## The Process\n\n### Step 1: Verify Work\n\n**Before presenting options, verify the work is complete:**\n\nCheck each of the following:\n- All planned tasks are done\n- All acceptance criteria are met\n- No known issues remain unaddressed\n\n**If verification fails:**\n```\nWork incomplete or issues remain:\n\n[Show what's missing or broken]\n\nCannot proceed with delivery until work is verified complete.\n```\n\nStop. Don't proceed to Step 2.\n\n**If verification passes:** Continue to Step 2.\n\n### Step 2: Confirm Delivery Target\n\nAsk or confirm: \"Where does this work go? Who receives it?\"\n\nExamples:\n- Integrate into main project\n- Submit to stakeholder for review\n- Keep as draft for later\n- Discard\n\n### Step 3: Present Options\n\nPresent exactly these 4 options:\n\n```\nWork complete. What would you like to do?\n\n1. Integrate into main project directly\n2. Submit for review / deliver to stakeholder\n3. Keep as-is (I'll handle it later)\n4. Discard this work\n\nWhich option?\n```\n\n**Don't add explanation** — keep options concise.\n\n### Step 4: Execute Choice\n\n#### Option 1: Integrate Directly\n\n1. Merge or apply the work into the main project\n2. Verify the integrated result still meets requirements\n3. Clean up any working drafts or temporary files\n4. Confirm integration complete\n\n#### Option 2: Submit for Review / Deliver\n\n1. Package or prepare the output for delivery\n2. Send to stakeholder or submit for review\n3. Note any context the reviewer needs\n4. Keep working copy until review is complete\n\nThen: Clean up workspace (Step 5)\n\n#### Option 3: Keep As-Is\n\nReport: \"Keeping work in progress at [location]. No delivery action taken.\"\n\n**Don't clean up.**\n\n#### Option 4: Discard\n\n**Confirm first:**\n```\nThis will permanently delete:\n- [Description of what will be deleted]\n- [Any associated drafts or working files]\n\nType 'discard' to confirm.\n```\n\nWait for exact confirmation.\n\nIf confirmed: Remove the work and working files.\n\nThen: Clean up workspace (Step 5)\n\n### Step 5: Clean Up Workspace\n\n**For Options 1, 2, 4:**\n\nBefore "}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project... Skill: Agent Workflow Owner: kangyishuai Summary: A structured workflow plugin for OpenClaw agents. Guides work through brainstorm → plan → execute → verify → deliver with persistent state and multi-project... Tags: latest:1.1.0 Version history: v1.1.0 | 2026-06-04T03:33:02.695Z | user Security audit fixes: narrowed trigger scopes for all skills (SQP-1), removed forced 1% activation threshold, added explicit user con","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1359,"uniquenessScore":48,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T19:15:37.133Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T19:15:37.133Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-09T20:30:09.012Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}