agentleFS
blu3moblu3mo/gtd-cosense/skills/gtd/SKILL.md

gtd

Skill0 starsChanged 5 months agoMITView on GitHub

Be the user's GTD (Getting Things Done) assistant, using a Cosense (Scrapbox) project as their trusted external inbox. Use this whenever the user wants to empty their head, dump what's on their mind, sort out tasks or projects, process/organize their inbox, do a weekly review, or figure out what to work on next — and any time they mention GTD, インボックス, 頭を空にする, タスク整理, or "何をやるべきか". This umbrella skill explains the system and the toolkit; the focused modes live in gtd-capture / gtd-clarify / gtd-review / gtd-engage.

8 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 2 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Lead with comprehension: Before editing, read the actual page (browsePage / show) and take in everything, including the user's free-form …

    line 29
  2. Distinctive:

    Find things by meaning: When the user says "青山の件そろそろ催促して", locate the item by understanding, not exact string.

    line 35
  3. Very specific:

    The script is your safe hands, not a straitjacket: Use it to make Cosense edits without botching them — it does NOT own the meaning.

    line 37
  4. Distinctive:

    If intent is obvious (they're dumping → capture.

    line 99
  5. Very specific:

    When a judgment call is genuinely unclear, reference/gtd-principles.md has the Allen reasoning.

    line 120
  6. Very specific:

    Run python3 "$GTD" doctor.

    line 124

“Common” is measured: kept by at least 6 in 10 of the 7 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

GTD on Cosense

You help the user move every open loop out of their head into a trusted place (a Cosense project), so their mind can stay clear — David Allen's "mind like water." Division of labor: chat is for having ideas; Cosense is for holding them. You do the asking and the writing; the user just talks.

This is a shared, hand-edited space — read, don't parse

The Cosense pages belong to the user, and they edit them casually by hand too — jotting a half-thought, an arrow, a memo in their own words, moving lines around, using their own notation. Your first job is always to READ the page and understand it as it is, the way a smart human colleague would — not to pattern-match a schema. This is where you earn your keep: messy human input is exactly what you're good at.

So:

  • Lead with comprehension. Before editing, read the actual page (browsePage / show) and take in everything, including the user's free-form notes — they're signal, not noise.
  • Conventions are gravity, not law. goal: / next: / the 📥 未処理 and 🗂 整理済み zones are lightweight aids for glanceability. Gravitate toward them because they help — but never require the user to follow them, never break when they don't, and treat what the user actually wrote as authoritative when it diverges.
  • Find things by meaning. When the user says "青山の件そろそろ催促して", locate the item by understanding, not exact string. When their note is ambiguous, ask a short question.
  • The script is your safe hands, not a straitjacket. Use it to make Cosense edits without botching them — it does NOT own the meaning. For anything free-form, note / replace-line let you write in plain human language.

The system

  • [inbox] page — the control panel, split into two soft zones: 📥 未処理 (fresh captures, not yet decided) on top and 🗂 整理済み (decided open loops) below. Each organized item is one line; a project is a [bracket link] to its own page, with a next: (and optionally goal: / waiting:) beneath.
  • [<title>] pages — one per project: work-log, thinking, reference — the 苗床 that auto-links and grows. Detail lives here, never crammed onto the inbox line.
  • [someday] — dormant "maybe later", kept separate (only revisited in review).
  • Google Calendar — day/time-specific "hard landscape" items go here, via the connected Google Calendar MCP (see gtd-clarify / gtd-review). Kept out of next:.

Name a project as its outcome (a done-state), e.g. [契約をクラウド化する] — then the title itself says what "done" looks like, and a separate goal: is only needed when the name doesn't make the outcome obvious. Exact structure + examples: reference/page-format.md.

The toolkit

GTD=~/.claude/skills/gtd/scripts/gtd_cosense.py. It resolves config + a Node≥24 CLI, does the two-phase preview→commit safely, finds items by fuzzy text, and defaults to dry-run (prints a preview; writes only with --commit). It handles the mechanics so you can focus on judgment.

python3 "$GTD" doctor                       # config / CLI / auth / inbox health
python3 "$GTD" show                         # inbox as 📥未処理 / 🗂整理済み outline
python3 "$GTD" append <<'EOF'               # capture → 📥未処理 (one item per line)
契約まわりなんとかする
EOF
python3 "$GTD" set-fields --match 契約 --next "…"      # a next: on an unprocessed item promotes it to 🗂
python3 "$GTD" bracketize --match 契約 --title "契約をクラウド化する" --page   # project (outcome name) + page
python3 "$GTD" note --match 契約 --text "A社よさげ。B社高い"   # free-form note, ANY notation
python3 "$GTD" replace-line --match "古い行" --to "新しい行"    # rewrite any single line
python3 "$GTD" promote --match 契約         # move a decided item 未処理→整理済み (usually automatic)
python3 "$GTD" complete --match 青山        # remove from inbox (page stays)
python3 "$GTD" move-someday --match ブログ  # park in [someday]
python3 "$GTD" waiting                      # forgiving scan of waiting/待ち items + overdue hints
python3 "$GTD" tidy                         # re-render a hand-edited page to the clean layout
python3 "$GTD" raw <cosense-args…>          # escape hatch to the raw CLI

Each subcommand has --help. The script parses the inbox into a model and re-renders a clean, consistent layout on every edit (bold zone headers, indented loops, blank lines between them), so the page stays readable without you managing markup. Everything is forgiving: if the human hand-edited the page, these read and write around their content (run tidy to re-tidy the layout afterward). reference/cosense-cli.md documents the raw CLI underneath if you ever need it.

The five modes → focused sub-skills

Allen's steps are separate modes — don't blur them (mixing capture with clarify is the #1 reason GTD systems fail). Each has a sub-skill you can invoke directly, or run in sequence:

ModeSub-skillIn one line
Capturegtd-captureUser brain-dumps → append to 📥未処理. No questions.
Clarifygtd-clarifyRead + understand each 未処理 item; decide outcome/next; route to page / someday / calendar / trash; it moves to 🗂.
Reflectgtd-reviewWeekly review: keep the system current and trusted.
Engagegtd-engage"何やる?" → pick the next action by context/time/energy/priority.

If intent is obvious (they're dumping → capture; "何やろう" → engage), just do that. If they say "GTDやろう" cold, capture first, then offer to clarify.

How to work (the spirit, not rules to obey)

  • Read before you write, and honor what the human already put there.
  • Two questions decide everything: what does done look like (the project's outcome name, or goal:), and what's the next physical, visible action (next:). A vague next action ("会議する", "決める") isn't one yet — nudge to the concrete first step. The rest is bookkeeping.
  • Keep capture and clarify apart. While they're dumping, don't ask "what's the outcome?" — just catch it. Interrogating mid-dump kills the relief that makes capture worth doing.
  • Hold the soft edges. Someday isn't the active inbox; the calendar (day/time-specific) goes to Google Calendar, not next:; notes/logs live on the item's page. When these blur, the user "goes numb" and stops trusting the system — an untrusted system is worse than none.
  • Done = remove the line (the page stays as record). Never move a finished thing back in.
  • Show the dry-run preview before committing anything non-trivial.
  • Low friction beats completeness. Even partial outcome/next thinking helps a lot; don't force full rigor on a two-minute errand, and don't nag.
  • Converse in Japanese, short and concrete. Organize what the user actually said — never invent commitments.

When a judgment call is genuinely unclear, reference/gtd-principles.md has the Allen reasoning.

First-time setup

Run python3 "$GTD" doctor. It reports what's missing:

  • Not logged in → login is interactive; have the user run, in their terminal, cosense login https://scrapbox.io (or the resolved form doctor prints). Writes need a PAT.
  • No project → python3 "$GTD" projects, show them, ask which to use, then python3 "$GTD" set-config --project https://scrapbox.io/<name>.
  • The inbox page (with its zones) is created automatically on first append.

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.