@zoulabo/line-hive 0.2.12 → 0.2.15

package/templates/line-notification.instructions.md

@@ -1,234 +1,73 @@
-# LINE Communication Protocol
+---
+description: "Use when LINE messaging tools (line_set_status, line_ask) are available. Governs mandatory status updates, progress reports, and permission alerts sent via LINE."
+applyTo: '**'
+---
+# LINE Communication Protocol (Light)
 
-**HARD RULE: When a LINE session is active, all replies MUST be sent via `line_ask`. Do not respond in this chat.**
-
-LINE tools are **only used during LINE sessions**. Outside a session, never call any `line_*` tools.
+## HARD RULE
+- Active LINE session ⇒ all user-facing replies via `line_ask`.
+- Outside LINE session ⇒ do not use `line_*` tools.
 
 ## LINE Session
-
-### Activation — starts when ANY of these happen:
-- User says "continue on LINE", "talk on LINE", "notify me on LINE", or similar
-- User says "preapprove for LINE", "prepare for LINE", or "prime LINE", or similar (run pre-flight, then activate)
-- You receive a `pendingReply` from `line_set_status`
-- You call `line_ask`
+### Activation
+- User requests LINE continuation/pre-flight.
+- `pendingReply` appears.
+- Agent calls `line_ask`.
 
 ### Agent Naming
-
-Pick a short, cute, gender-neutral name (max 8 chars). Prefer Japanese-English mashups — e.g. Mochi, Kumo, Yuzu, Sora, Fuwa, Hana, Suzu, Maru, Niko, Rin, Tama, Koko, Nori, Pip, Riku, Umi, Yuki, Kaze, Haru, Toki, Miso, Dango, Kinako, Azuki, Sakura, Matcha, Wasabi, Ponzu, Goma, Tofu. Check `line_list_agents` first — **name uniqueness is enforced**. On `agent_name_taken` error, pick a different name.
+- Short, cute, gender-neutral (max 8 chars).
+- Prefer JP-EN style names; check `line_list_agents` first.
+- If `agent_name_taken`, choose another name.
 
 ### Pre-Flight Tool Approval
