competition-race-condition-state-drift

Name: competition-race-condition-state-drift
Author: zhaoxuya520

8.8kstars1.4kforks

How to install competition-race-condition-state-drift?

zhaoxuya520/reverse-skill/competition-race-condition-state-drift

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-race-condition-state-drift

Installs into the current project.

Summary

Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for race windows, ordering bugs, idempotency failures, lock gaps, concurrent worker drift, and state inconsistencies that produce decisive effects. Use when the user asks to reproduce timing-sensitive bu

Files · 1

View on GitHub

SKILL.md

1	# Competition Race Condition State Drift
2
3	Use this skill only as a downstream specialization after `$ctf-sandbox-orchestrator` is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to `$ctf-sandbox-orchestrator` first.
4
5	Use this skill when the decisive behavior depends on request timing, async ordering, lock gaps, or stale state.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Identify mutable state first: rows, cache keys, queue payloads, session fields, counters, or files.
12	2. Reproduce with smallest concurrent sequence and fixed timing assumptions.
13	3. Capture one baseline run and one racing run with only one variable changed.
14	4. Track read, check, write, enqueue, and commit boundaries separately.
15	5. Prove final state drift from a clean reset.
16
17	## Workflow
18
19	### 1. Map Mutable Boundaries
20
21	- Record transaction scope, lock behavior, retry logic, idempotency keys, cache invalidation, and queue handoff.
22	- Note where read-check-write is split across requests, workers, or services.
23	- Keep each boundary tied to exact timestamps or sequence numbers.
24
25	### 2. Reproduce Timing Window
26
27	- Build deterministic concurrent inputs with controlled delay, duplicate requests, or reordered worker execution.
28	- Compare accepted and rejected paths under identical payloads.
29	- Record which condition flips when ordering changes.
30
31	### 3. Reduce To Decisive Race Chain
32
33	- Compress to: request A and B ordering -> stale check or lock gap -> conflicting writes -> resulting capability or artifact.
34	- State whether root cause is missing lock, weak idempotency, stale cache read, delayed async commit, or retry side effect.
35	- If the path becomes queue-dominant, hand off to queue worker drift skill.
36
37	## Read This Reference
38
39	- Load `references/race-condition-state-drift.md` for race harness ideas, evidence blocks, and parity checks.
40
41	## What To Preserve
42
43	- Mutable keys, transaction boundaries, lock behavior, and idempotency markers
44	- Timestamped or sequenced traces for baseline and race runs
45	- One minimal replayable concurrent sequence proving drift

People who liked this also viewed

6 picks

Type

competition-race-condition-state-drift

8.8kstars1.4kforks

View on GitHub

How to install competition-race-condition-state-drift?

zhaoxuya520/reverse-skill/competition-race-condition-state-drift

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-race-condition-state-drift

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Competition Race Condition State Drift
2
3	Use this skill only as a downstream specialization after `$ctf-sandbox-orchestrator` is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to `$ctf-sandbox-orchestrator` first.
4
5	Use this skill when the decisive behavior depends on request timing, async ordering, lock gaps, or stale state.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Identify mutable state first: rows, cache keys, queue payloads, session fields, counters, or files.
12	2. Reproduce with smallest concurrent sequence and fixed timing assumptions.
13	3. Capture one baseline run and one racing run with only one variable changed.
14	4. Track read, check, write, enqueue, and commit boundaries separately.
15	5. Prove final state drift from a clean reset.
16
17	## Workflow
18
19	### 1. Map Mutable Boundaries
20
21	- Record transaction scope, lock behavior, retry logic, idempotency keys, cache invalidation, and queue handoff.
22	- Note where read-check-write is split across requests, workers, or services.
23	- Keep each boundary tied to exact timestamps or sequence numbers.
24
25	### 2. Reproduce Timing Window
26
27	- Build deterministic concurrent inputs with controlled delay, duplicate requests, or reordered worker execution.
28	- Compare accepted and rejected paths under identical payloads.
29	- Record which condition flips when ordering changes.
30
31	### 3. Reduce To Decisive Race Chain
32
33	- Compress to: request A and B ordering -> stale check or lock gap -> conflicting writes -> resulting capability or artifact.
34	- State whether root cause is missing lock, weak idempotency, stale cache read, delayed async commit, or retry side effect.
35	- If the path becomes queue-dominant, hand off to queue worker drift skill.
36
37	## Read This Reference
38
39	- Load `references/race-condition-state-drift.md` for race harness ideas, evidence blocks, and parity checks.
40
41	## What To Preserve
42
43	- Mutable keys, transaction boundaries, lock behavior, and idempotency markers
44	- Timestamped or sequenced traces for baseline and race runs
45	- One minimal replayable concurrent sequence proving drift

People who liked this also viewed

6 picks

Type