@1aboveio/skills 0.18.0 → 0.19.0

package/skills/engineering/resolve-issues/generated/workflow-repair-policy.json

@@ -237,7 +237,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
       }
     },
     {
@@ -248,7 +248,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
       }
     },
     {
@@ -259,7 +259,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
       }
     },
     {
@@ -270,7 +270,18 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
+      }
+    },
+    {
+      "installName": "rush-issues",
+      "ownership": "owned",
+      "sourcePath": "skills/engineering/rush-issues",
+      "expectedSource": {
+        "id": "first-party",
+        "type": "first-party",
+        "package": "@1aboveio/skills",
+        "version": "0.19.0"
       }
     },
     {
@@ -281,7 +292,18 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
+      }
+    },
+    {
+      "installName": "rush-release",
+      "ownership": "owned",
+      "sourcePath": "skills/engineering/rush-release",
+      "expectedSource": {
+        "id": "first-party",
+        "type": "first-party",
+        "package": "@1aboveio/skills",
+        "version": "0.19.0"
       }
     },
     {
@@ -292,7 +314,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
       }
     },
     {
@@ -303,7 +325,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
       }
     },
     {
@@ -314,7 +336,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
       }
     },
     {
@@ -325,11 +347,23 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0"
+        "version": "0.19.0"
       }
     }
   ],
   "dependencyClosures": [
+    {
+      "invokedSkill": "rush-issues",
+      "members": [
+        "code-review",
+        "harness-runtime",
+        "e2e-test",
+        "rush-issues",
+        "smoke",
+        "engineering-runtime"
+      ],
+      "generatedIdentities": []
+    },
     {
       "invokedSkill": "resolve-issues",
       "members": [
@@ -350,6 +384,14 @@
         }
       ]
     },
