Skip to content
cccskills
FreePublished on GitHub

execute-plan

Use when carrying out an implementation plan the person has already approved, whether starting it or resuming it in a later session, and the tracker in it has to stay true while the work happens. Not for producing the plan (write-plan) and not for reviewing the result.

The English summary is being prepared. Showing the original description.

Ovich/swarmstorm13 stars(GitHub 13 + cccskills 0)

Run score Not tested

See how to install

Files included (1)

  • SKILL.md3.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Execute a plan

You are the plan's orchestrator; the orchestrate-plan skill holds those duties (the mandate, dispatch, checking the run, verification, merges, pull requests). Load it with this one.

The plan is a living document. write-plan built it and its tracker; this skill keeps both true as the work teaches something. Amending a task, adding one, dropping one or moving a decision is normal work, written into the plan as it happens.

Before starting

  • Open the plan in aiview every session and give the person the URL.
  • Do not start if the plan has no tracker, a phase has no goal, seats' roles and areas, or a check as a command (its tasks are written at its open). Say so and finish the plan first.
  • Reconcile a tracker the repository has moved past before starting; say what you found.
  • Every phase runs on the swarm board, however few seats it has, through the orchestrate-plan skill.

Keeping the plan and its tracker

The tracker's protocol is the write-plan skill's references/tracker.md, read before the first edit.

  • Tick as you go, never in a batch. ✅ only once this session has re-run the step's done-when.
  • Update before every handoff: a question, an approval, the end of a turn.
  • Change the plan before acting on the change. New work is a node, a dropped step is ✖ with the reason. A change that decides a module, interface, schema, contract or architecture is a row in the plan's decisions; one that becomes a slice gets its slice document first (write-slice).
  • A subagent's return is read, never pasted into a step; each line of it has a home, listed in the tracker's protocol.

When to pause

Stop for exactly three things:

  • A decision that is the person's. A finding that breaks a decision the plan rests on, a repair with real options, work outside the plan's scope.
  • Verification only a person can do. A browser flow, a real sign-in, another team's approval. Do everything mechanical first.
  • An action that leaves the machine and does not undo cheaply. A production deploy, a migration on shared data. Approved once each. A merge the mandate's pace gives the orchestrator is approved by the mandate.

A pause is a handoff: the tracker current; what happened, the decision wanted, the options and a recommendation; then what the person does next, numbered, each with its exact command. A secret goes in a file the pause names, by path and keys.

Do not pause for per-step sign-off, verification you can do yourself, naming, structure, tool choice, or a failure you understand whose fix changes nothing decided. Stop the line when one step fails twice for unrelated reasons.

The close

With a roadmap, say the plan finished and the roadmap may need redrawing; the person confirms the slot landed. When the plan delivered something a person looks at, recommend going over it with them through the validate-delivery skill.

List the decisions whose source is agent default that shipped, and ask whether any is to be revisited; when one of them is a contract, recommend the validate-delivery skill even if nothing was delivered for a person to look at.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

aiview

Free

Use whenever a document is produced for the user to read and react to while it evolves: a brainstorm board, a plan, a design language, a prototype, a PR analysis, a review report, a live PDF. Also when a document must be registered, opened, listed, moved or retired, or a prototype's bindings checked. Not for code, tests or configuration, or any file nobody opens in a browser.

The English summary is being prepared. Showing the original description.

Ovich/swarmstorm13Updated Oct 29, 2026

Use when a person wants to think an idea through and keep the discussion: a feature, a tool choice, an architecture question, before a plan or without one, with the agent through an interview. Produces a board in aiview holding the decisions, the diagrams and what was investigated. Not for a swarm of seats working it (brainswarm), not for an implementation plan and not for bug fixes.

The English summary is being prepared. Showing the original description.

Ovich/swarmstorm13Updated Oct 29, 2026

Use when a person wants a swarm of role seats to work a topic on the swarm board under a chosen protocol: a brainstorm (ideas before any judgment), a debate (questions argued to decisions, a skeptic endorsing) or an editorial (one text drafted, read by seats standing for its readers, revised), a protocol or template the project keeps as a `protocol-<name>` skill (or an older `brainswarm-<name>` one), or a custom protocol recommended for the person's intent, or a seat's brief names a brainswarm protocol. Produces the run's record in aiview, written by the orchestrator alone. Not for one person thinking aloud with the agent (brainstorm, interview) and not for a plan's slices (execute-plan).

The English summary is being prepared. Showing the original description.

Ovich/swarmstorm13Updated Oct 29, 2026

Use when dispatched to cold-read a plan, as an agent that was not in the conversation that wrote it, to say whether it can be carried out from the document alone. Produces what the reader would build, its questions, and a verdict, ready or not ready, repeated as the writer fixes the plan. Not for judging the design (interview, pr-review), not for the mechanical checks (aiview plan check, tracker check), and not for writing the plan (write-plan).

The English summary is being prepared. Showing the original description.

Ovich/swarmstorm13Updated Oct 29, 2026

Use when code is hard to follow and is to be audited or reworked: long if/else or switch chains, cascades of type checks or parse attempts, kind fields compared to strings, flag parameters, deep nesting, a function hard to read. Also for complexity guardrails, or one long conditional function pasted. Produces a ranked audit of families, one family reworked behind characterization tests, or the guardrails.

The English summary is being prepared. Showing the original description.

Ovich/swarmstorm13Updated Oct 29, 2026

Use when a page is wanted to work on something with the person during development, fed the project's real data (comparing model answers, walking an agent call by call, measuring an output against its template), when such a workbench has to change, be reworked or its feed broke, or mid-session when turns went into aligning with the person on how to do a kind of work that recurs and real project data could show it. Produces the page in aiview, kind `workbench`, and the project's `workbench-<bench>` skill with its feed and operating steps. Not for designing a product screen (design-prototype) or verifying user stories (verification-skill-create).

The English summary is being prepared. Showing the original description.

Ovich/swarmstorm13Updated Oct 29, 2026

See all skills by Ovich

Report a problem with this skill