Feature Summary Skill
Answers the question: How do we DOCUMENT and COMMUNICATE a feature to stakeholders, users, and developers?
This skill focuses on feature documentation and communication, transforming detailed breakdowns into accessible, comprehensive summaries that serve multiple audiences.
When to Use
Use this skill when you have a completed feature (or a detailed feature breakdown) and need to:
- Create comprehensive user-facing documentation
- Build a feature catalog or knowledge base
- Document business features for stakeholder communication
- Explain technical implementation to developers
- Create feature roadmaps and status tracking
- Document current and future capabilities
- Classify features by type (core, customization, performance, accessibility, UX)
Key indicator: You're asking "How do we document and communicate this feature?" or "What should users know about this capability?"
Works best with: This skill complements feature-breakdown (provides the detailed task list) and feature-planning (provides the execution sequence)
When NOT to Use
- You only have a feature idea/spec without breakdown details → Use
feature-breakdownfirst - You need to determine task execution order → Use
feature-planninginstead - You need to track real-time implementation progress → Use
execution-trackinginstead
Prerequisites
Recommended (but not strictly required):
-
Feature breakdown (
docs/features/[feature-name]/breakdown.md)- Provides detailed task list and component architecture
- Helps identify all feature aspects to document
-
Feature implementation (completed or well-understood)
- Access to working code or specifications
- Understanding of current status
-
Audience understanding
- Who will read this documentation?
- What do they need to know?
Inputs
- Feature specification or implemented feature (required)
- Feature breakdown document (recommended):
docs/features/[feature-name]/breakdown.md - Source code access (optional but helpful): For accurate implementation details
- Usage examples (optional): For user documentation
Directory Structure
All feature-summary output must follow this structure:
docs/features/[feature-name]/
├── breakdown.md (created by feature-breakdown skill)
├── summary.md (created by this skill - PRIMARY OUTPUT)
├── configuration.md (optional - created by this skill)
├── reference.md (optional - created by this skill)
└── implementation-progress.md (created by execution-tracking skill during implementation)
Outputs
MANDATORY FILE ORGANIZATION: All feature documentation must be in docs/features/<feature-name>/ subdirectory.
When this skill completes, it creates:
-
Primary Output: Feature Summary (
docs/features/[feature-name]/summary.md)- Comprehensive feature documentation
- 150-250 lines covering all major aspects
- Serves multiple audiences (users, developers, stakeholders)
- Includes feature type classification
- Example:
docs/features/git-blame-overlay/summary.md
-
Optional: Configuration Reference (
docs/features/[feature-name]/configuration.md)- Detailed configuration options and examples
- For features with significant customization
-
Optional: Reference Guide (
docs/features/[feature-name]/reference.md)- Technical implementation details for developers
- Architecture decisions and patterns
-
Supporting Structure:
docs/features/[feature-name]/breakdown.md- Implementation tasks (created by feature-breakdown skill)docs/features/[feature-name]/implementation-progress.md- Tracking file (created by execution-tracking skill)
Workflow Overview
The feature summary process transforms a feature concept into comprehensive documentation:
Feature Input (Breakdown or Implementation)
↓
Analyze Feature Aspects
↓
Identify Audiences & Use Cases
↓
Classify Feature Type
↓
Create Executive Summary
↓
Document Configuration & Options
↓
Explain Technical Implementation
↓
Define Status & Version Info
↓
Identify Limitations & Future Enhancements
↓
Write Output Files
↓
Comprehensive Feature Documentation
Core Workflow
Phase 1: Analyze Feature Scope
Input: Feature specification, breakdown, or implementation
-
Identify feature aspects:
- What does it do? (Core functionality)
- Why is it valuable? (Business value)
- How do users interact with it? (User experience)
- What are the key capabilities? (Feature list)
- What are the limitations? (Edge cases and constraints)
-
Extract technical details:
- How is it implemented? (Architecture, components)
- What are the technical requirements? (Dependencies, prerequisites)
- Where is the code located? (Source file references)
- What patterns or technologies are used?
-
Understand current state:
- Version number and release status
- When was it introduced?
- What improvements or fixes have been made?
- Is it production-ready?
Phase 2: Classify Feature Type
Assign the feature to one or more categories:
| Category | Description | Examples |
|---|---|---|
| Core Functionality | Essential feature defining the product's primary purpose | Git blame overlay, authentication system |
| Customization | Allows users to personalize behavior and appearance | Output patterns, color customization |
| User Experience | Improves usability, visual integration, and workflow | Theme adaptation, command palette |
| Accessibility | Supports users with different abilities and needs | Color options, keyboard shortcuts, ARIA labels |
| Performance | Optimizes speed and resource usage | Caching, lazy loading, pagination |
| Extended Functionality | Non-essential features that enhance core capability | Advanced filtering, export options |
| Developer Experience | Improves developer productivity and experience | Debugging tools, API documentation |
Output Format
Feature summaries include these key sections (in order):
- Feature Header - Name, overview, status, version, feature type
- Business Value - Why it matters, specific benefits
- What It Does - Core functionality with user experience and examples
- Key Features - Capabilities and extended functionality
- Configuration (if applicable) - Options and examples
- Technical Implementation - Code references and architecture
- User Interactions - Workflows and commands
- Status and Roadmap - Current status, limitations, future enhancements
- Related Features - Cross-references to related features
For a complete template with examples and detailed guidelines, see:
assets/documentation-template.md- Blank template for creating new featuresexamples/example-feature-summary-core.md- Core functionality exampleexamples/example-feature-summary-customization.md- Customization exampleexamples/example-feature-summary-performance.md- Performance example
Feature Type Classification
Every feature should be classified with a primary type and optional secondary types. This helps users understand:
- What is this feature? (Its purpose)
- Is it essential? (Core vs. optional)
- How does it relate to other features? (Ecosystem awareness)
Quick Reference
| Type | Icon | Purpose | Example |
|---|---|---|---|
| Core Functionality | ⭐ | Essential, defines product purpose | Git blame overlay |
| Customization | 🎨 | Personalization & preferences | Output patterns |
| User Experience | 👥 | Usability & visual integration | Theme-aware styling |
| Accessibility | ♿ | Support for diverse users | Color options |
| Performance | 🚀 | Speed & resource optimization | Caching system |
| Extended Functionality | ➕ | Optional enhancements | Export options |
| Developer Experience | 🛠️ | Developer productivity | API docs |
For detailed guidance on each type, see references/feature-type-reference.md
Guidelines
Writing for Multiple Audiences
For Users:
- Use clear, non-technical language
- Explain benefits and use cases
- Provide concrete examples
- Include configuration examples
For Developers:
- Include code references and file paths
- Explain architecture and design decisions
- Document patterns and conventions
- Link to technical documentation
For Stakeholders:
- Lead with business value
- Emphasize impact and ROI
- Focus on status and roadmap
- Quantify benefits where possible
Feature Classification
When assigning feature types:
- Identify primary category: What is this feature's main purpose?
- Note secondary categories: Can it serve multiple purposes?
- Explain classification: Why does this categorization make sense?
- Consider user perception: How do users think about this feature?
Technical Accuracy
- Reference actual source code paths
- Include line numbers for specific implementations
- Verify all code examples work correctly
- Document technical constraints accurately
Keeping Documentation Current
- Update status section when feature versions change
- Add to limitations if new constraints are discovered
- Move items from "Future Enhancements" when implemented
- Update configuration examples if options change
Common Pitfalls to Avoid
❌ Too technical for users: Remember non-technical readers; explain technical concepts ❌ Too vague for developers: Provide specific code references and implementation details ❌ Incomplete feature classification: Always explain why a feature fits its category ❌ Missing examples: Concrete examples are crucial for understanding ❌ Outdated information: Keep status and version info current ❌ Poor cross-linking: Reference related features; help readers understand relationships ❌ Missing technical details: Developers need code references and architecture info
Integration with Other Skills
The feature-summary skill works as part of a larger feature documentation ecosystem. For detailed integration workflows and examples:
- Overview of the skill ecosystem:
references/ecosystem-diagram.md - Practical integration workflows:
references/workflow-integration-guide.md - Quick navigation:
references/integration-guide.md
Recommended Skill Sequence
- feature-breakdown (1-2 hrs) - Decompose feature into tasks and acceptance criteria
- feature-summary (1-2 hrs) - Create user-facing documentation
- feature-planning (1-2 hrs) - Sequence tasks for execution
- execution-tracking (ongoing) - Monitor implementation progress
Key Concepts
feature-breakdown creates (docs/features/[name]/breakdown.md):
- Internal task list
- Component architecture
- Acceptance criteria
- Validation plan
feature-summary creates (docs/features/[name]/summary.md):
- User-facing documentation
- Business value explanation
- Configuration examples
- Roadmap and future enhancements
Quality Checklist
Before finalizing feature documentation:
- Feature type classification is clear and explained
- Business value section explains "why" not just "what"
- Examples show real-world usage
- Technical details are accurate with code references
- Configuration options are clearly documented
- Status and version info are current
- Known limitations are honestly documented
- Future enhancements are realistic and categorized
- Cross-references to related features are accurate
- Documentation is accessible to intended audiences
- Language is clear and concise
- All file paths and code references are accurate
Example Output
For a real example of how feature documentation should look, see the example feature summaries:
- Reference:
examples/example-feature-summary-core.md(Core functionality example) - Reference:
examples/example-feature-summary-customization.md(Customization example) - Reference:
examples/example-feature-summary-performance.md(Performance feature example)
See Also
feature-breakdown- Decompose features into tasksfeature-planning- Sequence tasks for executionexecution-tracking- Monitor feature implementation progressreadme-updater- Keep project README in sync with features