+    {
+      "invokedSkill": "rush-release",
+      "members": [
+        "rush-release",
+        "engineering-runtime"
+      ],
+      "generatedIdentities": []
+    },
     {
       "invokedSkill": "resolve-release",
       "members": [
@@ -426,14 +468,16 @@
         "sourceId": "first-party",
         "sourceType": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.18.0",
+        "version": "0.19.0",
         "installPath": null,
         "members": [
           "harness-runtime",
           "e2e-test",
           "ensure-coverage",
           "implement-and-pr",
+          "rush-issues",
           "resolve-issues",
+          "rush-release",
           "resolve-release",
           "review-pr",
           "smoke",
@@ -442,7 +486,7 @@
         "commands": [
           {
             "transport": "npm",
-            "command": "npx @1aboveio/skills@0.18.0 install --group engineering-workflow --yes"
+            "command": "npx @1aboveio/skills@0.19.0 install --group engineering-workflow --yes"
           }
         ],
         "onFailure": {

package/skills/engineering/resolve-issues/scripts/run-state.mjs

@@ -3412,7 +3412,7 @@ export const WORKFLOW_PREFLIGHT_COMMANDS = Object.freeze([
 
 const WORKFLOW_VERIFIER_URL = new URL('../../engineering-runtime/scripts/workflow-coherence.mjs', import.meta.url)
 const WORKFLOW_FALLBACK_POLICY_URL = new URL('../generated/workflow-repair-policy.json', import.meta.url)
-export const WORKFLOW_TRUSTED_FALLBACK_POLICY_SHA256 = 'c3d9fac9486de96cb064da61f2bfcb07d4ebc9935be804cfac0c0b9f743c7a30'
+export const WORKFLOW_TRUSTED_FALLBACK_POLICY_SHA256 = '27d1fb2d0bdf9ca37933dff2f0e1863d95f9f147baecbbce9dd3553a4c71a915'
 const WORKFLOW_REPAIR_RECIPE_REFERENCE = Object.freeze({
   id: 'engineering-workflow-dependency-first',
   generatedFrom: 'skills/distribution/generated/recipes.json',
@@ -3461,10 +3461,10 @@ const WORKFLOW_MATT_MEMBERS = Object.freeze([
   'prototype', 'research', 'resolving-merge-conflicts', 'setup-matt-pocock-skills', 'tdd',
   'to-spec', 'to-tickets', 'triage', 'wayfinder',
 ])
-// Dependency first, then the eight owned members, in the census order the generator emits.
+// Dependency first, then the ten owned members, in the census order the generator emits.
 const WORKFLOW_FIRST_PARTY_MEMBERS = Object.freeze([
-  'harness-runtime', 'e2e-test', 'ensure-coverage', 'implement-and-pr', 'resolve-issues',
-  'resolve-release', 'review-pr', 'smoke', 'engineering-runtime',
+  'harness-runtime', 'e2e-test', 'ensure-coverage', 'implement-and-pr', 'rush-issues', 'resolve-issues',
+  'rush-release', 'resolve-release', 'review-pr', 'smoke', 'engineering-runtime',
 ])
 const WORKFLOW_RECIPE_FIELDS = Object.freeze(['id', 'generatedFrom', 'groupId', 'lifecycle', 'renderTarget', 'stopOnFailure', 'steps'])
 const WORKFLOW_COMMAND_FIELDS = Object.freeze(['transport', 'command'])

package/skills/engineering/resolve-release/references/related-skills.md

@@ -3,6 +3,7 @@
 [SKILL.md](../SKILL.md) routes the phases; this file is the seam with every other skill — who
 produces this lane's input, who owns the gates it runs, and where a failure goes.
 
+- `rush-release` — the explicit GitHub Flow cut from green `main` (changelog + tag + Cloud Build/npm watch). It does not assemble, promote, or shift traffic; this lane still owns those.
 - `resolve-issues` — the **upstream** producer; its handoff is this skill's input. For an epic that is one integration-verified deliverable per [component](../../resolve-issues/references/integration-gate.md), each a combined PR whose tip step 1 re-verifies (principle 2) rather than re-merges.
 - `review-pr` — twice: **step 1** on the combined integration diff, **step 2** in promotion mode (fast-forward + release-readiness checklist).
 - `smoke` — the **exposure gate**: step 4a against the 0%-traffic candidate under read-only **`prod-preview`**, step 4b against the live service under **`prod-active`** (principle 4). The named [Validation Profile](../../smoke/references/manifest.md#validation-profiles-the-profiles-registry) owns the mutation policy, so both production profiles are mechanically read-only. Also the engine behind the SHA-keyed verdict recorder the candidate pin reads (principle 11).

package/skills/engineering/rush-issues/LICENSE

@@ -0,0 +1,3 @@
+MIT License
+
+Copyright (c) 2026 1AboveIO

package/skills/engineering/rush-issues/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: rush-issues
+description: "Slash/explicit-only (/rush-issues). Drive an issue, epic, or complete feature spec to one PR on one branch: model/target preflight, task map, shared exploration, up to 4 isolated implementers, combination, one independent code-review, then CI/queue/merge. Do not auto-select. Use for fast whole-spec delivery, including high-risk implementation work; risk changes model and validation depth, never the workflow. Retries and 30-minute task expiry trigger diagnosis and continuation. NOT for release work (rush-release or resolve-release)."
+disable-model-invocation: true
+dependencies:
+  - code-review
+  - smoke
+  - harness-runtime
+---
+
+# Rush issues
+
+Deliver the **entire spec in one PR on one branch**. Act as a thin scheduler:
+coordinate depth-1 subagents and local programs; do not implement product code
+in the orchestrator.
+
+**Operating bounds:** 30 minutes per task attempt · 2 retries before diagnosis ·
+in-flight cap 4 · exactly one combined PR.
+
+```text
+preflight (models + target only) -> task plan (show user)
+  -> exploration (shared findings)
+  -> continuously schedule runnable units, at most 4 in flight:
+       isolated implement -> validate -> self-review -> fix/re-validate as needed
+  -> combine every unit on one PR branch -> validate
+  -> data warehouse only: staged read-only canary on exact HEAD
+  -> open one PR
+  -> one independent code-review -> fix/re-validate/re-review as needed
+  -> watch CI -> fix/re-validate -> enqueue/merge
+```
+
+This file is the workflow and index. Read the linked procedure immediately
+before its stage; do not invent an unlinked substitute.
+
+| Stage / concern | Procedure |
+|---|---|
+| Model and target preflight | [references/preflight.md](references/preflight.md) |
+| Task map and run setup | [references/task-plan.md](references/task-plan.md) |
+| Shared exploration | [references/exploration.md](references/exploration.md) |
+| Isolated implementation loop | [references/implementation.md](references/implementation.md) |
+| Combine to one PR | [references/combine.md](references/combine.md) |
+| Staged read-only warehouse canary | [references/canary.md](references/canary.md) |
+| Independent factual review | [references/review.md](references/review.md) |
+| CI, queue, and merge | [references/cicd.md](references/cicd.md) |
+| Expiry, diagnosis, and continuation | [references/expire.md](references/expire.md) |
+| Live task plan | [references/task-plan.md](references/task-plan.md) |
+| Performance profiling | [references/profiling.md](references/profiling.md) |
+| Model catalog and leaf skills | [references/shared-modules.md](references/shared-modules.md) |
+
+## Run invariants
+
+- The PR branch contains every unit in the task map. Do not open a partial PR
+  and describe a reduced subset as the spec.
+- Never route a unit or run to another implementation workflow because it is
+  high-risk, large, or difficult. Keep the entire spec in Rush and apply the
+  repository's hazard guidance through model choice, implementation, tests,
+  review, and CI.
+- Prefer an isolated run branch + Git workspace. Every implementation unit owns
+  a separate branch + Git workspace until it is combined or handed back.
+- Schedule runnable units continuously and in parallel, with at most 4 active
+  implementation workers. Preserve declared blocking dependencies.
+- A retry counter reaching 2 or a task attempt reaching 30 minutes causes
+  expiry -> diagnosis -> revised plan -> continuation. Expiry alone is not a
+  terminal unit outcome and does not remove scope.
+- A human/external blocker may stop the run. Mark the unit `blocked`, preserve
+  its workspace, and hand back without claiming a whole-spec PR.
+- Never open per-unit PRs. Open exactly one PR, after all units are combined and
+  the combined HEAD validates.
+- When the run changes executable data-warehouse behavior or its data contract,
+  do not enter review until a staged read-only canary succeeds on the exact
+  combined HEAD. Any later code or configuration commit invalidates that
+  canary and requires validation plus a fresh canary on the new HEAD.
+- Review facts independently. Producer summaries, claims, logs, and evidence
+  may locate work but cannot establish correctness for the reviewer.
+- Do not manufacture review evidence collateral. Keep only the stage result,
+  commands actually run, findings, task-plan transitions, and profiling events.
+- Persist each task-plan transition and profiling event under one monotonically
+  increasing plan revision, then render the user board from that persisted
+  revision. Displayed counters must never outrun or lag stored state.
+
+## Stage contracts
+
+Every subagent brief includes:
+
+- original spec/unit source and acceptance criteria
+- absolute run workspace and unit workspace (when applicable)
+- absolute shared exploration findings path
+- model id + effort and required read-back
+- absolute skill path only when the stage explicitly invokes a leaf skill
+- required outcome and validation obligations, without prescribing an
+  implementation workflow, development methodology, or producer evidence format
+- proof-of-execution result path or structured return contract
+- 30-minute task-attempt deadline
+
+No readable result means the stage did not complete. A dead spawn is diagnosed
+and resumed in the same preserved workspace; it is never replaced by a success
+claim.
+
+## Workflow
+
+### 1. Preflight
+
+Select models and confirm the non-production target branch. Those are the only
+preflight decisions. Use the shared preflight module and model-catalog fast
+path: explorer is a balanced-coder that prefers `gpt-5.6-terra@high`; reviewer
+is a distinct deep-reasoner that prefers `gpt-5.5@high` when available. Risk
+may recommend a stronger operating point, but never changes the workflow.
+
+### 2. Build and show the task plan
+
+Create the isolated run branch/workspace, decompose the entire spec into
+implementable units, record blocking dependencies and shared surfaces, create
+the run state/profiling paths, and show the complete plan before any heavy
+spawn. Hazardous units stay in the plan with their required safety checks.
+
+### 3. Exploration
+
+Spawn one explorer. It reads every requirement, the codebase, named external
+documents, ADRs, and other context, then writes shared findings available to
+all implementers. It writes no product code.
+
+### 4. Implement every unit
+
+Give each unit its own branch/workspace and one implementer with the original
+unit context plus shared findings. State the required outcome and validation
+obligations, then let the active harness choose how to implement them. The
+implementer changes code, validates the result, self-reviews the net diff,
+fixes findings, and re-validates. Refill free worker slots immediately while
+respecting blocking dependencies.
+
+### 5. Combine and open one PR
+
+After every unit succeeds, combine all unit branches onto the isolated run
+branch, resolve integration conflicts, and validate the combined HEAD. For a
+data-warehouse run, execute the staged read-only canary on that exact HEAD
+after validation and before review. Open one PR against the confirmed target
+branch. If any unit or required canary remains blocked, do not open or describe
+a partial PR as completion of the spec.
+
+### 6. Independent review
+
+Spawn one reviewer on the combined HEAD using the `code-review` skill. It reads
+the original spec and repository standards, computes its own diff fixed point,
+inspects the implementation, and runs checks needed to verify findings. It does
+not accept producer evidence as proof. Fix blocking findings on the combined
+branch, validate, rerun the warehouse canary when required, then run a fresh
+review until successful; after 2 failed fix/review cycles, diagnose and continue
+with a revised approach.
+
+### 7. CICD
+
+Watch CI on the exact combined HEAD. Diagnose a failure and fix it on the same
+PR branch. A code/config change creates a new HEAD and invalidates the prior
+review and any warehouse canary: run relevant local validation, rerun the
+staged read-only canary when required, return to a fresh independent review of
+that HEAD, then push/watch again. A provider rerun with no HEAD change does not
+invalidate review or canary. Inspect live queue configuration before
+enqueueing; use the owning queue skill when installed. Enqueue/merge only when
+the exact HEAD is reviewed, green, and carries its required canary. After 2
+failed cycles or a 30-minute watch attempt, diagnose and continue rather than
+silently abandoning the run.
+
+## Task plan and profiling
+
+The task map is the live source of truth. Display it after run setup, every
+stage transition, worker/retry/diagnosis event, PR HEAD change, and about
+every 5 minutes during long work. Apply a transition, append its profiling
+event with the same `planRevision`, persist both, then render that exact plan
+revision. Profiling distinguishes wall time, effective LLM/program activity,
+and external wait.
+
+## Done
+
+Success means one PR containing the entire mapped spec is independently
+reviewed, green on its exact HEAD, canary-verified when it changes warehouse
+behavior, and merged when authorized (or handed back merge-ready in supervised
+mode). Final handoff includes the plan, PR URL/SHA, validation, canary when
+required, and review results, retries/diagnoses, wall/effective/wait timings,
+profiling path, and exploration path.

package/skills/engineering/rush-issues/agents/openai.yaml

@@ -0,0 +1,9 @@
+interface:
+  display_name: "Rush Issues"
+  short_description: "Slash/explicit-only fast delivery: complete spec to one PR"
+
+policy:
+  # Codex counterpart to SKILL.md disable-model-invocation: true
+  # (Claude Code / Pi). Keeps $rush-issues / explicit invoke; blocks
+  # description-based auto-selection.
+  allow_implicit_invocation: false

package/skills/engineering/rush-issues/evals/evals.json

@@ -0,0 +1,65 @@
+{
+  "skill_name": "rush-issues",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Dry-run only: do not modify Git, spawn workers, open a PR, or contact a provider. Plan a rush run for epic #2400 against main with six routine units: #2401 API parser, #2402 CLI adapter (depends on #2401), #2403 docs, #2404 unit tests, #2405 smoke journey, #2406 migration notes. Show the first user-visible task plan and the concrete explorer/implement/combine/review/CICD briefs and state transitions you would use. All six units are required by the original spec. Available models include openai/gpt-5.6-terra@high and openai/gpt-5.5@high.",
+      "expected_output": "A dry-run artifact that displays the complete task map before heavy work, uses shared exploration, schedules at most four isolated unit workspaces while respecting #2402's dependency, combines all six units into one PR, performs independent factual review, and records 30-minute/retry/profiling behavior.",
+      "files": [],
+      "expectations": [
+        "Displays a task plan containing all six units before exploration or implementation.",
+        "Records #2402 as blocked on #2401 and schedules runnable work continuously with at most four active workers.",
+        "Assigns every implementation unit its own branch and isolated Git workspace.",
+        "Uses one shared exploration pack and selects gpt-5.6-terra@high for exploration and a distinct gpt-5.5@high reviewer when available.",
+        "Combines only after all six mapped units succeed and opens exactly one whole-spec PR.",
+        "Runs one independent code-review stage that establishes facts independently of producer claims.",
+        "States the two-retry and 30-minute diagnosis/resume behavior and profiles wall, effective, and wait time."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Dry-run only: do not modify Git, spawn workers, open a PR, or contact a provider. Simulate a rush run with required units A, B, and C. B and C succeed. A fails validation twice and its current task reaches 30 minutes. Later, after all units are implemented, the producer's PR body claims every test is green, but an independently run test reveals a real defect. Show exact task-plan transitions, whether/when combination is allowed, the review/fix loop, and CICD handling if the first two CI fix attempts also fail.",
+      "expected_output": "A dry-run artifact where A expires into diagnosis and resumes in its preserved workspace, B/C do not become a partial PR, combination waits for A, review establishes facts independently rather than trusting producer evidence, every changed HEAD is validated and freshly reviewed, and two failed CI cycles trigger diagnosis and continuation.",
+      "files": [],
+      "expectations": [
+        "Transitions A's expired attempt to diagnosing after two failures or 30 minutes while preserving A's workspace and branch.",
+        "Records a changed hypothesis or plan before resetting the local retry counter and resuming A.",
+        "Does not combine B and C into a partial PR; combination waits until A, B, and C all succeed.",
+        "Treats producer test claims as untrusted and uses the independent reviewer’s own test result as the fact.",
+        "Fixes the review defect on the combined branch, validates the fix, and performs a fresh review of the new HEAD.",
+        "After two failed CI fix cycles, diagnoses and continues on the same PR branch rather than abandoning or reducing scope.",
+        "Invalidates the prior review after any code-changing CI fix and obtains a fresh independent review of the new HEAD before enqueue or merge.",
+        "Uses one planRevision for each persisted task-plan transition, profiling event, and displayed board so counters and HEAD cannot disagree.",
+        "Shows task-plan checkpoints and profiling for retries, diagnosis, wall/effective activity, and external wait."
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Dry-run only: do not modify Git, spawn workers, open a PR, or contact a provider. Plan a rush run for a high-risk money migration epic against main. Show preflight, task planning, implementation, combination, review, and CICD. The work must remain one whole-spec PR even though repository hazard guidance classifies every unit high-risk.",
+      "expected_output": "A dry-run artifact whose preflight asks only for model choice and target branch through the shared preflight module, retains every high-risk unit in Rush, applies deeper model/testing/review obligations, uses sandbox-compatible Git workspaces, and produces one combined PR without redirecting to another workflow.",
+      "files": [],
+      "expectations": [
+        "Uses the shared preflight module for only model choice and target-branch confirmation.",
+        "Does not redirect to resolve-issues or remove high-risk units from the Rush task map.",
+        "Uses risk only to strengthen model selection, implementation, validation, and review depth.",
+        "Keeps the entire high-risk epic within the one-branch, one-PR Rush workflow.",
+        "For sandboxed Git-mutating Pi workers, uses a self-contained clone workspace rather than a linked worktree whose Git metadata is outside the sandbox."
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Dry-run only: do not modify Git, submit a cluster job, spawn workers, open a PR, or contact a provider. Plan a rush run for an epic that changes a PySpark warehouse transformation, partition schema, and backfill watermark. The repository exposes its production entry point with --validate-only and a staging cluster using read-only credentials. Show the ordering from combined validation through review and what happens if a review or CI fix changes HEAD.",
+      "expected_output": "A dry-run artifact that classifies the run as warehouse-canary required, validates the combined branch, runs the real entry point in staged read-only validate-only mode on that exact HEAD before review, proves zero publication side effects, and invalidates/repeats the canary after every code or configuration HEAD change.",
+      "files": [],
+      "expectations": [
+        "Records warehouseCanaryRequired and a concrete classification reason in the task plan.",
+        "Runs the staged read-only canary after combined tests/validation and before independent review.",
+        "Binds the canary command or artifact and durable result to the exact combined 40-character HEAD.",
+        "Uses the real production entry point, staging/canary execution surface, bounded source scope, read-only credentials, and --validate-only.",
+        "Requires explicit publication skip, zero output records/bytes, and no table commit, checkpoint, watermark, offset, scheduler, or other state mutation.",
+        "Blocks instead of waiving the stage if read-only execution cannot be proven.",
+        "Invalidates the prior canary result after any code/configuration commit and reruns validation plus canary before review, enqueue, or merge."
+      ]
+    }
+  ]
+}

package/skills/engineering/rush-issues/references/canary.md

@@ -0,0 +1,45 @@
+# Staged read-only data-warehouse canary
+
+Run this stage after combined validation and before independent review when the
+run changes executable warehouse behavior or its data contract. Examples
+include Spark/SQL/ETL transformations, schemas, keys, partitions, watermarks,
+checkpoints, backfills, or publication/writer behavior. A task that merely
+reads application data or edits warehouse documentation does not activate this
+stage. Record the classification and reason in the task plan.
+
+## Exact-HEAD contract
+
+1. Resolve and record the combined branch's exact 40-character `headSha` after
+   tests and validation pass.
+2. Use the repository's real entry point and staging/canary execution surface
+   with read-only credentials. Bind any built artifact or submitted job to that
+   exact SHA.
+3. Use a bounded representative source snapshot/scope and the repository's
+   validate-only or dry-run guard. The guard must sit before every writer; a
+   mode that skips the transformation under test is not a canary.
+4. Prove the run created no table/object output, transaction or table-format
+   commit, checkpoint, watermark, consumed offset, scheduler-state change, or
+   other publication side effect. For Spark, require zero output records and
+   bytes plus an explicit publication skip.
+5. Record the command, non-secret target, source snapshot/scope, exact SHA,
+   start/end time, validation readings, logs, and zero-write observation in a
+   durable result.
+
+Do not run a write-enabled canary, infer safety from a command name, or replace
+the staged execution with local tests. If no repository-supported mode can
+prove read-only execution, mark the canary blocked and hand back the missing
+guard, credentials, environment, or authorization. Do not waive it as
+not-applicable after the run has been classified as warehouse-canary required.
+
+## Failure and invalidation
+
+A failed canary returns the combined branch to the fix loop. Diagnose the
+observed failure, change the code or execution plan, rerun relevant local tests
+and validation, then run a fresh canary. Two failed validate/canary cycles or a
+30-minute attempt follows [expire.md](expire.md).
+
+Any code or configuration commit invalidates the prior canary result, even when
+the change looks unrelated. A provider rerun or evidence read with no HEAD
+change may keep the result. When `warehouseCanaryRequired` is true, review, CI
+delivery, enqueue, and merge require a successful canary result for the current
+exact HEAD.

package/skills/engineering/rush-issues/references/cicd.md

@@ -0,0 +1,37 @@
+# CI, queue, and merge
+
+Operate only on the single combined PR branch after independent review
+succeeds.
+
+## Procedure
+
+1. Push the reviewed HEAD and watch required CI checks for that exact SHA.
+2. On failure, read the actual job logs and reproduce the failing command where
+   practical. Diagnose before editing.
+3. Fix on the same PR branch and run relevant local lint/build/test/smoke.
+4. If the fix changes HEAD, clear `reviewedHead`, mark review and the prior
+   canary result stale, rerun [canary.md](canary.md) when required, and return
+   to [review.md](review.md) for a fresh independent review of the new HEAD.
+   Only after that succeeds may the new reviewed HEAD be pushed/watched. A
+   provider rerun with no commit keeps the existing review and canary valid.
+5. Before enqueueing, assert `reviewedHead == headSha`; when
+   `warehouseCanaryRequired` is true, require a successful canary result naming
+   that exact SHA. Require CI green for the SHA and inspect live queue
+   configuration/protections. If Mergify is involved, load the `mergify` skill
+   and use its queue status/watcher procedure rather than a generic PR-check
+   poll.
+6. In `autonomous` mode, enqueue and watch through merge when authorized. In
+   `supervised` mode, hand back the exact green reviewed HEAD as merge-ready and
+   do not approve/merge on the human's behalf.
+
+## Expiry behavior
+
+Two failed fix/review/watch cycles or a 30-minute bounded watch expires the
+attempt. Follow [expire.md](expire.md): preserve the branch and logs, diagnose
+the failure or pending provider state, update the plan, and continue with a
+fresh bounded attempt. A pending queue after 30 minutes is wait diagnosis, not
+a reason to change code.
+
+If diagnosis proves an external or human blocker, mark CICD `blocked` and hand
+back the PR URL, exact HEAD, checks/queue state, and required next action. Never
+report merge success until the provider reports the exact PR merged.

package/skills/engineering/rush-issues/references/combine.md

@@ -0,0 +1,51 @@
+# Combine to one PR
+
+Combine only after every mapped unit has succeeded. The run branch and PR must
+carry the entire mapped spec.
+
+## Inputs
+
+- live task plan with every unit `succeeded`
+- every unit branch and exact succeeded SHA
+- isolated run branch/workspace from task-plan initialization
+- original spec and shared exploration findings
+- confirmed `targetBranch`
+
+## Procedure
+
+1. Fetch `origin/<targetBranch>` and confirm the run branch has the intended
+   fixed point. Do not destroy unpublished run-branch work.
+2. Merge or cherry-pick every unit branch in dependency order. Prefer a history
+   that preserves each unit id and SHA.
+3. Resolve conflicts in the run worktree. For non-trivial conflicts, spawn a
+   focused integration fix task with the same 30-minute attempt deadline.
+4. Run relevant lint, build, tests, and smoke on the combined HEAD. A check may
+   be `not-applicable` only with a concrete reason recorded on the plan.
+5. If `warehouseCanaryRequired` is true, follow [canary.md](canary.md) after
+   validation and run a staged read-only canary on this exact combined HEAD.
+   Do not proceed unless it succeeds and its result names that exact HEAD.
+6. Open exactly one PR against `targetBranch`. Include the original spec,
+   included unit ids and SHAs, validation results, and shared findings path.
+   Include the canary result for a data-warehouse run.
+7. Record the PR URL and combined HEAD on the task plan, then enter independent
+   review.
+
+## Whole-spec boundary
+
+- Never open per-unit PRs.
+- Never omit an expired or blocked unit and redefine the remainder as the
+  completed spec.
+- If a unit is diagnosing, continue it before combination.
+- If a unit is blocked on a human or external prerequisite, preserve all
+  workspaces and hand back the blocked plan. Do not open a partial PR claiming
+  the spec is implemented.
+- If integration exposes missing work, add or reopen units on the same plan,
+  complete them in isolated workspaces, then retry combination.
+
+## Completion
+
+Exactly one PR exists for the run; its HEAD includes every mapped unit; combined
+validation is green; any required warehouse canary is green on that exact HEAD;
+and the task plan records the PR, HEAD, unit SHAs, and commands run. The PR is
+not review-ready on producer claims alone: the next stage establishes facts
+independently.

package/skills/engineering/rush-issues/references/expire.md

@@ -0,0 +1,55 @@
+# Expiry, diagnosis, and continuation
+
+Expiry prevents blind repetition. It is a checkpoint, not permission to drop a
+unit from the spec.
+
+## Limits
+
+| Scope | Expiry condition |
+|---|---|
+| Implement / validate / self-review | 2 failed fix cycles without success |
+| Staged read-only warehouse canary | 2 failed validate -> canary cycles without success |
+| Independent review | 2 failed fix -> validate -> review cycles without success |
+| CICD | 2 failed diagnose -> fix -> validate -> push/watch cycles without success |
+| Any subagent task or bounded stage attempt | 30 minutes wall time |
+
+Do not start retry 3 unchanged. A spawn death with no result does not prove a
+work failure, but it still requires a short diagnosis before resuming in the
+same workspace.
+
+Reason codes: `retry-implement`, `retry-canary`, `retry-review`, `retry-cicd`,
+`timeout-task`, `spawn-death`, `combine-conflict`, `external-blocker`,
+`human-decision`.
+
+## Diagnose
+
+When an attempt expires:
+
+1. Stop the live task and preserve its branch/workspace and logs.
+2. Mark the attempt `expired` and the unit/fleet row `diagnosing`; free its
+   worker slot while diagnosis runs.
+3. Inspect current code, actual command output, failing tests/checks, task
+   boundaries, dependencies, and the prior two hypotheses. Do not accept the
+   failed worker's explanation without reproducing the relevant fact.
+4. Record a diagnosis: observed failure, root-cause hypothesis, what changes in
+   the plan/brief/validation, and the next bounded attempt.
+5. Continue from the preserved workspace. Reset the local retry counter only
+   after the plan materially changes; retain cumulative retry/diagnosis counts.
+
+Useful diagnosis outcomes:
+
+- **Approach change:** revise the brief or implementation strategy and resume.
+- **Further decomposition:** replace one oversized unit with smaller units that
+  still cover the same spec, then schedule them normally.
+- **Dependency correction:** add/fix a blocking edge and resume when runnable.
+- **Flake/infrastructure:** prove the classification, adjust the execution
+  method, and resume without changing product behavior to appease a flake.
+- **Human/external blocker:** mark `blocked`, preserve work, and hand back the
+  exact decision or prerequisite needed. Do not continue to combine a subset.
+
+## Fleet stages
+
+Exploration, combination, review, and CICD use the same expiry loop. A
+30-minute CI/queue watch may expire because the provider is still pending;
+record the wait diagnosis and start a fresh bounded watch. Only a factually
+blocked state ends the run, and it ends without a whole-spec completion claim.