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/filipebraida/adonisjs-starter-kit/layout-shellsnpx skills add filipebraida/adonisjs-starter-kit --skill layout-shellsgit clone --depth 1 https://github.com/filipebraida/adonisjs-starter-kitWrote 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/filipebraida/adonisjs-starter-kit/layout-shells)<a href="https://agentmods.dev/skills/filipebraida/adonisjs-starter-kit/layout-shells"><img src="https://agentmods.dev/badge/skills/filipebraida/adonisjs-starter-kit/layout-shells.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 | $0.00103 | $0.01265 |
| Opus 5 | $0.00051 | $0.00633 |
| Sonnet 5 | $0.00021 | $0.00253 |
| Haiku 4.5 | $0.00010 | $0.00127 |
Grade A, and why
layout-shells 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 4d 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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Layout shells
Every page imports the shell it needs; there is no runtime chooser. Variant / collapsible / direction / max-width are hardcoded inside the shell file — not props, not user-facing settings. If a project spun from this template doesn't need one of the shells (e.g. no marketing area), the shell file is deleted, not "disabled by config". The philosophy is starting clean over configuring at runtime — configurability adds branches that need to be tested, translated, permissioned; deletion doesn't.
Rules
- Every page imports its shell explicitly at the top of the page file. No wrapper picks the shell based on route, role, or props.
import AppLayout from '#common/ui/components/app_layout' export default function Page() { return <AppLayout>...</AppLayout> } - Shell decisions are hardcoded: variant, collapsible, direction, max-width live inside the shell file. Do not accept them as props.
- Header widgets are shared across shells that need them (
<NotificationBell />,<ToggleTheme />,<LanguageSwitcher />,<NavUser />) — same visual identity, imported directly by each shell that mounts them. - Nav configs live in a single file and are exposed as functions (
getMainNav(t),getFooterNav(t),getNavUser(t),getMobileFab(t)). Nav items support acan: 'permissionKey'field for RBAC gating — see [[authorization]]. Nav items are never hardcoded inside the shell file. - Providers stay at the root client entry, not inside shells. Theme, i18n, Tuyau, modal stack are mounted once so every shell renders inside them.
- Adding a shell is only worth it when the shape is genuinely new (installer wizard chrome, kiosk, checkout). Otherwise reuse an existing shell — the same page can render inside two different shells if two contexts need it.
Shell inventory (typical set)
Every app spun from this template starts with two:
AppLayout— the logged-in shell. Sidebar on desktop, bottom nav + top notification bar on mobile. Wraps every internal page (dashboard, users, settings, feature modules).AuthLayout— the pre-login shell (sign-in, sign-up, password flows). Simpler, no nav.
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.
- 4d ago First seen · 85 lines · 103 tokens per session scan A 60bafb2ff20e
layout-shells is a skill published in the GitHub repository filipebraida/adonisjs-starter-kit (94 stars, last pushed 24d ago), licensed MIT. It adds 103 tokens to every session and 1,265 once invoked, about $0.0005 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
coss-particles
Index of all COSS UI particle examples. Use when implementing UI features to find copy-paste-ready component patterns built on coss primitives. Each particle has a description and a JSON URL for easy installation.
coss
Helps implement coss UI components correctly. Use when building UIs with coss primitives and patterns (buttons, dialogs, selects, forms, menus, tabs, segmented controls, inputs, toasts, etc.), migrating from shadcn/Radix to coss/Base UI, composing trigger-based overlays, or troubleshooting coss component behavior.…
ui-beats
Use this skill when users want to add, customize, or troubleshoot UI Beats components in React/Next.js projects. It covers component selection, shadcn registry installation from uibeats.com, the UI Beats MCP server, motion and reduced-motion handling, and integration patterns for animated sections.
review-pr
Deep code review of a single open PR in nrwl/nx. Checks the PR out only inside an isolated sandbox, then runs four fixed reviewers: implementation (correctness, errors, types, performance), verification (tests, ticket grounding, comments, and docs), approach, and security. A reproduce-verifier executes a runnable…
dist-build-migration
Migrate an Nx package to build to a local dist/ directory with nodenext module resolution, exports map, and @nx/nx-source condition.
multi-version-compliance
Apply or review multi-version support compliance for first-party Nx plugins. Primary entry point: a Linear task ID (NXC-XXXX) from the "Multi-version supported across plugins" milestone — the task carries the resolved support window, findings, and "Needs human decision" items. Falls back to self-discovery when no task…