ed/manual_slop
Private
Public Access
0
0
Fork 0
Code Activity

conductor(track): superpowers review section 8 — executing-plans (medium)

Browse Source
This commit is contained in:
Edward R. Gonzalez
2026-07-05 13:22:06 -04:00
parent 424d0444d0
commit 2ef7f4d643
1 changed files with 66 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
conductor/tracks/superpowers_review_20260619/report.md
+66 -1
View File
@@ -459,7 +459,72 @@ The project follows the subagent-driven-development discipline with significant
## 8. Executing Plans
<!-- Section 8 medium (100-250 LOC). Skill: executing-plans. Verdict pending. -->
## 8. Executing Plans
### 8.1 What the skill prescribes
The `executing-plans` skill is the simpler counterpart to `subagent-driven-development` for "separate session with review checkpoints" execution. The 3-step Process is:
1. **Load and Review Plan** — Read plan file; review critically (identify any questions or concerns); if concerns, raise them with the human partner before starting; if no concerns, create TodoWrite and proceed.
2. **Execute Tasks** — For each task: mark as in_progress; follow each step exactly (plan has bite-sized steps); run verifications as specified; mark as completed.
3. **Complete Development** — Announce "I'm using the finishing-a-development-branch skill to complete this work"; REQUIRED SUB-SKILL: use superpowers:finishing-a-development-branch; follow that skill to verify tests, present options, execute choice.
The "When to Stop and Ask for Help" list: hit a blocker (missing dependency, test fails, instruction unclear); plan has critical gaps preventing starting; don't understand an instruction; verification fails repeatedly. The skill says "Ask for clarification rather than guessing."
The "When to Revisit Earlier Steps" list: partner updates the plan based on your feedback; fundamental approach needs rethinking. The skill says "Don't force through blockers - stop and ask."
The skill's most important meta-rule: "Never start implementation on main/master branch without explicit user consent."
### 8.2 Mapping to the project's existing pattern
The project's tier-1 orchestrator uses this pattern when initializing a new track (per `conductor/workflow.md` §"Planning Session Workflow"). The skill is also implicitly used by tier-2 tech-leads when picking up an approved plan.
| Skill rule | Project equivalent | Where |
|---|---|---|
| "Step 1: Load and Review Plan" | `conductor/workflow.md` §"Planning Session Workflow" steps 1-7 (Explore → Ask clarifying questions → Propose approaches → Write spec → User reviews spec → Write plan → User reviews plan) | `conductor/workflow.md` |
| "Review critically — identify any questions or concerns about the plan" | Tier-1 Track Initialization Rules §"Audit Before Specifying": "NEVER write a spec without first reading actual code using MCP tools" | `conductor/workflow.md` §"Tier 1 Track Initialization Rules" |
| "If concerns: Raise them with your human partner before starting" | Tier-1 spec is approved by the user before the plan is written (per the Planning Session Workflow) | `conductor/workflow.md` §"Planning Session Workflow" |
| "If no concerns: Create TodoWrite and proceed" | Every plan.md has the per-task structure that the implementing agent follows | `conductor/workflow.md` §"Task Workflow" |
| "Step 2: Execute Tasks — mark as in_progress" | "Mark In Progress: Before beginning work, edit `plan.md` and change the task from `[ ]` to `[~]`" | `conductor/workflow.md` §"Task Workflow" step 2 |
| "Follow each step exactly (plan has bite-sized steps)" | Tier-1 Track Initialization Rules §1 "Spec format" + §4 "Plan format" — bite-sized steps are mandatory | `conductor/workflow.md` |
| "Run verifications as specified" | The Phase Completion Verification and Checkpointing Protocol: automated tests + API hooks + user confirmation | `conductor/workflow.md` |
| "Mark as completed" | "Step 10.1: Update Plan: Read `plan.md`, find the line for the completed task, update its status from `[~]` to `[x]`, and append the first 7 characters of the *just-completed commit's* commit hash." | `conductor/workflow.md` §"Task Workflow" step 10 |
| "Step 3: Complete Development — REQUIRED SUB-SKILL: use superpowers:finishing-a-development-branch" | The project's `conductor/workflow.md` doesn't have a `finishing-a-development-branch` equivalent; the closest is "10. Finalize" in the track's plan.md (Phase 10: register in tracks.md + update metadata.json with final statistics) | `conductor/tracks/<id>/plan.md` Phase 10 |
| "When to Stop and Ask for Help" (4 stop conditions) | The project has the Per-Task Decision Protocol with 3 escalation levels: cosmetic → decide yourself; architectural → STOP and report to Tier 2; regression → STOP and report | `conductor/workflow.md` §"Per-Task Decision Protocol" |
| "When to Revisit Earlier Steps" (2 revisit conditions) | The "Inherited-Cruft Pattern (kill it)" rule: if the file is broken, ASK the user before fixing (revisit earlier steps in spirit) | `AGENTS.md` §"Process Anti-Patterns" §4 |
| "Never start implementation on main/master branch without explicit user consent" | `conductor/workflow.md` does NOT have an explicit "don't start on master" rule; the user's session opens on master and tracks are committed to master. The "tier2-autonomous-sandbox" track has its own branch-protection rules (per `conductor/tier2/opencode.json.fragment`) | Partial |
### 8.3 Where the project already follows the discipline
- **The Planning Session Workflow is the tier-1 orchestrator's executing-plans process** — load spec, review critically (Tier 1 audit), ask clarifying questions, propose 2-3 approaches, write spec, user reviews, write plan, user reviews, commit spec + plan in separate commits.
- **The per-task workflow is the bite-sized execution pattern** — mark in_progress, follow step exactly, run verification, mark completed. The "Mark In Progress → Follow each step exactly → Mark Completed" cycle is the workflow.md §"Task Workflow" steps 2, 4-5, 10.
- **The Deduction Loop (per Section 6) is the project's "STOP and report" rule** for the "When to Stop and Ask for Help" condition. The project goes beyond the skill: it doesn't just stop, it has a structured "5 things to do before surrendering" list.
### 8.4 Where the project doesn't follow the discipline
- **No `finishing-a-development-branch` skill** — the project's Phase 10 finalize is a simpler artifact (update state.toml + tracks.md + metadata.json) rather than the skill's "verify tests, present options, execute choice" pattern. The user's "review the work, decide merge/squash/PR" is implicit in the per-commit user-review workflow.
- **"Never start implementation on main/master branch without explicit user consent"** — the project DOES work on master directly; there's no worktree or branch creation required for normal tracks. This is ARCH-DIFF: the project treats master as the working branch; the skill's rule doesn't apply. (The tier2-autonomous sandbox is the exception, with explicit branch-protection rules.)
- **No explicit "When to Revisit Earlier Steps" rule** — the project relies on the Inherited-Cruft Pattern (per Section 6) to catch the "fundamentals need rethinking" condition. The skill's "discuss with the human partner before attempting more fixes" is partially covered.
### 8.5 Recommendations summary
The project follows the executing-plans discipline with three deviations: no `finishing-a-development-branch` skill (Phase 10 is simpler); works on master directly (no worktree rule); revisit-conditions are implicit (Inherited-Cruft Pattern). The deferred rebuild may want to:
- **LOW:** Consider codifying a "finishing-a-development-branch" check in `conductor/workflow.md` (after Phase 10): "verify all tests pass, present merge/review options to user, execute choice." Currently Phase 10 is "register in tracks.md + update metadata" only.
- **LOW:** Consider the master-vs-worktree question. The user's working pattern is master-direct; the skill's recommendation is worktree. This is a user-driven choice; deferring to the deferred rebuild is appropriate.
**Verdict.**
| Field | Value |
|---|---|
| **Primary** | `PARITY` |
| **Integration tag** | `INTEGRATED` |
| **Section size** | medium |
| **Cross-refs** | nagent_review_20260608 §5 (the durable-work thesis shapes how plans are executed); fable_review_20260617 (the cluster-sub-agent dispatch pattern is one execution path); intent_dsl_survey_20260612 §6 (the project's execution discipline is one of its "AI-agent properties") |
**Rationale.** The project's Planning Session Workflow + Task Workflow is a faithful re-encoding of executing-plans. The skill's "Mark In Progress → Follow each step → Mark Completed" cycle is the workflow steps 2, 4-5, 10. The "When to Stop" condition is the Deduction Loop + Per-Task Decision Protocol. The "finishing-a-development-branch" skill is partially covered by Phase 10.
**Recommended change.** Codify a "finishing-a-development-branch" check in `conductor/workflow.md` after Phase 10; consider the master-vs-worktree question in the deferred rebuild.
## 9. Dispatching Parallel Agents