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
- Vyrnexis/nim-agent-templatetheir own version, first seen Oct 15, 2026
- ROCm/FlyDSLtheir own version, first seen Oct 8, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- ROCm/FlyDSL★ 305same name
- Vyrnexis/nim-agent-template★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository51 other files it gives its agents.
- AGENTS.mdAGENTS.md
- architecture-remediationSkill
- attentionSkill
- classify-docSkill
- codebase-designSkill
- codebase-memory-mcpSkill
- codegraphSkill
- coding-standardsSkill
- contract-ledgerSkill
- conventional-commitsSkill
- database-migrationsSkill
- deduplicate-codeSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- github-issue-dependenciesSkill
- graphifySkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- implement-ticketSkill
- improve-codebase-architectureSkill
- project-delivery-managementSkill
- project-trackingSkill
- prototypeSkill
- repowiseSkill
- researchSkill
- resolving-merge-conflictsSkill
- review-architectureSkill
- review-specSkill
- setup-matt-pocock-skillsSkill
- spec-contractSkill
- spec-merge-cleanupSkill
- tddSkill
- teachSkill
- to-adr-docSkill
- to-docSkill
- to-specsSkill
- to-ticketsSkill
- triageSkill
- verify-architectureSkill
- verify-codeSkill
- verify-spec-closureSkill
- verify-specSkill
- verify-ticket-closureSkill
- verify-ticket-decompositionSkill
- wayfinderSkill
- wiki-lintSkill
- wiki-syncSkill
- wiki-synthesizeSkill
- writing-great-skillsSkill
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
- Distinctive: line 16
Isolation Principle: Only perform formatting actions on files touched in the workspace OR by the current ticket.
- Distinctive: line 17
Scope Extraction Invariant: Before running any style checks, you must explicitly identify the modified file paths using local version …
- Distinctive: line 18
Safety Invariant: If targeted lint fixes produce errors that cannot be solved automatically, do not attempt to guess manual overrides.
- Very specific: line 57
Reject Inline Overrides: If a code implementation generates lines exceeding the project's max-character limit, you must refactor the layout …
≈ “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.
Files
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
- 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).
- 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. - Escalation Exception: The only acceptable way to change line-length constraints is by modifying the project's global
pyproject.tomlorruff.tomlfile—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.pyExample 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.pyDoes 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
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.

