technical-writing
This skill produces structured technical documentation across four types: architectural decision records for design choices, system overviews for onboarding, API references for integrations, and operational runbooks for procedures. It enforces anti-patterns like documentation drift and future fiction while matching detail to audience—from high-level concepts for new developers to procedural steps for operations teams.
Technical-writing creates architectural decision records and other technical documentation tailored to your audience and use case.
AI-generated summary based on this skill's SKILL.md
Install
rsmdt/the-startup/technical-writing · repository language: Shell
git clone https://github.com/rsmdt/the-startup
cp -r the-startup/plugins/team/skills/development/technical-writing ~/.claude/skills/technical-writingnpx skillfed install rsmdt/the-startup/technical-writingFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How to write architectural decision records?
technical-writing helps you create architectural decision records (ADRs) that document design choices and their trade-offs in a structured format. ADRs capture the context, decision, consequences, and alternatives considered, making it easy for teams to understand why architectural choices were made and what constraints they address. This prevents knowledge loss and supports onboarding.
What types of documentation does technical-writing produce?
technical-writing generates four primary documentation types: architectural decision records for design choices, system architecture documentation for onboarding and stakeholder communication, API documentation with endpoints and schemas, and operational runbooks for incident response and deployment. Each type is tailored to its audience's needs and detail level.
How do I document API endpoints with technical-writing?
technical-writing creates API documentation that includes endpoints, request/response schemas, authentication details, and usage examples. It structures this information for integration teams and external developers, ensuring consistency across your API reference and preventing documentation from drifting out of sync with actual implementations.
Can technical-writing help create incident response runbooks?
Yes, technical-writing develops operational runbooks for incident response and deployment procedures. These runbooks provide step-by-step guidance for operations teams, including detection criteria, escalation paths, and resolution steps. Templates ensure consistency across your operational documentation.
How does technical-writing prevent documentation drift?
technical-writing maintains version-controlled documentation aligned with your code, reducing the risk of documentation becoming outdated. By treating documentation as a living artifact tied to your codebase and enforcing review practices, it helps keep technical information current and trustworthy for all stakeholders.
What's included in system architecture documentation for onboarding?
technical-writing produces system architecture documentation that explains high-level concepts, component relationships, data flows, and key decisions for new team members. It matches detail and terminology to audience expertise, helping onboard developers quickly while providing stakeholders with the context they need.
SKILL.md
rendered from the published skill — quoted content, verbatim
Persona
Act as a technical documentation specialist who creates and maintains documentation that preserves knowledge, enables informed decision-making, and supports system operations. You select the right documentation type for the situation and apply audience-appropriate detail.
Documentation Request: $ARGUMENTS
Interface
Document { type: ADR | SystemDoc | APIDoc | Runbook audience: Developers | Operations | Business | Mixed detailLevel: HighLevel | Technical | Procedural status: Draft | Proposed | Accepted | Deprecated | Superseded }
State { request = $ARGUMENTS docType: ADR | SystemDoc | APIDoc | Runbook audience: Developers | Operations | Business | Mixed context = {} document = null }
Constraints
Always: - Document the context and constraints that led to a decision before stating the decision itself. - Tailor documentation depth to its intended
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 3 files
plugins/team/skills/development/technical-writing/SKILL.md
plugins/team/skills/development/technical-writing/templates/adr-template.md
plugins/team/skills/development/technical-writing/templates/system-doc-template.md