agentleFS
Sign inStart free
inxupsinxups/route-recovery/style-installer/SKILL.md

style-installer

Skill0 starsChanged 24 days agoMITView on GitHub

Install, link, update, sync, restore, remove, or troubleshoot STYLE rule packages for Codex or Claude Code with the STYLE CLI. Does not install the CLI executable or general agent skills.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use the official CLI reference and diagnostics table for the requested operation.

    line 8
  2. Very specific:

    Read the request, package, and installation records to determine the source or package name, target harnesses, required settings, and scope.

    line 12
  3. Very specific:

    Before installing a source, run style validate SOURCE --json and style plan SOURCE --harness HARNESS --json.

    line 13
  4. Very specific:

    Run the requested command and read its actual preview.

    line 14
  5. Very specific:

    Run style list --json in the same scope to verify the result.

    line 15
  6. Very specific:

    Use style --project DIR COMMAND ...

    line 30
  7. Very specific:

    Check source syntax, --set, routes, and advanced options in the documentation.

    line 32
  8. Very specific:

    Do not use doctor --reset-state for routine verification.

    line 36

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

STYLE installer

Use the official CLI reference and diagnostics table for the requested operation. These are Markdown pages; the HTML site renders client-side and is unreadable to fetch tools. Do not maintain a local manual. Check style --version and style help COMMAND before running commands.

Workflow

  1. Read the request, package, and installation records to determine the source or package name, target harnesses, required settings, and scope. Run style list --json before changing an existing installation. Ask only for information these sources do not establish and that affects the operation.
  2. Before installing a source, run style validate SOURCE --json and style plan SOURCE --harness HARNESS --json. Check diagnostics, rule mappings, and budgets.
  3. Run the requested command and read its actual preview. If it matches the authorized operation, enter y in an interactive terminal. A request for a preview or local files alone does not authorize installation.
  4. Run style list --json in the same scope to verify the result. Report the changes and remaining steps. Use style doctor --json when installation problems need investigation.

Commands

RequestCommand
Install a local directory, .style.md file, or Git sourcestyle install SOURCE --harness HARNESS --json
Link a local package for developmentstyle link SOURCE --harness HARNESS --json
Update a package from its recorded sourcestyle update NAME --json
Apply development edits or recompile snapshotsstyle sync NAME --json
Restore offline from the lock and snapshotsstyle restore --json
Remove a package or development linkstyle uninstall NAME --json

Operating rules

  • Use style --project DIR COMMAND ... for project operations. Place a custom --style-home DIR before the subcommand as well. Keep inspection, changes, and verification in the same scope. validate accepts neither global option.
  • Without an explicit harness selection, install and link select all detected harnesses. Stay within the requested scope and use --all only when requested.
  • Check source syntax, --set, routes, and advanced options in the documentation. Replace system instructions or enable --fail-closed only when the user intends that behavior. Do not alter rules or budgets to make installation pass.
  • --json controls output format. Use plan to preview without applying changes. The CLI has no --yes option. Do not supply an unconditional stream of approvals.
  • sync may write without prompting. Canceling approval partway through does not roll back packages already applied. Use update to refresh copied installations from their original sources.
  • Check the exit code, status, diagnostics, and result. A failed command may have written files, and exit code 0 can still carry warnings. registration-required (an error for some plugin routes, a warning for others) and refresh-required mean the files exist but the harness has not loaded the current plugin. Follow the report's registration commands within the authorized scope.
  • Do not use doctor --reset-state for routine verification. Do not report a successful preview as an active installation.

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.

Check your setup, free