Slice Runner

Slice Runner

Run one milestone-aligned development slice from selection through merge. This skill coordinates the existing planner, implementor, and reviewer procedures in one strict workflow; it does not replace their rules.

Core Contract

Use this order:

1. Select or create exactly one normal Case.
2. Implement the Case on a feature branch.
3. Run local verification.
4. Trigger and require branch CI when available.
5. Review the change set.
6. Archive the Case, clean backlog, merge to main, and push.

Do not skip CI silently. Do not merge with failing local checks or failing branch CI unless the user explicitly authorizes a degraded merge after seeing the reason.

Intake

First determine the target repo and slice:

• If the user names a repo, work there.
• If the user names a Case, use that Case.
• If the user asks for the next slice, inspect agent_docs/plans/roadmap.md and agent_docs/plans/backlog.md; choose the top milestone-aligned slice.
• If multiple repos are plausible, use project-orchestrator guidance when available; otherwise compare roadmap current milestones directly.

Before creating a Case, inspect agent_docs/cases/CASE_*.md excluding completed_cases/.

• If no active Case exists, proceed.
• If one active Case exists, use it unless the user explicitly requested a different slice.
• If multiple normal Cases exist, stop and ask which one to run.
• Reviewer-created CASE_*-must-fix.md files are allowed alongside the original Case.

Planner Phase

Follow planner rules:

• Read repo agent_docs/README.md when present.
• Read roadmap, backlog, and tech debt log.
• Create a compact Case only if no suitable active Case exists.
• Ensure the Case includes Milestone.
• Put the selected slice in backlog.md Now if the repo uses that convention.
• Commit planner artifacts before implementation.

Commit message: planner: add <case-slug> next slice.

Implementation Phase

Follow implementor rules:

• Create/switch to branch case/<case-id> for normal Cases.
• Keep edits inside Case scope.
• Add or update focused tests for behavior changes.
• Update README only when user/developer-facing behavior changes.
• Run the focused verification named in the Case.
• Run lint/format checks when the repo has an established command.
• Commit implementation when checks pass.

Commit message: implement: <short outcome>.

CI Gate

After implementation is committed on the feature branch, trigger branch CI when repo scripts exist.

Preferred commands, from repo root:

/bin/bash scripts/ci_trigger_current_branch.sh
/bin/bash scripts/ci_watch_latest_branch_run.sh
/bin/bash scripts/ci_assert_latest_branch_green.sh

If the repo lacks these scripts, use the repo's documented branch CI command. If branch CI cannot run because of network, auth, missing workflow, or unavailable tooling:

• Report the exact command and failure.
• Do not merge unless the user explicitly accepts local-only verification.

Review And Merge Phase

Follow reviewer rules:

• Review git diff main...HEAD with a code-review mindset.
• If must-fix findings exist, create reviewer must-fix Cases and stop before merge.
• If no blockers exist, perform merge hygiene before merging:
  • Move the active Case into agent_docs/cases/completed_cases/.
  • Move completed CASE_*-must-fix.md files confirmed in the review loop.
  • Remove matching active-Case references from agent_docs/plans/backlog.md.
  • Update agent_docs/plans/tech_debt_log.md when debt is resolved or newly discovered.
  • Commit archival/backlog hygiene.
• Merge with git checkout main then git merge --no-ff <feature-branch>.
• Push main.

Use git pull --ff-only only when needed and approved by the user's workflow.

Required Final Report

Report:

• Repo, branch, Case path, and milestone.
• Commits created.
• Local verification commands and results.
• CI command/result or explicit reason CI was not run.
• Review outcome.
• Merge commit and push result.
• Residual risks or follow-ups.