step-commit
Discrete validated-step commit workflow for Code-Conductor. Use when capturing per-step validated work as structured commits. DO NOT USE FOR: deciding whether auto-commit is enabled or replacing the PR-time formatting gate.
- License 许可
- MIT
- 最近更新
- 2026-08-16
- Stars
- ★ 3
- Forks
- 0
01 前言 Front Matter
- name
- step-commit
- description
- Discrete validated-step commit workflow for Code-Conductor. Use when capturing per-step validated work as structured commits. DO NOT USE FOR: deciding whether auto-commit is enabled or replacing the PR-time formatting gate.
02 资源文件 2
- 参考文档platforms/claude.md246 B
- 参考文档platforms/copilot.md312 B
03 SKILL.md 正文
Step Commit Protocol
Purpose
This protocol captures validated step work as discrete commits during Code-Conductor's implementation loop. Each step commit records the pre-formatting validated state with structured metadata (plan reference, agent attribution, validation tier).
Code-Conductor loads this file by reference to keep its own directive count stable.
Protocol
Step 1 — Opt-out check
Code-Conductor's step commit gate checks auto_commit_enabled before loading this file — if opted out, this protocol is never loaded. This step is a documentation cross-reference only; no runtime check is needed here.
Step 2 — Branch safety
Verify the current branch is not a protected branch:
$branch = git branch --show-current
if ($branch -in 'main', 'develop', 'master') {
Write-Warning "On protected branch '$branch' — skipping step commit"
return
}
If on a protected branch, warn and skip — do not commit.
Step 3 — File capture
Use get_changed_files with filter sourceControlState: ['unstaged', 'staged'] to detect files with changes. The VS Code SCM model's 'unstaged' state covers both modified tracked files AND untracked/new files — no separate filter needed.
If no files are detected, skip the commit (nothing to commit).
Step 4 — Stage files
Stage files using the explicit file list from Step 3 — never use git add -A:
git add "file1.ext" "file2.ext" ...
Use the file list from Step 3's get_changed_files output. This avoids sweeping unrelated working-tree changes into the step commit.
Step 5 — Commit
Commit with the --no-verify flag (validated state — hooks are unnecessary overhead):
git commit --no-verify -m "step(N): {step-title}
Plan: issue-{ID}, Step N of M
Agents: {comma-separated agent list}
Validation: Tier 1 ✅"
Where:
N= current plan step number{step-title}= brief step title from the plan{ID}= issue numberM= total step count{agent list}= agents that worked on this step (e.g.,Code-Smith, Test-Writer)
Step 6 — SHA recording
After successful commit, record the commit SHA for informational purposes:
git rev-parse HEAD
The existing post-fix diff recipe git diff HEAD -- {files} remains correct — HEAD advances with each step commit, so at post-fix time only specialist fix changes appear as uncommitted.
Step 7 — Failure handling
Commit failure is non-blocking — the step's work is complete regardless.
On failure:
-
Warn in conversation output
-
Increment a consecutive-failure counter (tracked in conversation context)
-
Reset the counter to zero after any successful step commit.
-
If the consecutive-failure counter reaches ≥2, escalate to the user:
Step commits failing repeatedly — check hooks/git state. Continue without auto-commits?
(a) Disable auto-commits for remaining steps (set
auto_commit_enabledtofalse— Code-Conductor's step commit gate checks this flag before loading this protocol) (b) Investigate and retry -
Report failure status to Code-Conductor so the progress checkpoint annotates the step as
— ✅ DONE (uncommitted)rather than plain— ✅ DONE
Formatting Note
Formatting stays in Code-Conductor's Step 4 (Create PR) — step commits capture the pre-formatting validated state. The formatting gate runs at PR creation time (Step 4), not per step. Pre-commit hooks are bypassed during step commits via --no-verify.
Gotchas
| Trigger | Gotcha | Fix |
|---|---|---|
| Capturing a step commit | Broad staging picks up unrelated work and corrupts the validated snapshot | Stage only the explicit changed-file list returned by the SCM query |
Platform-specific invocation
This skill's methodology is tool-agnostic. Platform-specific routing lives alongside:
- Copilot: platforms/copilot.md
- Claude Code: platforms/claude.md
04 同仓库更多 Skills
webapp-testing
Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).
verification-before-completion
Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any "I'm finished" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).
validation-methodology
Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).
upstream-onboarding
Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.
ui-testing
Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).
ui-iteration
Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).