agentsclimarketplace

Correct assumptions

Skill jcdavis131/cursor-agent-skills/skills/correct-assumptions

42 agent-discipline skills for Cursor, distilled by watching an autonomous terminal coding agent (Claude Code + Fable 5). Includes the derivation method.

Install
npx -y skills add jcdavis131/cursor-agent-skills --skill correct-assumptions

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

When live recon contradicts a prior assumption or a documented blocker, trust the live evidence, state the correction explicitly with the evidence, and update your plan. Use whenever you discover the environment differs from what you (or the docs, or the task notes) assumed — a service that's actually running, a port that's actually open, a blocker that's actually resolved, a dependency that's actually installed.

SKILL.md

3.9 KB, as published. Nobody here has run it

Correct Assumptions

A documented blocker or a prior assumption is a hypothesis. Live recon is the measurement. When they contradict, the measurement wins — and you say so out loud.

The move

  1. Notice the contradiction. Live recon (a port scan, a pg_isready, a docker ps, a Get-Process) shows a state that differs from the documented blocker or your assumption.
  2. State the correction explicitly, with the evidence.

    "PG16 is already running on :5432 — it existed all along." Name what you assumed, what's actually true, and the evidence (the port, the process, the file). Don't just silently switch plans — say the correction.

  3. Update the plan. The unblock changes what's possible. Re-plan: the task that was blocked on "no Postgres" is now unblocked. Re-prioritize.
  4. Update the shared state if the blocker was documented. If TASKS.md / work_queue.json / a blocker note still says "Postgres unavailable", correct it there too — otherwise the next agent operates on the stale blocker. (Mind lane-discipline if the doc is another agent's.)

Why out-loud

  • Silent correction leaves the user and other agents blocked on a non-blocker. They're still planning around "no Postgres" while you quietly use it.
  • The evidence (the port, the process) is what makes the correction trustworthy. "Postgres is available" without evidence is another assertion.
  • A documented blocker being wrong is important metadata — it means the blocker tracking has a gap.

When NOT to correct

  • The "correction" is a one-off transient (a service flapped up for a second). Confirm stability before declaring the blocker resolved.
  • You're not sure the live state is real (a zombie process showing a port open but not accepting connections). Verify before correcting.
  • The blocker is another agent's lane to resolve. Surface the finding; let them update it.

Compare served value vs source value when a deployed value misbehaves

A deployed value that misbehaves (a 401 despite an env push) often means the value the platform serves ≠ the value in the source file. Don't re-push blindly — compare the two directly:

  • Pull what's actually served: vercel env pull /tmp/sf.env --environment production --yes (or the platform equivalent).
  • Parse both and diff: the served env vs the source file.
  • The discrepancy (e.g. a stale key Vercel still serves) explains the symptom.

The served value is ground truth for what the deploy actually has; the source file is what you pushed. When they diverge, the deploy serves the stale one. This is correct-assumptions applied to deployed config — trust what's served, not what you pushed.

Anti-patterns

  • Silent plan switch. You quietly use Postgres; the user is still asking "how do we unblock Docker?"; nobody knows it's already unblocked.
  • Correction without evidence. "Postgres works now" — why? Name the port/process.
  • Trusting the doc over the recon. The doc said :5433 unavailable; you don't check :5432 because the doc didn't mention it. Recon wins.
  • Updating your plan but not the shared blocker note. The next agent reads the stale blocker and re-derives the wrong assumption.

Pair with

  • session-orient — recon is where corrections are discovered.
  • document-non-action — a corrected blocker may turn a non-action ("can't do X, no Postgres") into an action.
  • lane-discipline — updating a blocker doc in another agent's lane is a coordinate-then-edit.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.