feat: worktree-per-task wave execution#1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
daniellam258 merged 2 commits into from
Aug 10, 2026
Merged

feat: worktree-per-task wave execution #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c60e932
feat: worktree-per-task wave execution
daniellam258 Aug 10, 2026
2e055f7
feat: wave binding duties in vendor template
daniellam258 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions skills/delivery-handoff/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-handoff
description: This skill should be used when the user asks for "a handoff prompt", "a prompt for codex/grok/claude", "something I can paste into another agent", or wants to continue tracked work in a different tool — and at any phase boundary of the cmk:delivery-pipeline skill when the operator prefers a different agent for the next phase.
version: 0.1.0
version: 0.2.0
---

# Delivery Handoff
Expand DownExpand Up@@ -69,7 +69,12 @@ freely; completeness matters, sections don't):
2. **Workspace** — absolute worktree path, branch, base branch (= future
PR base), the verify-before-touching commands, and the same-worktree
rule. For clusters: the issue → worktree/branch/base table plus where
the orchestration plan lives and which wave is active.
the orchestration plan lives and which wave is active. For a handoff
mid-way through a phase-3 wave, additionally enumerate every live task
worktree — path, task branch, wave-base SHA, and join state (pending /
integrated / escalated), from the wave manifest in the ledger — and
state that task worktrees follow the wave protocol's retention rules,
never ad-hoc cleanup.
3. **Read first** — ordered absolute paths: the phase skill(s) to follow,
the tracking contract (`cmk:delivery-workflow`), the context-efficiency
reference, the receiver's runtime binding
Expand Down
4 changes: 2 additions & 2 deletions skills/delivery-pipeline/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-pipeline
description: This skill should be used when the user asks to "work on", "deliver", "tackle", "pick up", or "implement" a tracker issue (TICKET-123), a list of issues, or a body of tracked work expected to finish without supervision — even if they never say "pipeline". Also use when handed a cluster of related issues, or a single issue whose surrounding cluster should be derived from tracker dependencies, expecting dependency-aware sequencing across worktrees.
version: 0.1.0
version: 0.2.0
---

# Delivery Pipeline
Expand DownExpand Up@@ -79,7 +79,7 @@ reads this instead of rediscovering it — keep it to those four things.
| Phase | Skill / engine | CMK adds |
|---|---|---|
| 1. Intake | `cmk:delivery-intake` | all of it — the tracker has no superpowers equivalent |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, and binding obligations inside each task body |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, `Exclusive resources:`, and binding obligations inside each task body |
| 3. Implement | `superpowers:subagent-driven-development` (below) | wave dispatch and its safety fixes |
| 4. Review | `cmk:delivery-review` | lenses, evidence bar, adversarial verification, disposition, depth disclosure |
| 5. Ship | `cmk:delivery-ship` | PR, tracker reconciliation, evidence |
Expand Down
57 changes: 33 additions & 24 deletions skills/delivery-pipeline/references/phase-3-execution.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -22,30 +22,39 @@ own model and effort; its "REQUIRED" caution exists for a stock agent that
declares neither. The role also requires the worker to report each commit
SHA, which is what the scope check below consumes.

CMK changes exactly one thing: **independent tasks run in the same wave.**
SDD serializes implementers because concurrent commits contaminate its
`BASE..HEAD` review packages — not merely because of file conflicts. Tasks
with no `Depends on:` and disjoint `File scope:` may be dispatched together
once three things hold:

1. **Review packages are path-scoped.** SDD's own review-package assembly
cannot take a pathspec and lives in a plugin cache that is overwritten
on update, so use a path-scoped review-package script the repo may
provide — appending `-- <File scope>` to the same commit range —
otherwise assemble the diff with `git diff` scoped to the task's file
list.
2. **Each package has its own output path.** A commit-range-only filename
is keyed by BASE and HEAD alone, so two tasks in one wave sharing a
range resolve to the *same file* and one silently overwrites the other.
Give each its own name, e.g. `review-task-<N>-<base7>..<head7>.diff`.
3. **Commits are checked against the declared scope.** A path-scoped diff
hides edits made outside that scope, so they would ship unreviewed.
Compare each task's actual commits against its `File scope:`; append
any overflow to the package so it still gets reviewed, and surface the
violation to the controller rather than silently reading past it.

Disjoint scopes make independence *checkable*, not guaranteed. Never
describe it as proven.
CMK changes exactly one thing: **independent tasks run in the same wave,
each in its own worktree.** SDD serializes implementers for two reasons,
and per-task worktrees remove both: concurrent commits contaminate a
shared branch's `BASE..HEAD` review packages, and a shared mutable build
root — one Cargo `target/` and its exclusive lock — serializes
"independent" tasks into lock-thrash where every worker turn blocks and
nothing progresses.

Wave eligibility: no `Depends on:`, disjoint `File scope:`, and no
intersecting `Exclusive resources:`. Disjoint scopes make independence
*checkable*, not guaranteed — never describe it as proven.

The dispatch, join, reconciliation, and cleanup protocol — parent-WIP
snapshot commits, pinned wave base, per-task branches, cache seeding,
rebase-then-ff-only integration, retention on failure, and every guard —
is `references/worktree-wave-execution.md`. Follow it exactly; its MUSTs
are load-bearing.

Review packages are per task branch: the range `wave-base..task-head`.
SDD's own review-package assembly cannot take a pathspec and lives in a
plugin cache overwritten on update, so use the repo's review-package
script where one exists — with an explicit per-task output path (a
range-keyed default silently collides between tasks sharing a base), the
task's `File scope:`, and its commits — otherwise assemble the diff with
`git diff` over the range. Either way, check each task's commits against
its declared scope: append any overflow to the package so it still gets
reviewed, and surface the violation to the controller rather than
silently reading past it.

**Thrash detection.** Lock-wait build output or repeated no-progress
timeouts are a scheduling fault, not a task fault: stop the affected
tasks, re-serialize or isolate the contended resource, and record it in
the ledger — never let the loop tick for hours against a lock.

Reading the ledger under waves: lines are keyed `Task <N>:`, so filter by
task ID **before** taking "the last line." Sequentially, the file's last
Expand Down
Loading
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all \u003cpre\u003e\u003ccode\u003e blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks"); } } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); } })(); (function(){ try { var __m = "github.com"; var __re = new RegExp('^' + "github\\.com" + '
Skip to content

