--- name: Fix slug: fix-2 category: Quality description: Fix implements a diagnosed bug fix after verify confirms a reproducible issue and maintainers trigger the fix flow. It updates the pinned file, proves the repro test passes, and runs lint and typecheck before a candidate is pushed. github: "https://github.com/emdash-cms/emdash/tree/main/infra/emdash-bot/.flue/skills/fix" language: TypeScript stars: 11579 forks: 1083 install: "npx degit https://github.com/emdash-cms/emdash/tree/main/infra/emdash-bot/.flue/skills/fix ~/.claude/skills/fix" installs_to: ~/.claude/skills/fix source_path: infra/emdash-bot/.flue/skills/fix/SKILL.md collection_size: 25 category_size: 1354 collection_url: "https://dirskills.com/collections/emdash-cms/emdash" added: 2026-08-12T04:42:40.768Z last_synced: 2026-08-12T04:42:40.768Z canonical_url: "https://dirskills.com/skills/fix-2" --- # Fix Fix implements a diagnosed bug fix after verify confirms a reproducible issue and maintainers trigger the fix flow. It updates the pinned file, proves the repro test passes, and runs lint and typecheck before a candidate is pushed. **Install:** ```bash npx degit https://github.com/emdash-cms/emdash/tree/main/infra/emdash-bot/.flue/skills/fix ~/.claude/skills/fix ``` ## README # Fix You are here because a maintainer issued a **fix** directive, verify returned `bug`, diagnose pinned the cause with at least `medium` confidence, and diagnose rated the fix `mechanical` or `clear-best-option`. Diagnose handed you a **proposed fix** -- a concrete plan naming the file and the change. Implement that plan, prove it works, and leave the change verified. The hard reasoning is done; do not re-litigate the diagnosis unless reading the code convinces you it is wrong (then abandon -- see below). **What your output is, and is not.** You are not merging and not opening a PR. You commit and push your change to the issue's `bot/fix-` candidate branch as the spine instructs; the push triggers a **preview build** the workflow posts to the issue; the reporter is asked to confirm it fixes _their_ case. **Only after the reporter confirms** does a draft PR open, and a maintainer reviews before anything reaches `main`. So the bar is "a correct, conventions-respecting change that makes the repro test pass" -- not "a perfect, unimprovable patch." A clear, test-backed fix is worth shipping for verification even when it is more than a one-liner. Equally: do not gold-plate, do not expand scope, do not refactor beyond the diagnosed bug. ## Environment - **Edit in the VFS** with the `edit_file` / `write_file` tools; read surrounding code with `read_file` and `grep`. Every VFS edit is replayed onto the container checkout before each container command. - **Run tests, lint, typecheck, and format in an attached container** -- none of the toolchain exists in the VFS. Attach once you are ready to verify, and do all `pnpm` and git work there. ## Do not - No `git tag` and no PR creation. Push only the issue's `bot/fix-` branch, with `--force-with-lease`, exactly as the spine instructs -- the push capability rejects every other ref. The workflow owns the preview and the PR. - No GitHub writes. Read-only API GETs only. - No network beyond the clone, the proxy-signed GitHub API, and the npm registry. - No `pnpm publish` / `npm publish`. - No drive-by edits. Touch only the files the diagnosed bug and its test need. A problem in a nearby file is a human's -- scope discipline. - Do not modify Lingui catalogs (`packages/admin/src/locales/*/messages.po`); the extract workflow handles them on merge. ## Procedure 1. **Re-read diagnose's root cause and proposed fix.** That is your target and your spec. The change should land in the file and approximate line diagnose named. If your work drifts to a different file, stop -- diagnose may be wrong, in which case abandon, do not wander. 2. **Establish a regression test where feasible.** Reproduce usually confirmed the bug without a test on disk. If the bug is unit- or integration-testable (a handler, a query, a pure function, an API route), write a `vitest` test now that fails for the reported reason, and confirm it fails in the container (`pnpm --filter test `) _before_ you touch the fix. A testable bug with no regression test is not fixed. If the bug only manifests in the browser (admin interaction, rendered output), do not write a browser test -- you cannot run one reliably here; verify through `agent-browser` instead and describe that manual verification so the maintainer can add a durable test when landing. 3. **Implement the proposed fix -- the smallest change that fully resolves the bug.** Follow EmDash conventions: - Internal imports end `.js`; type-only imports use `import type`. - State-changing routes start with `export const prerender = false;`. - Never interpolate values into SQL: Kysely `sql` tagged template for values, `sql.ref()` for identifiers, `validateIdentifier()` before any `sql.raw()`. - Handlers return `ApiResult`; errors use `apiError` / `handleError` with `SCREAMING_SNAKE_CASE` codes; never expose `error.message` to clients. - Authorization via `requirePerm` / `requireOwnerPerm` from `#api/authorize.js`; permissions live in `packages/auth/src/rbac.ts` -- do not invent strings inline. - Pagination returns `{ items, nextCursor? }` via `encodeCursor` / `decodeCursor`. - Content-table queries filter by `locale`. - Admin strings go through Lingui; logical Tailwind classes only. - `import.meta.env.DEV`, never `process.env.NODE_ENV`. - Migrations are forward-only and additive; register in `runner.ts` via `StaticMigrationProvider`. - Prefer additive changes. A breaking change needs an explicit changeset -- do not introduce one for an automated fix without compelling justification. 4. **Run the repro test (container).** It must now pass. If not, your fix is wrong or incomplete -- investigate, adjust, or abandon. Never weaken the test to make it pass. 5. **Run the affected package's suite (container).** `pnpm --filter test`. Read the output. New failures in tests you did not write are regressions -- fix them or abandon the whole change. Do not push regressions through. 6. **Typecheck (container).** `pnpm typecheck` for packages, `pnpm typecheck:demos` if a demo was involved. No new errors. 7. **Lint (container).** `pnpm lint:quick`. If the count looks off, snapshot with `pnpm lint:json | jq '.diagnostics | length'` -- a clean baseline stays clean. 8. **Format (container).** `pnpm format` (oxfmt, tabs). Do not bypass it. Format only the files you touched -- a repo-wide format reformats already-committed files and blows scope. 9. **Add a changeset when a published package changed.** Create the file under `.changeset/` (patch bump for a bug fix unless diagnosis says otherwise). Write it as release notes for someone upgrading -- lead with a verb, describe the observable effect, reference the issue -- not as a commit message. Include it in your fix commit. ## When to abandon Return not-fixed, with a clear reason, when: - The repro test does not actually fail before your change (diagnose or reproduce was wrong). - Your fix introduces regressions you cannot resolve without scope creep. - The fix turns out to need breaking-change-level design decisions a human should make. - Lint, typecheck, or format produces errors you cannot resolve cleanly. A failed attempt is still useful -- the bot posts the diagnose and verify output and explains why the automated fix was abandoned. ## Output Return: - Whether the fix succeeded. - The conventional-commit message you used: `fix(): (#)`, scope matching the package or area (`fix(core/menus)`, `fix(admin/seo)`, `fix(migrations)`). - The list of changed file paths, repo-root-relative. - Whether the repro test currently passes against your change -- with the command and its output as evidence. - Notes: design choices, rejected alternatives, edge cases, or (when not fixed) the specific reason you abandoned. The workflow reads this alongside the preview build your push triggered, and posts the outcome. It does not open a PR until the reporter confirms the preview fixes their case.