Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/sponge-b0b/polaris/format-codenpx skills add sponge-b0b/Polaris --skill format-codegit clone --depth 1 https://github.com/sponge-b0b/PolarisWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00066 | $0.01128 |
| Opus 5 | $0.00033 | $0.00564 |
| Sonnet 5 | $0.00013 | $0.00226 |
| Haiku 4.5 | $0.00007 | $0.00113 |
Grade A, and why
format-code scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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 (.):
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:
ruff format <path_to_modified_file_1> <path_to_modified_file_2>
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 91 lines · 66 tokens per session scan A 6fd57476008e
format-code is a skill published in the GitHub repository sponge-b0b/Polaris (4 stars, last pushed 2d ago), licensed Apache-2.0. It adds 66 tokens to every session and 1,128 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
release
Cut a versioned release of the DOS kernel — bump the version, draft release notes, commit, tag, push to master, and create a GitHub release. The tag push triggers the gated PyPI publish pipeline (publish.yml); the skill surfaces the run and its approval gate.
stable-release
Promote an already-shipped rolling release (vX.Y.Z) of the DOS kernel to a named stable channel — gated on a green kernel suite + a green third-party CI run on the candidate + a clean truth syscall + a soak window. Writes an evidence file and adds a stable/ git tag on the same commit. Does NOT bump versions or build…
dos-goal-fleet
Launch multiple goal-scoped workers in waves, each with a witness-gated stop condition and dos arbitrate file-tree safety. Use when an operator asks to run several independent goals in parallel and fold only verified ships.
dos-goal-gate
Ground a keep-working goal in evidence the worker did not author by wiring dos hook stop to refuse false done claims. Use for one self-stopping agent or loop worker; use dos-witness-claim for fold barriers.
dos-dispatch-loop
Run recurring dos-dispatch cycles, switching to dos-replan when the backlog drains and stopping on the kernel's loop verdict. Use for unattended dispatch->replan->dispatch work across disjoint lanes.
dos-supervise-loop
Keep a target count of dispatch loops alive across the workspace lane roster: spawn missing loops, scavenge stalled leases, and surface spinning workers. Use when supervising a DOS dispatch-loop fleet.