gilde

← All craftbooks

Type-Safety Pass

Build: software and codeevalv2.0.2released 2026-09-05workflow: build-loop

Tighten a module against unsafe patterns — loose equality, implicit coercions, swallowed catches, untyped boundaries, any-casts — with counted evidence: an audit that inventories the patterns by a stated method, fixes that never silence a check to move a count, a same-method re-count, and an enforced independent review.

Steps

Entry step: audit. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Audit with countscode auditorentry

    Inventory the unsafe patterns in scope with counts by a stated method, pick concrete targets, record the guardrail, and capture the suite green.

    Show working prompt
    The area to tighten: {{scope}}

Inventory the unsafe patterns before fixing any of them — the improvement will be proven by re-counting later, so the counts and the exact method are the deliverable here. Read the involved source, then count each pattern class in scope with a stated, repeatable method (a grep per pattern works; quote the exact expressions you used): loose equality against null or undefined (`==`/`!=` where a strict check belongs), implicit string/number coercions (arithmetic or concatenation on values that may arrive as strings), swallowed catches (a catch that hides the error and carries on as if nothing failed), untyped or unvalidated boundaries (inputs used without a shape check), and in TypeScript projects `any`-casts and ignore-comments. Record the count per pattern and where each hit lives.

Pick the concrete targets for this pass and state the guardrail: which behavior is pinned by tests and must not change, and which behavioral CONSEQUENCES of these patterns are bugs this pass is expected to fix — name each one. Then find how the project runs its tests (`list_package_scripts`), run the suite with `run_package_script` (`test`), and record it green before any change; if it is already red, stop and report that honestly. If the command needs first-use approval, say so and wait rather than guessing.

Write `{{workPath}}/audit.md` with exactly these sections: `## Inventory` (counts by pattern with the exact method and grep expressions used), `## Targets` (the hits this pass will fix, with backtick paths), `## Guardrail` (what must not change, and the declared consequence fixes that may). Cite the real files with backtick paths.

Observable handoff: write the completed result to `{{workPath}}/audit.md` in the project's artifacts drawer with `write_artifact`. Do not merely describe what the file would contain. Re-read it with `read_artifact` before finishing this phase and repair any incomplete sections.
  2. Fix pattern by patternsoftware engineer

    Fix the targeted patterns at the real sites, never silencing a check or weakening an assertion to move a count.

    Show working prompt
    Read `{{workPath}}/audit.md` and fix the targeted patterns at the REAL sites with `read_file` plus `write_file`/`replace_in_file`, pattern by pattern. Replace loose equality with strict checks that state what they mean; normalize or validate values at the boundary they cross instead of coercing mid-calculation; make swallowed catches surface the error — rethrow, or report it the way the audit's guardrail declares — rather than carrying on as if nothing failed. Never buy a lower count by weakening the code: no deleting an assertion, no silencing an error path, no bare casts, and in TypeScript no `any` or ignore-comment to make a diagnostic disappear — a count that falls that way is a regression wearing a metric. Behavior changes only where the audit declared a consequence fix, and each one gets named in your notes. Run the suite with `run_package_script` (`test`) as you go and keep it green; a change that goes red gets narrowed, not stacked on. If a targeted hit turns out to be correct as written, record why and leave it — honesty beats a moved count.

Write `{{workPath}}/change-notes.md` with exactly these sections: `## Patterns addressed` (each pattern class, what the fix was, and any declared consequence fix it delivered), `## Files touched` (backtick path per line), `## Deviations` (targets handled differently than the audit planned, or `none`, honestly). Before working, open `{{workPath}}/audit.md` with `read_artifact`.

Observable handoff: write the completed result to `{{workPath}}/change-notes.md` in the project's artifacts drawer with `write_artifact`. Do not merely describe what the file would contain. Re-read it with `read_artifact` before finishing this phase and repair any incomplete sections.
  3. Re-count and verifysoftware engineer

    Re-count every pattern with exactly the audit's method, quote before/after counts, and record the suite green.

    Show working prompt
    Prove the pass with fresh eyes. Read `{{workPath}}/audit.md` and RE-COUNT every pattern with EXACTLY the method and grep expressions it records — same expressions, same scope; a changed method voids the comparison, and if the recorded method cannot be reproduced that is a finding to report, not a license to substitute one. Quote the audit's count and the new count for each pattern side by side. Run the whole suite with `run_package_script` (`test`) and record the green result. Spot-check the fixed sites: the checks got stronger, not deleted, and no cast or ignore-comment crept in. Anything you could not actually re-run gets labeled unverified, never claimed.

