dmmulroy/better-result

adopt-better-result

Adopt better-result in an existing TypeScript codebase. Use for a repository-wide error-handling audit and proposal, or for implementing a named vertical slice with TaggedError and Result.

Trending #4863 First seen Jul 30, 2026

Installation

$ npx skills add dmmulroy/better-result --skill adopt-better-result

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from dmmulroy/better-result.

npx skills add dmmulroy/better-result

Browse all from dmmulroy/better-result

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 2.0K
License LICENSE
Default branch main
Open issues 5
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,473 B
  • docs SUMMARY.md 215 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 325 installs

SKILL.md

Adopt better-result

Start with evidence, then work at the scale named by the user.

Choose the branch

  • Audit branch: Use when the user requests a repository-wide audit or proposal, or has not named an implementation slice. Complete the audit branch before changing production code.
  • Named-slice branch: Use when the user explicitly requests implementation of a function, module, boundary, or previously proposed slice. Limit evidence collection to that slice and its propagation path.

An approved slice from the audit branch continues through the named-slice branch.

Audit branch: repository-wide proposal

1. Establish the repository and API facts

Read the repository instructions, package manifests, source layout, test commands, and architecture documentation. Determine whether better-result is installed and which version/API is available. Prefer installed types and source over remembered APIs.

Map every production-code area before studying individual failures. Exclude generated and vendored code from the audit; inspect tests for intended behavior.

Complete when: every production-code area is listed, the validation commands are known, and the available better-result API has been verified.

2. Audit every production-code area

Follow [references/repository-audit.md](references/repository-audit.md). Trace search evidence into end-to-end failure paths, keep grouped sites accountable with counts, and record obscured paths as unknown.

Write the audit to the repository's established documentation or planning location, falling back to docs/better-result-adoption.md.

Complete when: the report satisfies the coverage and completion requirements in repository-audit.md.

3. Design the target model

Apply the failure taxonomy in [references/tagged-errors.md](references/tagged-errors.md) and make each boundary decision with [references/result-boundaries.md](references/result-boundaries.md). Add the proposed dispositions, user-facing mappings, boundary decisions, and ranked vertical migration slices to the report.

Recommend the best first slice and explain why it is bounded and valuable.

Complete when: every catalogued failure has a disposition, every boundary has a recorded codec decision, and one first slice is recommended.

4. Present the approval gate

Present the report and recommendation. The audit branch's only repository change is the report.

Complete when: the report is presented. An explicit approval of one named vertical slice starts the implementation branch; otherwise the run ends here.

Named-slice branch: implementation

1. Establish the slice and API facts

Read the repository instructions, validation commands, installed better-result API, relevant production code, and tests. Trace the named failure source through its immediate callers to its handling or transport boundary. Reuse an existing adoption report when present; otherwise retain the evidence for the implementation summary.

Complete when: the slice boundary, current behavior, failure variants, callers, side effects, and transport boundaries are accounted for, and the available API is verified.

2. Implement one vertical slice

Follow [references/vertical-slice-migration.md](references/vertical-slice-migration.md), using [references/tagged-errors.md](references/tagged-errors.md) for failure dispositions and [references/result-boundaries.md](references/result-boundaries.md) for boundary contracts. Keep the implementation within the named propagation path.

Complete when: the path is consistently Result-based from failure source to its chosen handling boundary, with every error variant handled and every control-flow seam accounted for.

3. Verify and report

Run the repository's applicable format, lint, type-check, and relevant test commands. Update an existing adoption report with completed work, deviations, discoveries, and validation evidence; otherwise include them in the user-facing summary. End after recommending the next slice.

Complete when: all applicable checks pass, or every failure is reported with evidence, and the report or summary accurately describes the repository's current state.