# Lazy Skills > Routes multi-step or multi-tool tasks to the right combination of connected skills without loading every skill's full instructions upfront. Use this whenever a task plausibly touches more than one specialized skill in sequence or in combination — e.g. "query the database and validate the schema," "format this SQL and check it against the schema," or any request where completing it well would mean chaining two or more skilled capabilities together. Also use it proactively whenever you're about to invoke a skill and aren't sure whether related skills exist that the task also needs. Do NOT use this for single-skill tasks that already trigger cleanly on their own — it adds a lookup step that isn't worth it there. - Skill: `fibrousop07-dev/lazy-skills` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add fibrousop07-dev/lazy-skills` - Raw SKILL.md: https://api.skillmd.com/api/skills/fibrousop07-dev/lazy-skills/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Data & Analytics - Author: fibrousop07-dev (https://skillmd.com/u/fibrousop07-dev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fibrousop07-dev/lazy-skills --- # Lazy Skills ## Why this exists A large skill library is only useful if the model doesn't pay a token tax just for it existing. Every skill's frontmatter is already in context all the time — that's cheap and unavoidable. The expensive part is a skill's *body*, which only loads once the skill triggers. The risk with a big library isn't the skill count, it's tasks that quietly need two or three skills working together, where only loading the first one leaves you improvising the rest instead of using the tools built for it. This skill's job is narrow: when a task looks like it needs more than one connected skill, figure out which ones before you start, load only those, and don't touch anything else. If a task only needs one skill, get out of the way — don't add a lookup step to something that was already going to work. ## Step 1: Decide if this task needs the graph at all Most tasks don't. If the task maps cleanly onto one skill you already know about, just use that skill directly and skip everything below — reading `references/skill_map.json` for a single-skill task is pure overhead with no payoff. Reach for the graph when the task has any of these shapes: - It names two or more distinct actions that sound like they'd each be a skill's job ("query this, then format it, then validate it") - It's the kind of task where you already know the *first* skill to use, but finishing well obviously requires follow-on steps you don't have a tool for yet - You're not sure whether a skill you're about to use has companion skills that would improve the result, and the task is substantial enough that it's worth checking ## Step 2: Read the dependency graph Read `references/skill_map.json`. It's a small, flat map — skill name → intent, plus which other skills it `connects_to` and why. Treat the `connection_reason` field as the actual signal: it tells you *why* two skills are usually used together, so you can judge whether that reasoning applies to the task in front of you, rather than mechanically pulling in every connected node. You can also resolve connections programmatically instead of reading the whole file by eye: ```bash python scripts/check_deps.py [ ...] ``` This walks the graph breadth-first starting from the skill(s) you pass in and prints every connected skill it finds, with its intent. Pass in more than one starting skill if the task already told you it needs several. The script tracks visited nodes as it walks, so a cycle in the graph (skill A connects to B, B connects back to A) can't cause runaway expansion — it just stops re-visiting anything it's already seen. You don't need to reason about cycles yourself; the script handles it. ## Step 3: Load connected skills just-in-time, not upfront Once you know which skills the task needs, don't dump all of their instructions into context at once "to be safe." Load a connected skill's `SKILL.md` only right before you're about to actually use it — the same way you'd normally invoke any skill. If `check_deps.py` surfaces five connected skills but the task only ends up needing two of them, only load those two. Finding a skill's `SKILL.md` follows the normal skill directory layout: `~/.claude/skills/.agents/skills//SKILL.md` (or the project- local equivalent, if the skill in question is project-scoped rather than global — check both if you don't find it in one). If a skill name from the graph doesn't resolve to an actual installed skill (the map has drifted from what's actually installed), don't stop and error — just proceed without it and mention the mismatch in your response so the user can update `skill_map.json` later. The graph is a hint, not a hard dependency system. ## Step 4: Grow the graph from real usage `references/skill_map.json` ships with one small worked example (`db-query` → `sql-formatter`, `schema-validator`) rather than a speculative map of every installed skill. That's deliberate: a dependency you guessed at is often wrong, and a wrong edge is worse than a missing one because it actively misleads the next task. When you notice yourself manually chaining two skills together on a real task — the user asked for X, doing X well meant also reaching for Y — that's the signal to add a real edge to the graph, not to pre-populate it from skill names alone. To add one, append an entry under `skills` following the existing shape: `intent`, `connects_to`, `connection_reason`. Keep `connection_reason` honest and specific — it's what future-you (or future orchestrator runs) will use to decide whether the edge actually applies to a new task, so "these are usually used together" is worth less than "Y needs the schema that X just fetched." ## A note on portability across environments Every skill name in `skill_map.json` only means something relative to *whichever machine's skill library it was written against*. This file started life pointing at skills installed in one specific environment; if you install `lazy-skills` somewhere else — a different machine, a fresh Claude Code setup, a cloud or remote session — none of those names are guaranteed to exist there. That's expected, not a bug: Step 3's guidance above ("if a skill name doesn't resolve... proceed without it and mention the mismatch") is exactly the mechanism that keeps this from breaking anything when it happens. You'll just get a mismatch note instead of useful routing until the graph is adapted. If you're installing this in a new environment, the fastest fix is to rewrite `skill_map.json` against *that* environment's actual installed skills rather than assuming the shipped example applies — check what's really there (list `~/.claude/skills/.agents/skills/` or the project-local equivalent) before trusting any edge in this file.