agentleFS
Z0CC0Z0CC0/ATLAS-mem/skills/atlas-fix/SKILL.md

atlas-fix

Skill0 starsChanged 10 days agoMITView on GitHub

Gets a failing build, type check or linter back to green with the smallest changes, one error at a time, re-running after each. Stops and says why instead of guessing: same error twice, more errors than before, a missing dependency, a change of design. Use for "atlas fix", "fix the build", "it does not compile", "type errors", "lint is red", "CI is failing" — in any language.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    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. Very specific:

    After the first run: more than five errors, or a build that takes longer than about twenty seconds, or a CI log to work from: delegate to …

    line 43

≈ “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

One error, one smallest change, run again. Never a rewrite to make a compiler quiet.

What to read

Everything below lives in the fix/ folder beside this file.

  1. fix/method.md, always: how to find the command, the order to fix in, when to stop, what the report looks like.
  2. One file for the toolchain that is failing, chosen by the project's files: typescript.md (package.json, tsconfig.json), python.md (pyproject.toml, requirements.txt, manage.py), go.md (go.mod), rust.md (Cargo.toml), java-kotlin.md (pom.xml, build.gradle, build.gradle.kts), swift.md (Package.swift, *.xcodeproj), cpp.md (CMakeLists.txt, Makefile), csharp.md (*.csproj, *.sln), dart.md (pubspec.yaml). No file for the toolchain: work from method.md alone and say so in the report.

What is being fixed, by the words of the request

"build", "compile", nothing named → the build command. "types", "typecheck" → the type checker only. "lint" → the linter only; formatting errors are fixed by the project's formatter command, not by hand, run on the files this session changed and no others. The linter's own rules and configuration are never edited to pass. "CI" → the first failing step of the workflow file, run locally; a step that cannot run locally is named and left. "tests" → only what stops the tests from running: import errors, compile errors, fixtures that do not load. A test that runs and fails on an assertion is a behaviour, not a build error: one line each in the report, handed back. Asked outright to make failing tests pass: method.md, last section.

Where the work goes

After the first run: more than five errors, or a build that takes longer than about twenty seconds, or a CI log to work from: delegate to the atlas-fixer subagent, when it exists, with the project root, the exact command, and the absolute paths of fix/method.md and the toolchain file (they live beside this file). It runs the whole loop where the logs stay and hands back the report and the list of files it changed; print the report unchanged and say the files are already edited. One or two errors you can see: fix here.

Who runs the command

The atlas-runner subagent, when it exists: give it the exact command, take back the verdict and the error lines, never the log. Without it: run the command with output to a file in the scratch directory and read only the error lines from that file. Either way the log does not enter this conversation.

Form

The active compression level governs the prose. It never overrides the report format in method.md: the shape stays, the words inside it shorten. Error strings are quoted exactly.

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.