Race Condition

Shared mutable state is accessed from concurrent contexts without synchronization, producing nondeterministic behavior.

Security Scan

The skill is an instruction-only guide for diagnosing and fixing race conditions; its requirements and instructions are coherent with that purpose and it does not request extra permissions or install artifacts.

Purpose & Capability

Name, description, and SKILL.md all describe the same thing (identifying and mitigating race conditions). There are no unrelated environment variables, binaries, or install steps requested.

Instruction Scope

Runtime instructions are high-level developer guidance (identify shared state, use atomic ops, prefer immutability, test concurrency). They do not direct the agent to read files, exfiltrate data, call external endpoints, or access credentials.

Install Mechanism

No install spec and no code files — nothing is written to disk or downloaded. This is the lowest-risk form (instruction-only).

Credentials

The skill declares no required env vars, credentials, or config paths; the instructions do not reference any secret or unrelated environment access.

Persistence & Privilege

always is false and the skill does not request persistent presence or modification of other skills or system settings. Autonomous invocation is allowed by platform default but is not combined here with any broad privileges.

Assessment

This is a benign, text-only troubleshooting guide. It won't install software or access secrets. Before acting on its recommendations, review and test any code changes it suggests (especially locking and atomic operations), run concurrency/stress tests in a safe environment, and avoid blindly applying fixes without code review. If you let an agent modify your repository automatically, ensure the agent has limited permissions and that changes are reviewed to prevent accidental data corruption.

Two or more concurrent contexts — threads, async tasks, processes, requests — read and write the same state without coordination. Tests pass on a lightly-loaded machine; production corruption appears under real traffic.

Symptoms

• Counters that "mostly" work but occasionally lose increments.
• Check-then-act sequences (e.g., "if not exists, create") where two contexts both pass the check and both create.
• Shared caches or singletons mutated from request handlers without a lock.
• Data-corruption bugs that only reproduce under load or with specific timing.

What to do

• Identify every piece of shared mutable state. Draw the boundary: who reads it, who writes it, from which contexts.
• Replace check-then-act with atomic operations: compare-and-swap, INSERT ... ON CONFLICT, unique indexes, setnx.
• Prefer immutable data or message-passing over shared mutation. Actor-style patterns remove most races by construction.
• When a lock is unavoidable, hold it for the shortest possible span and document what state it protects.
• Test concurrency explicitly. A single-threaded test proves nothing about a multi-threaded code path. Use stress tests or pytest-asyncio / concurrent harnesses.