feat: worktree-per-task wave execution#1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
daniellam258 merged 2 commits into from
Aug 10, 2026
Merged

feat: worktree-per-task wave execution #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c60e932
feat: worktree-per-task wave execution
daniellam258 Aug 10, 2026
2e055f7
feat: wave binding duties in vendor template
daniellam258 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions skills/delivery-handoff/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-handoff
description: This skill should be used when the user asks for "a handoff prompt", "a prompt for codex/grok/claude", "something I can paste into another agent", or wants to continue tracked work in a different tool — and at any phase boundary of the cmk:delivery-pipeline skill when the operator prefers a different agent for the next phase.
version: 0.1.0
version: 0.2.0
---

# Delivery Handoff
Expand DownExpand Up@@ -69,7 +69,12 @@ freely; completeness matters, sections don't):
2. **Workspace** — absolute worktree path, branch, base branch (= future
PR base), the verify-before-touching commands, and the same-worktree
rule. For clusters: the issue → worktree/branch/base table plus where
the orchestration plan lives and which wave is active.
the orchestration plan lives and which wave is active. For a handoff
mid-way through a phase-3 wave, additionally enumerate every live task
worktree — path, task branch, wave-base SHA, and join state (pending /
integrated / escalated), from the wave manifest in the ledger — and
state that task worktrees follow the wave protocol's retention rules,
never ad-hoc cleanup.
3. **Read first** — ordered absolute paths: the phase skill(s) to follow,
the tracking contract (`cmk:delivery-workflow`), the context-efficiency
reference, the receiver's runtime binding
Expand Down
4 changes: 2 additions & 2 deletions skills/delivery-pipeline/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-pipeline
description: This skill should be used when the user asks to "work on", "deliver", "tackle", "pick up", or "implement" a tracker issue (TICKET-123), a list of issues, or a body of tracked work expected to finish without supervision — even if they never say "pipeline". Also use when handed a cluster of related issues, or a single issue whose surrounding cluster should be derived from tracker dependencies, expecting dependency-aware sequencing across worktrees.
version: 0.1.0
version: 0.2.0
---

# Delivery Pipeline
Expand DownExpand Up@@ -79,7 +79,7 @@ reads this instead of rediscovering it — keep it to those four things.
| Phase | Skill / engine | CMK adds |
|---|---|---|
| 1. Intake | `cmk:delivery-intake` | all of it — the tracker has no superpowers equivalent |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, and binding obligations inside each task body |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, `Exclusive resources:`, and binding obligations inside each task body |
| 3. Implement | `superpowers:subagent-driven-development` (below) | wave dispatch and its safety fixes |
| 4. Review | `cmk:delivery-review` | lenses, evidence bar, adversarial verification, disposition, depth disclosure |
| 5. Ship | `cmk:delivery-ship` | PR, tracker reconciliation, evidence |
Expand Down
57 changes: 33 additions & 24 deletions skills/delivery-pipeline/references/phase-3-execution.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -22,30 +22,39 @@ own model and effort; its "REQUIRED" caution exists for a stock agent that
declares neither. The role also requires the worker to report each commit
SHA, which is what the scope check below consumes.

CMK changes exactly one thing: **independent tasks run in the same wave.**
SDD serializes implementers because concurrent commits contaminate its
`BASE..HEAD` review packages — not merely because of file conflicts. Tasks
with no `Depends on:` and disjoint `File scope:` may be dispatched together
once three things hold:

1. **Review packages are path-scoped.** SDD's own review-package assembly
cannot take a pathspec and lives in a plugin cache that is overwritten
on update, so use a path-scoped review-package script the repo may
provide — appending `-- <File scope>` to the same commit range —
otherwise assemble the diff with `git diff` scoped to the task's file
list.
2. **Each package has its own output path.** A commit-range-only filename
is keyed by BASE and HEAD alone, so two tasks in one wave sharing a
range resolve to the *same file* and one silently overwrites the other.
Give each its own name, e.g. `review-task-<N>-<base7>..<head7>.diff`.
3. **Commits are checked against the declared scope.** A path-scoped diff
hides edits made outside that scope, so they would ship unreviewed.
Compare each task's actual commits against its `File scope:`; append
any overflow to the package so it still gets reviewed, and surface the
violation to the controller rather than silently reading past it.

Disjoint scopes make independence *checkable*, not guaranteed. Never
describe it as proven.
CMK changes exactly one thing: **independent tasks run in the same wave,
each in its own worktree.** SDD serializes implementers for two reasons,
and per-task worktrees remove both: concurrent commits contaminate a
shared branch's `BASE..HEAD` review packages, and a shared mutable build
root — one Cargo `target/` and its exclusive lock — serializes
"independent" tasks into lock-thrash where every worker turn blocks and
nothing progresses.

Wave eligibility: no `Depends on:`, disjoint `File scope:`, and no
intersecting `Exclusive resources:`. Disjoint scopes make independence
*checkable*, not guaranteed — never describe it as proven.

The dispatch, join, reconciliation, and cleanup protocol — parent-WIP
snapshot commits, pinned wave base, per-task branches, cache seeding,
rebase-then-ff-only integration, retention on failure, and every guard —
is `references/worktree-wave-execution.md`. Follow it exactly; its MUSTs
are load-bearing.

Review packages are per task branch: the range `wave-base..task-head`.
SDD's own review-package assembly cannot take a pathspec and lives in a
plugin cache overwritten on update, so use the repo's review-package
script where one exists — with an explicit per-task output path (a
range-keyed default silently collides between tasks sharing a base), the
task's `File scope:`, and its commits — otherwise assemble the diff with
`git diff` over the range. Either way, check each task's commits against
its declared scope: append any overflow to the package so it still gets
reviewed, and surface the violation to the controller rather than
silently reading past it.

**Thrash detection.** Lock-wait build output or repeated no-progress
timeouts are a scheduling fault, not a task fault: stop the affected
tasks, re-serialize or isolate the contended resource, and record it in
the ledger — never let the loop tick for hours against a lock.

