원클릭으로 Manus에서 모든 스킬 실행

tcr-kentbeck

스타2

포크0

업데이트2026년 3월 30일 20:53

Enforces Test && Commit || Revert (TCR): run tests after each micro-change, commit only on green, discard the change on red. ALWAYS trigger when the user mentions TCR, test-commit-revert, or wants strict incremental commits with no red states kept in the working tree or history. The agent makes tiny changes, runs the full test suite, and either commits on green or reverts everything on red — never accumulating broken code. Do NOT trigger for general TDD questions, test framework setup, CI pipelines, or code coverage — those do not need this skill.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

xpepper

xpepper/tcr-skill

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

TCR (Test && Commit || Revert)

Non-negotiables

When this skill applies, treat TCR as mandatory, not optional:

One small step — Prefer the smallest change that could move tests toward green (or add a failing test first in strict TDD, then minimal implementation).
Run tests — Use the project’s real test command (see Detecting the test command). Always run the full suite for that command (same as CI / default project test entrypoint): e.g. pytest with no path arguments, npm test / pnpm test / yarn test, cargo test, go test ./..., make test if that runs everything. Do not narrow to a single file, class, or -k filter unless the user explicitly asks for a scoped run.
Green → commit — If tests pass, commit that step immediately with a message that describes what changed (present tense, imperative).
Red → revert — If tests fail, do not keep the change. Restore the working tree to the last committed state (git restore . / git checkout -- . or revert unstaged edits as appropriate). Then retry with a smaller or different step.
Red → log — After reverting, append an entry to tcr-failure-log.md at the repository root (create it with a short title if missing). Record what went wrong so the failure is not invisible: when (ISO timestamp or equivalent), which test(s) failed and the assertion or error (or a short traceback excerpt), what change was attempted (intent in one or two sentences), and optionally what to try next. This file is append-only; do not delete past entries. Commit this log update with the next green commit if it is part of the same work, or as its own tiny commit if the user prefers a clean separation.

Do not accumulate uncommitted red edits “to fix in the next message.” Red means revert first, then log.

Workflow loop

edit (tiny) → run tests → pass? → git add + git commit
                      ↘ fail? → revert working tree → append tcr-failure-log.md → try again

Git behavior

Commit: Include only files that belong to the green step; keep commits small and atomic.
Revert on failure: Prefer discarding uncommitted changes to return to last commit. Do not commit broken states. If a commit was already made by mistake while red, use the project’s agreed recovery (e.g. git reset --soft HEAD~1 only when the user expects rewriting history—default to revert/discard before committing).
Branch: Same rules on feature branches: never push a sequence that leaves mainline patterns broken if your workflow requires linear green history.

Detecting the test command

Resolve how to test from the repo, in order:

package.json → scripts.test (or npm test / pnpm test / yarn test).
Makefile → make test or documented target.
pytest, cargo test, go test ./..., Maven/Gradle, etc., from project conventions.
If unclear, check README, CI config (e.g. .github/workflows), or ask once.

Use the same command the project already uses; do not invent a second test runner without reason.

Full suite: The goal is “everything this project’s standard test command runs.” If the repo documents a different “full” command (e.g. make test-all vs make test), use the one that matches CI or README for complete coverage.

Agent conduct

Proactive: After substantive edits, run the full test suite before suggesting the task is done.
Honest: If tests cannot be run in the environment, say so and either request permission to run them or describe exact commands for the user—do not claim TCR compliance without a green run.
Scope: TCR applies to coding tasks that touch behavior covered by tests; pure docs-only changes may skip tests only when they cannot affect execution.

Optional: user escape hatch

If the user explicitly says to skip TCR or bend the workflow for a one-off (e.g. WIP checkpoint), follow their instruction for that turn only, then return to TCR unless they say otherwise.

이 저장소의 다른 Skills

같은 저장소

tcr

xpepper/tcr-skill

