---
name: requirement-summary
description: Generate concise, structured summaries of requirements for quick team understanding. Use when analyzing requirements from text documents (MD, TXT, DOCX) or technical specifications to create bullet-point summaries that highlight core functionality and dependencies/constraints. Ideal for sprint planning, stakeholder updates, team onboarding, or any situation requiring rapid comprehension of requirement documents.
---

# Requirement Summary

## Overview

Generate structured, bullet-point summaries (5-7 items) from requirement documents that enable teams to quickly grasp core functionality and critical constraints without reading full specifications.

## Workflow

### 1. Analyze the Requirement Document

Read the provided requirement document thoroughly to identify:
- Core functionality and features being requested
- Technical dependencies and system constraints
- Integration points with existing systems
- Critical limitations or blockers
- Success criteria or acceptance conditions

### 2. Extract Key Information

Focus on information that directly impacts implementation decisions:
- **What** is being built (features, capabilities, user-facing changes)
- **Why** it's needed (business value, problem being solved)
- **Dependencies** (external systems, APIs, data sources, prerequisites)
- **Constraints** (technical limitations, performance requirements, compliance needs)
- **Scope boundaries** (what's explicitly excluded or deferred)

### 3. Structure the Summary

Create a bullet-point list with 5-7 items following this pattern:

```
**[Category]**: [Concise description]
```

Recommended categories:
- **Core Functionality**: Primary features or capabilities
- **Key Dependencies**: External systems, APIs, or prerequisites
- **Technical Constraints**: Performance, scalability, or platform limitations
- **Integration Points**: How this connects with existing systems
- **Success Criteria**: Measurable outcomes or acceptance conditions
- **Out of Scope**: Explicitly excluded features or future considerations

### 4. Apply Clarity Principles

Each bullet point should:
- Start with a bold category label for scannability
- Use active, specific language (avoid vague terms like "improve" or "enhance")
- Include concrete details (numbers, systems, technologies) when available
- Be self-contained and understandable without reading other bullets
- Focus on "what" and "why" rather than "how"

### 5. Validate Completeness

Ensure the summary answers:
- What problem does this solve?
- What are we building?
- What systems does this depend on or integrate with?
- What are the critical constraints or limitations?
- How will we know it's successful?

## Example

**Input**: A 3-page technical specification for a user authentication system

**Output**:
```
**Core Functionality**: Implement OAuth 2.0 authentication with support for Google and GitHub providers, including token refresh and session management

**Key Dependencies**: Requires integration with existing user database (PostgreSQL), Redis for session storage, and external OAuth provider APIs

**Technical Constraints**: Must support 10,000 concurrent users with <200ms authentication latency; sessions expire after 24 hours of inactivity

**Integration Points**: Connects to existing user profile service via REST API; emits authentication events to event bus for audit logging

**Security Requirements**: Enforce HTTPS-only, implement CSRF protection, store tokens encrypted at rest using AES-256

**Out of Scope**: Multi-factor authentication and single sign-on (SSO) deferred to Phase 2
```

## Tips

- Prioritize information that affects implementation decisions over background context
- Use specific technical terms (API names, technologies, metrics) rather than generic descriptions
- When requirements are ambiguous, note the ambiguity in the summary
- For large documents, focus on the most critical 5-7 points rather than trying to cover everything
- If the document lacks key information (dependencies, constraints), explicitly note what's missing