Reading the ledger under waves: lines are keyed `Task <N>:`, so filter by
task ID **before** taking "the last line." Sequentially, the file's last
Expand Down
Loading
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

feat: worktree-per-task wave execution#1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
daniellam258 merged 2 commits into from
Aug 10, 2026
Merged

feat: worktree-per-task wave execution #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c60e932
feat: worktree-per-task wave execution
daniellam258 Aug 10, 2026
2e055f7
feat: wave binding duties in vendor template
daniellam258 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions skills/delivery-handoff/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-handoff
description: This skill should be used when the user asks for "a handoff prompt", "a prompt for codex/grok/claude", "something I can paste into another agent", or wants to continue tracked work in a different tool — and at any phase boundary of the cmk:delivery-pipeline skill when the operator prefers a different agent for the next phase.
version: 0.1.0
version: 0.2.0
---

# Delivery Handoff
Expand DownExpand Up@@ -69,7 +69,12 @@ freely; completeness matters, sections don't):
2. **Workspace** — absolute worktree path, branch, base branch (= future
PR base), the verify-before-touching commands, and the same-worktree
rule. For clusters: the issue → worktree/branch/base table plus where
the orchestration plan lives and which wave is active.
the orchestration plan lives and which wave is active. For a handoff
mid-way through a phase-3 wave, additionally enumerate every live task
worktree — path, task branch, wave-base SHA, and join state (pending /
integrated / escalated), from the wave manifest in the ledger — and
state that task worktrees follow the wave protocol's retention rules,
never ad-hoc cleanup.
3. **Read first** — ordered absolute paths: the phase skill(s) to follow,
the tracking contract (`cmk:delivery-workflow`), the context-efficiency
reference, the receiver's runtime binding
Expand Down
4 changes: 2 additions & 2 deletions skills/delivery-pipeline/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-pipeline
description: This skill should be used when the user asks to "work on", "deliver", "tackle", "pick up", or "implement" a tracker issue (TICKET-123), a list of issues, or a body of tracked work expected to finish without supervision — even if they never say "pipeline". Also use when handed a cluster of related issues, or a single issue whose surrounding cluster should be derived from tracker dependencies, expecting dependency-aware sequencing across worktrees.
version: 0.1.0
version: 0.2.0
---

# Delivery Pipeline
Expand DownExpand Up@@ -79,7 +79,7 @@ reads this instead of rediscovering it — keep it to those four things.
| Phase | Skill / engine | CMK adds |
|---|---|---|
| 1. Intake | `cmk:delivery-intake` | all of it — the tracker has no superpowers equivalent |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, and binding obligations inside each task body |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, `Exclusive resources:`, and binding obligations inside each task body |
| 3. Implement | `superpowers:subagent-driven-development` (below) | wave dispatch and its safety fixes |
| 4. Review | `cmk:delivery-review` | lenses, evidence bar, adversarial verification, disposition, depth disclosure |
| 5. Ship | `cmk:delivery-ship` | PR, tracker reconciliation, evidence |
Expand Down
57 changes: 33 additions & 24 deletions skills/delivery-pipeline/references/phase-3-execution.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -22,30 +22,39 @@ own model and effort; its "REQUIRED" caution exists for a stock agent that
declares neither. The role also requires the worker to report each commit
SHA, which is what the scope check below consumes.

CMK changes exactly one thing: **independent tasks run in the same wave.**
SDD serializes implementers because concurrent commits contaminate its
`BASE..HEAD` review packages — not merely because of file conflicts. Tasks
with no `Depends on:` and disjoint `File scope:` may be dispatched together
once three things hold:

1. **Review packages are path-scoped.** SDD's own review-package assembly
cannot take a pathspec and lives in a plugin cache that is overwritten
on update, so use a path-scoped review-package script the repo may
provide — appending `-- <File scope>` to the same commit range —
otherwise assemble the diff with `git diff` scoped to the task's file
list.
2. **Each package has its own output path.** A commit-range-only filename
is keyed by BASE and HEAD alone, so two tasks in one wave sharing a
range resolve to the *same file* and one silently overwrites the other.
Give each its own name, e.g. `review-task-<N>-<base7>..<head7>.diff`.
3. **Commits are checked against the declared scope.** A path-scoped diff
hides edits made outside that scope, so they would ship unreviewed.
Compare each task's actual commits against its `File scope:`; append
any overflow to the package so it still gets reviewed, and surface the
violation to the controller rather than silently reading past it.

Disjoint scopes make independence *checkable*, not guaranteed. Never
describe it as proven.
CMK changes exactly one thing: **independent tasks run in the same wave,
each in its own worktree.** SDD serializes implementers for two reasons,
and per-task worktrees remove both: concurrent commits contaminate a
shared branch's `BASE..HEAD` review packages, and a shared mutable build
root — one Cargo `target/` and its exclusive lock — serializes
"independent" tasks into lock-thrash where every worker turn blocks and
nothing progresses.

Wave eligibility: no `Depends on:`, disjoint `File scope:`, and no
intersecting `Exclusive resources:`. Disjoint scopes make independence
*checkable*, not guaranteed — never describe it as proven.

The dispatch, join, reconciliation, and cleanup protocol — parent-WIP
snapshot commits, pinned wave base, per-task branches, cache seeding,
rebase-then-ff-only integration, retention on failure, and every guard —
is `references/worktree-wave-execution.md`. Follow it exactly; its MUSTs
are load-bearing.

Review packages are per task branch: the range `wave-base..task-head`.
SDD's own review-package assembly cannot take a pathspec and lives in a
plugin cache overwritten on update, so use the repo's review-package
script where one exists — with an explicit per-task output path (a
range-keyed default silently collides between tasks sharing a base), the
task's `File scope:`, and its commits — otherwise assemble the diff with
`git diff` over the range. Either way, check each task's commits against
its declared scope: append any overflow to the package so it still gets
reviewed, and surface the violation to the controller rather than
silently reading past it.

**Thrash detection.** Lock-wait build output or repeated no-progress
timeouts are a scheduling fault, not a task fault: stop the affected
tasks, re-serialize or isolate the contended resource, and record it in
the ledger — never let the loop tick for hours against a lock.

Reading the ledger under waves: lines are keyed `Task <N>:`, so filter by
task ID **before** taking "the last line." Sequentially, the file's last
Expand Down
Loading
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length \u003e 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

