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/bostonaholic/team/solid-principlesnpx skills add bostonaholic/team --skill solid-principlesgit clone --depth 1 https://github.com/bostonaholic/teamWhat 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.00032 | $0.00775 |
| Opus 5 | $0.00016 | $0.00387 |
| Sonnet 5 | $0.00006 | $0.00155 |
| Haiku 4.5 | $0.00003 | $0.00077 |
Grade A, and why
solid-principles 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 — 93 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SOLID Principles
Apply when writing new code; check for violations when reviewing. Each principle below carries the smells that betray it in a diff.
S — Single Responsibility
One reason to change — one actor or stakeholder whose requirements could change the code.
Smells: a unit with more than one clear purpose (UserService that validates,
persists, and sends email); and in a name (validateAndSave()); functions
past ~30 lines; multiple unrelated tests for one unit.
If you cannot name a function without "and", it has too many jobs.
O — Open/Closed
Open for extension, closed for modification. Adding behavior should not require changing existing tested code.
Smells: a switch/if-else chain on a type field that must be edited for
every new type; hardcoded variant lists; tests that break whenever a new
variant is added.
Fix by defining an interface for the varying behavior and adding implementations rather than branches.
L — Liskov Substitution
Subtypes are substitutable for their base types without the caller knowing which it got.
Smells: an override that throws NotImplementedError or does nothing;
callers checking instanceof before calling; subclasses weakening
preconditions or strengthening postconditions; tests that cannot run against
both base and subtype.
Design hierarchies on behavior, not taxonomy. Prefer composition when "is-a"
does not hold behaviorally. A subtype may restrict behavior (ReadOnlyList)
but must fulfill every contract the base advertises.
I — Interface Segregation
No client depends on methods it does not call.
Smells: a 10-method interface whose implementers each use three; implementing
by throwing UnsupportedOperationException; test doubles that must stub many
irrelevant methods.
Split large interfaces; compose small ones when a concrete type needs several contracts.
D — Dependency Inversion
High-level modules and low-level modules both depend on abstractions. Business logic does not import database drivers, HTTP clients, or filesystem APIs directly.
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 · 93 lines · 32 tokens per session scan A 8fd4d2aa6843
solid-principles is a skill published in the GitHub repository bostonaholic/team (11 stars, last pushed 2d ago), licensed MIT. It adds 32 tokens to every session and 775 once invoked, about $0.0002 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-30.
Other skills, from other repositories
tutti-workspace-app-factory
Create, convert, or repair one Tutti workspace app as either a self-contained publishable package under package/ or a Chrome-style local debug app under .tutti/dev-app/. Use for mention://workspace-app-factory/create handoffs, mention://workspace-app-factory handoffs, standalone app generation, adapting existing…
analyze-performance-traces
Analyze Chrome, Chromium, Electron, React DevTools, or Perfetto-compatible JSON traces and audit user-reported profiling findings without loading large artifacts into context; prove trigger-to-render/layout chains, separate measured facts from source inference, find exact code choke points, classify forced layout and…
tutti-app-release
Set up, review, run, or debug external repositories that publish a Tutti workspace app through the reusable Tutti App Release GitHub Actions workflow. Use for caller workflows, tutti.app.json manifests, @tutti-os/app-release-tools, S3/CloudFront release hosting, latest.json, versions.json, catalog.json, catalog-only…
tutti-record-agent-session-replay
From a Tutti checkout, run, audit, freshly replay, publish, or diagnose Session Replay cassettes that are driven by case-repository scenario scripts (CDP), not by interactive UI recording. Use for real-Provider capture while a scenario.mjs executes, cassette transport or semantic-state mismatches, fresh replay…
tutti-ui-system
Use when working with @tutti-os/ui-system components, replacing local UI with shared components, querying component ids or metadata, promoting UI into shared base or business components, or maintaining UI-system storyboard inventory.
tutti-architecture-review
Review tutti git diffs for project structure, layering, module ownership, and duplicate event-center infrastructure by planning focused architecture review tasks, then having the main agent orchestrate sub-agents for only the changed areas.