Executive Summary

Executive Summary

Generates an executive-focused summary document from Sherpy planning artifacts. Provides non-technical stakeholders with a clear understanding of the business problem, solution approach, timeline, and success criteria.

Usage

/executive-summary [base-directory]

If no directory is provided, auto-detect by looking for requirements/business-requirements.yaml in the current directory.

If not found, prompt the user: "Where are your planning artifacts located?"

Wait for the user to provide a path before proceeding.

Required Artifacts

The skill auto-discovers these files from the standard Sherpy folder structure:

Process

Step 1: Determine Base Directory and Scan for Required Artifacts

If no directory parameter was provided, check if requirements/business-requirements.yaml exists in the current directory.

• If found, use current directory as base_directory
• If not found, prompt: "Where are your planning artifacts located?" and wait for user response

Once base_directory is determined, scan for required files in standard locations. Display status:

## Executive Summary — Dependency Check

Scanning for required artifacts...

 ✓  requirements/business-requirements.yaml
 ✓  requirements/technical-requirements.yaml
 ✓  delivery/timeline.yaml

3 of 3 required files found.

Legend: ✓ found · ✗ missing

Step 2: Handle Missing Files

If any required files are missing, ask:

"Missing required files: timeline.yaml

>

Options:

1. Continue with partial data — Generate summary with available information (missing sections will be marked as [Not Available])

2. Exit — Complete missing artifacts first (run /delivery-timeline to generate timeline.yaml)

>

What would you like to do?"

Wait for user response:

• If user chooses 1 (Continue): Proceed with available data, mark missing sections clearly
• If user chooses 2 (Exit): Display which skills to run and exit gracefully

Step 3: Load and Parse Artifacts

Read all available files and extract:

From business-requirements.yaml:

• Project name and description
• Business goals and problem statement
• Target users and personas
• Core features and capabilities
• Success criteria and KPIs
• Scope and constraints

From technical-requirements.yaml:

• Solution architecture overview
• Technical risks and dependencies
• External integrations
• Compliance and security requirements
• Resource requirements (team, infrastructure)

From timeline.yaml (if available):

• Milestone delivery dates
• Production deploy date
• Total project duration
• QA and review phases

Step 4: Generate Executive Summary

Create summaries/executive-summary.md.

The output document includes: header (timestamp, project name), Business Problem (current state, business impact), Solution Overview (approach, benefits), Key Features & Capabilities (grouped by category), Timeline & Milestones (table with dates), Success Metrics (primary and secondary), Risks & Dependencies (risk table, external dependencies, assumptions), Resource Requirements (team, infrastructure, timeline commitment), and Conclusion.

See [references/output-spec.md](references/output-spec.md) for the complete document specification with section structure, writing guidelines, and formatting rules.

See [references/example.md](references/example.md) for a full example.

Step 5: Handle Missing Data Gracefully

When required files are missing, insert clear placeholders:

## Timeline & Milestones

[Not Available - `timeline.yaml` not found. Run `/delivery-timeline` to generate delivery timeline.]

**Estimated Duration:** [If milestones.yaml exists, sum milestone estimates]
**Target Completion:** TBD

Or for partial data:

## Risks & Dependencies

### Technical Risks
[Not Available - detailed risk analysis requires `technical-requirements.yaml`]

### External Dependencies
- [List any dependencies mentioned in available documents]

Step 6: Confirmation

After generating the summary, display:

## Executive Summary Generated ✓

**Location:** summaries/executive-summary.md
**Size:** [file size]

Summary includes:
  ✓ Business problem statement
  ✓ Solution overview
  ✓ Key features & capabilities
  ✓ Timeline & milestones
  ✓ Success metrics
  ✓ Risks & dependencies
  ✓ Resource requirements

The summary is ready for stakeholder review and communication.

Content Extraction Logic

Business Problem Section

Source: business-requirements.yaml

Extract from these fields:

• description or overview - Overall context
• business_goals.primary_goal - Main business driver
• problem_statement - Explicit problem description
• why or rationale - Why this matters

Structure: 1. Current State - What exists today, what's not working 2. Business Impact - Costs, inefficiencies, risks of status quo

