ワンクリックで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

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

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

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.