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 avelikiy/great_cto --skill vertical-restaurantsgit clone --depth 1 https://github.com/avelikiy/great_ctoWrote 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/avelikiy/great_cto/vertical-restaurants)<a href="https://agentmods.dev/skills/avelikiy/great_cto/vertical-restaurants"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/vertical-restaurants/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/avelikiy/great_cto/vertical-restaurants"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/vertical-restaurants.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00088 | $0.02415 |
| Opus 5 | $0.00044 | $0.01208 |
| Sonnet 5 | $0.00018 | $0.00483 |
| Haiku 4.5 | $0.00009 | $0.00242 |
Grade A, and why
vertical-restaurants 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 7d 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 — 164 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Vertical: restaurants & hospitality — don't spec it naive
Restaurants run on razor-thin margins (net 3–6%) with a hostile incumbent
stack. A spec that treats a menu as a flat list of {name, price} or
ignores who already owns the POS will ship something no operator can use.
This skill loads the domain so architect/pm sound like they've worked a
shift.
The 4 products in this vertical:
| Product | Archetype | One-liner |
|---|---|---|
| online-ordering | content | Own menu + checkout for dine-in/pickup/delivery — dodge aggregator fees |
| reservations | booking | Bookings, tables, text-the-waitlist |
| loyalty | crm | Points, offers, win-back |
| shift-scheduling | booking | Rota, open shifts, swaps with coverage rules |
Incumbents to position against: Toast (POS, ~$69–165/mo + hardware + 2.49%+ per swipe), Square (POS/SMB), SevenRooms (reservations/CRM, upmarket), ChowNow (commission-free ordering), DoorDash / Uber Eats / Grubhub (aggregators, 15–30% commission per order).
1. Domain vocabulary (use these words in the spec)
- COGS / food cost % — cost of ingredients ÷ menu price. Target ~28–35%.
- Prime cost — food cost + labor cost; the number operators obsess over (target ≤ ~60% of sales).
- Menu engineering — classifying items by popularity × margin into stars (high/high), plowhorses, puzzles, dogs (low/low). Drives what gets promoted or cut.
- 86'd — an item is out of stock / unavailable ("we're 86 on the salmon"). Must propagate instantly to every ordering channel.
- Modifiers / mods — choices on an item (size, temp, add bacon, no onions, sub fries). Grouped, with required/optional + min/max rules.
- Covers — number of guests served (a "200-cover night").
- Turn time — how long a table is occupied; reservations math depends on it (a 2-top turns in ~75 min).
- FOH / BOH — front of house (servers, host, bar) / back of house (kitchen, prep, dish). Scheduling and tips differ between them.
- Tip pooling — pooled tips split by rule (hours, role, points). Legally constrained — see §6.
- Comps / voids — comp = item given free (manager discretion); void = item removed before it's made. Both need audit trails.
- Ticket times — elapsed time from order fired to served; the kitchen's core SLA.
- Third-party aggregator commission — the 15–30% DoorDash/Uber Eats/ Grubhub take. The pain that makes owned ordering a wedge.
- KDS (kitchen display system) — screen in the kitchen that replaces paper tickets; orders route to it by station.
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.
- 7d ago First seen · 164 lines · 88 tokens per session scan A 2fb5db582c62
vertical-restaurants is a skill published in the GitHub repository avelikiy/great_cto (92 stars, last pushed yesterday), licensed MIT. It adds 88 tokens to every session and 2,415 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-09-03.
Other skills, from other repositories
spec-drift
Standalone plan-vs-code audit on any branch: runs /ship Step 8's plan-completion section from disk (hash-pinned) against an explicit plan and base. Report, JSON, exit code. Never edits code.
third-lens-review
After Claude self-pitfall + Codex on a ship-worthy/architecture/RT/security/contract change: run a third external model house (distant training distribution → different blind spots) on the patched artifact, then adversarial synthesis.
quality-review
After a PRD, spec, or plan, before implementation: hunt perceived-quality pitfalls (silent failures, missing loading/empty states, error recovery, state drift) that make a product feel cheap. Complements pitfall-verification.
boundaries
Analyze Phoenix context boundaries and module coupling via mix xref. Use when checking cross-context calls, validating dependencies, before splitting modules, or reviewing architecture.
elixir-idioms
OTP/BEAM patterns and Elixir idioms — GenServer, Supervisor, Task, Registry, pattern matching, with chains, pipes. Use when designing processes or debugging BEAM issues.
triage
Triage review findings interactively — approve, skip, or prioritize each issue. Use after /phx:review to filter findings before fixing.