dendritic migration

dendritic migration

modules/_opencode/command/albanian-lesson.md

@@ -0,0 +1,49 @@
+---
+description: Turn pasted Albanian lesson into translated notes and solved exercises in zk
+---
+
+Process the pasted Albanian lesson content and create two `zk` notes: one for lesson material and one for exercises.
+
+<lesson-material>
+$ARGUMENTS
+</lesson-material>
+
+Requirements:
+
+1. Parse the lesson content and produce two markdown outputs:
+   - `material` output: lesson material only.
+   - `exercises` output: exercises and solutions.
+2. Use today's date in both notes (date in title and inside content).
+3. In the `material` output:
+   - Keep clean markdown structure with headings and bullet points.
+   - Do not add a top-level title heading (no `# ...`) because `zk new --title` already sets the note title.
+   - Translate examples, dialogues, and all lesson texts into English when not already translated.
+   - For bigger reading passages, include a word-by-word breakdown.
+   - For declension/conjugation/grammar tables, provide a complete table of possibilities relevant to the topic.
+   - Spell out numbers only when the source token is Albanian; do not spell out English numbers.
+4. In the `exercises` output:
+   - Include every exercise in markdown.
+   - Do not add a top-level title heading (no `# ...`) because `zk new --title` already sets the note title.
+   - Translate each exercise to English.
+   - Solve all non-free-writing tasks (multiple choice, fill in the blanks, etc.) and include example solutions.
+   - For free-writing tasks, provide expanded examples using basic vocabulary from the lesson (if prompted for 3, provide 10).
+   - Translate free-writing example answers into English.
+   - Spell out numbers only when the source token is Albanian; do not spell out English numbers.
+
+Execution steps:
+
+1. Generate two markdown contents in memory (do not create temporary files):
+   - `MATERIAL_CONTENT`
+   - `EXERCISES_CONTENT`
+2. Set `TODAY="$(date +%F)"` once and reuse it for both notes.
+3. Create note 1 with `zk` by piping markdown directly to stdin:
+   - Title format: `Albanian Lesson Material - YYYY-MM-DD`
+   - Command pattern:
+     - `printf "%s\n" "$MATERIAL_CONTENT" | zk new --interactive --title "Albanian Lesson Material - $TODAY" --date "$TODAY" --print-path`
+4. Create note 2 with `zk` by piping markdown directly to stdin:
+   - Title format: `Albanian Lesson Exercises - YYYY-MM-DD`
+   - Command pattern:
+     - `printf "%s\n" "$EXERCISES_CONTENT" | zk new --interactive --title "Albanian Lesson Exercises - $TODAY" --date "$TODAY" --print-path`
+5. Print both created note paths and a short checklist of what was included.
+
+If no lesson material was provided in `$ARGUMENTS`, stop and ask the user to paste it.

modules/_opencode/command/code-review.md

@@ -0,0 +1,10 @@
+---
+description: Review changes with parallel @code-review subagents
+---
+Review the code changes using THREE (3) @code-review subagents and correlate results into a summary ranked by severity. Use the provided user guidance to steer the review and focus on specific code paths, changes, and/or areas of concern. Once all three @code-review subagents return their findings and you have correlated and summarized the results, consult the @oracle subagent to perform a deep review on the findings focusing on accuracy and correctness by evaluating the surrounding code, system, subsystems, abstractions, and overall architecture of each item. Apply any recommendations from the oracle. NEVER SKIP ORACLE REVIEW.
+
+Guidance: $ARGUMENTS
+
+First, call `skill({ name: 'vcs-detect' })` to determine whether the repo uses git or jj, then use the appropriate VCS commands throughout.
+
+Review uncommitted changes by default. If no uncommitted changes, review the last commit. If the user provides a pull request/merge request number or link, use CLI tools (gh/glab) to fetch it and then perform your review.

modules/_opencode/command/inbox-triage.md

