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/phuonghx/aim-cli/lint-and-validatenpx skills add phuonghx/aim-cli --skill lint-and-validategit clone --depth 1 https://github.com/phuonghx/aim-cliWhat 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.00084 | $0.00524 |
| Opus 5 | $0.00042 | $0.00262 |
| Sonnet 5 | $0.00017 | $0.00105 |
| Haiku 4.5 | $0.00008 | $0.00052 |
Grade A, and why
lint-and-validate 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.
What it actually says
Lint and Validate
Treat validation as part of writing the code, not a separate chore. Code is not "done" while a checker still complains.
Toolchain by ecosystem
Node.js / TypeScript
- Style + autofix --
npm run lint, ornpx eslint "<path>" --fixwhen there is no script - Type safety --
npx tsc --noEmit - Dependency audit --
npm audit --audit-level=high
Python
- Lint + autofix --
ruff check "<path>" --fix(fast, covers most rules) - Static security --
bandit -r "<path>" -ll - Type safety --
mypy "<path>"
The validation loop
- Make the edit.
- Run the relevant checks, e.g.
npm run lint && npx tsc --noEmit. - Read the output carefully -- look at the final summary, not just the exit code.
- Fix what it reports and re-run. Repeat until clean. Reporting code as finished while the summary shows failures is not acceptable.
When a step fails
- Linter complains -- resolve the style or syntax problem right away; many issues autofix.
- Type check complains -- reconcile the type mismatch before moving on.
- No tooling configured -- look for
.eslintrc,tsconfig.json, orpyproject.tomlin the project root and propose adding the missing config rather than skipping the check.
Non-negotiable: nothing gets committed or called complete until these checks pass.
Scripts
| Script | What it does | How to run |
|---|---|---|
scripts/lint_runner.py |
Detects the stack and runs its linters/type checks | python scripts/lint_runner.py <project_path> |
scripts/type_coverage.py |
Estimates type-annotation coverage | python scripts/type_coverage.py <project_path> |
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 46 lines · 84 tokens per session scan A 264f5de48df6
lint-and-validate is a skill published in the GitHub repository phuonghx/aim-cli (1 stars, last pushed 2mo ago), licensed MIT. It adds 84 tokens to every session and 524 once invoked, about $0.0004 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
hs-release
Cut a core Hindsight release (vX.Y.Z) and open the changelog + blog PR. Use when asked to cut/start a release, bump the version, or publish a new Hindsight version.
research-repository
Build a repository that makes findings findable, reusable, and cumulative across teams. Use when the same research keeps getting redone. For synthesising one study, use affinity-diagram.
survey-design
Design unbiased survey instruments — question wording, scales, and sampling — to measure attitudes at scale. Use when you need quantitative breadth. For behavioural experiments, use a-b-test-design (prototyping-testing).
design-critique
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use heuristic-evaluation (prototyping-testing).
design-sprint-plan
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use team-workflow.
handoff-spec
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use design-qa-checklist; for reusable library components use component-spec (design-systems).