Summarizing Project Milestones

Overview

Create a polished Markdown milestone review from the current conversation, local code context, diffs, tests, and the user's stated goal. Optimize the document for two uses: fast later review and interview-ready technical storytelling.

Default to Chinese output when the user writes in Chinese. Keep technical identifiers, commands, paths, and code symbols unchanged. For Chinese output, translate the section headings naturally instead of keeping the English labels below.

Workflow

1. Confirm the output folder and title.
   - If the user provides a folder, use it.
   - If the user provides no folder, ask for one short clarification before writing.
   - If the user provides no title, infer a concise title from the feature or milestone.
2. Gather evidence before summarizing.
   - Review the current conversation for decisions, blockers, fixes, and verification.
   - Inspect relevant files, recent diffs, tests, logs, and commands when available.
   - Prefer concrete code references over broad claims.
3. Write one Markdown file named YYYY-MM-DD-<title>.md.
   - Sanitize filename characters that are invalid on the host OS.
   - Create the output folder if it does not exist.
   - Do not overwrite an existing file silently; append a numeric suffix or ask when overwrite intent is unclear.
4. Finish with a concise note containing the saved file path and any evidence gaps.

Document Structure

Use this structure unless the user asks for a different one:

# <title>

## One-Sentence Summary

## Background and Goal

## Completed Work

## Key Implementation

## Difficulties Solved

## Optimizations and Tradeoffs

## Key Code Index

## Verification

## Interview Narrative

## Review Checklist

## Follow-Up Risks or Improvements

Section Guidance

One-Sentence Summary: State what was achieved and why it matters in one compact sentence.

Background and Goal: Explain the original problem, user need, business or engineering context, and success criteria.

Completed Work: List concrete delivered behavior, files changed, APIs touched, UI states, deployment changes, or docs produced.

Key Implementation: Explain the core technical design, data flow, important methods/classes/components, and how the pieces cooperate.

Difficulties Solved: Focus on problems that required judgment: ambiguous requirements, integration failures, environment issues, edge cases, performance, compatibility, permissions, data consistency, or debugging surprises.

Optimizations and Tradeoffs: Capture why this approach was chosen, what alternatives were rejected, and what improvements were made for maintainability, performance, reliability, readability, or user experience.

Key Code Index: Include file paths, function/component/class names, and short notes. Use line numbers when reliable. Keep code excerpts short; prefer references plus explanation.

Verification: Record commands, tests, manual checks, screenshots, build results, deployment checks, or known unverified areas.

Interview Narrative: Provide 2-4 interview-ready talking points in first person, plus likely follow-up questions and crisp answers when the milestone has enough substance.

Review Checklist: Add compact bullets the user can scan later: concepts, commands, pitfalls, patterns, and vocabulary.

Follow-Up Risks or Improvements: Mention remaining risks, technical debt, monitoring points, or next sensible steps. Do not invent problems; mark uncertainty clearly.

Evidence Rules

• Separate facts from inference. Use explicit wording such as "from the code" or "inferred from this conversation" when appropriate; translate those markers naturally in Chinese output.
• Avoid generic praise. Tie every highlight to a concrete implementation choice, bug, command, file, or outcome.
• If code context is missing, say what is missing and write the best conversation-based recap rather than pretending.
• If the current repo has uncommitted or unrelated changes, do not revert them. Use only relevant evidence.
• If a test or build was not run, state that directly in 验证方式.

Quality Bar

The final document should help the user answer:

• What problem did this feature solve?
• Which concrete parts did the user implement?
• What difficulties appeared, and how were they diagnosed and solved?
• Why was this design chosen, and what tradeoffs were made?
• How was correctness verified?
• If an interviewer follows up, can the user explain code and engineering details?