Development story report

Development Story Report

When to Use

Use this skill when the user wants a concise story of completed work rather than another implementation pass.

Good fits

• "wrap this up"
• "what did we find?"
• "summarize what changed"
• "give me a handoff note"

Bad fits

• open-ended brainstorming
• fresh implementation planning
• long-form documentation authoring

Surface Notes

• Conversation evidence comes first.
• Local or workspace evidence is optional support, not mandatory scope.
• Keep the final report short enough to scan quickly.

Overview

This skill creates a short story report for completed work. The report is written for a non-technical decision-maker by default, so it should explain what changed, why it matters, what remains open, and what should happen next with minimal jargon.

Use this reporting stance

• Lead with the answer, not the chronology.
• Prefer grouped outcomes over a play-by-play narrative.
• Use conversation context first.
• Use local or workspace evidence only when it materially improves accuracy.
• Mirror the user's language when it is clear which language they are using.

Default output

• Format: inline Markdown
• Length: about 300-500 words
• Audience: non-technical decision-maker
• Tone: clear, direct, calm
• Evidence style: brief cues only, such as "based on tests run" or "from the workspace changes"

Workflow

1. Confirm the task is a wrap-up request.
   • Trigger on explicit asks for a report, recap, handoff, summary, development story, or brief.
   • Also trigger on strong completion cues such as "wrap this up", "we're done", or "what did we find?"
2. Gather evidence.
   • Start with the current conversation.
   • Pull in local files, diffs, plans, notes, or outputs only when available and helpful.
3. Ask one short gap-check question only if a critical fact is missing.
   • Do not start a long interview.
4. Derive the governing thought.
   • What changed?
   • Why does it matter?
   • What should the reader conclude?
5. Group the support into 2-4 same-kind outcome buckets.
   • Good buckets: decisions, outcomes, findings, achievements, implications, unresolved issues.
   • Bad buckets: random chronology, mixed evidence types, implementation trivia.
6. Draft the report using the template below.
7. Run the quality gates before sending the final answer.

Evidence hierarchy

Use evidence in this order:

1. Direct statements from the current conversation
2. Verified local or workspace artifacts
3. Narrow inferences that are clearly supported by the first two

State uncertainty briefly when evidence is incomplete.

Pyramid Quality Gates

Check the draft against these rules before finalizing:

1. The first sentence must summarize the whole report.
2. Each support group must contain the same kind of idea.
3. The groups must be ordered logically, not arbitrarily.
4. Every summary line must express an implication, not a vague category label.
5. The report must reduce reader effort.
   • Remove unnecessary implementation detail.
   • Replace jargon with plain language when possible.
6. Open issues must be included when they materially affect risk, confidence, or next actions.
7. Evidence cues must stay lightweight.
   • Mention support briefly.
   • Do not turn the report into an appendix unless the user asks.

Anti-patterns

• Do not narrate the work minute by minute.
• Do not hide unresolved issues to make the report sound cleaner.
• Do not produce a changelog disguised as a summary.
• Do not bury the conclusion under setup.

Report Template

Use this structure by default:

# [Short title]

## Bottom line
[One sentence that states what was achieved or learned and why it matters.]

## Key outcomes
[Two to four short paragraphs or bullets grouped by outcome, decision, or implication.]

## Open issues
[Brief note on risks, blockers, unknowns, or unverified assumptions.]

## Next step
[One concrete next action.]

Writing rules

• Keep the whole report in the 300-500 word range unless the user asks for a different depth.
• If there are no material open issues, say so briefly instead of inventing one.
• When the user clearly wrote in another language, produce the report in that language.
• Use plain language that a busy non-technical reader can understand on the first pass.

Example Prompts

The skill should trigger for prompts like these:

• "Wrap this up for leadership."
• "Summarize what we found and what remains unresolved."
• "Give me a short handoff note from this work."
• "What did we achieve here, in plain English?"
• "Create a development story report from this session."

The skill should usually not trigger for prompts like these:

• "Write a PRD from scratch."
• "Turn this into a tutorial."
• "Draft meeting minutes."
• "Create a long technical postmortem."

Example framing

Good framing:

• Bottom line: "We clarified the approach, proved the build path, and reduced execution risk for the next implementation phase."
• Outcome group: "The main design choice was to keep Pyramid Principle logic inside the report skill rather than depending on a second skill, which keeps routing simpler and more portable."

Weak framing:

• "First we talked about the idea, then we looked at references, then we discussed options, then we asked some questions."