Writing Guidelines:

• Use business language, not technical jargon
• Quantify impact when possible (costs, time, users affected)
• Focus on business value, not technical challenges
• Keep it concrete and specific

Example:

"Customer support teams currently lack visibility into real-time system status, requiring manual checks across multiple dashboards and resulting in delayed incident response. This fragmentation leads to an average 45-minute MTTR and costs approximately $150K annually in lost productivity and customer churn."

Solution Overview Section

Source: business-requirements.yaml + technical-requirements.yaml

Extract from:

• solution_overview or proposed_solution
• architecture.approach - High-level technical approach (translate to business terms)
• key_capabilities - What the system will do

Structure: 1. Approach - What we're building (non-technical) 2. Benefits - How it solves the problem

Writing Guidelines:

• Translate technical concepts to business value
• Focus on outcomes, not implementation
• Explain how the solution addresses the problem
• Highlight differentiators or key advantages

Example:

"We will build a unified monitoring dashboard that aggregates system health metrics, alerts, and incident history in a single interface. The solution enables support teams to identify and respond to incidents within minutes, reducing MTTR by 70% and improving customer satisfaction."

Key Features Section

Source: business-requirements.yaml

Extract from:

• functional_requirements - Specific capabilities
• features or capabilities - Feature list
• user_stories - User-facing functionality

Categorization:

• Group related features together
• Use business-friendly category names
• Focus on what users can do, not how it works

Categories might include:

• User Management
• Data & Analytics
• Integrations
• Automation
• Reporting
• Security & Compliance

Format each feature:

- **[Feature Name]** - [Business value / what it enables]

Example:

### Monitoring & Alerting
- **Real-Time Status Dashboard** - View system health across all services at a glance
- **Smart Alert Routing** - Automatically notify the right team based on alert severity and service ownership
- **Historical Trends** - Identify patterns and predict potential issues before they impact users

Timeline & Milestones Section

Source: timeline.yaml (preferred) or milestones.yaml (fallback)

From timeline.yaml:

• Extract workback.project_start
• Extract workback.production_deploy
• Extract milestone dates from the timeline
• Extract QA rounds and durations

From milestones.yaml (if timeline unavailable):

• Sum estimated_duration for total
• List milestone sequence
• Note this is preliminary without QA/PR time

Presentation:

• Use a table for clear milestone visualization
• Highlight key delivery dates
• Show development vs QA vs deploy phases
• Make it scannable

Success Metrics Section

Source: business-requirements.yaml

Extract from:

• success_criteria - Explicit success measures
• measurable_outcomes - Quantifiable targets
• kpis or metrics - Tracking measures

Categorize as:

• Primary Metrics - Must-achieve targets (often tied to business goals)
• Secondary Metrics - Nice-to-have improvements

Format:

- **[Metric Name]:** [Target value] - [What this measures and why it matters]

Example:

### Primary Metrics
- **Mean Time to Resolution (MTTR):** < 15 minutes - Measures incident response speed and system reliability
- **Customer Satisfaction Score:** > 4.5/5.0 - Indicates user satisfaction with support response

Risks & Dependencies Section

Source: technical-requirements.yaml

Extract from:

• risks - Technical and project risks
• external_dependencies - Third-party services, APIs, teams
• constraints - Limitations or requirements
• assumptions - What we're assuming to be true

Risk Table Columns:

• Risk - Clear description of what could go wrong
• Impact - High/Medium/Low severity
• Mitigation - How we're addressing it

Dependencies Format:

- **[Dependency Name]:** [What it provides, who owns it, current status]

Example:

### External Dependencies
- **Stripe Payment API:** Payment processing service, owned by Finance team, production-ready
- **SendGrid Email Service:** Transactional emails, third-party SaaS, requires account setup (in progress)

Resource Requirements Section

Source: technical-requirements.yaml + business-requirements.yaml + timeline.yaml

Extract from:

• resources section in technical requirements
• team or stakeholders in business requirements
• Timeline duration for capacity calculation

Structure:

• Team - Roles, size, time commitment
• Infrastructure - Key technical resources needed
• Timeline Commitment - Total duration and capacity

Example:

