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

drill

스타0

포크0

업데이트2026년 6월 5일 02:38

Verify the closed test loop actually reacts by injecting one intentionally failing test, running each of the five loop tools, and recording the result. Use after init-loop and after any change to a loop tool.

설치

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

Manus에서 실행

출처

majiayu000

majiayu000/test-loop

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

다운로드

Manus에서 실행

drill

Prove the loop is wired correctly by breaking it on purpose.

When to use

Right after init-loop.
After editing any of the five loop tools.
After a refactor that touches CI, the pre-commit hook, or the report-render script.

Do not use this skill to verify a real failure. The drill is for verifying the loop, not for triaging a regression.

Inputs

Name	Required	Default	Description
`target_path`	yes	none	The project to drill.
`language`	yes	none	One of `swift`, `python`, `go`, `rust`. Picks the injection template.
`expected_failures`	no	`1`	The number of distinct failing tests to inject. One is the minimum needed to exercise the failure-classify step. Two or more tests whether the classifier deduplicates duplicate failure lines.
`drill_label`	no	`closed-loop-drill`	A short label used in test names so the drill fixture can be located later if cleanup is interrupted.

Output

Path	Contents
`docs/knowledge/drill-YYYY-MM-DD.md`	Evidence document: the commands that ran, the output captured, the verdict per step, and any defects found.
`docs/reports/<date>/`	Rendered test report from the injected failure (this is the "real" run the loop produces).
working tree	Briefly contains the drill fixture file. Cleaned up on success.

Algorithm (eight steps)

Inject a test fixture file containing the expected number of failing tests. Use the language-specific template. Place the file in the project's test directory under a name ending in DrillTests.
Run the test runner. The expected outcome is the test suite fails with the same number of failures as injected.
Run the report renderer. Verify the JSON summary has the failures_by_class field populated and the Markdown report has a Failures by class section.
Run the drift check. It should report drift: clean ✅ — the drill fixture is in the test directory, not the source directory, and so should not introduce drift. If it does, that is a finding for the drill report.
Run the pre-commit hook in dry-run mode. The fixture is intentional and should be staged to test the hook. The hook is expected to allow the test file (it only inspects the source directory), and a subsequent drill injects an undocumented source file to verify the hook blocks.
Run the pre-commit hook with a staged undocumented public symbol. The hook should exit non-zero and print a message pointing at the knowledge base.
Clean up the injected fixtures and verify the working tree is empty.
Write the drill evidence document.

Worked example (Swift)

In a Swift project with the loop already installed:

Create Tests/<Target>Tests/ClosedLoopDrillTests.swift:

@Test func drillAssertsWrongValue() {
    #expect(SessionDuration.thirtyMinutes.endDate(from: Date(timeIntervalSince1970: 0))
           == Date(timeIntervalSince1970: 100))
}

Run swift test. Expect red.
Run bash scripts/render_report.sh. Expect the report to list the failing test under ASSERTION_FAILURE.
Run bash scripts/check_drift.sh. Expect drift: clean.
Stage the test file, run .githooks/pre-commit. Expect exit 0 (test files are not in scope).
Create Sources/<Target>/DrillUndocumentedFixture.swift, stage it, run the hook. Expect exit 1.
rm the two fixtures, git reset, swift test — back to green.
Write docs/knowledge/drill-2026-06-02.md.

Anti-patterns

Leaving the fixture in the working tree. The drill is supposed to be invisible. A leftover fixture corrupts the next commit.
Drilling the loop but never reading the report. The drill produces an evidence document for a reason. If the report does not contain the expected sections, the loop is broken; the user must read the report to find that out.
Drilling the same day, twice. Two drills on the same day overwrite each other's evidence document. Wait until tomorrow, or pass a custom drill_label to disambiguate.

Cross-references

init-loop — runs this skill automatically on first install.
drift-check — exercised by step 4 of the drill.
failure-classify — exercised by step 3.
report-render — exercised by step 3.

이 저장소의 다른 Skills

같은 저장소

init-loop

majiayu000/test-loop

Install the closed test loop into a fresh project. Copies the pre-commit hook, the CI workflow, the render script, the drift check script, the failure classifier, and the knowledge-base templates, then prepares the drill handoff that verifies the loop reacts.

2026-06-230

drift-check

majiayu000/test-loop

Flag public symbols in the project's source tree that are not documented in the project's knowledge base. Use this before committing, in CI, or whenever a public API surface changes and you want to know whether the knowledge base has gone stale.

2026-06-050

failure-classify

majiayu000/test-loop

