agentleFS
sponge-b0bsponge-b0b/Polaris/.agents/skills/format-code/SKILL.md

format-code

Skill4 starsChanged 3 months agoApache-2.0View on GitHub

Formats, cleans, and structures modified or newly generated files in the workspace. Use this skill whenever work is being performed on an individual active ticket (e.g., using the `$implement-ticket` skill) OR on-demand anytime current working files require code formatting, style compliance, and cleaning prior to running local verification checks.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    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:

    Isolation Principle: Only perform formatting actions on files touched in the workspace OR by the current ticket.

    line 16
  2. Distinctive:

    Scope Extraction Invariant: Before running any style checks, you must explicitly identify the modified file paths using local version …

    line 17
  3. Distinctive:

    Safety Invariant: If targeted lint fixes produce errors that cannot be solved automatically, do not attempt to guess manual overrides.

    line 18
  4. Very specific:

    Reject Inline Overrides: If a code implementation generates lines exceeding the project's max-character limit, you must refactor the layout …

    line 57

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

Targeted Code-Formatting and Auto-Fix Style Skill

Objective

Enforce strict syntactic consistency and layout rules strictly across files altered or introduced in the workspace OR by the active issue ticket, fixing auto-resolvable lint issues and aligning modified blocks with standard project coding guidelines.

Guardrail Constraints

  • Isolation Principle: Only perform formatting actions on files touched in the workspace OR by the current ticket. Do not introduce refactors, delete unrelated feature modules, or modify logical variable assignments. Never run global repository-wide formatting commands inside an isolated workspace OR ticket lifecycle.
  • Scope Extraction Invariant: Before running any style checks, you must explicitly identify the modified file paths using local version control records or active workspace diffs.
  • Safety Invariant: If targeted lint fixes produce errors that cannot be solved automatically, do not attempt to guess manual overrides; log the file paths and error details clearly for the developer or next workflow block and report when completed.

Execution Steps

Execute these formatting and correction operations sequentially to standardize your targeted code alterations:

Step 1: Identify Targeted Changes

Locate and isolate the precise file paths modified or created in the workspace OR as part of the current ticket scope. Use git status or internal session tracking to extract the explicit target list:

git status --porcelain | awk '{print $2}' | grep '\.py$'

Step 2: Targeted Automated Lint Correction

Execute the ruff lint engine using the explicit auto-fixer modifier, targeting only the space-separated list of file paths extracted in Step 1. Do not use a trailing dot (.):

uv run --locked ruff check --fix <path_to_modified_file_1> <path_to_modified_file_2>

Step 3: Targeted Code Layout Standardisation

Execute the native code formatter over only the identified target file paths to adjust line spacing, wrapping bounds, indentation, and quote alignments to match our 88-character rule baseline:

uv run --locked ruff format <path_to_modified_file_1> <path_to_modified_file_2>

Code Quality & Suppression Guardrails

You must preserve the integrity of the project's formatting metrics. You are strictly forbidden from hiding or bypassing linting standards to make code changes pass verification checks.

Core Constraint

Never generate, execute, or commit automated rule suppressions. You are explicitly prohibited from running commands like uv run --locked ruff check . --select E501 --add-noqa (or any equivalent variant like C901) to inject # noqa: E501 or C901 comments into the codebase. You must never use --add-noqa in any form to bypass or suppress project rules. All formatting must be achieved through proper code restructuring and layout adjustments.

Compliance Rules

  1. No Automation Cheating: Long lines must be broken up manually using Python's native syntactic elements (e.g., implicit string concatenation inside parentheses, wrapping data structures, or breaking logical blocks).
  2. Reject Inline Overrides: If a code implementation generates lines exceeding the project's max-character limit, you must refactor the layout of the code until uv run --locked ruff check . passes naturally.
  3. Escalation Exception: The only acceptable way to change line-length constraints is by modifying the project's global pyproject.toml or ruff.toml file—and this requires explicit, manual human authorization before execution.

Examples

Example 1: Isolated Ticket Code Cleanup

User: "I just finished writing the code modifications for ticket #4." Agent Response: "I am invoking the format-code skill to identify the specific files changed under ticket #4, automatically resolve targeted lint warnings, and format those exact Python structures before triggering validation."

# 1. Agent identifies targeted changes
```bash
git status --porcelain | awk '{print $2}' | grep '\.py$'

# 2. Agent runs targeted lint correction
uv run --locked ruff check --fix core/runtime/execution/runtime_engine.py

# 3. Agent runs targeted code formatting
uv run --locked ruff format core/runtime/execution/runtime_engine.py

Example 2: Workspace Code Changes

User: "Can you format the files I've been working on before I push my changes?" Agent Response: "I am invoking the format-code skill to identify the specific files you worked on, automatically resolve targeted lint warnings, and format those exact Python structures before triggering validation."

# 1. Agent identifies targeted changes
```bash
git status --porcelain | awk '{print $2}' | grep '\.py$'

# 2. Agent runs targeted lint correction on your current working files
uv run --locked ruff check --fix core/auth/login.py tests/test_login.py

# 3. Agent runs targeted code formatting on your current working files
uv run --locked ruff format core/auth/login.py tests/test_login.py

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.