ql-execute skill
Runs an autonomous development execution loop that implements stories from a JSON specification using TDD and parallel worktree isolation.
- GitHub stars
- 24
- Files
- 1
- Last commit
- Jun 25, 2026
- License
- MIT
- Allowed tools
- —
What does the ql-execute skill do?
ql-execute runs an autonomous development execution loop that implements stories from a JSON specification using TDD and parallel worktree isolation.
Summary generated from the skill's SKILL.md.
About the ql-execute skill
Implementing software stories from a JSON specification is the primary function of this tool. It operates as an autonomous execution loop within a larger development pipeline, requiring a pre-existing quantum.json file and a git repository to function. Developers use it to automate the transition from a planned specification to completed, tested code through a structured process of implementation, quality checks, and review gates.
The system manages complexity by querying a dependency DAG to identify eligible stories. It can execute tasks sequentially or spawn parallel implementer subagents using native worktree isolation for simultaneous work. To prevent execution drift, the skill includes a liveness gate that monitors the orchestrator and provides a structured handoff if the process becomes stale. It relies on project-specific build tools like npm, pip, or cargo to validate changes during the test-driven development cycle.
What an agent can do with it
- 1Automated story implementationAn agent can start the autonomous building process to implement all pending stories defined in a specification file.
- 2Parallel development executionDevelopers can trigger multiple subagents to work on different stories at the same time using isolated environments.
- 3Automated code cleanupThe pipeline can automatically remove dead code and duplication after a story passes its initial review.
Written from the skill's SKILL.md. Every use case is checked against a quote from it.
How to install the ql-execute skill
Each command copies the skill folder into the client's skills directory. Restart the client or start a new session to load it.Install the ql-execute skill in Plugin
/plugin marketplace add andyzengmath/quantum-loop /plugin install quantum-loop@quantum-loop
Install the ql-execute skill in Claude Code
~/.claude/skills/ql-execute/SKILL.md
$ npx degit andyzengmath/quantum-loop/skills/ql-execute ~/.claude/skills/ql-executeInstall the ql-execute skill in Claude Code (project)
.claude/skills/ql-execute/SKILL.md
$ npx degit andyzengmath/quantum-loop/skills/ql-execute .claude/skills/ql-executeInstall the ql-execute skill in Codex
~/.agents/skills/ql-execute/SKILL.md
$ npx degit andyzengmath/quantum-loop/skills/ql-execute ~/.agents/skills/ql-executeInstall the ql-execute skill in Gemini CLI
~/.gemini/skills/ql-execute/SKILL.md
$ npx degit andyzengmath/quantum-loop/skills/ql-execute ~/.gemini/skills/ql-executeInstall the ql-execute skill in Claude.ai
npx degit andyzengmath/quantum-loop/skills/ql-execute ql-execute && zip -r ql-execute.zip ql-execute # claude.ai → Customize → Skills → + → Create skill → Upload a skill → ql-execute.zip
SKILL.md
View on GitHubQuantum-Loop: Execute
Run the autonomous execution loop to implement all stories in quantum.json.
Prerequisites
Before starting:
quantum.jsonmust exist (created by/quantum-loop:plan)- The project must be a git repository
- Project build tools must be available (npm, pip, cargo, etc.)
If prerequisites are not met, inform the user and stop.
Execution
Read and follow the orchestrator agent instructions in agents/orchestrator.md.
The orchestrator will:
- Read quantum.json state and validate the dependency DAG
- Query for eligible stories (pending/retriable with all dependencies passed)
- If 1 story eligible: execute it sequentially (implement, quality checks, review, commit)
- If 2+ stories eligible: spawn parallel implementer subagents in isolated worktrees
- Handle retries, cascade blocking, and error recovery
- Loop until all stories pass (COMPLETE) or no stories are executable (BLOCKED)
Orchestrator liveness gate (N14 / US-002 — v0.7.0)
Default-on for unattended /ql-execute runs. v0.6.7 + v0.6.8 + v0.6.9 all saw the orchestrator subagent abandon its cycle mid-execution (LLM context-drift). v0.6.8 N6 shipped a prose-only Self-monitoring guard. v0.6.9 N6-followup shipped lib/orchestrator-liveness.sh::poll_orchestrator_commits as a callable runtime helper. This v0.7.0 N14 SKILL-level wrapping is the third and final layer — auto-invoke the helper after dispatching the orchestrator, hand off to the parent on STALE.
# After dispatching the orchestrator subagent (Step 3 of Execution above):
source lib/orchestrator-liveness.sh
wrap_orchestrator_dispatch 600 60 || exit 1
The wrap_orchestrator_dispatch function (v0.7.1 N20 extraction; see
lib/orchestrator-liveness.sh) handles the QL_LIVENESS_ENABLE env-var
check, the poll_orchestrator_commits invocation, and the structured
handoff message internally. The SKILL just calls it and exits 1 on
STALE so CI / wrapper scripts can distinguish stale-signal exits from
clean COMPLETE / BLOCKED exits.
Env var contract:
QL_LIVENESS_ENABLE= |
Effect |
|---|---|
(unset) or true |
default — wrap orchestrator dispatch with poll_orchestrator_commits (timeout 600s, interval 60s) |
false |
skip the wrapping; preserve v0.6.9 dispatch semantics exactly (backwards compat for operators with their own wrappers) |
| any other value | treated as true (default-true semantics; warn to stderr) |
Handoff message structure (printed to stdout when STALE fires):
- One-line
[QL-EXECUTE] orchestrator-stale signal.header. - Pointer to
references/orchestrator-takeover.md(the v0.6.9 N13 SOP). - Numbered recovery steps the parent agent runs (drift verification + manual takeover).
The parent agent reads the handoff and either re-spawns /ql-execute (after confirming whether drift was a transient LLM hiccup) or takes over manually per the SOP. SKILL exits with rc=1 (orchestrator-stale) so CI / wrapper scripts can distinguish stale-signal exits from clean COMPLETE / BLOCKED exits.
Testability note (presence-only AC): the wrapping prose above is consumed by an LLM that runs /ql-execute. There is no runtime test that EXERCISES the env-var conditional or the handoff message structure inside the SKILL itself — those would require running the SKILL in a controlled fixture. Instead, tests/test_ql_execute_liveness_wrapping.sh verifies the prose contains the expected idioms (header, env var, default-true, cross-link, handoff structure). Matches v0.6.8 N6 prose-guard pattern.
Autonomous CLI Alternative
For unattended execution outside Claude Code (Linux/Mac):
./quantum-loop.sh --max-iterations 20
./quantum-loop.sh --parallel --max-parallel 4
On Windows, use /ql-execute instead of the shell script for reliable execution.
Signals
| Signal | Meaning |
|---|---|
<quantum>COMPLETE</quantum> |
All stories passed |
<quantum>BLOCKED</quantum> |
No executable stories remain |
<quantum>STORY_PASSED</quantum> |
One story completed (more remain) |
<quantum>STORY_FAILED</quantum> |
One story failed (will retry if attempts remain) |
<quantum>WAVE_PASSED</quantum> |
All stories in a coordinator wave passed (v0.8.0+ coordinator pattern; see agents/coordinator.md) |
<quantum>WAVE_FAILED</quantum> |
One or more wave stories failed (parent decides retry/abort) |
Post-review slop-cleanup hook (Phase 9 / P1.6)
After each story's two-stage review gate PASSES but BEFORE the merge to the feature branch, the orchestrator SHOULD invoke /quantum-loop:ql-deslop on the story's changed files. Opt-out via --no-deslop (record the reason in commit trailer Deslop: skipped | <reason>).
Mandatory safety rails, enforced by lib/deslop.sh:
validate_scope <file> BASE HEAD— rejects any edit to a file outside the story's diff. Prevents "adjacent cleanup" scope creep.take_baseline <before.json>— snapshots test / lint / typecheck exit codes.- Run ONE deslop pass at a time from the 4-pass taxonomy in
skills/ql-deslop/SKILL.md(dead-code → duplication → consistency → test-reinforcement). take_baseline <after.json>+compare_baseline before.json after.json. Any regression triggers:rollback_pass BASE <files>and emits<quantum>DESLOP_ROLLED_BACK</quantum>. The next pass does NOT start until the user inspects.- Persist per-pass report into
quantum.deslop[<story-id>].pass_<n>.
Language detection: bash lib/deslop.sh detect-language dispatches to the appropriate dead-code detector (knip / ts-prune / vulture / staticcheck / cargo-udeps). When tooling is missing, the step is skipped cleanly rather than failing the pipeline.
Post-pipeline review hook (Phase 8 / P1.1 + P1.2)
After COMPLETE fires, the orchestrator SHOULD invoke /quantum-loop:ql-deep-review before handing the merged branch back to the user. Opt-in via --deep-review (or mandatory when the feature's risk tier is HIGH / CRITICAL per lib/deep-review.sh compute_risk_score).
Gate steps:
- Run the wave-boundary checks on the final commit range (
BASE_SHA..HEAD_SHA):- Cross-story constant scan —
bash lib/wave-boundary.sh scan BASE HEADemits JSON findings for literals that canonicalize to the same key across ≥2 stories (e.g.'google'vs'google-api-key'; the Math-Research regression class). Gate viabash lib/wave-boundary.sh gate BASE HEAD— exit 0 = divergence found, exit 1 = clean. Non-empty findings are treated as amedium(2 variants) orhigh(3+ variants) severity input to the reviewer-set dispatch. - Wave-wide typecheck (
lib/resilience.shrun_typecheck). - Full test suite.
- Barrel + dep-manifest regeneration (
lib/barrel-regen.sh,lib/dep-manifest.sh).
- Cross-story constant scan —
- Compute risk tier:
bash lib/deep-review.sh score BASE HEAD→ thenbash lib/deep-review.sh tier <score>. - Dispatch the reviewer-set specified in
skills/ql-deep-review/SKILL.md §"Risk scoring". - Apply
lib/deep-review.sh actionability / dedup / hallucination / verdictin sequence to aggregate findings. - Persist the final review object into
quantum.reviews[<feature-id>].deepReview. - Verdicts:
BLOCKS_MERGE→ refuse handoff; emitSTORY_FAILEDwith blockers in the failureLog.REQUEST_CHANGES→ route to a targeted fix-story in the next wave.APPROVE_WITH_COMMENTS→ proceed but log comments intocodebasePatterns.APPROVE→ proceed cleanly.
For legacy pipelines that predate this hook, /quantum-loop:ql-deep-review can be invoked manually post-merge.
Files in this skill
1ql-execute skill questions
How do I install the ql-execute skill in Claude Code?
Run npx degit andyzengmath/quantum-loop/skills/ql-execute ~/.claude/skills/ql-execute. Claude Code loads skills from ~/.claude/skills (all projects) or .claude/skills (one project) and uses a skill when its description matches the task.
Which clients can use the ql-execute skill?
Any client that reads the Agent Skills format: Claude Code, Codex, Gemini CLI and claude.ai (upload as a ZIP). Scripts in the skill run only where the client allows code execution.
What are the prerequisites for running ql-execute?
A quantum.json file must exist (generated by /quantum-loop:plan), the project must be a git repository, and necessary build tools like npm, pip, or cargo must be available.
How does the tool handle multiple eligible stories?
If two or more stories are eligible, the tool spawns parallel implementer subagents using isolated worktrees.
What happens if the orchestrator subagent becomes stale?
The system uses a liveness gate to detect drift; if stale, it prints a handoff message with recovery steps and exits with a specific signal so CI/wrapper scripts can distinguish it from a clean exit.