manual-verify

name

manual-verify

description

Set up the local test vault and guide the user through manual verification of obsidian-reminder changes. Use this whenever a change should be verified in a real Obsidian vault — after implementing a fix or feature, when preparing a PR for review, or when the user says things like "動作確認して", "動作確認を手伝って", "テスト環境を整えて", "vaultで確認したい", or asks how to check that a change actually works. It prepares the vault (plugin symlink, plugin settings, companion plugins, generated test notes with per-fix instructions) and then hands the user a short checklist to execute in Obsidian.

Manual verification in a test vault

Automated tests only cover src/model/; anything touching the Obsidian API must be verified by a human in a running Obsidian. This skill prepares everything so that the user only has to launch Obsidian and walk through generated test notes.

Environment-specific configuration

Never hardcode vault paths, plugin directory names, or other machine-specific details in this skill, in test notes' front matter, or in any committed file. Read them from CLAUDE.local.md at the repository root (auto-loaded into context, gitignored). Expected entries: test vault path, plugin symlink location, installed companion plugins. If CLAUDE.local.md is missing or lacks the vault path, ask the user where their test vault is and offer to record it in CLAUDE.local.md for next time.

Workflow

1. Build the code under verification

Run a production build in the checkout to verify (main repo or a worktree):

mise exec -- npm run build

Confirm the change is actually in the artifact before involving the user, e.g. grep -c "<some string unique to the change>" main.js. The vault loads main.js, manifest.json, and styles.css from the plugin directory; all three exist at the checkout root after a build.

2. Point the vault at the checkout

ln -sfn <checkout-path> <vault>/.obsidian/plugins/<plugin-dir>

A git worktree works fine as the target: the hot-reload plugin watches any plugin directory containing .git, and a worktree's .git file satisfies that.

3. Prepare plugin settings (the data.json gotcha)

Because of the symlink, the plugin's data.json lives at the checkout root (it is gitignored). Two rules:

• Never edit data.json while Obsidian is running. The live plugin periodically saves its in-memory state and will silently overwrite your edits. Stage the desired file in the session scratchpad, ask the user to quit Obsidian, copy it into place, verify the copy, then ask them to relaunch.
• Set "scanned": false and "reminders": {} in the staged file. This forces a full vault rescan at startup; otherwise test notes created while Obsidian was closed may not be picked up (the plugin has no create-event listener, see #270).

Enable exactly the settings the tests need (e.g. enableTasksPluginReminderFormat, enableKanbanPluginReminderFormat, removeTagsForTasksPlugin). Keys can be read from an existing data.json or src/plugin/settings/index.ts.

4. Install companion plugins when the change involves interop

For fixes involving the Tasks/Kanban/etc. plugins, install the real plugin into the vault (while Obsidian is closed):

mkdir -p <vault>/.obsidian/plugins/<plugin-id>
cd <vault>/.obsidian/plugins/<plugin-id>
gh release download -R <owner>/<repo> --pattern main.js --pattern manifest.json --pattern styles.css --clobber

Then write the companion plugin's data.json with the settings the test requires (e.g. Kanban's "link-date-to-daily-note": true), and add its plugin id to <vault>/.obsidian/community-plugins.json.

5. Generate test notes

Create one note per fix in a dedicated folder at the vault root (default: reminder-test/), numbered in the order the user should execute them (1-<short title> (#<issue>).md, ...). Write the notes in the user's conversation language — the user reads them inside Obsidian, so they must be self-contained; the user should never need to switch back to the chat mid-test.

Template for each note:

# テスト<N>: <what is being verified> (#<issue>)

**手順**

1. <concrete step>
2. <concrete step>

**期待結果（修正後）**: <observable outcome>
**修正前の挙動**: <what the bug looked like, so the user can tell a real pass from a no-op>

<fixture lines the steps operate on, e.g. task lines>

Fixture rules:

• Use future dates (a week or more ahead) so reminders show up in the list without immediately firing notification popups during the test session.
• When a fix changes behavior on valid input, add a regression check to the same note (e.g. "insertion on a proper task line still works").

6. Hand the user a checklist

Post a compact message: quit/relaunch timing if settings were staged, the note order, and a one-line expected result per note (a table works well). Mention that the first launch rescans the vault and may take a few seconds. Ask for OK/NG per item, and for NG ask what was observed.

7. After verification

• Offer to record the verification results as a PR comment (English, factual, one line per verified fix).
• Offer cleanup: restore the vault symlink to the main repository checkout (rebuild master first so the vault serves the merged code), remove the worktree/branch. Test notes and companion plugins can stay in the vault for next time — mention it and let the user decide.