### Team
- **Development Team:** 3 engineers (2 backend, 1 frontend), full-time for 8 weeks
- **QA/Testing:** 1 QA engineer, 2 weeks during QA phases
- **Product:** 0.5 FTE for requirements and acceptance
- **DevOps:** 0.25 FTE for infrastructure setup and deployment

### Infrastructure
- PostgreSQL database (AWS RDS)
- Redis cache cluster
- Kubernetes cluster (existing infrastructure)
- Estimated cloud costs: $500/month

Error Handling

File Not Found

If a required file doesn't exist:

• Check standard docs/ locations first
• Check root directory as fallback
• Display exact path attempted
• Suggest which Sherpy skill generates the file

Invalid YAML

If a file can't be parsed:

• Display clear parsing error
• Show file path and line number
• Suggest regenerating the file

Missing Required Fields

If expected fields are missing:

• Use "[Not Specified]" placeholders
• Continue with available data
• Note missing information in confirmation

Output Location

Always output to: {base_directory}/summaries/executive-summary.md

Create directory if it doesn't exist:

mkdir -p {base_directory}/summaries

Writing Style Guidelines

Tone

• Professional and clear
• Non-technical language
• Focus on business value
• Confident but realistic about risks

Audience

• C-level executives
• Product managers
• Business stakeholders
• Non-technical decision makers

Avoid

• Technical jargon without explanation
• Implementation details
• Code or command references
• Acronyms without definition

Include

• Business impact and value
• Clear timelines and commitments
• Measurable outcomes
• Risk acknowledgment with mitigation

Integration with Sherpy Flow

This skill is designed to be called as the last part of Step 10 in /sherpy-flow, after /developer-summary. When invoked by sherpy-flow, it receives base_directory as a parameter. It should:

• Run after all planning artifacts are complete
• Auto-discover files from the organized folder structure within base_directory
• Not fail if optional sections are missing
• Generate the summary without user interaction when all files are present

Examples

See [references/example.md](references/example.md) for a complete sample executive summary.

Related Skills

• /developer-summary - Generate developer-focused technical summary
• /sherpy-flow - Full planning workflow (includes this skill at the end)
• /business-requirements-interview - Generates business-requirements.yaml
• /technical-requirements-interview - Generates technical-requirements.yaml
• /delivery-timeline - Generates timeline.yaml

Executive Summary

Generated: 2026-04-16 14:35:42 UTC Project: Package Domain Registry Service

---

Business Problem

Modern software development relies heavily on open-source packages from npm and other registries, but organizations lack visibility into the ownership and security status of these dependencies. Development teams currently manage package security through manual audits and ad-hoc scanning tools, leading to inconsistent coverage and delayed vulnerability detection.

Current State: Security teams must manually track package ownership across thousands of dependencies, requiring 15+ hours per week of dedicated analyst time. There is no centralized view of which packages are verified, who owns them, or when they were last scanned for vulnerabilities.

Business Impact: This fragmentation creates significant risk exposure, with an average 21-day delay between vulnerability disclosure and detection in production systems. The manual overhead costs approximately $180K annually in analyst time, while undetected vulnerabilities have resulted in two security incidents in the past year, affecting customer trust and requiring emergency remediation efforts.

---

Solution Overview

We will build a centralized Package Domain Registry Service that automates package ownership tracking, security scanning, and compliance reporting. The platform provides a single source of truth for package metadata, enabling automated verification workflows and real-time security visibility across the entire software supply chain.

Approach: The solution integrates directly with npm registries and security scanning services to automatically verify package ownership, track domain mappings, and orchestrate continuous vulnerability scans. Security teams gain a unified dashboard showing real-time security status, while development teams receive automated alerts when new vulnerabilities are discovered.

Benefits: By automating package verification and security scanning, organizations reduce manual overhead by 80%, detect vulnerabilities within 24 hours instead of 21 days, and gain comprehensive visibility into package security status across all projects. The system enables proactive risk management and demonstrates compliance with software supply chain security requirements.

---

Key Features & Capabilities

Package Verification & Ownership

