writing-tech-plans

jkappers's avatarfrom jkappers

Architectural planning and ADR creation. Use when evaluating feasibility, making technology choices, or defining system integration.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 17, 2025
[Architecture Design]

When & Why to Use This Skill

This Claude skill streamlines technical planning and architectural design by facilitating the creation of Architecture Decision Records (ADRs) and comprehensive technical overviews. It helps engineering teams evaluate feasibility, document technology choices, and define system integrations with a focus on long-term maintainability, security, and clear communication of trade-offs.

Use Cases

  • Evaluating and choosing between different technology stacks or frameworks for a new project to ensure technical alignment.
  • Documenting significant architectural changes or new patterns through ADRs to maintain a historical record of engineering decisions.
  • Defining system boundaries and data flow patterns when integrating multiple complex components to prevent architectural drift.
  • Conducting feasibility studies for proposed features to identify potential risks, security considerations, and system impacts before implementation.
namewriting-tech-plans
descriptionArchitectural planning and ADR creation. Use when evaluating feasibility, making technology choices, or defining system integration.

Technical Planning

Plan architecture and document decisions. Default to creating ADRs for significant decisions.

Architectural Focus

  1. System impact - What existing systems does this touch?
  2. Boundaries - Where does this feature start and end?
  3. Integration - How does it connect to existing components?
  4. Data flow - How does information move through the system?
  5. Trade-offs - What are we gaining and giving up?

ADRs

Create an ADR when choosing between technologies, selecting authentication approaches, introducing new patterns, or making trade-offs with long-term implications.

ADR Format

# ADR-{NNN}: {Decision Title}

**Status**: Proposed | Accepted | Rejected | Superseded
**Date**: YYYY-MM-DD

## Context

[Why is this decision needed?]

## Decision

[Clear statement of what was decided]

## Alternatives Considered

### {Alternative 1}
- **Pros**: ...
- **Cons**: ...
- **Why rejected**: ...

## Consequences

### Positive
- [Benefit]

### Negative
- [Trade-off]
- **Mitigation**: [How handled]

Scan docs/adr/ for existing ADRs and increment the highest number.

Technical Overview

Location: specs/YYYY-MM-DD-feature-name/technical-details.md

Structure

# Technical Overview: {Feature Name}

## Summary
[2-3 sentences]

## Architecture

### System Context
[How this fits into the broader system]

### Component Boundaries
[Components involved and responsibilities]

### Data Flow
[How data moves through the system]

## Integration Points
- **{System A}**: [How it integrates]

## Decisions
| Decision | ADR |
|----------|-----|
| [Choice] | [ADR-NNN](../docs/adr/NNNN-title.md) |

## Security Considerations
[Auth, authorization, data protection]

## Risks and Constraints
- **{Risk}**: [Description and mitigation]

## Open Questions
- [Unresolved questions]

Exclusions

Do not include: specific file paths, implementation order, code snippets, line-by-line details, time estimates, or timeline references.

Guidelines

Confirm feasibility before designing. Document decisions as ADRs. Trust implementers with the how. Think in systems and ripple effects. Address security by default.

Templates

  • templates/technical-details.md - Technical overview
  • templates/adr-template.md - ADR template
  • references/adr-guide.md - ADR guidelines