agentleFS
gpanakkalgpanakkal/crucible/SKILL.md

crucible

Skill3 starsChanged 29 days agoMITView on GitHub

Write solid unit tests using property-based testing and mutation testing. Use whenever unit tests are being written, fixed, audited, or reviewed in a TypeScript project; whether the user asks directly or test-writing occurs as a step inside another workflow (TDD, feature implementation, bug fixing, code review). Also use when checking test coverage or mutation scores, or when verifying the unit testing configuration. Provides test criteria and processes that other workflows should apply during their test-writing steps.

10 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When unit tests on a TypeScript project are being written, fixed, or audited — whether requested directly or as a step inside another …

    line 13
  2. Distinctive:

    When writing end-to-end, integration, UI, or simulation tests.

    line 17
  3. Distinctive:

    Before activating, check whether the project has opted out of this skill.

    line 21
  4. Distinctive:

    If any opt-out signal is found, do not activate automatically.

    line 26
  5. Distinctive:

    Do not modify application code unless specifically prompted to do so.

    line 45
  6. Distinctive:

    When asked to add tests, do not modify existing tests.

    line 46
  7. Distinctive:

    When asked to fix tests, do not add new tests.

    line 47
  8. Distinctive:

    When asked to audit tests, fix existing tests and then add tests as needed to meet test criteria.

    line 48

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Crucible

When to use this

When unit tests on a TypeScript project are being written, fixed, or audited — whether requested directly or as a step inside another workflow (e.g., TDD, feature implementation, bug fixing).

When NOT to use this

When writing end-to-end, integration, UI, or simulation tests.

Per-project opt-out

Before activating, check whether the project has opted out of this skill. Look for any of the following:

  • A .no-crucible file in the project root
  • "crucible: false" anywhere in AGENTS.md or .claude/settings.json

If any opt-out signal is found, do not activate automatically; only apply this skill if the user explicitly requests it in this conversation.

Modes

Pick the mode that matches the task, then read all listed files before starting. Do not work from memory of their contents.

ModeWhenRead first
Write testsAdding new tests (standalone request or a test-writing step in another workflow)references/test-criteria.md, references/writing-tests.md, references/assessing-a-module.md, references/mutation-testing.md, references/debrief-template.md
Fix testsRepairing existing tests without adding new onesreferences/test-criteria.md, references/assessing-a-module.md, references/mutation-testing.md, references/debrief-template.md
Audit testsEvaluating existing tests, project-wide or scopedreferences/test-criteria.md, references/auditing-tests.md, references/assessing-a-module.md, references/mutation-testing.md, references/debrief-template.md
Verify setupChecking that testing dependencies and configs are correctreferences/verifying-setup.md

references/test-criteria.md is mandatory reading in every mode that touches tests: it defines what "done" means.

Rules

  • Example commands use pnpm, but always use the project's package manager.
  • When invoked standalone:
    • Do not modify application code unless specifically prompted to do so.
    • When asked to add tests, do not modify existing tests.
    • When asked to fix tests, do not add new tests.
    • When asked to audit tests, fix existing tests and then add tests as needed to meet test criteria.
  • When embedded in another workflow (e.g., a TDD loop that owns code changes): that workflow's rules govern whether application code and in-progress tests may change, but the test criteria in references/test-criteria.md still apply in full, and tests that predate the workflow's current task must not be modified without telling the user. Debrief per the workflow's reporting instructions, following the embedded-workflow rules in references/debrief-template.md.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.