메뉴
Shared guidance for behaviour-focused tests in TDD, regression fixes, acceptance-test implementation, flaky test fixes, and test review. Use when writing, updating, stabilizing, or reviewing tests, or briefing another agent about tests, especially when deciding whether a cleanup/removal request needs a new test.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Orchestrates standalone or caller-batched bug fixes via implementor and reviewer subagents using TDD. Handles bugs and verified review findings sequentially, tracks them in a dated checklist, and commits each fix without disrupting a surrounding PR-resolution batch.
Resolve GitHub PR review comments from humans and Copilot, including reviews already auto-requested or in progress. Use for verified comment resolution, sequential bugfix batching, one-push CI/Copilot cycles, and SHA-aware waits that avoid stale-event loops.
Shared conventions for Go projects. Copyright boilerplate, code quality, GoConvey testing, architecture, and commands. Referenced by go-implementor, go-reviewer, and workflow skills.
Go TDD implementation workflow. References implementation-principles, go-conventions, testing-principles, and agent-conduct.
Review Go implementations against spec acceptance tests. References implementation-principles, go-conventions, testing-principles, and agent-conduct.
Shared cross-language delivery workflow and guidance for implementing the simplest sufficient solution, maximizing reuse of existing code, and avoiding speculative abstractions, dependencies, and refactors. Use when implementing or reviewing code in any language.
| name | testing-principles |
| description | Shared guidance for behaviour-focused tests in TDD, regression fixes, acceptance-test implementation, flaky test fixes, and test review. Use when writing, updating, stabilizing, or reviewing tests, or briefing another agent about tests, especially when deciding whether a cleanup/removal request needs a new test. |
Use tests to declare desired behaviour and prove the system has that behaviour. Prefer supported boundaries: public APIs, CLI output, HTTP contracts, rendered UI, persisted state, emitted files, errors, or other effects visible to users, callers, or downstream steps.
Do not write tests whose only claim is an implementation detail: private helpers, source layout, filenames, imports, CSS classes, deleted files, removed functions, removed routes, removed modules/processes, or the mere absence of an old feature.
Treat a flaky test as a bug in the test suite or product, not as a reason to skip coverage. Do not skip, quarantine, xfail, delete, or loosen the test until it no longer proves behaviour.
You may reimplement a flaky test to make it deterministic when the replacement preserves the spirit of what the original test was trying to prove. Prefer stable user-visible boundaries and remove nondeterminism by controlling clocks, randomness, ordering, external services, async waits, or fixture setup.
If a user asks to remove obsolete implementation or get rid of a previously implemented feature, first identify the desired behaviour after the change.
Reject tests that pass by coupling to implementation details, hardcoded results, stubs that bypass the behaviour under test, or assertions that only prove old artifacts are absent. Accept a cleanup/removal with no new test only when the implementor explicitly justifies that no supported behaviour changed and the existing behavioural tests and quality gates pass. Reject flaky-test changes that merely skip, quarantine, delete, or weaken the check instead of preserving its behavioural intent.
