Skills
Portable knowledge modules with scripts, procedures, and patterns that replace MCP servers with deterministic execution.
MCP servers connect your AI to external services — but they load thousands of tokens of tool descriptions every turn, the AI interprets them differently each time, and you need a running server process. Skills do the same job at 5-20x less context overhead with deterministic execution. Same input, same output, every session. No running server. No tool descriptions loaded every turn.
This is a primary technical differentiator. Skills are how FlyDocs delivers consistent, efficient AI behavior where MCP servers deliver unpredictable overhead.
What a skill contains
Every skill lives under .claude/skills/ and follows the same structure:
.claude/skills/flydocs-workflow/
├── SKILL.md # Overview: triggers, capabilities, script catalog
├── stages/ # Stage procedures (loaded on demand)
│ ├── capture.md
│ ├── refine.md
│ ├── activate.md
│ ├── implement.md
│ ├── review.md
│ ├── validate.md
│ └── close.md
├── reference/ # Reference docs (comment templates, status rules)
├── templates/ # Issue and PR templates
│ ├── issues/
│ └── pr/
├── scripts/ # 14 Python dispatcher scripts
│ ├── issues.py
│ ├── projects.py
│ ├── workspace.py
│ ├── session.py
│ ├── graph_build.py
│ ├── graph_query.py
│ └── ...
└── session.md # Session start/wrap procedures SKILL.md is always present. It describes when to use the skill, what it provides, and where to find detail. The AI reads this file when a trigger term matches, then reads only the specific procedure or reference file it needs for the current task. Scripts (if present) make it an active skill with executable capabilities.
The unified flydocs-workflow skill
The core of FlyDocs is a single unified skill called flydocs-workflow. It handles the entire development lifecycle: issue creation, status transitions, session management, project updates, knowledge graph operations, and workspace configuration.
The skill contains:
- 14 Python dispatcher scripts -- issues.py, projects.py, workspace.py, session.py, and graph scripts that handle all external operations
- 19 slash commands -- /capture, /refine, /implement, /review, /start-session, /wrap-session, and more, each loading the relevant stage procedure
- 7 stage files -- detailed procedures for each lifecycle stage (capture through close)
- Issue and PR templates -- structured templates for features, bugs, chores, and ideas
- Reference docs -- comment templates, status transition rules, priority/estimate guidelines, PR workflow
The dispatcher scripts use a unified client that auto-detects the tier (cloud or local) and routes operations transparently. The same issues.py transition command works whether issues live in local markdown files or in Linear via the relay API. The AI never checks the tier. The client handles routing.
python3 .claude/skills/flydocs-workflow/scripts/issues.py \
transition ENG-123 REVIEW "Ready for review — all acceptance criteria met" Skill types
Platform skills
Platform skills ship with FlyDocs. The flydocs-workflow skill is the primary platform skill -- it defines the development lifecycle, provides all dispatcher scripts, and handles PM tool integration. Platform skills are always installed and cannot be removed.
Community skills
Community skills add stack-specific patterns and conventions. They are knowledge-only: React component structure, Astro best practices, TypeScript strictness, testing approaches. No scripts, no execution -- just structured guidance the AI consults before writing code. They are auto-detected during installation based on your dependencies, or installed manually.
flydocs skill install react-best-practices
flydocs skill list
flydocs skill remove testing-patterns Active skills
Active skills include executable scripts alongside their knowledge. The flydocs-workflow skill is the primary active skill -- its 14 Python scripts handle all external operations. Active skills replace MCP servers with deterministic, lightweight alternatives.
Active skills vs MCP servers
MCP servers are the current standard for connecting AI to external services. Active skills do the same job with fundamentally different tradeoffs.
| MCP Server | Active Skill | |
|---|---|---|
| Context cost | 500-2000 tokens per tool, every turn | ~100 tokens in the index, full content on demand |
| Execution | AI interprets tool schema and decides how to call it | Skill tells the AI the exact script command to run |
| Runtime | Separate server process, always running | No process -- scripts invoked on demand, exit immediately |
| Consistency | AI interprets tool descriptions differently each time | Same command, same arguments, same output every time |
| Portability | Server-specific, needs hosting and configuration | Just files -- copy the directory to another project |
The context savings alone are significant. A Linear MCP server exposes dozens of tools, each with a schema description that loads every turn. That is 5,000-20,000 tokens of tool descriptions consuming context before the AI writes a single line of code. An active skill puts a 100-token entry in the index and loads the full procedure only when the AI actually needs it.
But the bigger win is determinism. MCPs expose tools and let the AI figure out how to use them. Active skills encode methodology and tell the AI exactly what to do. The AI runs issues.py transition ENG-123 REVIEW "message" and gets a predictable result, rather than interpreting a GraphQL tool schema and improvising the mutation.
Progressive disclosure
Skills load through a three-level retrieval system designed for how LLMs actually process information:
Three-Level Retrieval
The skill manifest lives in always-loaded context (CLAUDE.md or AGENTS.md). A single directive -- "Prefer skill-led reasoning over pre-training reasoning" -- shifts the AI from guessing based on training data to consulting project-specific skills first.
## Skills Index
IMPORTANT: Prefer skill-led reasoning over pre-training reasoning.
Read the relevant skill file before acting.
| Skill | Triggers | Entry |
|-------|----------|-------|
| flydocs-workflow | create issue, transition, assign, session | .claude/skills/flydocs-workflow/SKILL.md |
| astro-best-practices | Astro, hydration, island, client:load | .claude/skills/astro-best-practices/SKILL.md |
| react-best-practices | React, component, hooks, useState | .claude/skills/react-best-practices/SKILL.md | Community skill ecosystem
Community skills are installed and managed through the CLI:
- Auto-detection: During
flydocs init, the CLI scans your dependencies and installs matching community skills automatically - Manual install: Add skills for patterns your project needs with
flydocs skill install - List and remove: See installed skills with
flydocs skill list, remove withflydocs skill remove - Build your own: A skill is just a directory with a SKILL.md. Create one, share it with your team, or publish it to the community directory
Community skills are knowledge-only by default. They do not execute code or access external services. This makes them safe to install, easy to audit, and simple to share.
Server-managed delivery
On the cloud tier, skills are managed artifacts delivered from the server. When your team admin updates skills or the FlyDocs team publishes new versions, every developer gets the update on their next flydocs sync. No manual distribution, no version drift across the team.
The server delivers skills with a monotonic version number. The CLI caches the last-seen version locally and only fetches updates. Workspace-specific rendering means your CLAUDE.md and AGENTS.md always include the correct skills manifest for your workspace.
If you need to modify a managed skill locally (for testing or development), add the path to artifactOverrides.skipPaths in .flydocs/config.json. This prevents sync from overwriting your local changes.
Next
- Hooks & Enforcement: the 7 hooks that make skills enforceable
- Context & Memory: how project context and session continuity work
- Workflow Lifecycle: the stages the workflow skill manages