| name | report |
| description | Trigger when the user wants a formatted HTML report file — DORA metrics report, PR cycle time report, engineering excellence report, coverage report, or retest analysis report. Not for quick questions (use devlake skill instead).
|
| disable-model-invocation | true |
Report Generation Skill
Generate a structured HTML engineering report using DevLake MCP data. This skill follows the Generator pattern: load the DSPy task template, read the style guide, gather data, produce the report.
Available Resources
Read these as needed during report generation:
references/report-checklist.md — Quality checklist to verify the report before saving. Read this after generating the report to self-check.
../../docs/.prompts/ — Existing prompt templates for coverage and retest reports
- Report template:
references/report-template.html — HTML/CSS design system with component usage guide
Report Categories
| Category | MCP Tools to Use | Prompt Reference |
|---|
| DORA Metrics | get_deployment_frequency, get_lead_time_for_changes, get_failed_deployment_recovery_time | DORA 2025 benchmarks |
| PR Cycle Time | get_pr_cycle_time | Coding/Pickup/Review breakdown |
| Engineering Excellence | get_github_actions_health, analyze_pr_retests, get_pr_stats | Bottleneck score |
| Code Coverage | get_codecov_coverage, get_codecov_summary | docs/.prompts/coverage/ |
| Retest Analysis | analyze_pr_retests | docs/.prompts/quality_reports/ |
Workflow
- Ask the user which report category they want (or infer from context)
- Read the HTML template from
references/report-template.html — understand the CSS component library and placeholder format
- Gather scope from user:
project_name — the DevLake project/organization name
- Team/sub-group name (optional)
- Analysis period (default: 30 days)
- Gather data using MCP tools — prefer specialized tools over raw SQL:
- For DORA: use
get_deployment_frequency, get_lead_time_for_changes, get_failed_deployment_recovery_time
- For PR metrics: use
get_pr_cycle_time, get_pr_stats
- For retests: use
analyze_pr_retests
- For coverage: use
get_codecov_coverage, get_codecov_summary
- For custom queries: use
execute_query with patterns from skills/devlake/references/sql-patterns.md
- Produce HTML output:
- Use the report template CSS classes — do not write custom CSS
- Replace template placeholders:
{{REPORT_TITLE}}, {{BADGE_LABEL}}, {{REPORT_DATE}}, {{ANALYSIS_DAYS}}, etc.
- Every section must have a kebab-case
id and clickable .section-anchor
- Include
.metrics-grid cards at the top, .executive-summary box, data tables with .explanation-box, and recommendations
- Self-check: Read
references/report-checklist.md and verify the report against it
- Save the report to the user's working directory as
<category>_report_<date>.html
Gotchas
- Don't skip the HTML template read — the report template has specific CSS variables, component classes, and placeholder conventions. Reports that don't use the template look broken.
- Section IDs must be kebab-case —
executive-summary not executiveSummary. The anchor links depend on this format.
- Metric card color classes — use
.success (green) for good values, .warning (amber) for concerning, .danger (red) for critical, .info (cyan) for neutral. Don't hardcode color values.
- Chart.js is optional — only use
<canvas> charts if the data genuinely benefits from visualization. Tables are usually clearer for small datasets.
- Font loading — the template uses Google Fonts (Space Grotesk + JetBrains Mono). These require internet access to render.
- Large reports — if a report has more than 8 data tables, consider adding a table of contents after the header.
- Empty data — if a query returns no data for a section, don't omit the section. Include it with a note explaining no data was found for the period.