note-it

Capture implementation notes after code implementation and review/fix. Records design decisions, deviations, tradeoffs, and open questions to docs/issue#XXXX.html. Triggers on: /note-it, 记录笔记, implementation notes.

By smallnest · 391 installs

npx skills add smallnest/goal-workflow --skill note-it

Source repository · Upstream listing

Implementation Notes After completing implementation and review/fix for an Issue, capture a running implementation notes file that documents how the implementation diverges from or interprets the spec. Triggers Use when: After /goal implementation and /review it are both complete User says "记录笔记", "implementation notes", "note it", "/note it" Before /ship it (as a final checkpoint) Any time the user wants to capture design rationale The Job 1. Determine the Issue number from context (branch name, /goal target, or user input) 2. Review the implementation against the Issue spec / PRD 3. Generate an HTML notes file at docs/issue XXXX.html 4. Present a summary to the user Notes Structure The HTML file must cover these four categories. If a category has nothing to report, write "None" with a brief explanation. 1. Design Decisions Choices made where the spec was ambiguous or silent: What was the ambiguity? What choice did you make? What was the rationale? 2. Deviations Places where you intentionally departed from the spec: What did the spec say? What did you implement instead? Why was the deviation necessary or better? 3. Tradeoffs Alternatives you considered and why you picked what you did: What were the viable alternatives? What were the pros/cons of each? Why did the chosen approach win? 4. Open Questions Anything you'd want confirmed or revised: What assumption are you unsure about? What should the user verify? What might need follow up? Output Format: HTML Location: docs/ Filename: issue XXXX.html (where XXXX is the zero padded Issue number, e.g., issue 0042.html ) HTML Template Use this exact HTML structure: Example Item How to Determine the Issue Number 1. If the user provides it directly (e.g., /note it 42 ), use it 2. If on a branch named feat/issue 42 or fix/issue 42 , extract 42 3. If the last /goal target was 42 , use 42 4. Otherwise, ask the user: "Which Issue number should I use for the notes file?" Edge Cases Scenario Handling No Issue number found Ask the user to specify docs/ directory does not exist Auto create it Notes file already exists for this Issue Ask: "Update existing notes or overwrite?" — default to update (append new items) No deviations or open questions Write "None — implementation followed the spec as written." Spec/PRD file not found Note in Open Questions: "No PRD found at tasks/prd .md — verify against original requirements." Checklist Before saving: [ ] Issue number identified [ ] All four categories reviewed (even if some are "None") [ ] Design decisions explain rationale, not just what was done [ ] Deviations clearly contrast spec vs implementation [ ] Tradeoffs mention specific alternatives considered [ ] Open questions are actionable (user can answer yes/no or give direction) [ ] HTML is well formed and renders correctly