feat: worktree-per-task wave execution#1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
daniellam258 merged 2 commits into from
Aug 10, 2026
Merged

feat: worktree-per-task wave execution #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c60e932
feat: worktree-per-task wave execution
daniellam258 Aug 10, 2026
2e055f7
feat: wave binding duties in vendor template
daniellam258 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions skills/delivery-handoff/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-handoff
description: This skill should be used when the user asks for "a handoff prompt", "a prompt for codex/grok/claude", "something I can paste into another agent", or wants to continue tracked work in a different tool — and at any phase boundary of the cmk:delivery-pipeline skill when the operator prefers a different agent for the next phase.
version: 0.1.0
version: 0.2.0
---

# Delivery Handoff
Expand DownExpand Up@@ -69,7 +69,12 @@ freely; completeness matters, sections don't):
2. **Workspace** — absolute worktree path, branch, base branch (= future
PR base), the verify-before-touching commands, and the same-worktree
rule. For clusters: the issue → worktree/branch/base table plus where
the orchestration plan lives and which wave is active.
the orchestration plan lives and which wave is active. For a handoff
mid-way through a phase-3 wave, additionally enumerate every live task
worktree — path, task branch, wave-base SHA, and join state (pending /
integrated / escalated), from the wave manifest in the ledger — and
state that task worktrees follow the wave protocol's retention rules,
never ad-hoc cleanup.
3. **Read first** — ordered absolute paths: the phase skill(s) to follow,
the tracking contract (`cmk:delivery-workflow`), the context-efficiency
reference, the receiver's runtime binding
Expand Down
4 changes: 2 additions & 2 deletions skills/delivery-pipeline/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-pipeline
description: This skill should be used when the user asks to "work on", "deliver", "tackle", "pick up", or "implement" a tracker issue (TICKET-123), a list of issues, or a body of tracked work expected to finish without supervision — even if they never say "pipeline". Also use when handed a cluster of related issues, or a single issue whose surrounding cluster should be derived from tracker dependencies, expecting dependency-aware sequencing across worktrees.
version: 0.1.0
version: 0.2.0
---

# Delivery Pipeline
Expand DownExpand Up@@ -79,7 +79,7 @@ reads this instead of rediscovering it — keep it to those four things.
| Phase | Skill / engine | CMK adds |
|---|---|---|
| 1. Intake | `cmk:delivery-intake` | all of it — the tracker has no superpowers equivalent |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, and binding obligations inside each task body |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, `Exclusive resources:`, and binding obligations inside each task body |
| 3. Implement | `superpowers:subagent-driven-development` (below) | wave dispatch and its safety fixes |
| 4. Review | `cmk:delivery-review` | lenses, evidence bar, adversarial verification, disposition, depth disclosure |
| 5. Ship | `cmk:delivery-ship` | PR, tracker reconciliation, evidence |
Expand Down
57 changes: 33 additions & 24 deletions skills/delivery-pipeline/references/phase-3-execution.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -22,30 +22,39 @@ own model and effort; its "REQUIRED" caution exists for a stock agent that
declares neither. The role also requires the worker to report each commit
SHA, which is what the scope check below consumes.

CMK changes exactly one thing: **independent tasks run in the same wave.**
SDD serializes implementers because concurrent commits contaminate its
`BASE..HEAD` review packages — not merely because of file conflicts. Tasks
with no `Depends on:` and disjoint `File scope:` may be dispatched together
once three things hold:

1. **Review packages are path-scoped.** SDD's own review-package assembly
cannot take a pathspec and lives in a plugin cache that is overwritten
on update, so use a path-scoped review-package script the repo may
provide — appending `-- <File scope>` to the same commit range —
otherwise assemble the diff with `git diff` scoped to the task's file
list.
2. **Each package has its own output path.** A commit-range-only filename
is keyed by BASE and HEAD alone, so two tasks in one wave sharing a
range resolve to the *same file* and one silently overwrites the other.
Give each its own name, e.g. `review-task-<N>-<base7>..<head7>.diff`.
3. **Commits are checked against the declared scope.** A path-scoped diff
hides edits made outside that scope, so they would ship unreviewed.
Compare each task's actual commits against its `File scope:`; append
any overflow to the package so it still gets reviewed, and surface the
violation to the controller rather than silently reading past it.

Disjoint scopes make independence *checkable*, not guaranteed. Never
describe it as proven.
CMK changes exactly one thing: **independent tasks run in the same wave,
each in its own worktree.** SDD serializes implementers for two reasons,
and per-task worktrees remove both: concurrent commits contaminate a
shared branch's `BASE..HEAD` review packages, and a shared mutable build
root — one Cargo `target/` and its exclusive lock — serializes
"independent" tasks into lock-thrash where every worker turn blocks and
nothing progresses.

Wave eligibility: no `Depends on:`, disjoint `File scope:`, and no
intersecting `Exclusive resources:`. Disjoint scopes make independence
*checkable*, not guaranteed — never describe it as proven.

The dispatch, join, reconciliation, and cleanup protocol — parent-WIP
snapshot commits, pinned wave base, per-task branches, cache seeding,
rebase-then-ff-only integration, retention on failure, and every guard —
is `references/worktree-wave-execution.md`. Follow it exactly; its MUSTs
are load-bearing.

Review packages are per task branch: the range `wave-base..task-head`.
SDD's own review-package assembly cannot take a pathspec and lives in a
plugin cache overwritten on update, so use the repo's review-package
script where one exists — with an explicit per-task output path (a
range-keyed default silently collides between tasks sharing a base), the
task's `File scope:`, and its commits — otherwise assemble the diff with
`git diff` over the range. Either way, check each task's commits against
its declared scope: append any overflow to the package so it still gets
reviewed, and surface the violation to the controller rather than
silently reading past it.

**Thrash detection.** Lock-wait build output or repeated no-progress
timeouts are a scheduling fault, not a task fault: stop the affected
tasks, re-serialize or isolate the contended resource, and record it in
the ledger — never let the loop tick for hours against a lock.

Reading the ledger under waves: lines are keyed `Task <N>:`, so filter by
task ID **before** taking "the last line." Sequentially, the file's last
Expand Down
Loading
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