-
-When a LINE session is activated by the user, run a pre-flight approval sequence **before** they leave:
-
-1. Tell the user: "Accept each permission prompt. Then **send `?` in LINE and tap Continue** to prime a reply token, and confirm here when done."
-2. Trigger approvals in parallel (skip already-approved categories):
-   - **Terminal**: `ls package.json`
-   - **File edit**: `create_file(".line-hive-preflight", "")` then `rm .line-hive-preflight`
-   - **LINE MCP**: `line_set_status({ description: "pre-flight", agentName: "<name>" })` + `line_list_agents()`
-3. **Do NOT call `line_ask` during pre-flight** — no reply token exists yet.
-4. Once the user confirms, start the session with `line_ask`.
-
-**Skip pre-flight when:** session was activated by `pendingReply`, tools are already approved, or agent has auto-approved permissions.
-
-### Deactivation — ends ONLY when:
-- **User types directly into the editor chat** — they're back at the computer
-- User explicitly says "stop LINE" or "go quiet"
-
-**CRITICAL:** "done", "ok", "thanks", "got it" are conversational replies, NOT deactivation signals. Always call `line_ask` again after processing any reply.
-
-### Active Session Rules
-
-1. **Use `line_ask` for all communication.** Always pass `agentName`. After receiving a reply, always call `line_ask` again — keep the loop going until timeout or deactivation.
-2. **Default timeout policy (D1):** Use the `line_ask` default timeout (24h). Only pass `timeoutMs` when the user explicitly requests a custom timeout.
-3. **Inline status preference (D2):** Prefer `line_ask` `statusDescription`/`progress` over separate `line_set_status` calls where applicable.
-  - Use `line_set_status` only when no outgoing `line_ask` is appropriate (background progress, long-running work, idle/error transition, or collision/language setup)
-  - If using `line_set_status`, include progress in ~10% increments and always check returned `pendingReply`
-4. **Keep messages short** — 1-3 sentences. No filler ("Processing...", "Still here...").
-5. **On timeout**, stop the loop. The user's next message creates a `pendingReply` on your next `line_set_status`, re-activating the session.
-6. **Use numbering for actionable LINE content only** — decisions, tasks, options, and gap items must have stable IDs (`D1`, `A1`, `G1`, etc.). Do **not** force numbering on plain narrative/status sentences.
-
-### Built-in Queue Drain
-
-- `line_ask` now auto-prepends a `📬 Drain (N)` quick-reply button when queued messages exist.
-- Agents should treat this as built-in behavior and should not implement separate custom drain-button logic.
-
-### Numbering Protocol (Mandatory)
-
-Use stable, human-referenceable IDs in all docs and LINE messages:
-
-- **Decisions**: `D1`, `D2`, ...
-- **Actions/Tasks**: `A1`, `A2`, ...
-- **Gaps/Risks**: `G1`, `G2`, ...
-- **General numbered notes**: `N1`, `N2`, ...
-
-Rules:
-- Keep IDs stable across follow-up edits within the same discussion.
-- Do not renumber unchanged items when inserting new ones; append new IDs.
-- In LINE replies, refer to items by ID (e.g., `approve D2`, `skip A3`, `close G4`).
-- In rendered docs/HTML, include IDs in headings or first token of each bullet/row.
-- Narrative updates that are not asking for action may be plain text (no IDs required).
-
-### Quick Reply Usage (Principle-Based)
-
-Quick-reply examples in this doc are illustrative, not exhaustive. Agents may proactively use quick replies in **any** LINE interaction where constrained options improve speed/accuracy, as long as API limits are respected.
-
-Guardrails:
-- Max 13 quick-reply items.
-- Attach quick reply once per `line_ask` call (final message in multi-message sends).
-- Provide a text fallback command for each option (`approve D1`, `skip A2`, etc.).
-
-### Token Conservation
-
-Reply tokens are scarce — each `line_ask` call consumes one. LINE allows **up to 5 messages per reply token**. Use the `messages[]` parameter to batch everything into a single call:
-
-- **Use `messages[]`** — pass an array of up to 5 items. Plain strings are text, `file:` prefix for files (e.g. `"file:.line-hive-tmp/report.xlsx"`). Images auto-detect by extension.
-- **Batch files + text** — send text and files together: `messages: ["Here's the report:", "file:.line-hive-tmp/report.xlsx"]`
-- **File delivery** — generate files with `send: false`, then deliver via `messages[]`. Never use tool-specific `send: true` AND a separate `line_ask`.
-- **Never send a message just to acknowledge** — if the next step is another `line_ask`, skip the intermediate acknowledgment.
-- **5-message hard limit** — LINE API rejects >5 messages per token. Plan batches accordingly.
-
-Example — send text + XLSX + HTML in one token:
-```
-line_ask({ messages: ["Dashboard ready!", "file:.line-hive-tmp/dashboard.xlsx", "file:.line-hive-tmp/report.html"], agentName: "<name>" })
-```
-
-### Rich Content via HTML
-
-Use `line_render_markdown` for all rich content — diagrams, reports, diffs, code, math. It auto-injects CDN libraries for Mermaid diagrams, syntax highlighting (highlight.js), and math (KaTeX). Files are served with TTL (default 2h, max 24h).
-
-**Rule of thumb:** If content is longer than a couple of LINE bubbles (or might exceed LINE's ~2000 char limit), prefer sending an **HTML file** (phone-friendly) instead of a long text message.
-
-**Fallback (no render tool):** If `line_render_markdown` isn't available, you can still send a hand-written `.html` file via `messages[]`:
-```ts
-line_ask({ messages: ["Report:", "file:.line-hive-tmp/report.html"], agentName: "<name>" })
-```
-
-**Diagrams** — write mermaid in markdown, render to HTML (no `mmdc` needed). Use `flowchart LR` with `direction TB` inside subgraphs (or vice versa) — never make everything the same direction. Separate logical sections into individual diagrams rather than one giant chart:
-```bash
-create_file(".line-hive-tmp/diagram.md", "# Architecture\n\n```mermaid\nflowchart LR\n  subgraph Flow[\"Flow\"]\n    direction TB\n    A-->B-->C\n  end\n```")
-line_render_markdown({ inputPath: ".line-hive-tmp/diagram.md", outputPath: ".line-hive-tmp/diagram.html", title: "Architecture", ttl: 30 })
-line_ask({ messages: ["Architecture diagram:", "file:.line-hive-tmp/diagram.html"], agentName: "<name>" })
-```
-
-**Long reports / docs** — when content exceeds LINE's ~2000 char limit:
-```bash
-line_render_markdown({ inputPath: "path/to/report.md", outputPath: ".line-hive-tmp/report.html", title: "Report" })
-line_ask({ messages: ["Here's the full report:", "file:.line-hive-tmp/report.html"], agentName: "<name>" })
-```
-
-**Diffs** — format as markdown code blocks with `diff` language:
-```bash
-create_file(".line-hive-tmp/changes.md", "# Changes\n\n```diff\n- old line\n+ new line\n```")
-line_render_markdown({ inputPath: ".line-hive-tmp/changes.md", outputPath: ".line-hive-tmp/changes.html", title: "Diff" })
-line_ask({ messages: ["Here are the changes:", "file:.line-hive-tmp/changes.html"], agentName: "<name>" })
-```
-
-**Existing .md files** — skills, READMEs, docs:
-```bash
-line_render_markdown({ inputPath: "path/to/file.md", outputPath: ".line-hive-tmp/doc.html", title: "Title" })
-line_ask({ messages: ["Here's the doc:", "file:.line-hive-tmp/doc.html"], agentName: "<name>" })
-```
-
-Send raw images via `messages[]` with `file:` prefix: `messages: ["Screenshot:", "file:.line-hive-tmp/screenshot.png"]` — images auto-detect by extension and display inline.
-
-## Git Review Workflow
-
-When user says "git review", "commit", "review changes", or similar — use `line_git_review` to scan changes, analyze them, and send a decision-ready HTML report.
-
-### 3-Call Workflow
-
-```
-1. line_git_review({ mode: "scan" })           → JSON: branch, files, +/- stats
-2. [Analyze: group by feature, propose commits, flag decisions]
-3. line_git_review({ mode: "report", decisions, commits, groups, ttl: 120 }) → { url }
-4. line_ask({ messages: ["Git review (N files, +X -Y):", url], agentName })
-```
-
-### D/A Numbering
-
-Every item is either a **D** (decision — user must answer) or an **A** (agent-proposed commit):
-
-- **D items** — things the agent can't decide: binary files, submodules, ambiguous untracked files, security-sensitive content. Format: `D1 gitignore / D1 keep / D1 delete`
-- **A items** — proposed commits grouped by feature. Format: `A1 · feat: add login form` with file list and reasoning
-
-### Slot HTML Classes
-
-Build slot HTML using these pre-built CSS classes:
-
-**Decisions (`dc-box`):**
-```html
-<div class="dc-box"><h2>⚠️ Decisions</h2>
-  <div class="fi fw"><div class="fl">D1 · description</div>
-    <b>D1 option1</b> / <b>D1 option2</b></div>
-</div>
-```
-
-**Commits (`cm-box`):**
-```html
-<div class="cm-box"><h2>📦 Commits</h2>
-  <div class="cc"><div class="cm">A1 · feat: description</div>
-    <div class="cf">file1.ts, file2.ts</div>
-    <div class="cr">Reasoning</div></div>
-</div>
-```
-
-**Groups (`gr`):**
-```html
-<div class="gr">
-  <div class="gh" onclick="this.nextElementSibling.style.display=
-    this.nextElementSibling.style.display==='block'?'none':'block'">
-    <h2>Group Name</h2><span class="bd bf">FEAT</span>
-  </div>
-  <div class="gb" style="display:none"><div class="gd">Details</div></div>
-</div>
-```
-Badge classes: `.bf` (feature), `.bo` (docs), `.bx` (fix), `.bn` (new)
-
-### Reply Parsing
-
-User replies with comma-separated instructions:
-
-| Pattern | Action |
-|---------|--------|
-| `ok` / `go` | Execute all A commits + push |
-| `skip A2` | Don't commit group A2 |
-| `merge A1+A3` | Combine commits |
-| `msg A1: new msg` | Override commit message |
-| `D1 ignore` | Apply decision |
-| `no push` | Commit but don't push |
-| `cancel` | Abort |
-
-**Execution order:** Apply D decisions → stage files per group → commit → push → report result.
-
-### Grouping Heuristics
-
-1. Shared feature (handler + test + types)
-2. Shared purpose (all docs changes)
-3. Shared directory (when purpose unclear)
-4. Independent (single-file fixes)
-
-### Commit Prefixes
-
-`feat:` / `fix:` / `docs:` / `refactor:` / `chore:` / `style:`
-
-## Interactive Mode (ON DEMAND)
-
-Off by default. Activate only when user explicitly requests confirmations (e.g., "confirm on LINE"). Before modifying files or running commands: `line_ask("⏳ About to: <action summary> — confirm?")`. Deactivates with the LINE session.
+1. User accepts prompts, sends `?`, then taps `✅ Continue` once to prime a reusable reply token.
+2. Run approvals in parallel:
+   - Terminal: `ls -1 package.json README.md 2>/dev/null || ls -1`
+   - File edit: create/delete `.line-hive-preflight`
+   - LINE MCP: `line_set_status(pre-flight)` + `line_list_agents`
+3. Do not call `line_ask` during pre-flight.
+
+### Deactivation
+- Ends only when user returns to editor chat or says stop/quiet.
+- `done/ok/thanks` are not deactivation signals.
+
+## Active Session Rules
+1. Keep `line_ask` loop alive after each reply.
+2. Timeout default is 24h unless user asks custom.
+3. Prefer inline status (`statusDescription`, `progress`).
+4. Use `line_set_status` only when no outgoing `line_ask` is suitable.
+5. Keep messages 1–3 sentences.
+6. On timeout, stop loop and wait for reactivation.
+7. Use stable IDs for actions (`D#`, `A#`, `G#`, `N#`).
+8. During todo execution, update status after each completed task.
+9. Ask decisions one-by-one; include key detail, an HTML detail link specific to that decision, and quick replies for bounded options.
+
+## Quick Replies
+- Default ON for bounded choices (2–6 options).
+- Keep labels short; include text fallback.
+- Max 13 items; attach once per `line_ask` call.
+- Keep built-in queue drain behavior (`📬 Drain (N)`).
+- Action schema: `message` uses `text`; `postback` uses `data` (+ optional `displayText`) and must not include `text`.
+
+## Token/Delivery Rules
+- 0 push quota policy: LINE delivery must use reply tokens only.
+- Batch with `messages[]` (max 5).
+- Avoid duplicate send paths.
+- Prefer HTML for long/rich content.
+- In LINE sessions, do not send raw Markdown unless explicitly requested.
+- For `.md` docs (plans, READMEs, reports), render to HTML and send the HTML file/link by default.
+
+## Writing Style
+- Use plain, direct language with short sentences.
+- Prefer action checklists over process-heavy prose.
+- Avoid corporate jargon (e.g., "posture", "alignment", "leverage", "framework") unless user asks for formal style.
+
+## Git Review (Light)
+- `scan` → analyze (`D#`/`A#`) → `report` → `line_ask`.
+- Keep command patterns (`ok`, `skip A#`, `merge`, `msg`, `D#`, `no push`, `cancel`).
 
 ## DO NOT
-
-- Call `line_*` tools outside of a LINE session
-- Interpret reply content ("done", "ok", "thanks") as session termination
-- Spam reports more often than every 2 minutes
-- Use interactive mode unless explicitly requested
-- **Waste reply tokens** — never send a file via tool `send: true` and then a separate `line_ask` about it. Never send multiple `line_ask` calls when one suffices.
-- **Pass LINE tools to subagents** — only the top-level agent calls `line_*` tools
-- **Install packages during a session** — user can't approve prompts while away. Install during pre-flight instead.
-- **Fetch external URLs during a session** — may trigger permission prompts. Only fetch when user confirms no permission issue.
-- **Write temp files outside the project** — use `.line-hive-tmp/` (gitignored) for all temp files. Never use `/tmp`, `~/Desktop`, or any path outside the workspace — these trigger permission prompts that block while the user is away.
-
-### Screen Lock Warning
-
-Screen lock may re-lock the keychain or credential store, causing **SSH passphrase prompts** that block any terminal using SSH (`git push/pull`). Mitigate:
-- Run git remote operations **before** the user leaves (during pre-flight)
-- If a terminal hangs, it's likely a passphrase prompt — don't spawn more terminals
+- Pass LINE tools to subagents.
+- Install packages during active LINE sessions.
+- Fetch external URLs during session without prompt-safety confirmation.
+- Write temp files outside `.line-hive-tmp/`.