Skip to content
cccskills
FreePublished on GitHub

cold-read

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/swarmstorm13 stars(GitHub 13 + cccskills 0)

Run score Not tested

See how to install

Files included (1)

  • SKILL.md2.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Cold read

You stand for the agent who will carry this plan out with nothing but the document. You were not in the conversation that wrote it, and that is the point: its writer cannot see what is in their head and not on the page. Your job is to find it. A question you guess past is a task built on a guess.

What to do

  1. Read the plan through the aiview skill, every document it links, and the code it names where you need it to understand a part. Do not edit anything.
  2. Answer, in this order:
    1. What you would build: the goal, the design and the phases, in your own words, short. The writer compares it with what they meant.
    2. Your questions: everything you would have to ask, or guess, before writing any phase's tasks. Each one says where in the plan it arises.
    3. Your verdict: ready when no question is left, not ready otherwise.
  3. Talk it through with the writer. Ask back, push on an answer that does not convince you, say how you read a passage and let them correct you, propose a wording. The exchange is how you both find what the plan leaves unsaid; keep it going until you understand the work as they do.
  4. A question closes in the plan, not in the talk. Once you agree, re-read the changed place: what the next agent needs and only the conversation holds is still a question. Give the verdict again with what is closed and any new question the change raised.

What to check

  • Every term is defined or plainly the codebase's.
  • Every decision has its reason, so a case it did not foresee can be decided the same way.
  • The plan agrees with itself: the design, the decisions, the phases and the tracker say the same thing.
  • Every done-when is checkable: a command, an observable result, never a judgement.
  • Every file, module and document named exists, or the plan says it is created.
  • Each phase's tasks can be written from the plan alone: what it builds on, what it must not touch.

You judge clarity, not the design. A design you would have done otherwise is not a question; a design you cannot understand is. A flaw you cannot leave unsaid is named once, as a flaw, apart from the questions.

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 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

Use when a person asks to design a new module's interface or to rework an existing module so that it hides much behind little, in any tier (backend, frontend, test support, tooling), or says a module's callers know too much about it. Produces a module document in aiview, how a caller uses it, its one public entry point as signatures, what stays outside and the gap from today, discussed with the person until agreed. Not for writing the task that carries the rework out (orchestrate's tasks) and not for the rework itself.

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