• Automated Domain Verification - Verify package ownership through DNS records or hosted verification files
• Package-Domain Mapping - Maintain accurate registry of which organization owns each package
• Ownership Change Detection - Alert when package ownership transfers or verification expires

Security & Compliance

• Continuous Vulnerability Scanning - Automated daily scans across all tracked packages
• Real-Time Risk Alerts - Immediate notification when high-severity vulnerabilities are discovered
• Compliance Reporting - Generate audit reports showing security coverage and remediation status

Integration & Automation

• npm Registry Sync - Automatic synchronization with npm metadata
• Security Tool Integration - Native integration with Snyk and other scanning platforms
• API Access - Programmatic access for CI/CD pipeline integration

Visibility & Analytics

• Security Dashboard - Real-time view of package security status across organization
• Trend Analysis - Historical tracking of vulnerability patterns and remediation velocity
• SLO Monitoring - Track compliance with security response time objectives

---

Timeline & Milestones

Project Start: 2026-04-22 Production Deploy: 2026-06-30 Total Duration: 10 weeks

Complete Delivery Timeline

---

Success Metrics

Primary Metrics

• Vulnerability Detection Time: < 24 hours - Reduce time from CVE disclosure to detection in our systems from 21 days to under 24 hours
• Manual Audit Hours: < 3 hours/week - Reduce weekly manual audit time from 15 hours to less than 3 hours, freeing security analysts for higher-value work
• Package Coverage: > 95% - Ensure 95%+ of production dependencies are tracked and verified in the registry

Secondary Metrics

• Verification Success Rate: > 90% - Percentage of packages successfully verified on first attempt
• API Response Time: < 200ms p95 - Package lookup queries return within 200ms at 95th percentile
• Alert Response Time: < 4 hours - Security teams acknowledge critical alerts within 4 hours

Measurement Approach: Metrics will be tracked through DataDog dashboards starting at production launch. Monthly reports will be generated for the first quarter, then quarterly thereafter. Success criteria will be evaluated 30 days post-launch to allow for baseline establishment.

---

Risks & Dependencies

Technical Risks

External Dependencies

• npm Registry API: Package metadata source, owned by npm Inc, stable public API with documented rate limits
• Snyk Security Platform: Vulnerability scanning service, commercial SaaS product with existing enterprise contract, production-ready
• Auth0: Authentication service, existing organizational SSO integration, production-ready
• AWS Infrastructure: Hosting environment, existing organizational AWS account with available capacity

Assumptions

• npm API rate limits (600 requests/hour) are sufficient for daily sync of ~50K tracked packages
• Current Snyk enterprise contract includes API access for automated scanning workflows
• Security team has capacity to respond to automated alerts within defined SLOs
• Development teams will integrate package verification into existing CI/CD pipelines within 90 days of launch

---

Resource Requirements

Team

• Development Team: 3 engineers (2 backend, 1 full-stack), full-time for 10 weeks
• QA/Testing: 1 QA engineer, 1 week during QA phases (25% allocation)
• Product: 0.5 FTE for requirements validation and UAT (Security Team Lead)
• DevOps/Infrastructure: 0.25 FTE for AWS setup and deployment automation

Infrastructure

• PostgreSQL database (AWS RDS) with TimescaleDB extension for time-series data
• Redis cluster (AWS ElastiCache) for high-performance caching
• AWS SQS queues for asynchronous scan orchestration
• S3 bucket for verification file storage
• Estimated cloud costs: $650/month in production (development: $200/month)

Timeline Commitment

• Total Project Duration: 10 weeks (April 22 - June 30, 2026)
• Team Capacity Required: 3.75 FTE during development phase
• Peak capacity: Weeks 5-7 during security scanning integration (4 FTE)

---

Conclusion

The Package Domain Registry Service addresses a critical gap in our software supply chain security by automating package verification and vulnerability detection. With a 10-week timeline and focused team commitment, the project will reduce security risk exposure by 80% while freeing 12 hours of analyst time per week for strategic security initiatives. Production deployment by June 30 positions the organization to meet Q3 compliance requirements and demonstrate proactive supply chain risk management.

---

For detailed technical specifications, see `requirements/technical-requirements.yaml`. For detailed implementation plan, see `implementation/milestones.yaml`.

