From f4786627ec657d36bbf4baafb5a12ca8a0d858e4 Mon Sep 17 00:00:00 2001 From: Antheurus Date: Sat, 18 Jul 2026 02:02:13 +0700 Subject: [PATCH] docs: verify before filing a task, add status lifecycle recipe, default to attach+inline images - "Create a task" now documents a mandatory pre-write check: investigate the actual codebase first when the task is about a project you maintain, web-search first when it's an external but checkable fact, and write as-is only for purely personal/ subjective items with nothing to verify. - Image handling in that recipe is now unconditionally "attach every screenshot" (was worded as optional) plus a documented upgrade path to inline embed-image when grpc-auth is already set up, without ever auto-triggering the interactive grpc-auth flow as a side effect of filing a task. - New "Move a task through its status lifecycle" recipe: resolve the task id by search when not already known, set status to In Progress on start / Done on finish, verify each write, same pattern as the create recipe. --- SKILL.md | 67 +++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 59 insertions(+), 8 deletions(-) diff --git a/SKILL.md b/SKILL.md index 47b26bf..28c0421 100644 --- a/SKILL.md +++ b/SKILL.md @@ -121,7 +121,26 @@ collection (a `set`/Query filtered on the `task` type, sometimes called somethin tracker"), a new task lands there automatically — nothing needs to be added to it manually (don't `lists add` against a `set`, that only works on collections, see Gotcha #8). Attaching a screenshot is a routine part of this recipe too, not a rare extra — most real tasks come -from a screenshot, so step 5 covers it: +from a screenshot, so step 5 covers it. + +*Verify before you write it down.* A task written straight from what someone typed is only as +good as their memory of the bug/fact in that moment — worth writing, but worth more once +checked. Before filling in the task body, work out which of these three cases applies: + +- **It's about a project you actually maintain** (the subject matches one of the known project + tags in your `references/SPACES.md` cache — a real local codebase you can open). Go look: + grep/read the relevant files, or use whatever code-intelligence tooling is available in the + session, and confirm the claim before writing it down. A report like "the save button is + missing" often turns out to be a specific root cause a few files deep (a missing flush, a + wrong default, a debounce with no cleanup) — finding that first turns the task into something + immediately actionable (file:line references, confirmed behavior) instead of a restated guess. + If something you were told turns out not to match the code, say so and correct it in the task + rather than writing down both the wrong and right version. +- **It's about something outside your own codebases but still a checkable fact** (a claim about + an external tool, service, price, or behavior that a web search could confirm or refute). Do + that search first and fold the verified answer into the task. +- **It's neither** — a personal reminder, an opinion, a preference, a to-do with nothing to + verify against any source. Write it as given; there's nothing to check it against. ```bash # 1. the project tag must already exist — create it first if this is a new project, tags @@ -133,7 +152,7 @@ anywrite objects create --type task \ --name ": " \ --status "To Do" \ --property tag= \ - --body "" + --body "" # 3. optional extra tags (multi_select takes comma-separated names, each must already exist): anywrite objects create --type task \ @@ -145,9 +164,10 @@ anywrite objects create --type task \ # 4. verify it landed anywrite verify --property status="To Do" --property tag= --pretty -# 5. optional: attach a screenshot/image (this is the ONLY working way to attach an image — -# do NOT try embedding `![alt](url)` in --body/--markdown, it is silently stripped on save, -# see references/MARKDOWN.md): +# 5. attach every screenshot/image that came with the task — not optional, most real tasks +# come from a screenshot and a task without its evidence attached is half-filed (this is the +# ONLY working way to attach an image — do NOT try embedding `![alt](url)` in +# --body/--markdown, it is silently stripped on save, see references/MARKDOWN.md): anywrite files upload --file /path/to/screenshot.png # -> {"object_id": "", ...} anywrite objects update --json \ @@ -156,9 +176,40 @@ anywrite objects update --json \ The attached image shows up in the Anytype app under the object's ⓘ info panel as a file property — NOT inline in the note body, and not visible on the main page by default unless -`attachments` is set as a "featured" property on that type's template. If the actual goal is -a picture visible directly in the body text, that's a different mechanism entirely — see -"Embedding an image inline" below. +`attachments` is set as a "featured" property on that type's template. + +Attachment is the floor, not the ceiling — if inline visibility (a picture in the body itself, +not tucked in a property) matters more for this task, check whether `limited_app_key` is +already present in `~/.anywrite/config.json` (presence check only — never print or log the +value: `python3 -c "import json,os;p=os.path.expanduser('~/.anywrite/config.json');print(bool(json.load(open(p)).get('limited_app_key')) if os.path.exists(p) else False)"`). +If it's there, also run `embed-image` for the most relevant screenshot(s) — see "Embedding an +image inline" below. If it's not there yet, don't trigger `grpc-auth` as a side effect of +filing a task: it needs the user to read a popup and type a code within under a minute, which +is a human-only action, not something to fire off mid-workflow. Attach and move on; mention +once that inline embedding is available via a one-time `grpc-auth` if they want it later. + +**Move a task through its status lifecycle** — a task doesn't stay `"To Do"` forever. Move it +the moment the user signals a state change, in whatever words they use ("gua kerjain sekarang", +"lagi dikerjain", "udah beres", "selesai", "done", "mark as done"): starting work means +`"In Progress"`, finishing means `"Done"`. If you don't already have the task's id from earlier +in the session, resolve it by name instead of guessing — and if more than one task plausibly +matches, ask the user which one rather than picking: + +```bash +# resolve the id if you only have a name/description +anywrite search space --query "" --json '{"types":["task"]}' + +# starting work +anywrite objects update --status "In Progress" +anywrite verify --property status="In Progress" --pretty + +# finishing +anywrite objects update --status "Done" +anywrite verify --property status="Done" --pretty +``` + +`verify` after every status change is what confirms the write actually landed — the same +reasoning as the create recipe's step 4, not a one-off habit specific to creation. **Embedding an image inline** (a real picture in the body text, not a property reference) — the public REST API genuinely cannot do this (see `references/MARKDOWN.md`); it requires