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 skills add tranhieutt/software_development_department --skill design-systemgit clone --depth 1 https://github.com/tranhieutt/software_development_departmentWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tranhieutt/software_development_department/design-system)<a href="https://agentmods.dev/skills/tranhieutt/software_development_department/design-system"><img src="https://agentmods.dev/badge/skills/tranhieutt/software_development_department/design-system.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $0.00039 | $0.01005 |
| Opus 5 | $0.00019 | $0.00502 |
| Sonnet 5 | $0.00008 | $0.00201 |
| Haiku 4.5 | $0.00004 | $0.00101 |
Grade A, and why
design-system 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 8d 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 — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
System Design
Phase 1: Clarify requirements (always do this first)
Ask before designing:
- Scale: How many users/requests/day? Read-heavy or write-heavy?
- Consistency: Strong (banking) or eventual (social feed)?
- Availability target: 99.9% (8.7h/yr downtime) or 99.99% (52min/yr)?
- Latency budget: p99 < 100ms? < 1s?
- Geography: Single region or multi-region?
Capacity estimation shortcuts
1M users/day active → ~12 req/s avg, ~120 req/s peak (10x)
1KB per request → 1M req/day = ~1GB/day = ~365GB/year
Read:write ratio 10:1 (typical social) → optimize read path first
1 server handles ~1000 req/s (rule of thumb for I/O-bound services)
Component breakdown template
Client layer → Web / Mobile / API consumers
CDN → Static assets, edge caching
API Gateway → Rate limiting, auth, routing, SSL termination
Services → Domain-specific services (User, Order, Payment, Notification)
Cache → Redis for hot data (sessions, rate limits, computed results)
Database → Primary DB + Read replicas
Message queue → Async operations, event-driven decoupling
Storage → Object storage for files (S3/GCS)
Monitoring → Metrics, logs, traces, alerts
Database selection guide
| Need | Choose |
|---|---|
| ACID transactions, relations | PostgreSQL |
| High-scale document store | MongoDB |
| Key-value, cache, pub/sub | Redis |
| Time-series data | TimescaleDB / InfluxDB |
| Graph relationships | Neo4j |
| Full-text search | Elasticsearch |
| Analytical/OLAP | ClickHouse / BigQuery |
Caching strategies
Cache-aside (read): App checks cache → miss → DB → write to cache
Write-through: Write to cache AND DB simultaneously (consistent, slower writes)
Write-behind: Write to cache → async flush to DB (fast writes, risk of loss)
Read-through: Cache handles DB reads automatically
TTL guidelines:
- Sessions: 15-30 min
- User profile: 5 min
- Product catalog: 1 hour
- Config/settings: 24 hours
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.
- 8d ago First seen · 116 lines · 39 tokens per session scan A 53dd43e9edb9
design-system is a skill published in the GitHub repository tranhieutt/software_development_department (72 stars, last pushed 3mo ago), licensed MIT. It adds 39 tokens to every session and 1,005 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
playwright-cli
Automates browser interactions for testing and validating your own web applications using playwright-cli. Use when you need terminal-first browser control for navigation, form filling, screenshots, tracing, bound browser sessions, debugging, or generating Playwright test code. Only use against applications you own or…
database-migrations
Database migration best practices for schema changes, data migrations, rollbacks, and zero-downtime deployments across PostgreSQL, MySQL, and common ORMs (Prisma, Drizzle, Kysely, Django, TypeORM, golang-migrate).
flutter-ui
Build Flutter UI from Figma MCP or image input. Scans src for design tokens (colors, sizes, text styles), existing components, and naming conventions before writing a single line of code. Never hard-codes values.
serena
Serena code intelligence — LSP-powered symbol navigation, diagnostics, and targeted code surgery. Activate before complex refactors, cross-file analysis, or when graph tools need symbol-level depth.
analyze
Risk analysis and approach selection before planning. Use when requirements are ambiguous, approaches vary, or work touches hub/bridge nodes. Skip for typo fixes.
prototype
Build throwaway code to validate an uncertain approach before committing to a plan. Two branches — Logic (terminal state machine) or UI (multiple designs on one route with URL-param switcher). No persistence, no tests, single-command start. Use between analyze and plan when the approach itself is uncertain.