Note It

Name: Note It
Author: smallnest

smallnest/goal-workflow

284 installs
199 repo stars
Updated July 21, 2026
smallnest/goal-workflow

Helps with productivity & planning tasks.

About

note-it is a Claude Code skill for productivity & planning. It helps solo builders move faster with AI-assisted development.

note-it
Productivity & Planning
AI-coding skill

Note It by the numbers

284 all-time installs (skills.sh)
+32 installs in the week ending Aug 5, 2026 (Skillselion tracking)
Ranked #921 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
Data as of Aug 5, 2026 (Skillselion catalog sync)

npx skills add https://github.com/smallnest/goal-workflow --skill note-it

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/smallnest/goal-workflow/note-it.svg)](https://skillselion.com/skills/smallnest/goal-workflow/note-it)

Installs	284
repo stars	★ 199
Last updated	July 21, 2026
Repository	smallnest/goal-workflow ↗

What it does

Helps with productivity & planning tasks.

Files

SKILL.mdMarkdownGitHub ↗

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:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Implementation Notes — Issue #XXXX</title>
  <style>
    * { margin: 0; padding: 0; box-sizing: border-box; }
    body {
      font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
      background: #FAF9F6;
      color: #1a1a1a;
      padding: 2.5rem 2rem;
      line-height: 1.7;
    }
    .container { max-width: 800px; margin: 0 auto; }
    h1 { font-size: 1.375rem; font-weight: 700; margin-bottom: 0.25rem; }
    .meta { color: #8B8680; font-size: 0.8125rem; margin-bottom: 2rem; }
    h2 {
      font-size: 1rem;
      font-weight: 600;
      margin-top: 2rem;
      margin-bottom: 0.75rem;
      padding-bottom: 0.375rem;
      border-bottom: 1px solid #E8E4DE;
      display: flex; align-items: center; gap: 0.5rem;
    }
    .dot {
      width: 8px; height: 8px; border-radius: 50%; display: inline-block;
    }
    .dot.design { background: #5B8A72; }
    .dot.deviation { background: #D97757; }
    .dot.tradeoff { background: #4A6FA5; }
    .dot.question { background: #D4A843; }
    .item {
      background: #FFFFFF;
      border: 1px solid #E8E4DE;
      border-radius: 8px;
      padding: 1rem 1.25rem;
      margin-bottom: 0.75rem;
      box-shadow: 0 1px 3px rgba(0,0,0,0.03);
    }
    .item h3 { font-size: 0.875rem; font-weight: 600; margin-bottom: 0.375rem; }
    .item p { font-size: 0.8125rem; color: #4A4540; margin-bottom: 0.375rem; }
    .label {
      display: inline-block;
      font-size: 0.6875rem;
      font-weight: 500;
      padding: 0.125rem 0.5rem;
      border-radius: 4px;
      margin-right: 0.375rem;
    }
    .label-design { background: #F5F8F6; color: #5B8A72; border: 1px solid #5B8A72; }
    .label-deviation { background: #FFF5F0; color: #D97757; border: 1px solid #D97757; }
    .label-tradeoff { background: #F0F4F8; color: #4A6FA5; border: 1px solid #4A6FA5; }
    .label-question { background: #FDF8F0; color: #D4A843; border: 1px solid #D4A843; }
    .none { color: #B0AAA4; font-style: italic; font-size: 0.8125rem; }
    .footer {
      text-align: center; margin-top: 2.5rem; color: #B0AAA4;
      font-size: 0.6875rem;
    }
  </style>
</head>
<body>
  <div class="container">
    <h1>Implementation Notes</h1>
    <p class="meta">Issue <a href="{{ISSUE_URL}}">#{{ISSUE_NUMBER}}</a> &mdash; {{ISSUE_TITLE}} &mdash; {{DATE}}</p>

    <h2><span class="dot design"></span> Design Decisions</h2>
    <!-- One .item per decision, or .none if none -->

    <h2><span class="dot deviation"></span> Deviations</h2>
    <!-- One .item per deviation, or .none if none -->

    <h2><span class="dot tradeoff"></span> Tradeoffs</h2>
    <!-- One .item per tradeoff, or .none if none -->

    <h2><span class="dot question"></span> Open Questions</h2>
    <!-- One .item per question, or .none if none -->

    <p class="footer">Generated by goal-workflow /note-it</p>
  </div>
</body>
</html>

Example Item

<div class="item">
  <h3><span class="label label-design">Decision</span> Used interface-based polymorphism instead of switch</h3>
  <p><strong>Ambiguity:</strong> The spec said "handle different types" without specifying how.</p>
  <p><strong>Choice:</strong> Defined a <code>Handler</code> interface with per-type implementations.</p>
  <p><strong>Rationale:</strong> Adding new types requires no changes to existing code (Open/Closed Principle). A switch would grow unboundedly.</p>
</div>

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."