원클릭으로
dev-pipeline-commit
TDD phase 5 — commit if tests pass and review confidence >= 7, write result.md summary. Used by dev-pipeline orchestrator.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
TDD phase 5 — commit if tests pass and review confidence >= 7, write result.md summary. Used by dev-pipeline orchestrator.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
TDD build phase — implement feature code from a plan spec without modifying tests. One round per invocation; orchestrator loops with run-tests.
TDD phase 2 — run the test suite and confirm correct red state (tests fail before implementation). Used by dev-pipeline orchestrator after write-tests.
TDD phase 4 — adversarial review of implementation against the plan spec. Returns confidence score 0-10. Used by dev-pipeline orchestrator.
Run the project test suite and return structured TestResult JSON. Used by dev-pipeline build loop and standalone test verification.
Orchestrates the TDD build pipeline: read plan → write tests → red check → build until green → review → commit. Launches phase subagents via Task. Use when building from plans/<feature>/plan.md, running dev-pipeline, or implementing a spec after dev-plan.
TDD phase 1 — write the full test suite from a plan spec before any implementation exists. Used by dev-pipeline orchestrator or standalone when writing tests from plans/*/plan.md Test contracts.
| name | dev-pipeline-commit |
| description | TDD phase 5 — commit if tests pass and review confidence >= 7, write result.md summary. Used by dev-pipeline orchestrator. |
| disable-model-invocation | true |
Commit if quality gates pass; always write the result summary.
plans/<feature>/plan.mdplans/<feature>/result.md (same folder as plan, replace plan.md → result.md){ test, error, file? }Commit only if:
testsPassed === true, andreviewConfidence >= 7Otherwise: report what is blocking. Do not commit.
When committing:
## Goal — concise, focus on whyAlways write resultPath with this structure (fill in Commit section honestly):
# Result: {specPath}
## Status
| | |
|---|---|
| Tests | ✓ PASS or ✗ FAIL (N remaining) |
| Build rounds | {buildRounds} |
| Review confidence | {reviewConfidence}/10 |
## Review notes
{reviewNotes}
## Remaining test failures
(only if failures exist — bullet list)
## Commit
(what you did: committed with message "…" / did not commit because …)
Report what you did: committed or blocked, and confirm resultPath was written.