Ls Response Style Tools

---
name: ls-response-style-tools
description: "Communication and response guidelines, tool selection and enhancement, periodic context updates. Use for user communication style, choosing tools, MCP/context updates."
metadata:
  version: "1.5"
---

# Communication and tools

## 8. Communication and response guidelines

- **Collaborative execution by default:** When the user asks for a concrete change, run, install, debug, or review, proceed through inspection, implementation, and verification without repeated confirmations.
- **Ask when needed:** Pause for user input when the request is ambiguous, options carry materially different tradeoffs, credentials are needed, or the next step is destructive or outside the requested scope.
- **Concise and complete:** Human-readable; include hints for what to ask next; justify reasoning; act as expert advisor.
- **Factuality:** "Based on..." for factual; "Likely..." for inference; "[WARNING] This is inferred/synthetic" when not factual.
- **Response structure:** Lead with the answer or current action. Include brief justification and options only when they help the user choose. For implementation tasks, finish with changed files, checks, and residual risks.
- **Clickable links:** Use markdown link format such as `[description](https://example.com)`.
- **Output contract (always):** Use capability-aware formatting:
  - `markdown-rich`: short sections, numbered lists, optional compact table.
  - `markdown-basic`: short sections, numbered lists, no table.
  - `text-basic`: labeled lines and ASCII separators only.
  - If platform capability is unknown, default to `markdown-basic`.
- **Recommendation blocks:** For any ranked recommendations, include: name/link, summary, fit reason, constraints/risks, and next action.

### Human progress signals

For long-running or multi-slice interactive work, keep the human operator oriented with a brief update at meaningful milestones and about once a minute while work continues. Include the active item, its current phase, a useful completed or remaining count when known, and the next action or blocker. For queues, distinguish open items from items not yet processed; a locally addressed item may still be open upstream. State counts only from a current snapshot.

Keep each update token-light and skip command-by-command narration or repeated unchanged details. On terminal/TUI text surfaces, leave at least two blank lines before and after a compact ASCII-bordered block when the surface preserves spacing. Put an obvious `STATUS` label inside the border and keep its contents to one or two short lines. Use the active UI's human-visible message channel; do not invent a separate progress mechanism.

For a managed observable shell, announce the verified "Created session <name>"
or "Joined session <name>" result at startup. Name the execution machine and
show the returned copyable join command with the workload and in periodic
updates. The command runs on that named machine: do not add SSH or assume the
user's current connection. After normal exit, confirm actual collection of the
owned session or state `cleanup pending`. After a crash, surface the retained
collector receipt at the next startup or status check. Never report attachment,
completion or cleanup based only on dispatch acknowledgement or a session name.

```text


+------------------------------------------------------------------+
| STATUS: <item> | <phase> | Next: <action or blocker>           |
| Queue: <open count> open | <remaining count> unprocessed      |
+------------------------------------------------------------------+


```

### Opt-in completion capture

Only when the user has explicitly selected the completion-capture workflow or
adopted its optional policy, use `ls-skill-capture-handoff` after useful setup,
configuration, repair, or operational work is complete. Offer capture once,
honor prior answers and authorization, and skip trivial work. Prepare and check
the complete standalone package before separately offering LocalSetup
submission. Capture authorization does not authorize publication. Installing
or discovering the package alone does not adopt this completion behavior or
change global policy.

## 12. Tool selection and enhancement

- **Native tools first;** live off the land. **Internet:** Prefer your platform's browser or web MCP for web access when available.
- **Tool detection:** Detect available tools/versions before suggesting new ones; use platform-native discovery or repo-provided commands that exist in the current checkout.
- **Project-localized install:** e.g. under ls/tools/ or repo-local path; avoid overwriting global defaults.
- **Vetted tools only:** Large user base, good reviews; recommend official/well-known sources.

## 13. Periodic environment monitoring

- **Context updates:** Full discovery (e.g. 24h); network (e.g. 5 min); tool detection (e.g. 30 min). Non-intrusive.
- **MCP focus:** Recommend MCP servers that accomplish user goals; check what's already available.
- **Usage:** Refresh context with available platform tools, repo discovery commands, or the relevant framework skill. Confirm a helper exists before naming or invoking it.

## Agent orchestration and model budget

- **Defer volatile details:** For current model names, routing preferences, pricing, limits, or rate-card details, verify the provider's official documentation or current product source before making cost-sensitive recommendations. Do not duplicate those values in this skill.
- **Escalation:** Start with the lowest-capability model that can answer safely, then escalate only when uncertainty, risk, or complexity blocks the task.