agentleFS
zaxbysaucezaxbysauce/opencode-swarm/.agents/skills/mock-to-internals-migration/SKILL.md

mock-to-internals-migration

Skill517 starsChanged 3 days agoMITView on GitHub

Codex canon for migrating opencode-swarm tests away from Bun mock.module leakage toward _internals dependency-injection seams. Use when touching tests with mock.module, adding test seams, fixing Bun mock isolation failures, or updating source modules for injectable internals.

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run barrel-import-dependent tests after modifying barrel exports.

    line 21
  2. Very specific:

    Prefer a small _internals seam exposing only the dependency under test over a new mock.module target — mock.module leaks across test files …

    line 28
  3. Distinctive:

    Check for existing wrapper patterns before applying sandbox wrapping.

    line 34
  4. Distinctive:

    Run tests on the unmodified codebase before starting, to establish a failure baseline.

    line 35
  5. Very specific:

    Run the lint check (e.g. bun run lint) as part of pre-submit verification, not just the build.

    line 37
  6. Very specific:

    Run git diff <base>..<head> --name-only and confirm file presence before marking introduced_by_pr verdicts.

    line 54
  7. Distinctive:

    Add or update tests covering the trigger condition and the forbidden shortcut.

    line 59
  8. Very specific:

    Use apply_patch for source and test edits.

    line 69
  9. Very specific:

    Use focused per-file bun --smol test <file> --timeout 30000 validation first.

    line 70
  10. Distinctive:

    Prefer small seams that expose only the dependency under test.

    line 72

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “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

Mock To Internals Migration

This is the canonical Codex migration protocol (self-contained since the #2966 retired-generated-skill reconciliation; it previously delegated to a retired generated fork). The host-agnostic rules live in AGENTS.md invariant 7 and .opencode/skills/writing-tests/SKILL.md; this canon carries the migration's own procedure and checks.

Required Procedure

  • Mirror the existing opt-in pattern when gating tools behind feature flags: a separate tool-map constant, a conditional merge in src/agents/index.ts, and gating tests verifying BOTH the disabled and enabled states.
  • Run barrel-import-dependent tests after modifying barrel exports.
  • Audit code structure integrity before editing a file that was recently refactored or extracted (the symbol may have moved).
  • Grep for all vi.fn(), vi.spyOn(), vi.mock() in converted files before declaring the conversion complete.
  • Spread the real module's exports (...realModule) as the base of every mock.module return object that must remain (Node built-ins especially).
  • Prefer a small _internals seam exposing only the dependency under test over a new mock.module target — mock.module leaks across test files in Bun's shared test-runner process (AGENTS.md invariant 7; the allowlist is closed by bun run check:invariants Check 4).
  • Design command-transformation pipelines as idempotent passes, not stacking layers.
  • Check for existing wrapper patterns before applying sandbox wrapping.
  • Run tests on the unmodified codebase before starting, to establish a failure baseline.
  • Run the lint check (e.g. bun run lint) as part of pre-submit verification, not just the build.

Forbidden Shortcuts

  • Invent new tool-gating mechanisms for opt-in feature flags.
  • Label post-change test failures as "pre-existing" without having run the tests before the change.

Reviewer Checks

  • Grep for import-from-barrel patterns in test files and run the affected tests after barrel changes.
  • Grep for mock.module patterns that lack the ...realModule spread.
  • Confirm bun:test isolation patterns match the skill guidelines.
  • For wrapper transforms, verify idempotency by applying the transform twice and confirming the output equals the single-call output.
  • Run git diff <base>..<head> --name-only and confirm file presence before marking introduced_by_pr verdicts.

Test Engineer Checks

  • Add or update tests covering the trigger condition and the forbidden shortcut.

Also load:

  1. .agents/skills/writing-tests/SKILL.md
  2. .agents/skills/engineering-conventions/SKILL.md if the seam touches runtime-sensitive code

Codex-specific execution notes:

  • Use apply_patch for source and test edits.
  • Use focused per-file bun --smol test <file> --timeout 30000 validation first.
  • Restore any _internals overrides in afterEach.
  • Prefer small seams that expose only the dependency under test.

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.