feat: worktree-per-task wave execution#1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
daniellam258 merged 2 commits into from
Aug 10, 2026
Merged

feat: worktree-per-task wave execution #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c60e932
feat: worktree-per-task wave execution
daniellam258 Aug 10, 2026
2e055f7
feat: wave binding duties in vendor template
daniellam258 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions skills/delivery-handoff/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-handoff
description: This skill should be used when the user asks for "a handoff prompt", "a prompt for codex/grok/claude", "something I can paste into another agent", or wants to continue tracked work in a different tool — and at any phase boundary of the cmk:delivery-pipeline skill when the operator prefers a different agent for the next phase.
version: 0.1.0
version: 0.2.0
---

# Delivery Handoff
Expand DownExpand Up@@ -69,7 +69,12 @@ freely; completeness matters, sections don't):
2. **Workspace** — absolute worktree path, branch, base branch (= future
PR base), the verify-before-touching commands, and the same-worktree
rule. For clusters: the issue → worktree/branch/base table plus where
the orchestration plan lives and which wave is active.
the orchestration plan lives and which wave is active. For a handoff
mid-way through a phase-3 wave, additionally enumerate every live task
worktree — path, task branch, wave-base SHA, and join state (pending /
integrated / escalated), from the wave manifest in the ledger — and
state that task worktrees follow the wave protocol's retention rules,
never ad-hoc cleanup.
3. **Read first** — ordered absolute paths: the phase skill(s) to follow,
the tracking contract (`cmk:delivery-workflow`), the context-efficiency
reference, the receiver's runtime binding
Expand Down
4 changes: 2 additions & 2 deletions skills/delivery-pipeline/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-pipeline
description: This skill should be used when the user asks to "work on", "deliver", "tackle", "pick up", or "implement" a tracker issue (TICKET-123), a list of issues, or a body of tracked work expected to finish without supervision — even if they never say "pipeline". Also use when handed a cluster of related issues, or a single issue whose surrounding cluster should be derived from tracker dependencies, expecting dependency-aware sequencing across worktrees.
version: 0.1.0
version: 0.2.0
---

# Delivery Pipeline
Expand DownExpand Up@@ -79,7 +79,7 @@ reads this instead of rediscovering it — keep it to those four things.
| Phase | Skill / engine | CMK adds |
|---|---|---|
| 1. Intake | `cmk:delivery-intake` | all of it — the tracker has no superpowers equivalent |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, and binding obligations inside each task body |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, `Exclusive resources:`, and binding obligations inside each task body |
| 3. Implement | `superpowers:subagent-driven-development` (below) | wave dispatch and its safety fixes |
| 4. Review | `cmk:delivery-review` | lenses, evidence bar, adversarial verification, disposition, depth disclosure |
| 5. Ship | `cmk:delivery-ship` | PR, tracker reconciliation, evidence |
Expand Down
57 changes: 33 additions & 24 deletions skills/delivery-pipeline/references/phase-3-execution.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -22,30 +22,39 @@ own model and effort; its "REQUIRED" caution exists for a stock agent that
declares neither. The role also requires the worker to report each commit
SHA, which is what the scope check below consumes.

CMK changes exactly one thing: **independent tasks run in the same wave.**
SDD serializes implementers because concurrent commits contaminate its
`BASE..HEAD` review packages — not merely because of file conflicts. Tasks
with no `Depends on:` and disjoint `File scope:` may be dispatched together
once three things hold:

1. **Review packages are path-scoped.** SDD's own review-package assembly
cannot take a pathspec and lives in a plugin cache that is overwritten
on update, so use a path-scoped review-package script the repo may
provide — appending `-- <File scope>` to the same commit range —
otherwise assemble the diff with `git diff` scoped to the task's file
list.
2. **Each package has its own output path.** A commit-range-only filename
is keyed by BASE and HEAD alone, so two tasks in one wave sharing a
range resolve to the *same file* and one silently overwrites the other.
Give each its own name, e.g. `review-task-<N>-<base7>..<head7>.diff`.
3. **Commits are checked against the declared scope.** A path-scoped diff
hides edits made outside that scope, so they would ship unreviewed.
Compare each task's actual commits against its `File scope:`; append
any overflow to the package so it still gets reviewed, and surface the
violation to the controller rather than silently reading past it.

Disjoint scopes make independence *checkable*, not guaranteed. Never
describe it as proven.
CMK changes exactly one thing: **independent tasks run in the same wave,
each in its own worktree.** SDD serializes implementers for two reasons,
and per-task worktrees remove both: concurrent commits contaminate a
shared branch's `BASE..HEAD` review packages, and a shared mutable build
root — one Cargo `target/` and its exclusive lock — serializes
"independent" tasks into lock-thrash where every worker turn blocks and
nothing progresses.

Wave eligibility: no `Depends on:`, disjoint `File scope:`, and no
intersecting `Exclusive resources:`. Disjoint scopes make independence
*checkable*, not guaranteed — never describe it as proven.

The dispatch, join, reconciliation, and cleanup protocol — parent-WIP
snapshot commits, pinned wave base, per-task branches, cache seeding,
rebase-then-ff-only integration, retention on failure, and every guard —
is `references/worktree-wave-execution.md`. Follow it exactly; its MUSTs
are load-bearing.

Review packages are per task branch: the range `wave-base..task-head`.
SDD's own review-package assembly cannot take a pathspec and lives in a
plugin cache overwritten on update, so use the repo's review-package
script where one exists — with an explicit per-task output path (a
range-keyed default silently collides between tasks sharing a base), the
task's `File scope:`, and its commits — otherwise assemble the diff with
`git diff` over the range. Either way, check each task's commits against
its declared scope: append any overflow to the package so it still gets
reviewed, and surface the violation to the controller rather than
silently reading past it.

**Thrash detection.** Lock-wait build output or repeated no-progress
timeouts are a scheduling fault, not a task fault: stop the affected
tasks, re-serialize or isolate the contended resource, and record it in
the ledger — never let the loop tick for hours against a lock.

Reading the ledger under waves: lines are keyed `Task <N>:`, so filter by
task ID **before** taking "the last line." Sequentially, the file's last
Expand Down
Loading
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

feat: worktree-per-task wave execution#1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
daniellam258 merged 2 commits into from
Aug 10, 2026
Merged