Group failing tests by naming convention so a real assertion failure is not hidden among tests that exist to verify a system rejects something. Use after running the test suite and before reading the report.

2026-06-050

report-render

majiayu000/test-loop

Turn a test runner's raw log into a Markdown report plus a structured JSON summary. Embeds the failure classification so a reader can see the failing tests, the run summary, and the failure-class counts on one page.

2026-06-050

test-loop-bootstrap

majiayu000/test-loop

Meta-skill: choose which of the other five test-loop skills to invoke first, based on the user's description of the current state of their project. Use when a user says something like "I want to add tests to this project" or "this project has no CI" and the right entry point is not obvious.

2026-06-050

name	drill
description	Verify the closed test loop actually reacts by injecting one intentionally failing test, running each of the five loop tools, and recording the result. Use after init-loop and after any change to a loop tool.
metadata	{"type":"project","language":"any","inputs":"target project path, language, test framework","outputs":"docs/knowledge/drill-YYYY-MM-DD.md, drill artifacts"}

drill

Prove the loop is wired correctly by breaking it on purpose.

When to use

Right after init-loop.
After editing any of the five loop tools.
After a refactor that touches CI, the pre-commit hook, or the report-render script.

Do not use this skill to verify a real failure. The drill is for verifying the loop, not for triaging a regression.

Inputs

Name	Required	Default	Description
`target_path`	yes	none	The project to drill.
`language`	yes	none	One of `swift`, `python`, `go`, `rust`. Picks the injection template.
`expected_failures`	no	`1`	The number of distinct failing tests to inject. One is the minimum needed to exercise the failure-classify step. Two or more tests whether the classifier deduplicates duplicate failure lines.
`drill_label`	no	`closed-loop-drill`	A short label used in test names so the drill fixture can be located later if cleanup is interrupted.

Output

Path	Contents
`docs/knowledge/drill-YYYY-MM-DD.md`	Evidence document: the commands that ran, the output captured, the verdict per step, and any defects found.
`docs/reports/<date>/`	Rendered test report from the injected failure (this is the "real" run the loop produces).
working tree	Briefly contains the drill fixture file. Cleaned up on success.

Algorithm (eight steps)

Inject a test fixture file containing the expected number of failing tests. Use the language-specific template. Place the file in the project's test directory under a name ending in DrillTests.
Run the test runner. The expected outcome is the test suite fails with the same number of failures as injected.
Run the report renderer. Verify the JSON summary has the failures_by_class field populated and the Markdown report has a Failures by class section.
Run the drift check. It should report drift: clean ✅ — the drill fixture is in the test directory, not the source directory, and so should not introduce drift. If it does, that is a finding for the drill report.
Run the pre-commit hook in dry-run mode. The fixture is intentional and should be staged to test the hook. The hook is expected to allow the test file (it only inspects the source directory), and a subsequent drill injects an undocumented source file to verify the hook blocks.
Run the pre-commit hook with a staged undocumented public symbol. The hook should exit non-zero and print a message pointing at the knowledge base.
Clean up the injected fixtures and verify the working tree is empty.
Write the drill evidence document.

Worked example (Swift)

In a Swift project with the loop already installed:

Create Tests/<Target>Tests/ClosedLoopDrillTests.swift:

@Test func drillAssertsWrongValue() {
    #expect(SessionDuration.thirtyMinutes.endDate(from: Date(timeIntervalSince1970: 0))
           == Date(timeIntervalSince1970: 100))
}

Run swift test. Expect red.
Run bash scripts/render_report.sh. Expect the report to list the failing test under ASSERTION_FAILURE.
Run bash scripts/check_drift.sh. Expect drift: clean.
Stage the test file, run .githooks/pre-commit. Expect exit 0 (test files are not in scope).
Create Sources/<Target>/DrillUndocumentedFixture.swift, stage it, run the hook. Expect exit 1.
rm the two fixtures, git reset, swift test — back to green.
Write docs/knowledge/drill-2026-06-02.md.

Anti-patterns

Leaving the fixture in the working tree. The drill is supposed to be invisible. A leftover fixture corrupts the next commit.
Drilling the loop but never reading the report. The drill produces an evidence document for a reason. If the report does not contain the expected sections, the loop is broken; the user must read the report to find that out.
Drilling the same day, twice. Two drills on the same day overwrite each other's evidence document. Wait until tomorrow, or pass a custom drill_label to disambiguate.

Cross-references

init-loop — runs this skill automatically on first install.
drift-check — exercised by step 4 of the drill.
failure-classify — exercised by step 3.
report-render — exercised by step 3.