agentleFS
lza6lza6/claw-code-tingfeng/skills/build-fix/SKILL.md

build-fix

Skill5 starsChanged 12 days agoMITView on GitHub

Fix build and TypeScript errors with minimal changes

13 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use docs-ci, docs-interfaces and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • jh941213Skill

    docs-ci

    문서 CI(링크·OpenAPI lint·breaking 게이트·mermaid 검증)나 문서 드리프트 감지(docs.yaml 신선도 검사)를 설치하거나 돌릴 때 사용. 문서 내용 작성은 docs-architecture·docs-interfaces·docs-manuals.

    Also in 3 projects that use this

  • jh941213Skill

    docs-interfaces

    API·이벤트 인터페이스 문서(OpenAPI·swagger·AsyncAPI 명세, 엔드포인트 레퍼런스, API 구성도·시퀀스, API CHANGELOG)를 만들거나 코드와 맞출 때 사용. 시스템 구성도는 docs-architecture, API 설계 원칙은 api-design-principles.

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-import

    Import instincts from file or URL into project/global scope

    Also in 3 projects that use this

  • RachaelQuiselSkill

    client-docs

    Client documentation. Use when a build needs documentation updates or missing project documents need to be identified.

    Also in 3 projects that use this

  • planailabsSkill

    docs-architecture

    Layout, build pipeline, and structural gotchas for this dual-Astro repo. Read before changing structure, routing, or adding content. Operational/dev-server questions → dev-build skill.

    Also in 3 projects that use this

  • +4 more from jh941213
  • +1 more from TheKREATORS

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. 0 are common, 14 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 14

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.

    line 22
  2. Distinctive:

    Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.

    line 23
  3. Distinctive:

    If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the build-fix …

    line 24
  4. Very specific:

    Run the project's type check command (e.g., tsc --noEmit, mypy, cargo check, go vet)

    line 30
  5. Distinctive:

    Add type annotations where missing

    line 35
  6. Distinctive:

    Add null checks where needed

    line 36
  7. Distinctive:

    NO refactoring of unrelated code

    line 42
  8. Distinctive:

    ONLY what's needed to make build pass

    line 45
  9. Distinctive:

    Run the project's type check command after each fix

    line 48
  10. Distinctive:

    Ensure no new errors introduced

    line 49
  11. Distinctive:

    Stop when build passes

    line 50
  12. Very specific:

    Prefer omx sparkshell for noisy build/typecheck runs, repository search/listing, and bounded read-only inspection when summary output is …

    line 54
  13. Distinctive:

    Use raw shell when exact stdout/stderr, shell composition, dependency installation, or low-level debugging fidelity is required.

    line 55
  14. Very specific:

    If omx sparkshell returns incomplete, ambiguous, or summary unavailable output, retry with a more precise command or the raw shell …

    line 56
  15. Distinctive:

    No new errors introduced

    line 87
  16. Distinctive:

    Minimal changes: - Don't refactor while fixing

    line 112
  17. Distinctive:

    Test after: - Ensure tests still pass

    line 114

“Common” is measured: kept by at least 6 in 10 of the 8 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

Build Fix Skill

Fix build and compilation errors quickly with minimal code changes. Get the build green without refactoring.

When to Use

This skill activates when:

  • User says "fix the build", "build is broken"
  • TypeScript compilation fails
  • the build command or type checker reports errors
  • User requests "minimal fixes" for errors

What It Does

GPT-5.4 Guidance Alignment

  • Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
  • Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
  • If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the build-fix workflow is grounded.
  • Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.

Delegates to the build-fixer agent (STANDARD tier) to:

  1. Collect Errors
    • Run the project's type check command (e.g., tsc --noEmit, mypy, cargo check, go vet)
    • Or run the project's build command to get build failures
    • Categorize errors by type and severity
  2. Fix Strategically
    • Add type annotations where missing
    • Add null checks where needed
    • Fix import/export statements
    • Resolve module resolution issues
    • Fix linter errors blocking build
  3. Minimal Diff Strategy
    • NO refactoring of unrelated code
    • NO architectural changes
    • NO performance optimizations
    • ONLY what's needed to make build pass
  4. Verify
    • Run the project's type check command after each fix
    • Ensure no new errors introduced
    • Stop when build passes

Command Guidance

  • Prefer omx sparkshell for noisy build/typecheck runs, repository search/listing, and bounded read-only inspection when summary output is enough.
  • Use raw shell when exact stdout/stderr, shell composition, dependency installation, or low-level debugging fidelity is required.
  • If omx sparkshell returns incomplete, ambiguous, or summary unavailable output, retry with a more precise command or the raw shell immediately.

Agent Delegation

delegate(
  role="build-fixer",
  tier="STANDARD",
  prompt="BUILD FIX TASK

Fix all build and TypeScript errors with minimal changes.

Requirements:
- Run tsc/build to collect errors
- Fix errors one at a time
- Verify each fix doesn't introduce new errors
- NO refactoring, NO architectural changes
- Stop when build passes

Output: Build error resolution report with:
- List of errors fixed
- Lines changed per fix
- Final build status"
)

Stop Conditions

The build-fixer agent stops when:

  • Type check command exits with code 0
  • Build command completes successfully
  • No new errors introduced

Output Format

BUILD FIX REPORT
================

Errors Fixed: 12
Files Modified: 8
Lines Changed: 47

Fixes Applied:
1. src/utils/validation.ts:15 - Added return type annotation
2. src/components/Header.tsx:42 - Added null check for props.user
3. src/api/client.ts:89 - Fixed import path for axios
...

Final Build Status: ✓ PASSING
Verification: [type check command] (exit code 0)

Best Practices

  • One fix at a time - Easier to verify and debug
  • Minimal changes - Don't refactor while fixing
  • Document why - Comment non-obvious fixes
  • Test after - Ensure tests still pass

Scenario Examples

Good: The user says continue after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.

Good: The user changes only the output shape or downstream delivery step (for example make a PR). Preserve earlier non-conflicting workflow constraints and apply the update locally.

Bad: The user says continue, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.

Use with Other Skills

Combine with other skills for comprehensive fixing:

With Ultrawork:

/ultrawork fix all build errors

Spawns multiple build-fixer agents in parallel for different files.

With Ralph:

/ralph fix the build

Keeps trying until build passes, even if it takes multiple iterations.

With Team:

/team "debug build failures and fix type errors"

Uses: explore → build-fixer → verifier workflow.

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.