feat: worktree-per-task wave execution #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c60e932
feat: worktree-per-task wave execution
daniellam258 Aug 10, 2026
2e055f7
feat: wave binding duties in vendor template
daniellam258 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions skills/delivery-handoff/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-handoff
description: This skill should be used when the user asks for "a handoff prompt", "a prompt for codex/grok/claude", "something I can paste into another agent", or wants to continue tracked work in a different tool — and at any phase boundary of the cmk:delivery-pipeline skill when the operator prefers a different agent for the next phase.
version: 0.1.0
version: 0.2.0
---

# Delivery Handoff
Expand DownExpand Up@@ -69,7 +69,12 @@ freely; completeness matters, sections don't):
2. **Workspace** — absolute worktree path, branch, base branch (= future
PR base), the verify-before-touching commands, and the same-worktree
rule. For clusters: the issue → worktree/branch/base table plus where
the orchestration plan lives and which wave is active.
the orchestration plan lives and which wave is active. For a handoff
mid-way through a phase-3 wave, additionally enumerate every live task
worktree — path, task branch, wave-base SHA, and join state (pending /
integrated / escalated), from the wave manifest in the ledger — and
state that task worktrees follow the wave protocol's retention rules,
never ad-hoc cleanup.
3. **Read first** — ordered absolute paths: the phase skill(s) to follow,
the tracking contract (`cmk:delivery-workflow`), the context-efficiency
reference, the receiver's runtime binding
Expand Down
4 changes: 2 additions & 2 deletions skills/delivery-pipeline/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-pipeline
description: This skill should be used when the user asks to "work on", "deliver", "tackle", "pick up", or "implement" a tracker issue (TICKET-123), a list of issues, or a body of tracked work expected to finish without supervision — even if they never say "pipeline". Also use when handed a cluster of related issues, or a single issue whose surrounding cluster should be derived from tracker dependencies, expecting dependency-aware sequencing across worktrees.
version: 0.1.0
version: 0.2.0
---

# Delivery Pipeline
Expand DownExpand Up@@ -79,7 +79,7 @@ reads this instead of rediscovering it — keep it to those four things.
| Phase | Skill / engine | CMK adds |
|---|---|---|
| 1. Intake | `cmk:delivery-intake` | all of it — the tracker has no superpowers equivalent |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, and binding obligations inside each task body |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, `Exclusive resources:`, and binding obligations inside each task body |
| 3. Implement | `superpowers:subagent-driven-development` (below) | wave dispatch and its safety fixes |
| 4. Review | `cmk:delivery-review` | lenses, evidence bar, adversarial verification, disposition, depth disclosure |
| 5. Ship | `cmk:delivery-ship` | PR, tracker reconciliation, evidence |
Expand Down
57 changes: 33 additions & 24 deletions skills/delivery-pipeline/references/phase-3-execution.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -22,30 +22,39 @@ own model and effort; its "REQUIRED" caution exists for a stock agent that
declares neither. The role also requires the worker to report each commit
SHA, which is what the scope check below consumes.

CMK changes exactly one thing: **independent tasks run in the same wave.**
SDD serializes implementers because concurrent commits contaminate its
`BASE..HEAD` review packages — not merely because of file conflicts. Tasks
with no `Depends on:` and disjoint `File scope:` may be dispatched together
once three things hold:

1. **Review packages are path-scoped.** SDD's own review-package assembly
cannot take a pathspec and lives in a plugin cache that is overwritten
on update, so use a path-scoped review-package script the repo may
provide — appending `-- <File scope>` to the same commit range —
otherwise assemble the diff with `git diff` scoped to the task's file
list.
2. **Each package has its own output path.** A commit-range-only filename
is keyed by BASE and HEAD alone, so two tasks in one wave sharing a
range resolve to the *same file* and one silently overwrites the other.
Give each its own name, e.g. `review-task-<N>-<base7>..<head7>.diff`.
3. **Commits are checked against the declared scope.** A path-scoped diff
hides edits made outside that scope, so they would ship unreviewed.
Compare each task's actual commits against its `File scope:`; append
any overflow to the package so it still gets reviewed, and surface the
violation to the controller rather than silently reading past it.

Disjoint scopes make independence *checkable*, not guaranteed. Never
describe it as proven.
CMK changes exactly one thing: **independent tasks run in the same wave,
each in its own worktree.** SDD serializes implementers for two reasons,
and per-task worktrees remove both: concurrent commits contaminate a
shared branch's `BASE..HEAD` review packages, and a shared mutable build
root — one Cargo `target/` and its exclusive lock — serializes
"independent" tasks into lock-thrash where every worker turn blocks and
nothing progresses.

Wave eligibility: no `Depends on:`, disjoint `File scope:`, and no
intersecting `Exclusive resources:`. Disjoint scopes make independence
*checkable*, not guaranteed — never describe it as proven.

The dispatch, join, reconciliation, and cleanup protocol — parent-WIP
snapshot commits, pinned wave base, per-task branches, cache seeding,
rebase-then-ff-only integration, retention on failure, and every guard —
is `references/worktree-wave-execution.md`. Follow it exactly; its MUSTs
are load-bearing.

Review packages are per task branch: the range `wave-base..task-head`.
SDD's own review-package assembly cannot take a pathspec and lives in a
plugin cache overwritten on update, so use the repo's review-package
script where one exists — with an explicit per-task output path (a
range-keyed default silently collides between tasks sharing a base), the
task's `File scope:`, and its commits — otherwise assemble the diff with
`git diff` over the range. Either way, check each task's commits against
its declared scope: append any overflow to the package so it still gets
reviewed, and surface the violation to the controller rather than
silently reading past it.

**Thrash detection.** Lock-wait build output or repeated no-progress
timeouts are a scheduling fault, not a task fault: stop the affected
tasks, re-serialize or isolate the contended resource, and record it in
the ledger — never let the loop tick for hours against a lock.

Reading the ledger under waves: lines are keyed `Task <N>:`, so filter by
task ID **before** taking "the last line." Sequentially, the file's last
Expand Down
Loading
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

feat: worktree-per-task wave execution#1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
daniellam258 merged 2 commits into from
Aug 10, 2026
Merged

