mcp-tui: Skill for Claude Code

Write Technical Specification

Create a technical specification for a component, feature, or architecture decision. Tech specs are the bridge between requirements (user stories) and implementation (code). They answer "how" and "why" before code is written.

Pre-Flight Checks

1. Confirm what needs to be specified with the user
2. Read .claude/rules/architecture.md for active decisions and constraints
3. Read .claude/rules/documentation.md for documentation standards
4. Identify related user stories or requirements
5. Determine spec type: Component Spec, Feature Spec, or ADR

Spec Type Selection

Component Spec

For new components or significant changes to existing components:

• A new service, module, or subsystem
• A significant refactoring of an existing component
• A new integration with an external system

Feature Spec

For features that span multiple components:

• A new user-facing capability
• A cross-cutting concern (auth, logging, caching)
• A feature that changes multiple existing components

ADR (Architecture Decision Record)

For significant architectural decisions:

• Technology choices (framework, database, library)
• Pattern adoption (event sourcing, CQRS, microservices)
• Infrastructure decisions (hosting, deployment, scaling)
• Migration decisions (old pattern to new pattern)

---

Component Spec

Format

# Component: [Name]

## Status: [Draft | Review | Approved | Implemented]

## Purpose
[One sentence: what does this component do and why does it exist?]

## Context
[What problem does this solve? What existing code does it replace or extend?]

## Interface

### Public API
| Method/Function | Input | Output | Description |
|----------------|-------|--------|-------------|
| [name] | [params with types] | [return type] | [what it does] |

### Events Emitted
| Event | Payload | When |
|-------|---------|------|
| [name] | [data shape] | [trigger condition] |

### Events Consumed
| Event | Source | Action |
|-------|--------|--------|
| [name] | [context] | [what this component does] |

## Dependencies

### Required
| Dependency | Purpose | Interface |
|-----------|---------|-----------|
| [name] | [why needed] | [how accessed] |

### Optional
| Dependency | Purpose | Fallback |
|-----------|---------|----------|
| [name] | [why useful] | [behavior when absent] |

## Data Model

### State Shape
[Key data structures, schemas, types]

### Persistence
[How and where state is stored — database table, cache, file, memory]

### Migrations
[If this changes existing data, what migration is needed?]

## Behavior

### Core Algorithm / Logic
[How the component works — decision logic, transformations, state transitions]

### Side Effects
[What I/O does this component perform? Isolated at boundaries per architecture rules.]

### Concurrency
[Thread safety, race conditions, ordering guarantees]

## Error Handling
| Error Condition | Detection | Recovery | User Impact |
|----------------|-----------|----------|-------------|
| [what fails] | [how detected] | [how handled] | [what user sees] |

## Performance
- Expected throughput: [requests/sec, items/sec]
- Latency target: [p50, p95, p99]
- Resource limits: [memory, connections, file handles]
- Scaling approach: [horizontal, vertical, none]

## Security
- Authentication: [how callers are authenticated]
- Authorization: [what permissions are required]
- Data sensitivity: [PII, secrets, financial data]
- Attack surface: [input validation, injection prevention]

## Testing Strategy
| Tier | What to Test | Approach |
|------|-------------|----------|
| Unit | Pure logic, validation, transformations | Direct function calls, no mocks |
| Integration | Data access, external service calls | Real database, replay proxies |
| E2E | User-facing behavior | Full stack, highest fidelity |

## Open Questions
[Anything unresolved that needs input before implementation]

## Related
- User Stories: [US-NNN]
- User Flows: [flow links]
- ADRs: [ADR-NNN]
- Bounded Context: [context name]