The gap between "technically documented" and "actually usable" is where most developer experience falls apart. Tutorials, onboarding guides, FAQs, runbooks, and i18n guides all serve different purposes, but they share a common goal: get the reader from confused to productive as fast as possible. These skills focus on documentation that teaches, not just describes.
Key takeaway
ClaudeVault's developer guide skills give Claude Code structured workflows for the six documentation types that teach rather than just describe — step-by-step tutorials with working code examples, developer onboarding guides that compress the path from first clone to first contribution, runbooks for operational procedures, FAQ generation from real support patterns, i18n content strategy for multilingual products, and technical proposals that structure decisions before code is written.
When new developers take three weeks to ship their first pull request because onboarding means reading the README and figuring out the rest on their own
When operational runbooks exist as Slack messages from the last time someone fixed the problem, not as tested procedures anyone on the team can follow
When the same questions appear in support channels every week and nobody has compiled the answers into a searchable FAQ
When tutorials describe API endpoints but never show a working example that a reader can clone, run, and modify to understand the concept
A Claude Code developer guide workflow builds from onboarding through task-specific tutorials to operational runbooks, creating a documentation stack that serves developers at every stage from first day to on-call rotation.
Start with the onboarding guide writer. Claude generates a four-phase onboarding plan — Day 1 environment setup, Week 1 architecture walkthrough, Weeks 2-3 guided first project, Week 4 independent contribution — tailored to the actual codebase structure, dependencies, and toolchain the new developer will encounter.
The tutorial writer produces hands-on guides with working code examples. Claude structures each tutorial with a specific learning objective, prerequisites, numbered steps that build incrementally, and a verification step so the reader knows the tutorial worked. Every code sample is generated from the actual project patterns.
Use the runbook writer for operational documentation — deployment procedures, incident response steps, database maintenance tasks. Claude generates step-by-step procedures with decision trees for branching scenarios, rollback instructions, and verification checks. Automated runbooks built this way reduce MTTR by 50 percent.
The FAQ generator identifies recurring questions from support channels, issue trackers, and Slack conversations, then produces structured answers. Claude formats each answer for standalone readability — a developer who finds the FAQ through search should understand it without reading the surrounding content.
Finally, the proposal writer structures decisions that should happen before code is written. Claude generates technical proposals with problem statement, proposed solution, alternatives considered, trade-offs, implementation plan, and success criteria — so the team can argue about the approach before committing to code.
Outcome
An onboarding guide that gets developers productive in days instead of weeks, tutorials with working code examples, runbooks that turn operational procedures into tested scripts, FAQs generated from real support patterns, and technical proposals that structure decisions before the first line of code.
| Skill | Best for | Complexity | Primary use case |
|---|---|---|---|
| Tutorial Writer | Hands-on learning guides | Beginner | Step-by-step tutorials with working code examples and verification |
| Onboarding Guide Writer | New developer orientation | Intermediate | Four-phase onboarding from environment setup to independent contribution |
| Runbook Writer | Operational procedures | Intermediate | Deployment, maintenance, and incident response step-by-step procedures |
| FAQ Generator | Recurring question documentation | Beginner | Structured answers from support tickets, Slack, and issue patterns |
| I18n Content Advisor | Multilingual product content | Advanced | Translation-ready content strategy and locale management |
| Proposal Writer | Pre-implementation decision documents | Intermediate | Technical proposals with alternatives, trade-offs, and success criteria |
Produces operational runbooks that on-call engineers follow at 3am without prior context. Use when creating step-by-step procedures for incidents or maintenance tasks. Decision trees, copy-paste commands, escalation paths, rollback steps.
Writes runbooks for the on-call engineer who has been paged for something they have never seen before and is reading the runbook for the first time.
Creates step-by-step tutorials that take readers from starting point to working result with progressive complexity. Use when building learn-by-doing content with code examples. Verification steps, complete file listings, troubleshooting notes.
Writes tutorials that people finish — because every step works, every explanation lands, and the reader feels progressively more capable.
Anticipates user questions from documentation, code, or product context and writes direct answers. Use when generating FAQs that reduce support ticket volume. Progressive detail, search-optimized, inverted pyramid.
Generates FAQs sourced from real user confusion — the gaps between what docs say and what users need to know — not from what the product team thinks matters.
Reviews user-facing content and code for internationalization readiness. Use when preparing a product for translation or new locale support. String concatenation, pluralization, date formatting, cultural assumptions.
Reviews content and code for the structural issues that cost thousands in translator rework — not grammar errors, but patterns that make translation impossible or produce broken output in other langua
Produces developer onboarding guides that take a new hire from repo access to first shipped PR with zero tribal knowledge gaps. Use when creating internal onboarding documentation. Fresh laptop test, verification checkpoints, first-task tutorial.
Produces onboarding guides tested by the "fresh laptop test" — a competent developer with a new machine and no prior context follows every step without asking anyone for help.
Produces RFC-style technical proposals that frame problems precisely, present solutions with evaluation detail, and honestly assess alternatives. Use when writing technical proposals, RFCs, or ADRs. Alternatives analysis, risk assessment, phased implementation.
Writes proposals that get approved on the first review cycle by anticipating every objection — spending more words on the problem and alternatives than on the solution.
Yes. The onboarding guide writer analyzes the actual codebase — dependencies, toolchain, architecture, and testing patterns — to produce a four-phase onboarding plan. Developers with structured onboarding documentation reach full productivity 40 percent faster than those who navigate the codebase without guided context.
The runbook writer generates structured procedures with decision trees for branching scenarios, rollback instructions, and verification checks at each step. Automated runbooks reduce mean time to recovery by 50 percent because they replace improvisation with tested, repeatable procedures that any team member can follow.
A clear learning objective, explicit prerequisites, numbered steps that build incrementally, working code examples generated from real project patterns, and a verification step that confirms the tutorial worked. The tutorial writer structures each guide this way so the reader builds understanding through doing, not just reading.
Yes. The FAQ generator identifies recurring questions from support tickets, Slack conversations, and issue trackers, then produces structured answers formatted for standalone readability. Each answer works independently so developers who find it through search understand it without needing surrounding context.
Store guides in the repository alongside code using a docs-as-code approach, update them in the same pull requests where features ship, and pair with the docs freshness auditor from the Code Documentation topic to flag guides that have drifted from the codebase they describe.