feat: worktree-per-task wave execution #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c60e932
feat: worktree-per-task wave execution
daniellam258 Aug 10, 2026
2e055f7
feat: wave binding duties in vendor template
daniellam258 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions skills/delivery-handoff/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-handoff
description: This skill should be used when the user asks for "a handoff prompt", "a prompt for codex/grok/claude", "something I can paste into another agent", or wants to continue tracked work in a different tool — and at any phase boundary of the cmk:delivery-pipeline skill when the operator prefers a different agent for the next phase.
version: 0.1.0
version: 0.2.0
---

# Delivery Handoff
Expand DownExpand Up@@ -69,7 +69,12 @@ freely; completeness matters, sections don't):
2. **Workspace** — absolute worktree path, branch, base branch (= future
PR base), the verify-before-touching commands, and the same-worktree
rule. For clusters: the issue → worktree/branch/base table plus where
the orchestration plan lives and which wave is active.
the orchestration plan lives and which wave is active. For a handoff
mid-way through a phase-3 wave, additionally enumerate every live task
worktree — path, task branch, wave-base SHA, and join state (pending /
integrated / escalated), from the wave manifest in the ledger — and
state that task worktrees follow the wave protocol's retention rules,
never ad-hoc cleanup.
3. **Read first** — ordered absolute paths: the phase skill(s) to follow,
the tracking contract (`cmk:delivery-workflow`), the context-efficiency
reference, the receiver's runtime binding
Expand Down
4 changes: 2 additions & 2 deletions skills/delivery-pipeline/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-pipeline
description: This skill should be used when the user asks to "work on", "deliver", "tackle", "pick up", or "implement" a tracker issue (TICKET-123), a list of issues, or a body of tracked work expected to finish without supervision — even if they never say "pipeline". Also use when handed a cluster of related issues, or a single issue whose surrounding cluster should be derived from tracker dependencies, expecting dependency-aware sequencing across worktrees.
version: 0.1.0
version: 0.2.0
---

# Delivery Pipeline
Expand DownExpand Up@@ -79,7 +79,7 @@ reads this instead of rediscovering it — keep it to those four things.
| Phase | Skill / engine | CMK adds |
|---|---|---|
| 1. Intake | `cmk:delivery-intake` | all of it — the tracker has no superpowers equivalent |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, and binding obligations inside each task body |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, `Exclusive resources:`, and binding obligations inside each task body |
| 3. Implement | `superpowers:subagent-driven-development` (below) | wave dispatch and its safety fixes |
| 4. Review | `cmk:delivery-review` | lenses, evidence bar, adversarial verification, disposition, depth disclosure |
| 5. Ship | `cmk:delivery-ship` | PR, tracker reconciliation, evidence |
Expand Down
57 changes: 33 additions & 24 deletions skills/delivery-pipeline/references/phase-3-execution.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -22,30 +22,39 @@ own model and effort; its "REQUIRED" caution exists for a stock agent that
declares neither. The role also requires the worker to report each commit
SHA, which is what the scope check below consumes.

CMK changes exactly one thing: **independent tasks run in the same wave.**
SDD serializes implementers because concurrent commits contaminate its
`BASE..HEAD` review packages — not merely because of file conflicts. Tasks
with no `Depends on:` and disjoint `File scope:` may be dispatched together
once three things hold:

1. **Review packages are path-scoped.** SDD's own review-package assembly
cannot take a pathspec and lives in a plugin cache that is overwritten
on update, so use a path-scoped review-package script the repo may
provide — appending `-- <File scope>` to the same commit range —
otherwise assemble the diff with `git diff` scoped to the task's file
list.
2. **Each package has its own output path.** A commit-range-only filename
is keyed by BASE and HEAD alone, so two tasks in one wave sharing a
range resolve to the *same file* and one silently overwrites the other.
Give each its own name, e.g. `review-task-<N>-<base7>..<head7>.diff`.
3. **Commits are checked against the declared scope.** A path-scoped diff
hides edits made outside that scope, so they would ship unreviewed.
Compare each task's actual commits against its `File scope:`; append
any overflow to the package so it still gets reviewed, and surface the
violation to the controller rather than silently reading past it.

Disjoint scopes make independence *checkable*, not guaranteed. Never
describe it as proven.
CMK changes exactly one thing: **independent tasks run in the same wave,
each in its own worktree.** SDD serializes implementers for two reasons,
and per-task worktrees remove both: concurrent commits contaminate a
shared branch's `BASE..HEAD` review packages, and a shared mutable build
root — one Cargo `target/` and its exclusive lock — serializes
"independent" tasks into lock-thrash where every worker turn blocks and
nothing progresses.

Wave eligibility: no `Depends on:`, disjoint `File scope:`, and no
intersecting `Exclusive resources:`. Disjoint scopes make independence
*checkable*, not guaranteed — never describe it as proven.

The dispatch, join, reconciliation, and cleanup protocol — parent-WIP
snapshot commits, pinned wave base, per-task branches, cache seeding,
rebase-then-ff-only integration, retention on failure, and every guard —
is `references/worktree-wave-execution.md`. Follow it exactly; its MUSTs
are load-bearing.

Review packages are per task branch: the range `wave-base..task-head`.
SDD's own review-package assembly cannot take a pathspec and lives in a
plugin cache overwritten on update, so use the repo's review-package
script where one exists — with an explicit per-task output path (a
range-keyed default silently collides between tasks sharing a base), the
task's `File scope:`, and its commits — otherwise assemble the diff with
`git diff` over the range. Either way, check each task's commits against
its declared scope: append any overflow to the package so it still gets
reviewed, and surface the violation to the controller rather than
silently reading past it.

**Thrash detection.** Lock-wait build output or repeated no-progress
timeouts are a scheduling fault, not a task fault: stop the affected
tasks, re-serialize or isolate the contended resource, and record it in
the ledger — never let the loop tick for hours against a lock.

Reading the ledger under waves: lines are keyed `Task <N>:`, so filter by
task ID **before** taking "the last line." Sequentially, the file's last
Expand Down
Loading
Loading
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

feat: worktree-per-task wave execution#1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
daniellam258 merged 2 commits into from
Aug 10, 2026
Merged