Executive Summary Specification

Version: 1.0.0 Document Type: Markdown File Pattern: executive-summary.md Generated By: /executive-summary skill

---

1. Document Overview

Purpose

Provides non-technical stakeholders with a comprehensive view of the business problem, solution approach, timeline, success metrics, and risks. Translates planning artifacts into business-focused language for executive review and approval.

Dependencies (Input Artifacts)

Required:

• requirements/business-requirements.yaml - Business problem and features
• requirements/technical-requirements.yaml - Technical risks and resources

Optional:

• delivery/timeline.yaml - Delivery schedule and dates

Outputs (What Uses This)

• Executive review and approval
• Stakeholder communication
• Business case documentation
• Project kickoff materials

---

2. File Format & Location

Format: Markdown (.md), UTF-8, LF line endings

Location: {base_directory}/summaries/executive-summary.md

Naming: Fixed filename, no versioning or date suffixes

---

3. Document Structure

Required Sections

3.1 Header Block

# Executive Summary

*Generated: YYYY-MM-DD HH:MM:SS UTC*
*Project: [project-name]*

---

Fields:

• Generated: ISO 8601 timestamp of generation
• Project: From business-requirements.yaml → project.name

3.2 Business Problem

## Business Problem

[2-3 paragraphs describing the problem being solved. Focus on business impact,
not technical details.]

