smithery.ai

note

Capture complex technical discoveries into structured, reusable notes. Use when explaining system behaviors, documenting debugging insights, or preserving knowledge.

First seen Mar 21, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Skill metadata

Parsed from SKILL.md frontmatter.

More metadata
execution-tier
balanced

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,443 B
  • docs SUMMARY.md 177 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

Technical Discovery Note

Capture complex technical discoveries into structured, reusable notes.

Arguments (parsed from user input)

  • find - Find existing notes without creating new ones

- find (no args) - List all notes for the current repository - find <slug> - Find a specific note by slug (e.g., find cohort-uploads)

  • slug: kebab-case name for the note (required for creating/updating)

Example invocations:

Find existing notes:

  • /note find - List all notes for current repo
  • /note find cohort-uploads - Find specific note by slug

Create or update notes:

  • /note cohort-uploads
  • /note oauth-flow
  • /note feature-flags-evaluation

Your Task

Step 1: Parse Arguments

Extract from user input:

  • find_mode = true if first argument is "find"
  • slug = optional kebab-case note name (e.g., cohort-uploads, oauth-flow)

Step 2: Route by Mode

Find Mode (find_mode is true)

No slug provided — list all notes:

scripts/note-list.sh

Returns tab-separated <slug>\t<path>\t<title> (one per line).

If notes exist, display: "Found {count} notes for {org}/{repo}:" followed by slug and title for each, then offer to open or read any of them.

If no notes exist, display: "No notes found for {org}/{repo}" and suggest running /note <slug> to create one.

Slug provided — find specific note:

scripts/note-find.sh {slug}

Returns tab-separated status and path:

  • found\t/path/to/note.md - Note exists
  • new\t/path/where/note/would/be.md - Note doesn't exist

If found: display "Found note: {slug}", show the file path, read and summarize the first ~30 lines, then offer to open or continue editing.

If new: display "No note found for slug: {slug}", show where it would be created, and suggest running /note {slug} (without find) to create it.

Then stop — do not proceed with creating notes in find mode.

Create/Update Mode (find_mode is false)

If slug is missing, ask the user what to name the note and suggest a slug based on recent conversation context.

Run the helper script to find an existing note or get the path for a new one:

result=$(scripts/note-find-or-create.sh {slug})
status=$(echo "$result" | cut -f1)
note_path=$(echo "$result" | cut -f2)

Never construct paths manually — the script derives org/repo from the current git repository, builds the path (~/dev/haacked/notes/PostHog/repositories/{repo}/{slug}.md for PostHog repos, ~/dev/haacked/notes/Dev/repositories/{org}/{repo}/{slug}.md otherwise), and validates the slug format. The org/repo → path mapping itself has one owner, scripts/notes-path.sh, which /go also uses for plan directories.

If status is found: tell the user the existing note path and that you're updating it, then read the current content and add new discoveries while preserving existing knowledge.

If status is new: tell the user the new note path, create the parent directory (mkdir -p "$(dirname "$note_path")"), and use templates/discovery-note.md as the starting point (insert today's date in YYYY-MM-DD format).

Then create or update the note based on the current conversation context, any code explored during this session, and debugging insights or system behaviors discovered.

Quality Standards

Your notes should:

  • Eliminate re-discovery: Provide enough detail that the same exploration isn't needed again
  • Enable quick context: Allow someone to understand the system in minutes, not hours
  • Support implementation: Include practical examples and configuration details
  • Reference authority: Link to specific files, commits, or PRs

Boundary: /note vs /support

Use /note for Use /support for
Technical discoveries for future dev Customer tickets (Zendesk, GitHub)
System behavior documentation Weekly support log summaries
Knowledge that persists indefinitely Time-bounded support work
Cross-cutting insights Customer-specific investigation

If you discover something during support that should be permanent technical docs, use /note to capture it separately.