Menu
Use when a goal should be split across multiple queued session turns with reflection turns between work turns.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Explicit-only Docker deploy. Run this skill's bundled scripts/deploy.sh directly; do not search for skills, inspect trees, or use subagents.
Explicit-only Docker deploy. Run this skill's bundled scripts/deploy.sh directly; do not search for skills, inspect trees, or use subagents.
Use only when explicitly invoked as $web-service-scaffold to run the bundled web-service scaffold script.
Enforce the repository package documentation contract as a navigable dependency graph. Use when creating or updating package README, docs pages, navigation tables, architecture router, API docs, usage docs, constraints, blast-radius/consumer records, internals, decisions, or testing docs. Docs exist so a later model drills down from task to edit target with minimal context and sees blast radius before editing. Keep content terse; keep only repo-specific contracts, paths, edges, intent, and decisions.
Enforce the repository Docker contract: Docker-first runtime, one root docker-compose.yml, module-owned Docker assets, apps service-module to container mapping, isolated networking, Docker socket passthrough for container-spawning services, a standard npm deploy entrypoint, and runtime-only Dockerfiles that copy prebuilt local dist artifacts instead of building the project. Use when defining compose services, Dockerfiles, networks, volumes, env_file wiring, deploy scripts, Docker socket access, or container ownership.
Run headless browser smoke and E2E tests for scaffolded web services. Use when verifying rendered web UI, checking browser errors, creating Playwright-style scenarios, collecting screenshots, or testing a deployed/local service through Chromium.
| name | turnplan |
| description | Use when a goal should be split across multiple queued session turns with reflection turns between work turns. |
Use turnplan when a single prompt/tool-call chain is likely to be too large,
too long, or too prone to reasoning loops, and the work can be advanced by
several ordinary queued turns.
Do not use it for short work that can finish in the current turn.
turnplan only edits the current session request queue. It does not run a
separate scheduler, hook, or special turn mode. Every queued item runs later as
a normal user request.
When creating a plan, provide:
goal: the final outcome the whole queued sequence is meant to reach.requests: concrete future work requests.For requests A, B, and C, the tool queues:
A
reflection request
B
reflection request
C
final summary request
Reflection requests are ordinary turns. They invoke this skill with
$turnplan, remind the model of the original goal, inspect completed work
through session history, compare the remaining queue to the goal, and use
turnplan again if the queue needs adjustment.
The model performs the reflection analysis. The function tool only exposes the queue controls needed to inspect and change the remaining request queue.
Use:
list before modifying existing queued work when item ids matter.add for one concrete request.update when a queued request is still useful but stale.delete when a queued request is redundant or wrong.clear only when the remaining queue should be discarded.During a reflection request:
turnplan with action="list" to see the remaining queue.Keep queued requests actionable. A queued work request should tell the next turn what to inspect, implement, verify, or decide. Avoid vague requests like "continue" unless the previous turn made the next action unambiguous.