agentleFS
MathCazMathCaz/claude-skills/notes-M/SKILL.md

notes-M

Skill1 starsChanged 4 months agoMITView on GitHub

Persistent, distilled note-taking for any multi-turn topic — investigations, debugging, design discussions, data analyses, brainstorms, grill-me sessions. Each topic gets its own folder (`<parent>/<YYYY-MM-DD>-<topic-slug>/`) containing `<topic-slug>-notes.md` plus any side artifacts (reports, exports, diagrams). Survives `/compact`, session end, and multi-day work. Auto-invokes when starting a multi-step topic; can also be invoked explicitly.

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 12 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Don't use for: simple one-shot Q&A, well-scoped code edits, tasks with their own deliverable.

    line 19
  2. Distinctive:

    Always ask the user: if a candidate looks relevant:

    line 41
  3. Very specific:

    If continuing → read the existing <topic-slug>-notes.md fully before adding anything.

    line 43
  4. Very specific:

    If notes/ doesn't exist at cwd, present the user with 4 options:

    line 49
  5. Distinctive:

    Wait for the answer. Then:

    line 59
  6. Distinctive:

    When the topic produces an artifact that isn't note-text — HTML report, CSV export, diagram, screenshot, query result, scratch SQL, sub-doc …

    line 116
  7. Very specific:

    Update the notes file's ## Artifacts section: - file.ext — one-line purpose.

    line 118
  8. Distinctive:

    After every meaningful turn (finding, decision, ruled-out hypothesis, new open thread):

    line 124
  9. Distinctive:

    Update the file with the new content

    line 126
  10. Distinctive:

    Never batch. If context is lost at any moment, the file already holds everything.

    line 130
  11. Distinctive:

    Collapse rule: when a thread of several exchanges resolves to one decision/finding, replace the intermediate entries with ONE consolidated …

    line 139
  12. Distinctive:

    Supersession rule: when a later finding overrides an earlier one, REPLACE the earlier entry.

    line 141
  13. Distinctive:

    Pivot rule: when new content makes earlier entries stale (not wrong — no longer relevant because direction changed):

    line 143
  14. Distinctive:

    If the pivot itself is illuminating ("tried X, hit Y, switched to Z"), replace the stale entries with ONE dead-end entry capturing the …

    line 144
  15. Distinctive:

    If the pivot is just "we changed direction, no lesson", DELETE the stale entries silently.

    line 145

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Notes (notes-M)

A generic persistent-note primitive. Each topic = a self-contained folder (<topic-slug>-notes.md + supporting artifacts). The folder is the source of truth; topics live across sessions.

Naming convention: main file = <topic-slug>-notes.md where <topic-slug> is the folder name with the leading YYYY-MM-DD- stripped. Example: folder 2026-06-26-claude-setup/ → file claude-setup-notes.md. In legacy mode (d, single file no folder), file name = <YYYY-MM-DD>-<topic-slug>.md.

When to use

  • User starts a multi-step investigation, debugging session, design discussion, data analysis, or brainstorm — anything that will span more than ~5 substantive turns
  • User explicitly invokes (/notes-M) or another skill (e.g. grill-me-M) delegates file mechanics here
  • User mentions: "take notes", "let's analyze", "let's dig into", "let's design", "investigate", "debug", "trace"

Don't use for: simple one-shot Q&A, well-scoped code edits, tasks with their own deliverable.

Step 1 — Resolve the location

Default structure (when parent exists or user accepts the proposal):

<parent>/                        ← default: notes/
└── <YYYY-MM-DD>-<topic-slug>/   ← topic folder
    ├── <topic-slug>-notes.md     ← main file (folder name minus `YYYY-MM-DD-` prefix)
    └── <side artifacts>          ← reports, exports, diagrams, etc.

1.a — Derive the slug

Short kebab-case from the topic (e.g. auth-login-flow-investigation, mart-freshness-drift, sql-style-rules).

1.b — Scan for existing match

  • ls <parent>/ (cheap, no file reads — try notes/, brainstorms/, topics/, projects/, or whatever the user uses)
  • Grep folder names for tokens from the current topic
  • For any candidates, head -5 the inner <topic-slug>-notes.md (just the header — Topic / Goal / Status / Last updated)
  • Always ask the user if a candidate looks relevant:

    "Continue notes/2026-06-20-auth-login-flow-investigation/ (Status: in progress, Last updated: 2026-06-22), or start a new topic?"

  • If continuing → read the existing <topic-slug>-notes.md fully before adding anything. Print the folder path back.

1.c — No match found → ASK before creating

Default proposal: <cwd>/notes/<YYYY-MM-DD>-<slug>/<slug>-notes.md.

If notes/ doesn't exist at cwd, present the user with 4 options:

No `notes/` parent folder at <cwd>. Where should the topic live?
  (a) Create `notes/2026-06-27-<slug>/<slug>-notes.md` (new parent folder)
  (b) Use a different parent name (you pick — e.g. `brainstorms/`, `docs/research/`, `topics/`)
  (c) No parent folder — create `2026-06-27-<slug>/<slug>-notes.md` at cwd root
  (d) No folders at all — single file `2026-06-27-<slug>.md` at cwd root (legacy mode)