**Current State:** [What exists today, what's not working]

**Business Impact:** [Costs, inefficiencies, risks of status quo]

---

Sources: business-requirements.yaml → problem_statement, business_goals.primary_goal, description Style: Business language, quantify impact, focus on value not technical challenges

3.3 Solution Overview

## Solution Overview

[2-3 paragraphs explaining the solution in non-technical terms]

**Approach:** [What we're building]

**Benefits:** [How it solves the problem]

---

Sources: business-requirements.yaml → solution_overview, proposed_solution; technical-requirements.yaml → architecture.approach (business terms) Style: Outcomes-focused, translate technical to business value

3.4 Key Features & Capabilities

## Key Features & Capabilities

### [Feature Category 1]
- **[Feature Name]** - [Business value / what it enables]
- **[Feature Name]** - [Business value / what it enables]

### [Feature Category 2]
- **[Feature Name]** - [Business value / what it enables]

---

Sources: business-requirements.yaml → functional_requirements, features, user_stories Categories: User Management, Data & Analytics, Integrations, Automation, Reporting, Security & Compliance Format: Group by business area, focus on what users can do (not how)

3.5 Timeline & Milestones

## Timeline & Milestones

**Project Start:** [Start date or TBD]
**Production Deploy:** [Target date or TBD]
**Total Duration:** [Weeks/months]

### Complete Delivery Timeline

| Phase | Start Date | End Date | Duration | Notes |
|-------|------------|----------|----------|-------|
| **Development** | [Date] | [Date] | [X weeks] | [Milestone breakdown: M0, M1, M2...] |
| **PR Reviews** | [Date] | [Date] | [X days] | [Code review and approval process] |
| **QA Round 1** | [Date] | [Date] | [X days] | [Initial testing and bug fixes] |
| **QA Round 2** | [Date] | [Date] | [X days] | [Regression and final validation] |
| **Final Signoff** | [Date] | [Date] | [X days] | [Stakeholder approval] |
| **Production Deploy** | [Date] | [Date] | [1 day] | [Release to production] |
| **Feature Flag Removal** | [Date] | [Date] | [X days] | [Gradual rollout completion] |

---

Sources: delivery/timeline.yaml → workback, milestone dates, QA rounds, feature flag timeline; implementation/milestones.yaml (fallback) Format: Complete table showing all phases start-to-finish; include PR reviews, QA rounds, signoff, deploy, feature flag removal

3.6 Success Metrics

## Success Metrics

### Primary Metrics
- **[Metric Name]:** [Target] - [What this measures]
- **[Metric Name]:** [Target] - [What this measures]

### Secondary Metrics
- **[Metric Name]:** [Target] - [What this measures]

**Measurement Approach:** [How and when metrics will be evaluated]

---

Sources: business-requirements.yaml → success_criteria, measurable_outcomes, kpis Format: Primary (must-achieve) vs Secondary (nice-to-have) metrics

3.7 Risks & Dependencies

## Risks & Dependencies

### Technical Risks
| Risk | Impact | Mitigation Strategy |
|------|--------|---------------------|
| [Risk description] | High/Med/Low | [How we're addressing it] |

### External Dependencies
- **[Dependency Name]:** [What it provides, who owns it, status]

### Assumptions
- [Key assumption 1]
- [Key assumption 2]

---

Sources: technical-requirements.yaml → risks, external_dependencies, constraints, assumptions Format: Risk table (Impact: High/Med/Low, Mitigation); dependencies with ownership/status; assumptions

3.8 Resource Requirements

## Resource Requirements

### Team
- **Development Team:** [Size, roles, time commitment]
- **QA/Testing:** [Size, time commitment]
- **Product/Design:** [Size, time commitment]
- **DevOps/Infrastructure:** [Size, time commitment]

### Infrastructure
- [Key infrastructure requirements]
- [Estimated costs if available]

### Timeline Commitment
- **Total Project Duration:** [Duration]
- **Team Capacity Required:** [FTE count or percentage]

---

Sources: technical-requirements.yaml → resources, infrastructure; business-requirements.yaml → team; delivery/timeline.yaml → duration

3.9 Conclusion

## Conclusion

[2-3 sentences tying together problem, solution, timeline, and expected outcome]

---

*For detailed technical specifications, see `requirements/technical-requirements.yaml`.*
*For detailed implementation plan, see `implementation/milestones.yaml`.*

---

4. Generation Guidelines

Discovery & Scanning

• Auto-detect base directory from requirements/business-requirements.yaml location
• If not found, prompt: "Where are your planning artifacts located?"
• Display scan status (✓ found / ✗ missing)

Handling Missing Files

If required files missing, offer: (1) Continue with partial data, or (2) Exit to complete artifacts

Generation Process

1. Parse YAML artifacts (business-requirements, technical-requirements, timeline if available) 2. Generate summaries/executive-summary.md with all sections per structure in §3 3. Insert placeholders for missing data: [Not Available - run /delivery-timeline] 4. Confirm with status, location, and included sections

---

5. Validation Rules

Required Sections (All Must Be Present)

• Header block with timestamp and project name
• Business Problem (2-3 paragraphs, business language, no jargon)
• Solution Overview (2-3 paragraphs, outcomes-focused)
• Key Features (≥1 category, business value per feature)
• Timeline & Milestones (complete delivery timeline table, or [Not Available])
• Success Metrics (primary/secondary split, targets, measurement approach)
• Risks & Dependencies (table with Impact High/Med/Low, ownership, mitigation)
• Resource Requirements (team roles, infrastructure, capacity)
• Conclusion (2-3 sentences)

Content Quality Gates

• No technical jargon or implementation details
• All metrics have targets and measurement approach
• Timeline shows complete delivery phases: Development → PR Reviews → QA Round 1 → QA Round 2 → Final Signoff → Production Deploy → Feature Flag Removal
• Risk table includes Impact and Mitigation columns
• Dependencies list ownership and status

---

6. Error Handling

File Not Found

Error: Required file not found
Path: {base_directory}/requirements/business-requirements.yaml
Run: /business-requirements-interview

Invalid YAML

Error: Cannot parse requirements file
File: technical-requirements.yaml
Line: 42
Issue: Invalid YAML syntax

Missing Fields

• Use "[Not Specified]" for missing optional fields
• Continue generation with available data
• Note missing fields in confirmation

---

7. Integration Points

Input Skills: /business-requirements-interview, /technical-requirements-interview, /delivery-timeline

Sherpy Flow: Step 10 (after /developer-summary). Receives base_directory, auto-discovers files, generates silently.

Audience: C-level executives, product managers, business stakeholders

Writing Style: Professional, non-technical, business value-focused, realistic about risks

---

8. Example

Complete example: summaries/example-executive-summary.md

---

Version History

1.0.0 (2026-04-16)

• Initial specification
• Defines structure, generation logic, and validation rules
• Aligned with /executive-summary skill implementation