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 3awny/qship --skill qdirectorygit clone --depth 1 https://github.com/3awny/qshipWrote 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/3awny/qship/qdirectory)<a href="https://agentmods.dev/skills/3awny/qship/qdirectory"><img src="https://agentmods.dev/badge/skills/3awny/qship/qdirectory/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/3awny/qship/qdirectory"><img src="https://agentmods.dev/badge/skills/3awny/qship/qdirectory.svg" alt="Reviewed on agentmods" width="80" 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.00058 | $0.01884 |
| Opus 5.5 | $0.00023 | $0.00754 |
| Sonnet 5.5 | $0.00012 | $0.00377 |
| Haiku 4.5 | $0.00006 | $0.00188 |
Grade A, and why
qdirectory 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 1mo 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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Directory Organization Review
You are a directory-organization specialist for the {{COMPANY_SLUG}} monorepo. The goal is to catch new files that landed in the wrong place — wrong layer, wrong domain, or in a "common/utils/shared" directory whose existing contents don't actually fit. Without this catch, parallel hierarchies grow and refactors become impossible.
Scope
Default to new and substantively-moved files in the diff:
git diff develop...HEAD --diff-filter=AR --name-only
For each file, classify which repo it lives in (any in your repos.json) and which layer (api/, services/, repositories/, data_models/, schemas/, migrations/alembic/, ui/, connectors/, tests/). Whole-repo audits are an opt-in (--full) — too noisy as a default.
Core principle: read the directory before placing into it
A directory's name tells you what someone intended. Its contents tell you what it is. They diverge over time. Before suggesting that a new file go into an existing directory, list its contents and read 2–3 representative files. The cohesive purpose you find determines whether the new file fits.
Example failure:
{{CODEBASE_PATH_PREFIX}}/{{PRIMARY_REPO_NAME}}/common/looks generic, but its contents are all {{COMPANY_SLUG_UPPER}} {{PRIMARY_REPO_NAME}} API clients (users.py,gadgets.py,gizmos.py). Putting connector infrastructure there mixes two unrelated concerns. Correct location:{{CODEBASE_PATH_PREFIX}}/{{PRIMARY_REPO_NAME}}/connectors/common/— following thecommon/pattern already used inside individual connectors but at the cross-connector level.
This is the most common failure mode of automated directory advice — recommending placement based on the directory's name rather than its current contents.
{{COMPANY_SLUG}} layer map
Use this as the anchor when assessing placement. Every new file should map to exactly one cell:
| Layer | What lives there | What does NOT |
|---|---|---|
api/ (or routers/) |
FastAPI route declarations, request/response handling, HTTP-specific validation | Business logic, SQL, domain rules |
services/ |
Business logic, orchestration across multiple repos, side-effect coordination | Direct SQLAlchemy queries, HTTP serialization |
repositories/ |
Data access — single-aggregate CRUD, queries, embedding side-effects | Cross-aggregate orchestration, HTTP types |
data_models/ (SQLAlchemy) |
ORM model classes only | Pydantic schemas, business logic |
schemas/ (Pydantic) |
Request / response shapes, validators | ORM models, DB queries |
migrations/alembic/versions/ |
Alembic revisions | Anything else |
connectors/ |
Third-party integrations (External ERP, external CRM/accounting connector, etc.) | {{COMPANY_SLUG_UPPER}}-internal API clients |
ui/components/react/ |
React/TSX components | Page-level Dash layouts |
ui/pages/ |
Dash page layouts and callbacks | React component definitions |
tests/ |
Test files (test_*.py, *.test.tsx) |
Production code |
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.
- 1mo ago First seen · 110 lines · 58 tokens per session scan A 8f4f64c6f954
qdirectory is a skill published in the GitHub repository 3awny/qship (2 stars, last pushed 3mo ago), licensed MIT. It adds 58 tokens to every session and 1,884 once invoked, about $0.0002 per session on Opus 5.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
reviewer
Philosophical guardrails enforcer — independently audits code, tests, and spec for layered-integrity, Why>What, error-as-data, and the related Ironclad philosophical invariants. Activate only when the connected project contains spec.yaml or the user explicitly names Cladding; ignore ordinary requests in uninitialized…
plan-eng-review
Engineering plan review. Reviews a plan document for architecture, code quality, test coverage, and performance before implementation begins. Produces a coverage diagram, failure modes map, and parallelization strategy. Use when asked to "review this plan", "eng review", or "architecture review".
review
Pre-merge code review — the single canonical review of a change before it lands. Covers BOTH diff safety/structure (SQL safety, LLM trust-boundary violations, conditional side effects) AND engineering quality (architecture fit, edge cases, test coverage, performance). Use when asked to "review this PR", "code review"…
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements.
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation.
review
5-pass structured code review — correctness, security, performance, readability, consistency.