@@ -0,0 +1,81 @@
+---
+description: Triage inbox one message at a time with himalaya only
+---
+
+Process email with strict manual triage using Himalaya only.
+
+Hard requirements:
+- Use `himalaya` for every mailbox interaction (folders, listing, reading, moving, deleting, attachments).
+- Process exactly one message ID at a time. Never run bulk actions on multiple IDs.
+- Do not use pattern-matching commands or searches (`grep`, `rg`, `awk`, `sed`, `himalaya envelope list` query filters, etc.).
+- Always inspect current folders first, then triage.
+- Treat this as a single deterministic run over a snapshot of message IDs discovered during this run.
+
+Workflow:
+1. Run `himalaya folder list` first and use those folders as the primary taxonomy.
+2. Use this existing folder set as defaults when it fits:
+   - `INBOX`
+    - `Correspondence`
+    - `Orders and Invoices`
+    - `Payments`
+    - `Outgoing Shipments`
+    - `Newsletters and Marketing`
+    - `Junk`
+    - `Deleted Messages`
+3. Determine source folder:
+   - If `$ARGUMENTS` is a single known folder name (matches a folder from step 1), use that as source.
+   - Otherwise use `INBOX`.
+4. Build a run scope safely:
+   - List with fixed page size `20` and JSON output: `himalaya envelope list -f "<source>" -p 1 -s 20 --output json`.
+   - Start at page `1`. Enumerate IDs in returned order.
+   - Process each ID fully before touching the next ID.
+   - Keep an in-memory reviewed set for this run to avoid reprocessing IDs already handled or intentionally left untouched.
+   - When all IDs on the current page are in the reviewed set, advance to the next page.
+   - Stop when a page returns fewer results than the page size (end of folder) and all its IDs are in the reviewed set.
+5. For each single envelope ID, do all checks before any move/delete:
+    - Check envelope flags from the JSON listing (seen/answered/flagged) before reading.
+    - Read the message: `himalaya message read -f "<source>" <id>`.
+    - If needed for classification, inspect attachments: `himalaya attachment download -f "<source>" <id> --dir /tmp/himalaya-triage`.
+    - If attachments are downloaded, inspect them and `rm` the downloaded files from `/tmp/himalaya-triage` after use.
+    - Move: `himalaya message move -f "<source>" "<destination>" <id>`.
+    - Delete: `himalaya message delete -f "<source>" <id>`.
+6. Classification precedence (higher rule wins on conflict):
+    - **Actionable and unhandled** — if the message needs a reply, requires manual payment, needs a confirmation, or demands any human action, AND has NOT been replied to (no `answered` flag), leave it in the source folder untouched. This is the highest-priority rule: anything that still needs attention stays in `INBOX`.
+    - Human correspondence already handled — freeform natural-language messages written by a human that have been replied to (`answered` flag set): move to `Correspondence`.
+    - Human communication not yet replied to but not clearly actionable — when in doubt whether a human message requires action, leave it untouched.
+    - Clearly ephemeral automated/system message (alerts, bot/status updates, OTP/2FA, password reset codes, login codes) with no archival value: move to `Deleted Messages`.
+    - Automatic payment transaction notifications (charge/payment confirmations, receipts, failed-payment notices, provider payment events such as Klarna/PayPal/Stripe) that are purely informational and require no action: move to `Payments`.
+    - Subscription renewal notifications (auto-renew reminders, "will renew soon", price-change notices without a concrete transaction) are operational alerts, not payment records: move to `Deleted Messages`.
+    - Installment plan activation notifications (e.g. Barclays installment purchase confirmations) are operational confirmations, not payment records: move to `Deleted Messages`.
+    - "Kontoauszug verfügbar/ist online" notifications are availability alerts, not payment records: move to `Deleted Messages`.
+    - Orders/invoices/business records: move to `Orders and Invoices`.
+    - Shipping/tracking notifications (dispatch confirmations, carrier updates, delivery ETAs) without invoice or order-document value: move to `Deleted Messages`.
+    - Marketing/newsletters: move to `Newsletters and Marketing`.
+    - Delivery/submission confirmations for items you shipped outbound: move to `Outgoing Shipments`.
+    - Long-term but uncategorized messages: create a concise new folder and move there.
+7. Folder creation rule:
+   - Create a new folder only if no existing folder fits and the message should be kept.
+   - Naming constraints: concise topic name, avoid duplicates, and avoid broad catch-all names.
+   - Command: `himalaya folder add "<new-folder>"`.
+
+Execution rules:
+- Never perform bulk operations. One message ID per `read`, `move`, `delete`, and attachment command.
+- Always use page size 20 for envelope listing (`-s 20`).
+- If any single-ID command fails, log the error and continue with the next unreviewed ID.
+- Never skip reading message content before deciding.
+- Keep decisions conservative: when in doubt about whether something needs action, leave it in `INBOX`.
+- Never move or delete unhandled actionable messages.
+- Never move human communications that haven't been replied to, unless clearly non-actionable.
+- Define "processed" as "reviewed once in this run" (including intentionally untouched human messages).
+- Include only messages observed during this run's listings; if new mail arrives mid-run, leave it for the next run.
+- Report a compact action log at the end with:
+  - source folder,
+  - total reviewed IDs,
+  - counts by action (untouched/moved-to-folder/deleted),
+  - per-destination-folder counts,
+  - created folders,
+  - short rationale for non-obvious classifications.
+
+<user-request>
+$ARGUMENTS
+</user-request>

modules/_opencode/command/plan-spec.md

@@ -0,0 +1,17 @@
+---
+description: Dialogue-driven spec development through skeptical questioning
+---
+
+Develop implementation-ready specs through iterative dialogue and skeptical questioning.
+
+First, invoke the skill tool to load the spec-planner skill:
+
+```
+skill({ name: 'spec-planner' })
+```
+
+Then follow the skill instructions to develop the spec.
+
+<user-request>
+$ARGUMENTS
+</user-request>

modules/_opencode/command/session-export.md

@@ -0,0 +1,17 @@
+---
+description: Add AI session summary to GitHub PR or GitLab MR description
+---
+
+Update the PR/MR description with an AI session export summary.
+
+First, invoke the skill tool to load the session-export skill:
+
+```
+skill({ name: 'session-export' })
+```
+
+Then follow the skill instructions to export the session summary.
+
+<user-request>
+$ARGUMENTS
+</user-request>