sprint-closer

Extract completed sprint artifacts and generate Obsidian-compatible markdown documentation.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/mferris77/SpringBoard --skill sprint-closer
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sprint-closer
Source: https://github.com/mferris77/SpringBoard/tree/main/.github/skills/sprint-closer
Command: npx skills add https://github.com/mferris77/SpringBoard --skill sprint-closer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Reduces documentation drift by extracting what was actually built during a completed sprint and generating consistent, engineer-focused Obsidian-compatible documentation in /docs so teams do not rely on manual, error-prone writeups.

Core Features & Use Cases

  • Sprint Summary Generation: Reads sprint artifacts (README.md, tasks.md, development-log.md) and drafts a canonical sprint-<N>-summary.md with completed deliverables, decisions, and deferred items.
  • Targeted Architecture Updates: Detects architectural impacts and appends sprint update notes to the specific sections of docs/architecture/* when changes are evidenced.
  • Feature Index Maintenance: Adds or updates rows in docs/features/index.md for completed user-facing features to keep the feature catalog current.
  • Use Case: At sprint close, run this process to create a single narrative summary, annotate architecture docs, and update the feature index for reviewers and new team members.

Quick Start

Run sprint-closer on specs/<NNN>-sprint-<N>/ to generate the sprint summary, update impacted architecture sections, and update the features index in docs/.

Frequently Asked Questions about sprint-closer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automatically generate sprint documentation from completed development artifacts?▼

To generate sprint documentation automatically, this process extracts completed sprint artifacts like README.md, tasks.md, and development-log.md to produce Obsidian-compatible sprint summaries, architecture update notes, and feature index entries under docs/.

What is the best way to update architecture docs based on a completed sprint?▼

Updating architecture docs based on a completed sprint involves detecting architectural impacts and appending sprint update notes to specific sections of docs/architecture/* only when changes are evidenced in the development log.

How do I maintain a feature index in markdown after closing a sprint?▼

Maintaining a markdown feature index after closing a sprint requires adding or updating rows in docs/features/index.md for completed user-facing features to keep the catalog current for reviewers.

Do I need specific folder structures to generate sprint summaries from development logs?▼

Generating sprint summaries requires a completed sprint folder containing README.md, tasks.md, and development-log.md, and reads repository files under specs/ and docs/ to preserve glossary terminology and write relative links.

Why does documentation drift occur and how can it be prevented in software engineering?▼

Documentation drift occurs when teams rely on manual, error-prone writeups. It can be prevented by automatically extracting what was actually built during a completed sprint to generate consistent, engineer-focused markdown documentation.