chore: improve skill

Signed-off-by: Dennis Zhuang <killme2008@gmail.com>

Author: killme2008

CLAUDE.md

@@ -56,7 +56,29 @@ AI tool          ←  MCP server (get_build_errors) ←  store.Drain()  ←  per
 - **Host field**: `LogMessage.Host` is set via cached `os.Hostname()` at capture startup. Used for multi-source origin labeling. GreptimeDB uses `COALESCE(host, '')` for backward compat with pre-existing rows.
 - **File store IPC**: `pending.jsonl` → atomic rename to `pending.jsonl.draining` → read → delete. Leftover lines written back to prevent data loss.
 - **Config merge**: `.mcp.json` / `settings.json` / `opencode.json` reads existing → upserts devtap entry → writes back. Never overwrites other tools' config.
-- **Instruction injection**: Appends `<!-- devtap:start -->` / `<!-- devtap:end -->` block to project instruction files. Idempotent via marker detection.
+- **Instruction injection**: Appends `<!-- devtap:start -->
+## devtap
+
+devtap captures build/dev output from a separate terminal and delivers it here via MCP.
+
+**You MUST check devtap in these situations:**
+- At the start of each new task or conversation turn
+- Before writing or editing any code
+- After being told that a build, test, or dev server has new output
+
+**Use this call order:**
+1. Call "get_build_status" once at the start of the turn.
+2. Call "get_build_errors" when status reports pending messages, when the user says new output arrived, or before the first code edit in the turn.
+
+**Call limit per turn:** call "get_build_errors" at most once per turn unless new output is reported.
+
+**Multi-source mode:** when devtap drains from multiple sources, tags are prefixed with "host/label |" (for example, "[devtap: myhost/local | make]"). "host" is the machine name, "label" identifies the source. Show these prefixes as-is. If output includes source warnings (for example, source unreachable), show those warnings verbatim and continue with output from reachable sources.
+
+**Output format:** when "get_build_errors" returns content:
+If build succeeded, acknowledge briefly (do not repeat the output).
+If build failed, present the error output verbatim in a fenced code block.
+Then add one line: "Next action: <what you will do>".
+<!-- devtap:end -->` block to project instruction files. Idempotent via marker detection.
 - **Session encoding**: `session.EncodeDir("/foo/bar")` → `"-foo-bar"`, shared across adapters.
 - **Capture modes**: `runner.go` (batch, flush every 50 lines) vs `longrun.go` (debounce timer, for dev servers).
 - **Scanner buffers**: 64KB initial / 1MB max (`internal/capture/errors.go`). On scanner error (line >1MB), pipe is drained to discard to prevent child process deadlock.

skills/devtap-get-build-errors/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: devtap-get-build-errors
-description: Fetch pending devtap build/dev output for the current turn using get_build_status and get_build_errors. Use when the user asks to check build errors, latest build logs, or "/get_build_errors"-style actions.
+description: Fetch devtap output for the current turn. Default to concise summaries and print raw logs only on explicit request.
 metadata:
   short-description: Fetch devtap output
 ---
@@ -16,14 +16,18 @@ Use this skill when the user asks for build errors, latest build output, or an e
    - status reports pending output
    - user explicitly asks to fetch/check logs now
    - user says new build/test/dev output arrived
-3. If build succeeded, acknowledge briefly (do not repeat the output).
-4. If build failed, present the error output verbatim in a fenced code block.
-5. Keep source warnings verbatim (for example, unreachable source warnings).
-6. After the output, add one line: `Next action: <what you will do>`.
+3. If build succeeded, acknowledge briefly (do not repeat output).
+4. If build failed, provide a concise summary by default:
+   - source label(s)
+   - final failure signal (for example exit code or test summary)
+   - most actionable failing case/file/error line(s)
+5. Show raw output verbatim only when the user explicitly asks for full/raw/original logs.
+6. Keep source warnings verbatim (for example, unreachable source warnings).
+7. After the output (or summary), add one line: `Next action: <what you will do>`.
 
 ## Rules
 
 - Do not fabricate or reinterpret error content.
 - Do not call `get_build_errors` repeatedly in the same turn unless new output is reported.
-- MCP tool names map to CLI subcommands: `get_build_status` → `devtap status`, `get_build_errors` → `devtap drain`.
+- MCP tool names map to CLI subcommands: `get_build_status` -> `devtap status`, `get_build_errors` -> `devtap drain`.
 - If MCP tools are unavailable, use `scripts/get_build_errors.sh` as CLI fallback.