Wait for the answer. Then:

  • (a) → create notes/<YYYY-MM-DD>-<slug>/ + <slug>-notes.md
  • (b) → use the user's parent name + <YYYY-MM-DD>-<slug>/ + <slug>-notes.md
  • (c) → create <YYYY-MM-DD>-<slug>/ directly at cwd + <slug>-notes.md
  • (d) → create single <YYYY-MM-DD>-<slug>.md at cwd (no folder, no artifacts support)

Remember the chosen structure for the rest of the topic. Future saves go in the same place. Print the absolute path of the notes file back to the user.

Step 2 — Skeleton

# <Topic>

**Goal:** <one-line statement of what we're working on>
**Mode:** investigation | interview | analysis | generic
**Status:** in progress
**Started:** <YYYY-MM-DD>
**Last updated:** <YYYY-MM-DD>

---

## Summary
*(running synthesis — readable standalone)*

## <Body section(s) — see mode-specific guidance below>

## Artifacts
*(list of side files in this folder, with one-line purpose each. Skip in mode (d) — no folder.)*

## Open flags
*(pending input + owner)*

Step 3 — Body shape by mode

The body is mode-shaped, not a fixed template. Pick a structure that fits the topic. These are hints, not rules — the goal is efficient notes, not preserved conversation structure.

Investigation / debug:

  • ## Findings — claim · confidence (confirmed | probable | speculative) · evidence (file:line, query, commit)
  • ## Reasoning chains — for non-trivial conclusions, the path from evidence to claim
  • ## Dead-ends explored — hypothesis + why ruled out
  • ## Open threads — what's unverified, what's next

Interview / grill (consumed by grill-me-M):

  • ## Decisions log — consolidated topics: Decision · Why · Dead-ends · Flags

Data analysis:

  • ## Hypotheses — what we're testing
  • ## Results — finding + pointer to query/figure (NOT the full output)
  • ## Surprises — things that contradicted assumptions

Generic:

  • Free-form distilled notes — pick sections as needed: ## Facts, ## Decisions, ## Pointers, ## TODO

Step 4 — Side artifacts

When the topic produces an artifact that isn't note-text — HTML report, CSV export, diagram, screenshot, query result, scratch SQL, sub-doc — save it into the topic folder alongside the notes file. Use a descriptive filename (research-report.html, candidates.csv, architecture.png).

Update the notes file's ## Artifacts section: - file.ext — one-line purpose.

In mode (d) — single file, no folder — there's no place for artifacts. Note that limitation if the topic starts producing them; offer to migrate to a folder structure.

Step 5 — Checkpoint discipline

After every meaningful turn (finding, decision, ruled-out hypothesis, new open thread):

  • Update the file with the new content
  • Update **Last updated:**
  • Apply the curation rules below — don't blindly append

Never batch. If context is lost at any moment, the file already holds everything.

Step 6 — Curation rules (apply when updating)

The file is a curated, detailed deliverable — rich enough to derive other documents from (PRD, plan, summary), but never a raw transcript.

  • Capture: decisions, load-bearing rationale, constraints discovered, options considered + why each was rejected, flags with owners, illuminating dead-ends. Be generous — keep enough detail that this file alone is enough to later derive a PRD, plan, or summary without losing the reasoning.
  • Drop: conversational back-and-forth. Restated context. Exact user wording unless that wording IS the decision. Obvious duplication.

Collapse rule: when a thread of several exchanges resolves to one decision/finding, replace the intermediate entries with ONE consolidated entry (decision + key why + dead-ends worth remembering).

Supersession rule: when a later finding overrides an earlier one, REPLACE the earlier entry. Don't keep both. Add a one-line "changed from X because Y" only if the change itself is decision-relevant.

Pivot rule: when new content makes earlier entries stale (not wrong — no longer relevant because direction changed):

  • If the pivot itself is illuminating ("tried X, hit Y, switched to Z"), replace the stale entries with ONE dead-end entry capturing the lesson.
  • If the pivot is just "we changed direction, no lesson", DELETE the stale entries silently.
  • Decisions that depended on the old direction get re-asked under the new framing.

Detect pivots proactively. When new content invalidates earlier entries, surface it: "These earlier entries assumed X; this pivots to Y — drop, keep as dead-end, or re-ask?"

The ## Summary should be readable standalone — if someone only reads that section, they have the full picture.

Step 7 — Status & lifecycle

  • in progress — active work; sessions end and resume against the same folder
  • parked — set aside, may resume later; add a ## Parked because note
  • concluded — done; add a ## Outcome section (answer/decision + links to PR, ticket, ADR)

End of session vs end of topic:

  • End of session (stopping for now): file stays in progress. No reconcile beyond the last checkpoint.
  • End of topic (resolved or parked): final reconcile — read the file for contradictions, fix them, set status, give a short recap. Consider archiving the whole folder.

Rules

  • Append cheaply, distill aggressively — efficient notes beat preserved conversation structure
  • Be concise on context an agent could re-read — point to file:line, don't paste full files
  • Redact secrets (API keys, tokens, passwords, PII) — in the notes file AND in side artifacts
  • Print the absolute path of the notes file when creating or reopening
  • Before /compact: offer to write a "current state" summary entry so the post-compact agent (or future you) can resume cleanly

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.