developer-summary
Developer Summary
Generates a developer-focused summary document from Sherpy planning artifacts. Provides developers with a quick-start view of what's being built, key deliverables, and the milestone roadmap.
Usage
/developer-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:
| File | Location | Purpose |
|---|---|---|
business-requirements.yaml |
requirements/ |
Project overview and deliverables |
technical-requirements.yaml |
requirements/ |
Technical context and architecture |
milestones.yaml |
implementation/ |
Milestone sequence and estimates |
timeline.yaml |
delivery/ |
Timeline estimates and dates |
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:
## Developer Summary — Dependency Check
Scanning for required artifacts...
✓ requirements/business-requirements.yaml
✓ requirements/technical-requirements.yaml
✓ implementation/milestones.yaml
✗ delivery/timeline.yaml
3 of 4 required files found.
Legend: ✓ found · ✗ missing
Step 2: Handle Missing Files
If any required files are missing, ask:
"Missing required files: timeline.yaml
Options:
- Continue with partial data — Generate summary with available information (missing sections will be marked as [Not Available])
- 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
- Core features and capabilities
- Key deliverables
From technical-requirements.yaml:
- Technology stack
- Architectural patterns
- Key technical components
From milestones.yaml:
- Milestone sequence (m0, m1, m2, etc.)
- Milestone names and descriptions
- Dependencies between milestones
- Estimated duration per milestone
From timeline.yaml (if available):
- Total project duration
- Target completion date
- Timeline workback schedule
Step 4: Generate Developer Summary
Create summaries/developer-summary.md.
The output document includes: header (timestamp, project name), Overview (3-5 sentence synthesis), Deliverables (grouped by category), Milestones & Timeline (M0, M1... with duration, dependencies, key deliverable), and Summary (total milestones, estimated duration, target completion).
See references/output-spec.md for the complete document specification with section structure and formatting rules.
See references/example.md for a full example.
Step 5: Handle Missing Data Gracefully
When required files are missing, insert clear placeholders:
## Milestones & Timeline
[Not Available - `milestones.yaml` not found. Run `/implementation-planner` to generate milestones.]
Or for partial data:
## Summary
**Total Milestones:** 4
**Estimated Total Duration:** 6 weeks (estimated from milestones)
**Target Completion:** [Not Available - run `/delivery-timeline` to set production deploy date]
Step 6: Confirmation
After generating the summary, display:
## Developer Summary Generated ✓
**Location:** summaries/developer-summary.md
**Size:** [file size]
Summary includes:
✓ Project overview
✓ Deliverables breakdown
✓ Milestone roadmap
[Missing data: timeline completion date - run /delivery-timeline]
The summary is ready for developer onboarding and reference.
Deliverables Extraction Logic
Identifying Deliverables
Parse the following sources to build the deliverables list:
From business-requirements.yaml:
functional_requirements→ User-facing featuresfeaturesorcapabilities→ High-level capabilitiesscope.in_scope→ Explicitly included items
From technical-requirements.yaml:
architecture.components→ Technical componentstechnology_stack→ Infrastructure items (databases, APIs, services)data_model.entities→ Domain entities/modelsapis.endpoints→ API endpoints if listedintegration_points→ External integrations
Categorization Rules
Group deliverables into logical categories based on type:
- API Endpoints - REST/GraphQL endpoints, webhooks
- Domain Handlers - Business logic handlers, command processors
- UI Components - Pages, views, components (if applicable)
- Data Models - Entities, schemas, database tables
- Infrastructure - Databases, message queues, auth systems
- Integrations - External service connections
- Background Jobs - Scheduled tasks, workers
- Configuration - Environment setup, deployment configs
Use the most relevant categories based on what's present in the requirements. Don't force categories that don't apply.
Overview Generation Logic
Crafting the Overview Paragraph
Synthesize information from multiple sources to create a concise, informative overview:
Elements to include (in order):
- What - The system/feature being built (1 sentence)
- Why - The problem it solves or value it provides (1 sentence)
- How (high-level) - The approach or key capability (1 sentence, optional)
Source fields to use:
business-requirements.yaml:descriptionoroverviewbusiness_goals.primary_goalsuccess_criteria
technical-requirements.yaml:solution_overviewarchitecture.approach
Template:
"[System Name] is a [type of system] that [primary function]. It addresses [problem] by [solution approach], enabling [key benefit/outcome]. The system will [key technical approach or differentiator]."
Example:
"The Sherpy CLI is a structured planning tool for AI-assisted software development. It addresses requirement drift and planning gaps by conducting guided interviews and generating comprehensive implementation plans with task-level detail. The system enforces best practices like task sizing, TDD requirements, and style anchors throughout the planning process."
Keep it Concise
- Maximum 5 sentences
- No bullet points in the overview
- Focus on business value, not implementation details
- Avoid jargon unless it's domain-specific and necessary
Milestone Roadmap Logic
Extracting Milestone Information
For each milestone in milestones.yaml, extract:
Required fields:
id- Milestone identifier (m0, m1, etc.)name- Milestone titledescription- What the milestone deliversestimated_duration- Time estimatedependencies- Which milestones must complete first
Formatting:
- Display milestones in sequence (m0 → m1 → m2...)
- Show dependencies clearly
- Highlight the "key deliverable" from the first line of the description or the most important success criterion
Example extraction:
# From milestones.yaml:
milestones:
- id: m1
name: API Foundation
description: |
Build core REST API with authentication and authorization.
Includes user management endpoints and JWT token handling.
dependencies: [m0]
estimated_duration: 2 weeks
success_criteria:
- All auth endpoints functional
- JWT tokens properly validated
Renders as:
### M1: API Foundation
**Duration:** 2 weeks
**Dependencies:** M0
**Key Deliverable:** Core REST API with authentication and authorization
Timeline Calculation
If timeline.yaml is available:
- Use
total_durationfield - Use
production_deploy_datefor target completion - Show the calculated project dates
If only milestones.yaml is available:
- Sum all
estimated_durationvalues - Convert to appropriate unit (days/weeks)
- Note that this is an estimate without QA/PR time
If neither is available:
- Mark as "TBD" with instruction to run appropriate skill
Error Handling
File Not Found
If a required file doesn't exist in the expected location:
- Check alternative common locations (root directory as fallback)
- Display clear error with exact path tried
- Suggest which Sherpy skill generates that file
Invalid YAML
If a file exists but can't be parsed:
- Display parsing error
- Show the file path and line number if available
- Suggest checking file format or regenerating
Missing Required Fields
If a file is missing expected fields:
- Use sensible defaults or mark as "[Not Specified]"
- Continue generating summary with available data
- Note missing fields in the confirmation output
Output Location
Always output to: {base_directory}/summaries/developer-summary.md
If the directory doesn't exist, create it:
mkdir -p {base_directory}/summaries
Integration with Sherpy Flow
This skill is designed to be called as Step 10 in /sherpy-flow. 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 files (like timeline) are missing
- Generate the summary without user interaction when all files are present
Examples
See references/example.md for a complete sample developer summary.
Related Skills
/executive-summary- Generate executive summary for stakeholders/sherpy-flow- Full planning workflow (includes this skill at the end)/implementation-planner- Generates the milestones.yaml used by this skill/delivery-timeline- Generates the timeline.yaml used by this skill
More from validkeys/sherpy
technical-requirements-interview
Conducts structured interviews to derive technical requirements from business requirements. Requires completed business-requirements.yaml as input. Asks targeted technical questions about architecture, technology stack, data model, APIs, security, testing, and deployment. Generates technical-requirements.yaml output.
48business-requirements-interview
Conducts structured interviews to gather comprehensive business requirements. Asks one question at a time with multiple-choice options, tracks progress in JSONL format, and generates structured business-requirements.yaml output. Use when starting a new project or feature to ensure clear understanding of goals, scope, users, and success criteria.
46implementation-planner
Generates detailed implementation plans with milestones and tasks from business and technical requirements. Embeds best practices including task sizing (30m-2.5h), style anchors, TDD requirements, and quality constraints. Outputs milestones.yaml and milestone-m*.tasks.yaml files ready for development.
42implementation-plan-review
Reviews generated implementation plans against best practices including task sizing (30m-2.5h), style anchors, TDD requirements, drift prevention, and quality constraints. Validates milestones.yaml and task files for completeness, alignment, and development readiness.
39implementation-plan-best-practices
Educational guide on best practices for creating implementation plans that prevent drift. Covers style anchors, task sizing, TDD requirements, affirmative instructions, drift handling, and quality gates. Use when creating or improving implementation plans to ensure they follow proven patterns.
37sherpy-flow
Orchestrates the full Sherpy planning workflow from requirements to QA-ready delivery plan. Detects which artifacts already exist, shows a visual pipeline status, and guides through each skill in sequence — gap analysis, business interview, technical interview, implementation planning, plan review, definition of done, architecture decisions, delivery timeline, QA test plan, and summary generation. Automatically organizes all artifacts into a structured docs/ folder.
31