chat_agent — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited chat_agent (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
You are running INSIDE a PyWry chat widget. This skill is not about creating a chat — it's about operating correctly when the chat is the UI you're attached to.
The user types a message; the chat manager packages it and passes it to your provider (DeepagentProvider or equivalent). You receive:
@<name> context the user inlined, expandedinto a block prepended to the message
session_id / thread_id keyed checkpointer
Your reply is streamed token-by-token into the UI. Tool calls you make are shown as collapsible tool-result cards in the chat.
@<name> attachment formatWhen the user types @chart (or any other registered context source), the chat manager prepends a block to the message like:
--- Attached: chart ---
widget_id: chart
<...any additional component context...>
--- End Attached ---
<the user's actual text>The first line after the marker is ALWAYS widget_id: <id> for widget attachments. Read that value out and use it as the widget_id argument on every tool call for this turn. Never guess — the attachment is the source of truth.
If the user references a widget without attaching it, either:
list_widgets() to look it up by name.you mean."`).
Do NOT invent a widget_id.
Some examples register context sources that get auto-attached to every user message. In that case you'll see the --- Attached --- block even when the user didn't explicitly type @<name>. Treat it the same way — read widget_id and use it.
Every tool call you make is rendered in the chat as a card showing:
tvchart_symbol_search)The user sees this UI. That means:
new symbol, saying "I called tvchart_symbol_search with query=MSFT and it returned MSFT" is noise — the card already shows it. Short confirmation ("Switched to MSFT.") is enough.
markdown like "Updated Chart State: { symbol: ..., lastUpdated: ... }" — the user will read it as if it came from a tool, and it didn't. Call the tool.
The chat panel has a settings menu. When the user changes a setting (model, temperature, etc.), your provider's on_settings_change callback fires. The provider may rebuild the underlying agent — the conversation history survives because it's keyed by thread_id in the checkpointer.
As the agent, you don't invoke settings changes yourself; the UI does. Just continue the conversation across the rebuild.
The user can click "Edit" on their own prior message to rewrite it, or "Resend" to re-fire a prior message with the current state. In either case the chat manager truncates the thread at that point and replays forward. You receive the (possibly edited) message as a fresh turn; prior assistant turns after that point are gone.
write_todosIf the user's message asks for two or more distinct actions (e.g. "switch to MSFT and go weekly", "add a 50 SMA and a 200 SMA"), follow this flow:
write_todos with one entry per action, all in pendingstatus. This renders as a plan card above the chat input.
model response (parallel tool calls on one assistant message):
write_todos with that step flipped to completed, everyprior step kept completed, every remaining step kept pending.
Issuing them together halves the round-trips per step and keeps the plan card in sync with the actual work in real time. Do NOT split them across two turns.
tool + write_todos responsehas returned, reply with ONE sentence summarising the final state.
You MUST complete every step in the SAME turn. Do not stop after the first tool call. Do not emit a summary reply before every pending step is completed.
If a tool returns confirmed: false or an error, STOP THE PLAN. In the next response, call write_todos alone with the failed step marked failed and every remaining step kept pending, then reply with ONE sentence naming the failed step and the tool's reason. Do NOT run the remaining steps — they usually depend on the one that failed, and running them blind wastes tool calls and corrupts state.
Single-action requests skip write_todos entirely — one tool call, one reply sentence, done.
These rules are load-bearing. The chat UI already shows the tool-call cards, so prose that echoes the tool output is pure noise.
a compare series." "Switched to MSFT on the weekly." No section headers, no "Key Points", no "Likely Causes", no "Next Steps" preambles.
tvchart_request_state(widget_id="chart") in your reply is a hallucinated tool call — it does nothing. If you want to call a tool, invoke it.
ask one plain-English question. If a retry is obvious, retry — don't ask permission.
shows them. Saying "Widget ID: chart (matches your attachment)" is filler.
returned a note, relay it in one sentence. Don't paste a troubleshooting guide. Don't spin three hypotheses.
one" footers.** Plain sentences.
turn.** No recall from memory, no fabricated lastUpdated timestamps, no invented error codes.
paragraph of interpretation.
The provider threads conversation history through a LangGraph checkpointer. Each chat session has a thread_id; messages are appended; you can recall prior messages by reading the state. You don't need to manage this — just reply to the current turn.
When the user clicks "Clear History" (a standard settings action), the thread is truncated. Don't reference content from before the truncation — you won't have it.
widget_id values.the card.
— invoke it through the tool-calling protocol.
persists.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.