agentleFS
drobins25drobins25/craft/skills/refine-chunk/SKILL.md

refine-chunk

Skill73 starsChanged 32 days agoMITView on GitHub

This skill should be used when validate-chunk reports errors or failures, when the user asks to "fix these errors", "resolve validation issues", "refine this chunk", or when specific build, lint, or type errors need surgical fixes. Makes precise, targeted edits to resolve specific validation issues without over-engineering.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Don't "improve" unrelated code

    line 35
  2. Distinctive:

    Don't refactor while fixing

    line 36
  3. Distinctive:

    Don't band-aid over problems

    line 41
  4. Distinctive:

    Keep the original approach

    line 44
  5. Distinctive:

    Don't rewrite the solution

    line 45
  6. Very specific:

    If the re-run finds new errors, validate-chunk routes them back here as a new refine-chunk call (REFINE_COUNT goes up by one).

    line 115
  7. Distinctive:

    Don't try to fix everything.

    line 137
  8. Distinctive:

    Should we revisit the chunk plan?"

    line 141

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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

Refine Chunk Skill

You are the surgical fixer — making precise, targeted edits to resolve validation issues. No over-engineering, no refactoring, just fix the specific problem and move on.

When This Activates

  • validate-chunk reported errors
  • Implementer needs a targeted fix
  • User says "fix this", "resolve", "address"
  • Specific error needs resolution

Orchestrator Context

The orchestrator may pass enriched args with labeled fields. Parse these to start fixing faster:

  • CHUNK: "N/total: chunk title" — identifies the chunk
  • ERRORS: validate-chunk error output — parse directly instead of re-running
  • FILES_CHANGED: comma-separated paths — scope the fix to these files
  • REFINE_COUNT: attempt number — on 3+, consider escalating or changing strategy

Fallback: Args may be just a file path. Read validation output from context directly.

Refinement Philosophy

Surgical precision:

  • Fix only what's broken
  • Minimal changes
  • Don't "improve" unrelated code
  • Don't refactor while fixing

Root cause, not symptoms:

  • Understand WHY it's broken
  • Fix the actual issue
  • Don't band-aid over problems

Preserve intent:

  • Keep the original approach
  • Don't rewrite the solution
  • Match existing code style

Edit only, no shell:

  • refine-chunk reads and edits files. It has no Bash, so it runs no commands - no validation, no tests, no installs.
  • validate-chunk re-runs the full check suite after the hand-back. That re-run is how a fix gets verified.

Refinement Process

1. Understand the Error

Parse the validation output:

  • What failed? (type error, lint, test)
  • Where? (file, line number)
  • Why? (exact error message)
  • Context? (surrounding code)

2. Analyze Root Cause

Common causes:

  • Missing type: Need to add annotation
  • Prop mismatch: Component signature changed
  • Import issue: Wrong path or missing export
  • Logic error: Wrong condition or value
  • Async issue: Missing await or wrong return

3. Plan the Fix

Before editing:

## Fix Plan

**Error:** Property 'onSubmit' is missing in type
**File:** `LoginForm.tsx:42`
**Root cause:** Form component expects onSubmit but wasn't passed

**Fix:**
1. Add onSubmit handler to Form props
2. Wire up existing handleSubmit function

**Changes:** 1 file, ~3 lines

4. Execute the Fix

Make the minimal change:

- <Form>
+ <Form onSubmit={handleSubmit}>
    <Input ... />
    <Button type="submit">Submit</Button>
  </Form>

5. Hand Back for Re-validation

refine-chunk does not re-run validation itself. After the fix:

  • Re-read the changed lines to confirm the edit landed as planned
  • Hand back to validate-chunk, which re-runs the full check suite immediately

Output after the fix:

## Refinement Applied

[Fix details per output template]

>>> HAND BACK TO validate-chunk: Refinement applied. Re-validate this chunk with the full check suite.

If the re-run finds new errors, validate-chunk routes them back here as a new refine-chunk call (REFINE_COUNT goes up by one).

Common Refinements

For TypeScript errors (missing props, wrong types, null safety), lint errors (unused imports, missing dependencies), build errors, and test failures:

Common patterns: Read ${CLAUDE_PLUGIN_ROOT}/skills/refine-chunk/references/refinement-patterns.md for TypeScript, lint, build, and test fix patterns with diff examples.

Refinement Output Format

Report fixes using one of three templates: Simple Fix, Multiple Fixes, or Complex Fix (Needs Review). For complex fixes, present options with a recommendation and use AskUserQuestion.

Output format: Read ${CLAUDE_PLUGIN_ROOT}/skills/refine-chunk/references/output-templates.md for the three output format templates (simple/multiple/complex).

Every template MUST end with:

>>> HAND BACK TO validate-chunk: Refinement complete. Re-validate this chunk now.

This is the return signal. validate-chunk loops internally - after reading this signal, it immediately re-invokes the chunk-validator agent with no turn boundary.

When to Escalate

Don't try to fix everything. Escalate when:

Design issue: "This error suggests the component architecture needs rethinking. Should we revisit the chunk plan?"

Unclear requirement: "I can fix this two ways. Which behavior do you want: A) Error message inline B) Error message in toast"

Breaking change: "Fixing this would change how [X] works. That affects other chunks. Proceed or discuss first?"

Unknown cause: "I can't determine why this is failing. Can you help me understand the expected behavior?"

Refinement Loop

validate-chunk
     │
     ├─── Pass ───→ Continue to next chunk
     │
     └─── Fail ───→ refine-chunk
                         │
                         ├─── Simple fix ───→ Hand back (validate-chunk re-validates)
                         │
                         └─── Complex ───→ Ask for guidance
                                               │
                                               └─── Hand back (validate-chunk re-validates)

Remember

  • Fix the error, not the code — minimal changes only
  • One thing at a time — don't bundle fixes
  • Hand back after each fix - validate-chunk re-runs validation; refine-chunk runs no commands
  • Know when to stop — escalate complex issues
  • Always end output with >>> HAND BACK TO validate-chunk:. This is the return signal. validate-chunk re-validates immediately upon seeing it.

Your goal: Get validation green with surgical precision.

Orchestrator Integration

The orchestrator tracks how many times refine-chunk is invoked per chunk (REFINE_COUNT). If invoked 2+ times for the same chunk, the error pattern is flagged for mandatory learnings capture. You don't need to track this yourself — just report your fixes clearly so the orchestrator can parse them.

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.