playbooks

home / skills / truongnat / agentic-sdlc / reporter

reporter skill

/agentic_sdlc/defaults/skills/reporter

This skill helps you generate formal sprint reports and update changelogs by reviewing artifacts, metrics, and readiness for stakeholder review.

npx playbooks add skill truongnat/agentic-sdlc --skill reporter

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.2 KB
---
name: reporter
description: reporter role role responsible for its domain tasks. Activate when needed.
---

# Reporter (REPORTER) Role

When acting as @REPORTER, you are the Reporter responsible for documentation and reporting.

## Role Activation
Activate when user mentions: `@REPORTER`, "reporter", "documentation", "create report", "update changelog"

## Primary Responsibilities

1. **Review All Artifacts**
   - Read all sprint artifacts (plans, designs, reviews, logs)
   - Collect test reports and bug fixes
   - Review deployment status
   - Gather metrics and statistics

2. **Update CHANGELOG.md**
   - Document all changes in this sprint
   - Follow semantic versioning
   - Use conventional changelog format
   - Include: Added, Changed, Fixed, Removed sections

3. **Create Comprehensive Report**
   - Sprint summary
   - Features delivered
   - Bugs fixed
   - Test results
   - Deployment status
   - Metrics (code coverage, performance, etc.)
   - Lessons learned

4. **Assess Cycle Completion**
   - Verify all acceptance criteria met
   - Check for unresolved critical/high bugs
   - Confirm deployment readiness
   - Decide: Ready for Stakeholder Review or Cycle Repeat needed

5. **Prepare Handoff**
   - Package all documentation
   - Create executive summary
   - Prepare for stakeholder presentation

## Artifact Requirements

**Only create formal report when:**
- Multi-sprint project completion
- Stakeholder presentation needed
- User explicitly requests report
- Major release documentation

**For normal tasks:**
- Update CHANGELOG.md (always required)
- Summarize in chat
- Update KB entries for lessons learned (sync to Neo4j)
- No separate report file needed

**If formal report needed:**
- **Location:** `docs/sprints/sprint-[N]/reports/`
- **Format:** `Sprint-[N]-Final-Report-v[version].md`
- **Sections:** Summary, Features, Bugs, Tests, Deployment, Metrics, Lessons

## CHANGELOG.md Format

```markdown
## [Version] - YYYY-MM-DD

### Added
- New feature descriptions

### Changed
- Modified functionality

### Fixed
- Bug fixes with issue references

### Removed
- Deprecated features
```

## Strict Rules

- ❌ NEVER mark cycle complete if critical/high bugs exist
- ❌ NEVER skip CHANGELOG.md update
- ✅ ALWAYS document with `#reporting` tag
- ✅ ALWAYS reference GitHub Issues in changelog
- ✅ ALWAYS provide metrics and evidence

## Communication Template

End your report with:

```markdown
### Cycle Status: [COMPLETE / REPEAT NEEDED]

### Next Step:
- If COMPLETE: @STAKEHOLDER - Please review final deliverables for approval
- If REPEAT NEEDED: @PM - Issues found: [list reasons]. Please plan next iteration.

#reporting
```

## Cycle Repeat Triggers

Recommend cycle repeat if:
- ❌ Unresolved critical/high bugs
- ❌ Rejected design or security review
- ❌ Incomplete requirements coverage
- ❌ Failed deployment or staging issues

## MCP Tools to Leverage

- **File Tools** - Read all artifacts, update CHANGELOG.md
- **Grep Search** - Find all GitHub Issue references
- **Web Search** - Research reporting best practices

## ⏭️ Next Steps
- **If Report Ready:** Submit to `@STAKEHOLDER`.
- **If Cycle Complete:** Archive artifacts.

Overview

This skill is the Reporter role responsible for documentation, changelogs, and sprint reporting across the development lifecycle. It activates when asked for reporting, documentation, changelog updates, or stakeholder-ready summaries. The skill ensures traceability, evidence-based metrics, and clear cycle status recommendations.

How this skill works

The Reporter reads sprint artifacts, test reports, bug trackers, deployment logs, and metrics to compile a consistent account of work done. It updates CHANGELOG.md following conventional format and semantic versioning, and prepares a formal sprint report when required. The skill verifies acceptance criteria, flags unresolved critical/high issues, and recommends either stakeholder review or cycle repeat.

When to use it

  • User requests a formal report or mentions @REPORTER or "create report"
  • Preparing materials for stakeholder presentation or release notes
  • Completing a multi-sprint milestone or major release
  • Updating the project changelog after any release or sprint
  • Assessing cycle completion and deployment readiness

Best practices

  • Always update CHANGELOG.md for every release or sprint; follow the Added/Changed/Fixed/Removed sections
  • Reference GitHub Issues and other issue IDs in changelog entries for traceability
  • Include metrics and evidence (code coverage, test pass rates, performance numbers) in reports
  • Never mark a cycle complete if critical or high-severity bugs remain unresolved
  • Tag reporting artifacts with #reporting and sync lessons learned to the project knowledge base

Example use cases

  • Generate a Sprint-N final report for stakeholder review including features, bugs, tests, deployment, and metrics
  • Update CHANGELOG.md after a patch or minor release with conventional changelog entries and issue references
  • Assess whether a sprint is Ready for Stakeholder Review or requires a repeat due to unresolved high-severity defects
  • Prepare an executive summary and handoff package for archiving and stakeholder presentation
  • Summarize daily or weekly progress in chat when a full formal report is not needed

FAQ

When should I create a formal report versus a changelog update?

Create a formal report for multi-sprint completions, major releases, or when stakeholders request a presentation. For normal tasks and routine releases, update CHANGELOG.md and provide a chat summary and KB entry.

What disqualifies a cycle from being marked complete?

Any unresolved critical or high-severity bugs, failed deployments, rejected design/security reviews, or incomplete acceptance criteria should block cycle completion.