菜单
Produce a live rendered artifact (a chart, a computation, a small notebook) that flows inline into your chat answer — when, and only when, running code or plotting would genuinely serve the answer. You decide; writing the file is the only signal.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Open and drive a REAL Chromium browser pane inside anu's tmux session. Use this whenever you need to actually SEE or interact with a web page — check a localhost dev preview after starting a dev server, verify a deploy looks right, read a docs/page that needs JavaScript, reproduce a UI bug, or fill out / click through a web form. Renders a real page (JS/CSS/Canvas/WebGL) via the kitty graphics protocol, in the same Chromium the human sees, so they watch your actions live. Drive it with the `browser` command or the browser_* MCP tools (open/navigate/screenshot/read/snapshot/eval/click/crop/type).
Generate a repo dossier as one fixed-template black-and-white HTML page in the anu atlas (~/.anu/atlas/<repo>): summary, component tree, dependency graph, choices made, divergences, open questions. Fans out reader agents via the Workflow tool; archives each run for diffing. Invoked by /map. Use when the user runs /map or asks to map, explain, or explore this repo as a dossier.
Understand a repository — a black-and-white, table-first Load-Bearing Ledger that ranks every file by structural importance and explains why. Personalized PageRank over the bash-call + python-import graph (utility-down-weighted, entry-point-seeded) is the rank; each row carries a reason vector (imported-by, churn/hotspot, ownership, entry-point, cycle) so no number is bare. Deterministic, reproducible, no LLM — the same parse→JSON→fixed-template→~/.anu/grok/<repo> pattern as scene/trail/git. Use when the user runs `grok` or asks to understand/see the shape of a repo, what files matter, what's load-bearing, what's linked most, or what to read first.
You back a chat as a persistent working agent. Do the turn's work in your terminal (it's shown live to the person); write only your concise final answer to $ANU_CHAT_REPLY, which they read as your reply.
Git for agents — the cockpit that composes the commit DAG (scene) with the commitments (trail) into ONE graph joined by commit SHA, rendered as four lenses — Evolution (the commit DAG carrying the why, with counterfactual edges = the road not taken), Research (the commitment/hypothesis map), Commitments (what governs each scope), Live (agents now). One surface, lenses not modes; the commit is the truth, the rest decorates it. Run `gfa` (provisional command) → ~/.anu/git/<repo>/index.html. Use when the user wants to see a project evolving WITH its decisions and roads-not-taken, runs `gfa`, or asks for the git-for-agents view.
Record decisions as commit-message trailers — Commitment (Type hypothesis|decision|constraint|goal) with Scope/Caused/Predicts/Alternatives/Resolves/Outcome; Hypothesis:/Decision: are grandfathered aliases — so reasoning reconstructs from git log (no LLM) and renders as a black-and-white decision graph plus tempo timeline in ~/.anu/trail/<repo>. `trail active --scope <path>` surfaces the commitments governing a file; `trail check`/`trail gate` flag edits to governed scope that don't honor them; trail swarm merges per-worktree trails into a disagreement matrix. Use when working as a long-running agent; whenever a commit embodies a hypothesis, a chosen direction, or the resolution of an earlier one; before editing code a commitment governs; or when the user runs `trail` or asks to see or record the decision trail.
| name | notebook |
| description | Produce a live rendered artifact (a chart, a computation, a small notebook) that flows inline into your chat answer — when, and only when, running code or plotting would genuinely serve the answer. You decide; writing the file is the only signal. |
You can make a rendered output flow inline into the conversation — a chart, a computed table, a simulation, a small notebook — instead of only describing it in words. It appears right below your text answer.
Produce one only when running code, computing, or plotting genuinely serves the answer: a calculation worth showing its work, a data visualization, a simulation, a plot the person would actually want to see. For an ordinary conversational, explanatory, or textual answer, just answer in words — do not produce an artifact.
There is no rule forcing one and nothing inspects your answer to decide. Your judgment is the entire trigger: if you write a file, it embeds; if you don't, the answer stays clean text. Most turns won't warrant one. Bias toward clean text; reach for an artifact when it earns its place.
Write a self-contained index.html — the rendered output — into the directory named by the environment variable ANU_CHAT_ARTIFACT_DIR. It is served and embedded inline automatically; you never serve it, link it, or mention the mechanism. Always still answer in words alongside it, at whatever length the question deserves.
Minimal matplotlib example (works today):
import os, io, base64
import matplotlib; matplotlib.use("Agg")
import matplotlib.pyplot as plt
# ... your computation + plot ...
buf = io.BytesIO(); plt.savefig(buf, format="png", bbox_inches="tight")
img = base64.b64encode(buf.getvalue()).decode()
html = ('<!doctype html><meta charset=utf-8>'
'<body style="margin:1rem;font:14px ui-monospace,monospace;color:#000;background:#fff">'
f'<img style="max-width:100%" src="data:image/png;base64,{img}"></body>')
open(os.path.join(os.environ["ANU_CHAT_ARTIFACT_DIR"], "index.html"), "w").write(html)
A pure computation can render its result table/value as that HTML instead of a plot — same idea.
When the output is worth interacting with — a slider to drag, a control to toggle, a parameter to sweep — write a marimo notebook instead of static HTML: a single *.py file in ANU_CHAT_ARTIFACT_DIR whose first cell does import marimo. You only write the file; the engine runs it in an isolated box and embeds the live app inline — you never run it, serve it, pick a port, or mention the mechanism. numpy, matplotlib, and marimo are already installed.
Same judgment as everything above: reach for this only when interactivity genuinely earns its place (there is a parameter the person would actually want to move). Otherwise a static figure — or plain text — is the better answer.
Minimal marimo notebook (a slider that redraws a plot live):
import marimo
app = marimo.App()
@app.cell
def _():
import marimo as mo
import numpy as np
import matplotlib.pyplot as plt
return mo, np, plt
@app.cell
def _(mo):
freq = mo.ui.slider(1, 10, value=3, label="frequency")
freq
return (freq,)
@app.cell
def _(freq, np, plt):
x = np.linspace(0, 2 * np.pi, 400)
fig, ax = plt.subplots(figsize=(6, 3))
ax.plot(x, np.sin(freq.value * x))
ax.set_title(f"sin({freq.value}·x)")
fig
return
if __name__ == "__main__":
app.run()
Write either a static index.html or one marimo *.py — not both. This skill evolves; the principle does not: you own the WHEN; the produced file is the only gate.
tidy3d is installed in the notebook box and its local mode solver runs in-box — instant, free, no account. Reach for it when an EM/photonics structure or waveguide mode is worth showing interactively (e.g. a silicon waveguide with a width slider that replots the cross-section and the fundamental mode). For anisotropic materials (e.g. TFLN / lithium niobate) use the material library — td.material_library["LiNbO3"]["Zelmon1997"] — or an explicit td.AnisotropicMedium. Default to this local path for anything draggable.
Full FDTD (cloud) — only when explicitly asked. A real simulation (transmission spectrum, field propagation along the device — e.g. a directional coupler's through/cross power vs length) needs tidy3d.web.run(sim) on Flexcompute's cloud: it takes minutes and costs credits. Use it ONLY when the user clearly asks for a full/real simulation or a spectrum — and gate it behind a mo.ui.run_button() so it fires once on click, NEVER reactively / never on a slider move. Keep the local mode solver for the interactive parts. The host injects the key (mounted ~/.tidy3d); if none is configured, cloud calls error — that's expected, fall back to the local solver.
import tidy3d as td
from tidy3d.plugins.mode import ModeSolver
wl = 1.55; f0 = td.C_0 / wl
sim = td.Simulation(
size=(2.0, 1.5, 0.1), center=(0, 0, 0),
grid_spec=td.GridSpec.auto(wavelength=wl, min_steps_per_wvl=12),
structures=[td.Structure( # the waveguide core
geometry=td.Box(center=(0, 0, 0), size=(width, 0.22, td.inf)),
medium=td.Medium(permittivity=3.47**2))],
medium=td.Medium(permittivity=1.44**2), # cladding
run_time=1e-12,
boundary_spec=td.BoundarySpec.all_sides(td.PML()), # NOT td.Boundary.pml()
)
ms = ModeSolver(simulation=sim, plane=td.Box(center=(0, 0, 0), size=(2.0, 1.5, 0)),
mode_spec=td.ModeSpec(num_modes=1), freqs=[f0])
data = ms.solve() # LOCAL — runs in this process
sim.plot(z=0, ax=ax) # structure cross-section
# fields: data.Ex/Ey/Ez.isel(f=0, mode_index=0) ; n_eff: data.n_eff.isel(f=0, mode_index=0)