Implement

/implement — build the tasks test-first

Stage 4 of the SDD pipeline. Work the task checklist (in the GitHub issue comment) top to bottom using the tdd discipline. This stage is done by the main assistant (not a subagent) because it commits to the branch and must keep CI green at every step.

Before starting

Run gh issue view <N> — read the spec (body) and the plan + tasks comments. The tasks comment has the checklist; the plan comment has the files, guardrails, and risks.

The loop (per task)

1. Red — write/extend the test named in the task; run npm test and watch it fail for the right reason. Import from @jest/globals; resolve source via the bare aliases; extend test/__mocks__/obsidian.ts when the unit pulls in more Obsidian API (see the tdd skill).
2. Green — make the minimal change to pass.
3. Refactor — clean up with the suite green.
4. Verify — npm run verify (typecheck + oxlint + jest) must be green. For score tasks also run npm run lint:obsidian and confirm no new violations. For i18n tasks confirm en.ts/es.ts key parity.
5. Commit — one Conventional Commit per completed task/advance (constitution §IX): git add -A && git commit -m "<type>(<scope>): <subject>".
6. Check off the task — mark [x] directly in the GitHub issue comment (edit the comment with gh issue comment <comment-id> --edit-last or find the comment id and patch it).
7. Keep CI green — push the branch; the CI workflow re-runs the blocking guardrails. Because verify is green locally, CI stays green. Fix forward if a push ever goes red — don't stack more commits on a red branch.

Rules

• Single branch — one feature/* branch for the whole issue; never commit to main.
• Never introduce innerHTML, inline el.style.*, Title-case UI strings, bare console.*, or global app — they cost score (constitution §III–IV). Build DOM with createEl; style with c() + SCSS; log with log.
• The user's theme wins (§XV). No hex or named colour in a stylesheet, no pixel the --size-4-* grid can express, Obsidian's own classes (mod-cta, clickable-icon, setting-item, is-active) before inventing one, and a shape that exists twice goes in src/styles/utils/mixins.scss. The guide, with Obsidian's own wording, is docs/development/obsidian-styling.md.
• Touching the Canvas patcher? Keep every patched access guarded and uninstalled on unload (§VI) — see issue #91 / the reviewer agent.
• Update the matching docs/ page + mkdocs.yml nav in the same commit that changes behavior (§VIII).

Exit → stage 5

When all tasks are checked off, do four things before declaring done:

1. Docs audit (mandatory)

For every user-facing change — new feature, changed behaviour, new config option, new action, changed UI text — ask: does the existing docs page cover this?

• New feature / behaviour change → update the matching page under docs/ AND check the mkdocs.yml nav (add an entry if the feature deserves its own page).
• New action → add or update docs/actions/<ActionName>.md.
• New config option → update the settings section of the relevant architecture page.
• API / public surface change → update docs/api/ZettelFlowAPI.md.
• No user-facing change (pure refactor, test, chore) → docs audit is still required; confirm explicitly that no doc update is needed and state why.

This audit is a blocking exit criterion — do not commit the implementation without it. Docs and code travel in the same commit (or a docs: follow-up commit immediately after).