Guide users through TCR (Test && Commit || Revert), TCRDD, and git-gamble workflows. ALWAYS trigger when a user mentions TCR, TCRDD, "test commit revert", "git gamble", or "git-gamble". Trigger when a user wants to combine TDD with automatic commits/reverts, enforce baby steps via a commit-or-revert loop, or asks about the --red/--green/--refactor flags. Trigger when someone says they want to "develop with TDD and TCR", "use TCR to force smallest steps", or "gamble" on their tests. Do NOT trigger for general TDD-only questions, general unit testing questions, test framework setup, CI pipelines, mocking, or code coverage — those do not need this skill.

2026-03-292

name	tcr-kentbeck
description	Enforces Test && Commit \|\| Revert (TCR): run tests after each micro-change, commit only on green, discard the change on red. ALWAYS trigger when the user mentions TCR, test-commit-revert, or wants strict incremental commits with no red states kept in the working tree or history. The agent makes tiny changes, runs the full test suite, and either commits on green or reverts everything on red — never accumulating broken code. Do NOT trigger for general TDD questions, test framework setup, CI pipelines, or code coverage — those do not need this skill.
license	MIT
compatibility	Requires git

TCR (Test && Commit || Revert)

Non-negotiables

When this skill applies, treat TCR as mandatory, not optional:

One small step — Prefer the smallest change that could move tests toward green (or add a failing test first in strict TDD, then minimal implementation).
Run tests — Use the project’s real test command (see Detecting the test command). Always run the full suite for that command (same as CI / default project test entrypoint): e.g. pytest with no path arguments, npm test / pnpm test / yarn test, cargo test, go test ./..., make test if that runs everything. Do not narrow to a single file, class, or -k filter unless the user explicitly asks for a scoped run.
Green → commit — If tests pass, commit that step immediately with a message that describes what changed (present tense, imperative).
Red → revert — If tests fail, do not keep the change. Restore the working tree to the last committed state (git restore . / git checkout -- . or revert unstaged edits as appropriate). Then retry with a smaller or different step.
Red → log — After reverting, append an entry to tcr-failure-log.md at the repository root (create it with a short title if missing). Record what went wrong so the failure is not invisible: when (ISO timestamp or equivalent), which test(s) failed and the assertion or error (or a short traceback excerpt), what change was attempted (intent in one or two sentences), and optionally what to try next. This file is append-only; do not delete past entries. Commit this log update with the next green commit if it is part of the same work, or as its own tiny commit if the user prefers a clean separation.

Do not accumulate uncommitted red edits “to fix in the next message.” Red means revert first, then log.

Workflow loop

edit (tiny) → run tests → pass? → git add + git commit
                      ↘ fail? → revert working tree → append tcr-failure-log.md → try again

Git behavior

Commit: Include only files that belong to the green step; keep commits small and atomic.
Revert on failure: Prefer discarding uncommitted changes to return to last commit. Do not commit broken states. If a commit was already made by mistake while red, use the project’s agreed recovery (e.g. git reset --soft HEAD~1 only when the user expects rewriting history—default to revert/discard before committing).
Branch: Same rules on feature branches: never push a sequence that leaves mainline patterns broken if your workflow requires linear green history.

Detecting the test command

Resolve how to test from the repo, in order:

package.json → scripts.test (or npm test / pnpm test / yarn test).
Makefile → make test or documented target.
pytest, cargo test, go test ./..., Maven/Gradle, etc., from project conventions.
If unclear, check README, CI config (e.g. .github/workflows), or ask once.

Use the same command the project already uses; do not invent a second test runner without reason.

Agent conduct

Proactive: After substantive edits, run the full test suite before suggesting the task is done.
Honest: If tests cannot be run in the environment, say so and either request permission to run them or describe exact commands for the user—do not claim TCR compliance without a green run.
Scope: TCR applies to coding tasks that touch behavior covered by tests; pure docs-only changes may skip tests only when they cannot affect execution.

Optional: user escape hatch

If the user explicitly says to skip TCR or bend the workflow for a one-off (e.g. WIP checkpoint), follow their instruction for that turn only, then return to TCR unless they say otherwise.