القائمة
Use when deciding whether to re-enter the loop on a survivor.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when attacking branches to find what the verifier cannot catch.
Use when flagging branch conviction or calibrating instinct against outcomes.
Use when budgeting, routing, and scaling a run to fit the ask.
Use when selecting the surviving branch on verifier evidence after collision.
Use when recording dead branches so future runs avoid re-litigating them.
Use when isolating branches in git worktrees and reconciling the survivor.
| name | the-spiral |
| description | Use when deciding whether to re-enter the loop on a survivor. |
A spiral is another co-precipitation round run ON the survivor of the last one — the precipitate becomes the next round's task. Depth is available but never free: each round costs a full loop's tokens, and an unbounded spiral is how runs escape their budgets. The engine enforces the cap; this skill is the judgment about when depth actually pays.
max_spiral_depth — config key / PQA_MAX_SPIRAL_DEPTH, default 1, validated to
[0, 5]. Depth 0 disables spirals entirely.pqa.orchestrator.run_pqa(..., spiral_depth=d, max_spiral_depth=m) aborts with a
reported (never silent) aborted=True RunReport when d > m — "a brake is not a
steering wheel": the budget alone must never be the only thing stopping recursion.spiral_depth is surfaced in the run report, so nobody mistakes a two-round result
for a one-shot.budget: — noise in the taxonomy, not learning.verifier:/adversary: failure row, the answer already exists; read it instead..pqa/artefacts/).spiral_depth=d+1 and the
remaining budget, never a fresh one — depth competes with breadth for the same
tokens. The scale gate re-classifies the new ask from scratch: a build run's spiral
is often a patch run.spiral_depth; the parent's
precipitate references the child ("spiraled: see run ") so the registry shows
the lineage.Run 1 (build): "make nightly export faster" → survivor b2 "delta-export", verified 88%, precipitate "delta-export: the fastest query is the one not run", 420k of 800k tokens spent. The precipitate's open question: backfill semantics for new consumers.
Gate check: new axis named ✓; remaining 380k ≥ one patch-sized round ✓; no matching failure row ✓ → spiral approved at depth 1.
Run 2 (spiral, depth 1, budget = the remaining 380k): task "define backfill semantics for delta-export consumers" — the scale gate classifies it patch (2 branches: backfill-on-subscribe vs lazy-page-on-read). Lazy wins, verified. Total: 2 rounds, ~690k tokens, both inside the original envelope, lineage recorded in both reports.
The counterfactual round 3 ("cursor or offset pagination?") is a decide-ask — one
judge pass at decide economics answers it, and max_spiral_depth=1 would have refused
a third full loop anyway. Both brakes exist; neither is the steering wheel.