feat: worktree-per-task wave execution #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c60e932
feat: worktree-per-task wave execution
daniellam258 Aug 10, 2026
2e055f7
feat: wave binding duties in vendor template
daniellam258 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions skills/delivery-handoff/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-handoff
description: This skill should be used when the user asks for "a handoff prompt", "a prompt for codex/grok/claude", "something I can paste into another agent", or wants to continue tracked work in a different tool — and at any phase boundary of the cmk:delivery-pipeline skill when the operator prefers a different agent for the next phase.
version: 0.1.0
version: 0.2.0
---

# Delivery Handoff
Expand DownExpand Up@@ -69,7 +69,12 @@ freely; completeness matters, sections don't):
2. **Workspace** — absolute worktree path, branch, base branch (= future
PR base), the verify-before-touching commands, and the same-worktree
rule. For clusters: the issue → worktree/branch/base table plus where
the orchestration plan lives and which wave is active.
the orchestration plan lives and which wave is active. For a handoff
mid-way through a phase-3 wave, additionally enumerate every live task
worktree — path, task branch, wave-base SHA, and join state (pending /
integrated / escalated), from the wave manifest in the ledger — and
state that task worktrees follow the wave protocol's retention rules,
never ad-hoc cleanup.
3. **Read first** — ordered absolute paths: the phase skill(s) to follow,
the tracking contract (`cmk:delivery-workflow`), the context-efficiency
reference, the receiver's runtime binding
Expand Down
4 changes: 2 additions & 2 deletions skills/delivery-pipeline/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
---
name: cmk:delivery-pipeline
description: This skill should be used when the user asks to "work on", "deliver", "tackle", "pick up", or "implement" a tracker issue (TICKET-123), a list of issues, or a body of tracked work expected to finish without supervision — even if they never say "pipeline". Also use when handed a cluster of related issues, or a single issue whose surrounding cluster should be derived from tracker dependencies, expecting dependency-aware sequencing across worktrees.
version: 0.1.0
version: 0.2.0
---

# Delivery Pipeline
Expand DownExpand Up@@ -79,7 +79,7 @@ reads this instead of rediscovering it — keep it to those four things.
| Phase | Skill / engine | CMK adds |
|---|---|---|
| 1. Intake | `cmk:delivery-intake` | all of it — the tracker has no superpowers equivalent |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, and binding obligations inside each task body |
| 2. Spec & plan | `cmk:delivery-spec-plan`, via `superpowers:brainstorming` + `superpowers:writing-plans` | design-doc inputs; `Depends on:`, `File scope:`, `Exclusive resources:`, and binding obligations inside each task body |
| 3. Implement | `superpowers:subagent-driven-development` (below) | wave dispatch and its safety fixes |
| 4. Review | `cmk:delivery-review` | lenses, evidence bar, adversarial verification, disposition, depth disclosure |
| 5. Ship | `cmk:delivery-ship` | PR, tracker reconciliation, evidence |
Expand Down
57 changes: 33 additions & 24 deletions skills/delivery-pipeline/references/phase-3-execution.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -22,30 +22,39 @@ own model and effort; its "REQUIRED" caution exists for a stock agent that
declares neither. The role also requires the worker to report each commit
SHA, which is what the scope check below consumes.

CMK changes exactly one thing: **independent tasks run in the same wave.**
SDD serializes implementers because concurrent commits contaminate its
`BASE..HEAD` review packages — not merely because of file conflicts. Tasks
with no `Depends on:` and disjoint `File scope:` may be dispatched together
once three things hold:

1. **Review packages are path-scoped.** SDD's own review-package assembly
cannot take a pathspec and lives in a plugin cache that is overwritten
on update, so use a path-scoped review-package script the repo may
provide — appending `-- <File scope>` to the same commit range —
otherwise assemble the diff with `git diff` scoped to the task's file
list.
2. **Each package has its own output path.** A commit-range-only filename
is keyed by BASE and HEAD alone, so two tasks in one wave sharing a
range resolve to the *same file* and one silently overwrites the other.
Give each its own name, e.g. `review-task-<N>-<base7>..<head7>.diff`.
3. **Commits are checked against the declared scope.** A path-scoped diff
hides edits made outside that scope, so they would ship unreviewed.
Compare each task's actual commits against its `File scope:`; append
any overflow to the package so it still gets reviewed, and surface the
violation to the controller rather than silently reading past it.

Disjoint scopes make independence *checkable*, not guaranteed. Never
describe it as proven.
CMK changes exactly one thing: **independent tasks run in the same wave,
each in its own worktree.** SDD serializes implementers for two reasons,
and per-task worktrees remove both: concurrent commits contaminate a
shared branch's `BASE..HEAD` review packages, and a shared mutable build
root — one Cargo `target/` and its exclusive lock — serializes
"independent" tasks into lock-thrash where every worker turn blocks and
nothing progresses.

Wave eligibility: no `Depends on:`, disjoint `File scope:`, and no
intersecting `Exclusive resources:`. Disjoint scopes make independence
*checkable*, not guaranteed — never describe it as proven.

The dispatch, join, reconciliation, and cleanup protocol — parent-WIP
snapshot commits, pinned wave base, per-task branches, cache seeding,
rebase-then-ff-only integration, retention on failure, and every guard —
is `references/worktree-wave-execution.md`. Follow it exactly; its MUSTs
are load-bearing.

Review packages are per task branch: the range `wave-base..task-head`.
SDD's own review-package assembly cannot take a pathspec and lives in a
plugin cache overwritten on update, so use the repo's review-package
script where one exists — with an explicit per-task output path (a
range-keyed default silently collides between tasks sharing a base), the
task's `File scope:`, and its commits — otherwise assemble the diff with
`git diff` over the range. Either way, check each task's commits against
its declared scope: append any overflow to the package so it still gets
reviewed, and surface the violation to the controller rather than
silently reading past it.

**Thrash detection.** Lock-wait build output or repeated no-progress
timeouts are a scheduling fault, not a task fault: stop the affected
tasks, re-serialize or isolate the contended resource, and record it in
the ledger — never let the loop tick for hours against a lock.

Reading the ledger under waves: lines are keyed `Task <N>:`, so filter by
task ID **before** taking "the last line." Sequentially, the file's last
Expand Down
Loading
Loading