agentleFS
Sign inStart free
Renozoic-FoundryRenozoic-Foundry/forge-public/.claude/skills/note/SKILL.md

note

Skill0 starsChanged 3 months agoMITView on GitHub

Add a scratchpad note for the next process checkpoint

24 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use add, update and 5 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • tim-mccrimmonSkill

    add

    Process a document (PRD, architecture doc, security requirements, etc.) into structured context. Extracts relevant information and generates appropriate SCDs.

    Also in 3 projects that use this

  • AnthropicSkill

    update

    Sync tasks and refresh memory from your current activity. Use when pulling new assignments from your project tracker into TASKS.md, triaging stale or overdue tasks, filling memory gaps for unknown people or projects, or running a comprehensive scan to catch todos buried in chat and email.

    Also in 4 projects that use this

  • genomewalkerSkill

    resume

    Resume a thread by loading its ~800-token context capsule

    Also in 3 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 4 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 5 projects that use this

  • GoogleSkill

    tdd

    Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 4 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 18 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Add a scratchpad note to be reviewed at the next appropriate process checkpoint.

    line 16
  2. Very specific:

    If $ARGUMENTS is empty, ?, or help: Print:

    line 18
  3. Distinctive:

    Stop — do not execute any further steps.

    line 32
  4. Very specific:

    Read docs/sessions/scratchpad.md (create it if it does not exist).

    line 38
  5. Very specific:

    If no tag is provided and the note sounds like a process concern, suggest adding [evolve].

    line 50
  6. Very specific:

    If the note is tagged [bug] (replaces the deprecated /bug command):

    line 54
  7. Distinctive:

    Prompt for severity: Ask the user to classify severity:

    line 56
  8. Very specific:

    Route: Search docs/specs/ for an existing spec that covers this area.

    line 67
  9. Very specific:

    If found: add | Route: Spec NNN to the entry

    line 68
  10. Very specific:

    If not found: add | Route: needs-spec

    line 69
  11. Very specific:

    If severity is critical or high: "Next: run /spec <bug summary> to create a hotfix spec immediately."

    line 74
  12. Distinctive:

    Prompt for category: Ask the user to classify the signal:

    line 81

“Common” is measured: kept by at least 6 in 10 of the 18 edited versions of this file we could read. “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
<!-- forge:paths-note (Spec 575): process-state paths in this command (docs/specs, docs/sessions, docs/decisions, docs/research, docs/process-kit, docs/backlog.md) are the CLASSIC-DEFAULT spellings, not fixed locations. When the project configures forge.paths (e.g. the `contained` layout), resolve each key before use — bash: `forge_path <key>` (source ${CLAUDE_PLUGIN_ROOT:-.}/.forge/lib/config.sh, forge_config_load AGENTS.md); python: `${CLAUDE_PLUGIN_ROOT:-.}/.forge/bin/forge-py .../runtime_config.py path <key>`. -->

Framework: FORGE

Model-Tier: haiku

Add a scratchpad note to be reviewed at the next appropriate process checkpoint.

If $ARGUMENTS is empty, ?, or help: Print:

/note — Add a scratchpad note for review at the next process checkpoint.
Usage: /note <text>
Arguments: text (required) — the note to save. Optionally prefix with a tag.
Tags: [validate], [session], [evolve], [bug], [signal] — controls when/how the note is reviewed.
Examples:
  /note check if the extractor handles empty inputs
  /note [evolve] review scoring weights after 5 completed specs
  /note [bug] login page returns 500 on empty password
  /note [signal] repeated friction with test harness teardown
See: docs/sessions/scratchpad.md

Stop — do not execute any further steps.

Usage: /note <your note text>

  1. Read docs/sessions/scratchpad.md (create it if it does not exist).
  2. Append the note as a new entry with today's date and a [ ] checkbox:
    - [ ] 2026-MM-DD: <note text>
  3. Confirm the note was saved and state when it will be reviewed:
    • Notes tagged [close] → reviewed during the next /close run
    • Notes tagged [session] → reviewed during the next /session run
    • Notes tagged [evolve] (or legacy [outer-loop]) → reviewed during the next /evolve run
    • Notes tagged [bug] → handled as a structured bug report (see Step 3b below)
    • Notes tagged [signal] → handled as a signal capture (see Step 3c below)
    • Untagged notes → reviewed at next /close OR /session, whichever comes first
  4. If no tag is provided and the note sounds like a process concern, suggest adding [evolve].

[mechanical] Step 3b — [bug] tag handling (Spec 131)

If the note is tagged [bug] (replaces the deprecated /bug command):

  1. Prompt for severity: Ask the user to classify severity:
    • critical: data loss, crash, security vulnerability
    • high: feature broken, incorrect output, blocks workflow
    • medium: degraded behavior, workaround exists
    • low: cosmetic, minor inconvenience
  2. Build structured bug entry: Format as:
    - [ ] 2026-MM-DD: [bug] <description> | Severity: <level>
  3. Route: Search docs/specs/ for an existing spec that covers this area.
    • If found: add | Route: Spec NNN to the entry
    • If not found: add | Route: needs-spec
  4. Persist: Append to docs/sessions/scratchpad.md AND to docs/sessions/signals.md as type bug.
  5. Next action:
    • If severity is critical or high: "Next: run /spec <bug summary> to create a hotfix spec immediately."
    • Otherwise: "Bug noted. It will surface at the next /close or /session."

[mechanical] Step 3c — [signal] tag handling (Spec 131)

If the note is tagged [signal] (replaces the deprecated /harvest command):

  1. Prompt for category: Ask the user to classify the signal:
    • content: what worked/didn't in a deliverable
    • process: what worked/didn't in the workflow
    • architecture: design insight for future work
  2. Build structured signal entry: Format as:
    - [ ] 2026-MM-DD: [signal] <description> | Category: <category>
  3. Persist: Append to docs/sessions/scratchpad.md AND to docs/sessions/signals.md as the appropriate signal type (retro-content, retro-process, or retro-architecture).
  4. Next action: "Signal captured. It will inform the next /close retro chain and /matrix re-scoring."

Automatic review: The following commands check docs/sessions/scratchpad.md for open items:

  • /close — prints open [close] and untagged notes before Quick Check items
  • /session — prints all open notes and asks which to resolve or carry forward
  • /evolve — prints open [evolve] notes as part of the process health check
  1. Present a context-aware next action: "Note saved. Continue current work — it will surface at the next /<review-command>."

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.

Check your setup, free