/loop-workflow-planner

name: loop-workflow-planner
description: 'Define a platform-neutral bounded loop for standard or deep work using measurable acceptance criteria, verification, retry limits, independent review, memory, and stop conditions. Skip lookups, tiny edits, and one-off explanations.'
id: 'agents.skills.loop-workflow-planner.skill'
title: 'Loop Workflow Planner'
doc_type: 'skill'
layer: 'skill'
status: 'active'
publishable: true
local_only: false
skill: 'loop-workflow-planner'
tags:
    - 'agents/skill-package'
    - 'agents/planning'
    - 'workflow/agent-loop'
parent:
    - '[[AGENTS|Canonical Agent Policy]]'
related:
    - '[[common/agent-loop-policy|Agent Loop Policy]]'
    - '[[common/stop-criteria-rules|Stop Criteria Rules]]'
    - '[[common/bounded-retry-rules|Bounded Retry Rules]]'
    - '[[common/verification-loop-rules|Verification Loop Rules]]'
    - '[[common/context-compaction-rules|Context Compaction Rules]]'
    - '[[common/independent-review-rules|Independent Review Rules]]'
    - '[[common/worktree-parallelism-rules|Worktree Parallelism Rules]]'
    - '[[templates/loop-workflow-contract|Loop Workflow Contract Template]]'
    - '[[templates/loop-memory|Loop Memory Template]]'
    - '[[skills/execution-plan-manager/SKILL|Execution Plan Manager]]'
    - '[[skills/frontend-quality-reviewer/SKILL|Frontend Quality Reviewer]]'
depends_on:
    - '[[AGENTS|Canonical Agent Policy]]'

Loop Workflow Planner

Purpose

Create a platform-neutral Loop Workflow Contract for standard or deep work that must iterate until measurable acceptance criteria pass.

This skill does not implement code. It defines objective, scope, verification, retry limits, stop conditions, independent review, and memory update rules so Codex, GPT-based agents, Claude, and generic coding agents can execute the same workflow without depending on Claude-only commands.

When To Use

Use this skill when the task is `Standard Workflow` or `Deep Workflow` and one or more are true:

• the user asks to continue until lint, typecheck, build, visual QA, CI, or another measurable check passes;
• verification may fail and repair is in scope;
• a repeated failure already happened;
• a bugfix, CI repair, refactor, or UI implementation needs bounded retry;
• independent review should judge completion;
• the work may need resumable memory;
• multiple agents or worktrees are being considered.

When Not To Use

Do not use for:

• Fast Lookup;
• one obvious typo or type error;
• tiny direct edits;
• pure explanation;
• design-only direction with no iterative verification;
• platform-specific `/goal`, `/loop`, or `/schedule` commands without a platform-neutral contract;
• unbounded autonomous work.

Required Context

1. Read `AGENTS.md`. 2. Read `common/agent-loop-policy.md`. 3. Read `common/stop-criteria-rules.md`. 4. Read `common/bounded-retry-rules.md`. 5. Read `common/verification-loop-rules.md`. 6. Read `common/context-compaction-rules.md` when stop/resume or memory matters. 7. Read `common/independent-review-rules.md` when review is needed. 8. Read `common/worktree-parallelism-rules.md` only when parallel agents, branches, or worktrees are considered. 9. Read the current Goal Contract, Execution Plan, user request, or `project/active-goals.md` when present. 10. Read the active coverage map and target `S-###` slices when a durable plan exists. 11. Read `project/verification-profile.md` when verification commands matter.

Do not read unrelated skills or generated `dist/**` during normal runtime.

Tool Contract

• May read project overlays and verification profiles.
• May write or update a durable loop contract only when the task is genuinely resumable or deep.
• May recommend host mappings for Claude, Codex, GitHub, or generic agents, but must not require host-specific commands.
• Must not implement source code.
• Must not run verification commands.
• Must not install packages, tools, MCP servers, UI libraries, or testing workflows.
• Must not create parallel worktrees or branches without explicit user approval and an ownership plan.

Workflow

1. Confirm task scale. Stop if the task is Fast Lookup or lightweight without repeated failure. 2. Confirm or derive the objective from an existing goal, execution plan, or explicit user request. 3. Reuse the active Goal Contract `AC-###` criteria when present. Otherwise, convert vague completion language into measurable acceptance criteria without creating a competing set of criteria. 4. Reference the target `S-###` slices when a durable execution plan exists. Do not add, reorder, renumber, or mark slices from the loop contract. 5. Define allowed scope and out-of-scope changes. 6. Select loop type: one-pass verification, bounded retry, goal-based loop, or open exploration. 7. Set maximum attempts or turns. 8. Define verification commands, rendered checks, or manual evidence sources. 9. Define retry strategy and what must change after a failed attempt. Every durable retry record must name the affected `AC-###` and `S-###`. 10. Define stop and escalation conditions. 11. Decide whether independent review is required. 12. Decide whether loop memory is needed and where it belongs. 13. Decide whether parallel work is safe; default to no parallelism. 14. Produce a Loop Workflow Contract. 15. Hand off to the next smallest relevant skill.

Output Contract

Final response: return only facts that affect the user's understanding, confidence, or next action. Omit empty fields and workflow narration.

Return or write:

Loop Workflow Contract
Goal ID
Objective
Allowed Scope
Acceptance Criteria
Target Slices
Loop Type
Max Attempts Or Turns
Retry Strategy
Verification
Independent Review
Memory Update
Stop Conditions
Escalation Conditions
Final Evidence
Next Slice
Next Skill Or Next Step

When a Goal Contract exists, preserve its `AC-###` identifiers in the loop contract, verification evidence, retry history, and final report. When an Execution Plan exists, prese