Home/Catalog/Quality
Quality — does it work?
Brief 98

Concurrency & Race-Condition Audit

The bugs that only appear under load — races, shared mutable state, and ordering assumptions that hold on a quiet laptop and break in production.

CONCURRENCY.md4 phases7 lenses~2.8k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: find the defects that hide until two things happen at once — races, unguarded shared state, and ordering assumptions that pass every test on a quiet machine and corrupt data under real traffic.

Read-only pass. Read concurrent paths, shared state, and transaction boundaries; change nothing but the report file.

What it looks for

7 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Shared mutable state

globals, singletons, and caches mutated from concurrent requests or threads

2

Check-then-act races

read, decide, write sequences with no atomicity (TOCTOU)

3

Idempotency

retries, double-submits, and webhook redelivery that duplicate effects

4

Locking discipline

missing locks, over-broad locks, lock ordering that can deadlock

5

Async ordering

assumptions that async work completes in order; unawaited work

6

Transaction boundaries

multi-statement logic with no transaction; wrong isolation level

7

External concurrency

concurrent writes to one row; a job runner processing a task twice

The deliverable

What lands in your repo

One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.

CONCURRENCY.md
1
Findings
each: severity S1–S3 · location · the interleaving that triggers it · the fix
2
Silent corruptors
the races that leave no error behind, called out
3
Systemic fixes
the idempotency keys, locks, or transaction patterns that close whole classes
4
How to reproduce
the concurrency the tests should now exercise
One file. Evidence-backed. It ends by asking before touching anything.
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Find the concurrent surfaces

Identify what runs concurrently.

2
Phase 2

Audit through 7 lenses

Give the interleaving that triggers each finding.

3
Phase 3

Curate

Rank by blast radius × likelihood.

4
Phase 4

Report

Create CONCURRENCY.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:concurrency-audit.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-concurrency-audit:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=98 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/98.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,795 characters)
# Goal: Concurrency & Race-Condition Audit

You are working inside this repo. Mission: find the defects that hide until two things happen at once — races, unguarded shared state, and ordering assumptions that pass every test on a quiet machine and corrupt data under real traffic.

Read-only pass. Read concurrent paths, shared state, and transaction boundaries; change nothing but the report file.

## Phase 1 — Find the concurrent surfaces
- Identify what runs concurrently: request handlers, background jobs, workers, async tasks, webhooks.
- Locate shared mutable state each touches: globals, singletons, caches, the same database rows.
- Note the operations that must be atomic but span several steps.

## Phase 2 — Audit through 7 lenses
Give the interleaving that triggers each finding.
1. **Shared mutable state** — globals, singletons, and caches mutated from concurrent requests or threads
2. **Check-then-act races** — read, decide, write sequences with no atomicity (TOCTOU)
3. **Idempotency** — retries, double-submits, and webhook redelivery that duplicate effects
4. **Locking discipline** — missing locks, over-broad locks, lock ordering that can deadlock
5. **Async ordering** — assumptions that async work completes in order; unawaited work
6. **Transaction boundaries** — multi-statement logic with no transaction; wrong isolation level
7. **External concurrency** — concurrent writes to one row; a job runner processing a task twice

## Phase 3 — Curate
- Rank by blast radius × likelihood: data corruption on a hot path outranks a rare double-log.
- For each, describe the interleaving that triggers it and the fix — atomic op, lock, idempotency key, transaction.
- Flag the ones that are silent: races that corrupt without ever throwing.

## Phase 4 — Report
Create `CONCURRENCY.md` at repo root:
1. **Findings** — each: severity S1–S3 · location · the interleaving that triggers it · the fix
2. **Silent corruptors** — the races that leave no error behind, called out
3. **Systemic fixes** — the idempotency keys, locks, or transaction patterns that close whole classes
4. **How to reproduce** — the concurrency the tests should now exercise

Start the report with today's date. If `CONCURRENCY.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- Describe the interleaving; a race with no scenario is a guess
- The dangerous races are the silent ones that corrupt without throwing
- No concurrent code in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words
- Report only — end by asking which races to fix first

House rules for this Goal Prompt

  • Describe the interleaving; a race with no scenario is a guess
  • The dangerous races are the silent ones that corrupt without throwing
  • No concurrent code in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
  • If a reports/ directory exists at the repo root, write the report there instead of the root.
  • Before asking, present the top findings as a ranked list in plain words
  • Report only — end by asking which races to fix first
Keep exploring

More Quality briefs