From example-skills
Creates structured technical documents like ADRs, system analyses, RFCs, and research synthesis using evidence-based reasoning and argument structure. For architecture docs and decision records.
How this skill is triggered — by the user, by Claude, or both
Slash command
/example-skills:technical-analytical-writingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Communicate complex technical ideas clearly through structured analysis and evidence-based reasoning.
Communicate complex technical ideas clearly through structured analysis and evidence-based reasoning.
# ADR-{NNN}: {Decision Title}
**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-{NNN}
**Date:** YYYY-MM-DD
**Deciders:** {names/roles}
## Context
What is the issue that motivates this decision? What forces are at play?
## Decision
What is the change being proposed or decided?
## Consequences
### Positive
- {benefit}
### Negative
- {tradeoff}
### Neutral
- {observation}
## Alternatives Considered
### {Alternative A}
- Pros: {list}
- Cons: {list}
- Why rejected: {reason}
# {System/Component} Analysis
## Executive Summary
{2-3 sentences: what, why, recommendation}
## Current State
{What exists today, with evidence}
## Problem Statement
{Specific, measurable issue being addressed}
## Analysis
{Evidence-based investigation}
## Recommendations
{Ordered by priority, with effort estimates}
## Appendix
{Raw data, detailed metrics, supplementary evidence}
# RFC: {Title}
**Author:** {name}
**Status:** Draft | Review | Accepted | Rejected
**Created:** YYYY-MM-DD
**Review deadline:** YYYY-MM-DD
## Summary
{One paragraph: what this proposes}
## Motivation
{Why this is needed, with concrete examples}
## Detailed Design
{How it works, with diagrams and code examples}
## Drawbacks
{Honest assessment of downsides}
## Alternatives
{What else was considered and why this approach wins}
## Unresolved Questions
{Open items for discussion}
Every analytical section follows:
| Strength | Evidence Type | Example |
|---|---|---|
| Strongest | Production metrics | "P99 latency increased 3x after migration" |
| Strong | Reproducible test | "Benchmark shows 40ms vs 120ms" |
| Moderate | Code analysis | "This pattern creates N+1 queries" |
| Weak | Expert opinion | "The team believes this will scale" |
| Weakest | Analogy | "Netflix does it this way" |
Lead with the conclusion, then support:
Bad:
We analyzed the database, then the cache layer, then the API, and found that response times are slow because the cache hit rate is only 23%.
Good:
Cache hit rate is 23%, causing slow response times. The database query layer generates cache keys inconsistently, leading to unnecessary misses. Standardizing key generation would bring hit rate to ~85%.
## {Problem Name}
**Problem:** {specific, measurable issue}
**Solution:** {proposed change}
**Evidence:** {why this solution addresses the problem}
**Effort:** {T-shirt size + key dependencies}
| Criterion | Option A | Option B | Option C |
|-----------|----------|----------|----------|
| Performance | ★★★ | ★★ | ★★★ |
| Complexity | Low | Medium | High |
| Team familiarity | High | Low | Medium |
| Maintenance cost | Low | High | Medium |
| **Recommendation** | **✓** | | |
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| API rate limiting | High | Medium | Client-side rate limiter + cache |
| Data migration failure | Low | Critical | Rollback plan + dry-run first |
| Team bandwidth | Medium | High | Phased rollout |
| Situation | Diagram Type |
|---|---|
| System components | Architecture diagram (boxes + arrows) |
| Process flow | Flowchart or sequence diagram |
| Data relationships | ER diagram |
| Timeline | Gantt or timeline |
| Hierarchy | Tree diagram |
| Comparison | Table (not a diagram) |
```mermaid
graph LR
A[Client] --> B[API Gateway]
B --> C[Auth Service]
B --> D[Skills Service]
D --> E[(Database)]
```
npx claudepluginhub a-organvm/a-i--skills --plugin document-skillsProvides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.