Write `{{workPath}}/verification.md` with exactly these sections: `## Before / after counts` (per pattern, the audit count next to the re-count, same greps), `## Suite` (the full-suite result from the real run), `## Result` (which declared consequences are now fixed, and anything unverified). Before working, open `{{workPath}}/audit.md` with `read_artifact`.

Observable handoff: write the completed result to `{{workPath}}/verification.md` in the project's artifacts drawer with `write_artifact`. Do not merely describe what the file would contain. Re-read it with `read_artifact` before finishing this phase and repair any incomplete sections.
  4. Evaluate the deliverablecode-quality reviewer

    Independently grade the observable deliverable and route it to finish, repair, or user escalation.

    Show working prompt
    Review `{{workPath}}/verification.md`, `{{workPath}}/audit.md`, `{{workPath}}/change-notes.md` against every criterion below. Inspect the underlying evidence files named by the workflow; do not grade from the author's summary alone.

1. audit.md counts real patterns in real files with the exact method recorded (grep expressions quoted), and a green suite receipt exists from before the work started.
2. Counts genuinely fell and the re-count method matches the audit's exactly: verification.md quotes before and after per pattern — the measured target moved against the recorded baseline using the same method.
3. No suppression bought the improvement: open the touched files and confirm no assertion was weakened, no check deleted, no error path silenced, and no cast or ignore-comment introduced to move a count.
4. Observable behavior unchanged (or changed only as the audit declared): each consequence fix the audit named happened and is recorded in change-notes.md, and nothing else moved.
5. No stage left the suite red (receipts, not claims): green before the pass and green after it, from real runs.
6. change-notes.md names every touched file (paths that exist) and records its deviations honestly, including targets left alone because they were correct as written.

Open `{{workPath}}/verification.md`, `{{workPath}}/audit.md`, `{{workPath}}/change-notes.md` with `read_artifact`. Write the evidence-backed review to `{{workPath}}/review.md` in the artifacts drawer with `write_artifact`.

List the findings as a markdown table with columns `| Severity | File | Line | Problem | Fix |` (severities: critical/major/minor/nit; empty table only on PASS). Give each criterion a PASS or FAIL with a concrete path, excerpt, measurement, or observed behavior. End with exactly `Verdict: PASS` or `Verdict: REVISE`. The gate ENFORCES the verdict: a well-formed REVISE is rejected and routed back to `repair` automatically, carrying your findings — so list every finding in the table with a concrete fix. On PASS, `advance_task_step` to `finish`. Never write PASS while a criterion is unmet.
  5. Finishproject lead

    All deterministic and reviewer criteria passed.

    Show working prompt
    The independent review passed. Read `{{workPath}}/review.md` with `read_artifact`, then use `write_task_note` to record a concise DONE summary with the final deliverable paths (`{{workPath}}/verification.md`, `{{workPath}}/audit.md`, `{{workPath}}/change-notes.md`) and the evidence that each acceptance criterion passed. Report DONE without starting new work.
  6. Repair the deliverablesoftware engineer

    Fix only the concrete gaps from the latest independent review.

    Show working prompt
    Read `{{workPath}}/review.md` with `read_artifact` and repair every failed criterion in `{{workPath}}/verification.md`, `{{workPath}}/audit.md`, `{{workPath}}/change-notes.md`. Make changes on each file's declared surface (`write_artifact` for artifact inputs, `write_file` for workspace inputs), not in task notes or a reply. Preserve evidence that already passed. Re-run or re-check anything the reviewer found unproven. Ensure `{{workPath}}/verification.md` is genuinely updated this turn so the repair is observable, then hand it back for independent evaluation.
  7. Escalate unresolved concernsproject lead

    The bounded repair loop ended without a defensible pass.

    Show working prompt
    The deliverable did not pass after 3 review rounds. Do not claim success. Read `{{workPath}}/review.md` with `read_artifact`, then use `write_task_note` to record DONE_WITH_CONCERNS: the unmet criteria, what was attempted, the affected paths, and the smallest user decision or missing input needed to continue.

Triggers

Phrases that suggest this craftbook to a crew.

Source

View this craftbook on GitHub · MIT license