菜单
Persist, version, and iterate on LLM-generated UI (widgets, HTML, markdown). Load when the user wants to save, find, update, or iterate on a previously-rendered widget — anything that should outlive the chat scrollback.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/kirodotdev/KiroCrew --skill artifacts命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Same-session monitoring loop for PRs, CI runs, tickets, and deployments using the monitor_start / monitor_update / autonudge_stop MCP tools. The loop re-injects your check instructions into THIS session on an idle interval — same context, same tools — and works from dashboard chat, Slack threads, and Discord DMs. Use when the user says "babysit", "monitor", "keep checking", "keep an eye on", "loop on this PR", "let me know when", or wants polling that outlives a wait+poll window. NOT for fresh-session work (use cron_add) or external-system callbacks (use register_hook).
Build, validate, and install Kiro Crew theme packs -- pack anatomy, the 54-variable palette, role-tagged fonts, the overrides.css allowlist (what installs vs what actually renders), and the install-verify cycle. Use when the user wants to create or edit a theme pack.
Build, package, and publish KiroCrew external apps. Covers app.json manifest, UI components, crons, skills, self-healing install, git publishing, and common pitfalls.
正在显示 SKILL.md
基于 SOC 职业分类
| name | artifacts |
| description | Persist, version, and iterate on LLM-generated UI (widgets, HTML, markdown). Load when the user wants to save, find, update, or iterate on a previously-rendered widget — anything that should outlive the chat scrollback. |
| triggers | artifact, save widget, save this, iterate, iterate on, update the widget, change the widget, version, library, find widget, what have we built, iterate again, redo the |
@kirocrew-core/artifact_*)A widget rendered inline in chat (<mcwidget>) is transient — it scrolls
away with the conversation. An artifact is a widget (or other content)
that's been given a stable identity, a version history, and a URL the user
can open from /artifacts/<slug> in the dashboard.
Artifacts exist so the user can build a library of durable, named work — useful UIs (CR queue, pipeline health, ticket triage, dashboards) and substantial documents (plans, design docs, analyses, reports) alike — to return to, iterate on across sessions without losing prior versions, or share with peers for feedback. The library is curated: it holds work worth keeping, not a mirror of every file or a copy of the chat.
| Concept | Means |
|---|---|
| Slug | URL-safe identifier like cr-queue (auto-derived from name). Stable across versions. The user references artifacts by slug. |
| Version | Monotonic integer. Every content change bumps it. The 50 most-recent versions are retained; older ones get pruned (configurable via ). |
MAX_VERSIONS| Save | Persist the artifact for the first time. Picks a slug, returns it. |
| Update / Iterate | Modify content of an existing artifact. Bumps version, preserves history. |
| List / Find | Discover what's saved. Filter by tag, kind, name substring. |
| Tool | Purpose |
|---|---|
artifact_save | Create a new artifact, returns slug |
artifact_get | Load content + metadata (optional version) |
artifact_update | Modify content/metadata; bumps version on content change |
artifact_list | Filter by tag, kind, q (name substring) |
artifact_versions | List version numbers for a slug |
artifact_delete | Permanently remove |
All under the @kirocrew-core MCP server.
When you produce work worth keeping — something the user would plausibly want later — save it:
cr-queue."artifact_save with
source_path, and kind="markdown" for markdown); if it lives only inline in
chat, offer to save it.Don't save throwaway output: one-shot answers, quick demo widgets, scratch notes, or project/package code that belongs in a CR.
Before writing a plan/doc/analysis from scratch, check whether one already
exists: artifact_list(q="<topic>") finds your own artifacts — offer to iterate
on a strong match instead of duplicating it. (Use artifact_list for this;
don't run a knowledge search just to find artifacts.)
artifact_save (kind=widget)Before calling artifact_save with kind=widget, always call
artifact_list(kind="widget", q="<name>") first to check for an existing
artifact with the same name. If a match exists, do not call
artifact_save — call artifact_update on the existing slug instead so
the new content captures as a new version of the same artifact identity.
Only call artifact_save after artifact_list returns no name match.
This rule applies regardless of how the user phrased the request. "Save
this version", "save this", "remember this", and silent auto-saves all
go through the same pre-save check. The artifact-store backend also
attaches a duplicate-warning hint to the artifact_save response when
a same-named widget artifact already exists — if you see that hint, the
save just created a duplicate and you should artifact_delete the new
one and artifact_update the existing one to recover.
The frontend's bookmark click runs an equivalent dedup probe before POSTing, so a user clicking the bookmark icon won't create duplicates even if you forget the rule above. The rule still matters for explicit "save this" turns where the user goes through you, not the bookmark.
Whenever you emit an <mcwidget> body that came from (or just became) a
saved artifact, include the slug as an attribute on the opening tag:
<mcwidget title="CR Queue" slug="cr-queue">
…body…
</mcwidget>
This binds the impression to the saved artifact. The bookmark icon
renders filled, the title links to /artifacts/<slug>, and clicking
the bookmark un-saves rather than creating a duplicate.
Always emit the slug on:
artifact_save returnsartifact_update (iteration)artifact_list(q="...") — see "iterate without a slug" below)The tool responses for artifact_save, artifact_get, and artifact_update
all return a re-emit hint with the exact <mcwidget title="..." slug="...">
opening tag — copy it verbatim. If you find yourself typing the tag from
memory you're doing it wrong.
If you forget the slug, the user clicking save creates a duplicate artifact. The frontend has a title-based safety net that catches most cases (it searches for an existing artifact with the same name on save click and binds to the most recently updated one), but the safety net is a backstop for legacy widgets and agent compliance failures — not a substitute for threading the slug correctly.
artifact_save carries the slug — preserve it.artifact_list(q="...") — version
snapshots also capture historical titles.slug= and the
frontend will derive a stable identity from the message location. This
works because the same chat message renders the same derived slug on
every load — so if the user clicks bookmark, refreshes, and clicks
again, the second click hits the same slug (idempotent, no duplicate).The frontend bookmark POSTs directly to the API and updates its own UI state — the icon flips between filled (saved) and unfilled (not saved). You don't get a chat event for this. The save and un-save are intentionally silent so the conversation history stays clean.
What this means in practice:
[UI] saved-as-artifact message after the
user clicks the bookmark.artifact_list (most recent first; filter by q if you have a name
hint). The "iterate without a slug" decision tree below covers this case./api/artifacts/<slug> on mount and on tab visibility change, so
bookmark state stays consistent across tabs / sessions / refreshes
without you doing anything.The user says "iterate on artifact — change X". Flow:
artifact_get(slug) → read current.htmlartifact_update(slug, content=new_html) → version bumps to vN+1Some sessions are artifact-bound companions: the user opened them from an
artifact's detail page, and your session context includes an injected entry
("Companion chat for artifact `` …") naming the slug, kind, version,
and open-comment count. In a companion session the user speaks naturally
("summarize this", "make the header sticky") without repeating the slug —
resolve every artifact reference to the slug from that context entry. Your
behavior is otherwise unchanged: the same iterate flow and the same comment
triage rules apply, and the user sees your artifact_update results live in
the page next to the chat.
When the user says "iterate on the widget" / "update the date widget" / "change the badge to red" without specifying a slug, follow this decision tree:
Did the conversation already establish an artifact slug
(via a prior artifact_save call by you, or a slug= attribute on a widget
you re-emitted earlier this session)?
├── YES → use that slug, run the iterate flow above
└── NO ──┬── Did you emit a widget in a recent turn that the user
│ is plausibly referring to?
│ ├── YES → save the previous widget body as v1 with a
│ │ descriptive name, THEN apply the change as v2
│ │ via artifact_update. Surface the slug to the user
│ │ ("Saved as `<slug>` and updated to v2 with the change.")
│ └── NO ──── call artifact_list (most recent first); if a
│ strong match exists, confirm with the user
│ ("Did you mean `cr-queue` (last updated 2m ago)?")
│ before iterating. If no match, ask which artifact
│ they mean.
└── (fallthrough) ─→ ask the user to disambiguate.
Critical: never tell the user "the widget wasn't saved, so I can't iterate" — that contradicts the entire point of the feature. Save it yourself, iterate on it, and tell them what slug you assigned.
Comments delegate work: once a comment's directive is carried out, the comment has done its job. When you address artifact comments (the user asked you to iterate / "address the comments"), triage EVERY open comment as part of the same pass — never leave the human to re-read and clean up stale annotations by hand.
A comment may be anchored: artifact_get_comments returns the exact quoted
span it was attached to, because the human selected that text in the artifact
before writing the note. Treat an anchored comment as an instruction about that
span — resolve it there rather than applying it globally, and re-read the span
before editing, since a prior edit may have moved it. An anchor whose quote no
longer exists in the content comes back flagged as orphaned; say so instead of
guessing where it used to point.
| Case | Action |
|---|---|
| Unambiguous directive, fully applied ("delete this", "fix typo", a clear reframe) | artifact_delete_comment with a reason ("applied in vN: ") |
| Applied with interpretation or judgment the human may want to check | artifact_mark_review + short artifact_reply_comment stating what was done |
| Not applied / you disagree / needs discussion | artifact_reply_comment with your reasoning; leave the thread open |
| Anchor text deleted as part of applying the comment | Same as row 1 — delete |
Rules:
resolved status) is human-only — never attempt it.artifact_update, comment by
comment. Deletions are audited and appear in the artifact's activity feed
with your reason, so nothing disappears without a trace.^[a-z0-9](?:[a-z0-9-]{0,78}[a-z0-9])?$.When the user asks "what have we built?" / "what artifacts do we have?" /
"show me my widgets", call artifact_list and present the results — slug,
name, kind, version, updated_at. Group by tag if that aids comprehension.
artifact_list accepts tag, kind, and q (name substring) filters.
Use them to narrow when the user gives constraints.
artifact_update(slug, content=X) ALWAYS bumps the version when content changes.MAX_VERSIONS = 50; older ones get pruned./artifacts/<slug> (dropdown).artifact_get(slug, version=N) to read, then artifact_update(slug, content=that_html) to make it the new current.Tags are free-form, ≤ 16 per artifact. Useful tag conventions:
cr, pipeline, ticket, oncall, opslack, web, uploadwip, archivedKind is one of widget (default), html, markdown, svg, json, text.
Use widget for <mcwidget> bodies; the others for raw content the
dashboard renders differently.
kind: html — widget is correct.<mcwidget title="..."> tag in content.
Save the inner HTML body so the artifact page can wrap it in the same
iframe sandbox.artifact_update.artifact_delete without explicit user direction. Deletes are
permanent.User: render a small mcwidget showing today's date and a colored status
badge.
You: <mcwidget title="Today's status">… body …</mcwidget>
(Heuristic: probable ongoing dashboard intent → auto-save.)
[calls artifact_save(name="Today's status", content="<inner html>",
kind="widget")]
Saved as `today-s-status`.
User: change the badge to red.
You: [calls artifact_get("today-s-status")]
[modifies the badge color]
[calls artifact_update("today-s-status", content=new_html)]
<mcwidget title="Today's status" slug="today-s-status">
… body with red badge …
</mcwidget>
Updated to v2.
When you summarise a content change to a file-backed artifact (after
artifact_update, artifact_revert, or any edit), the dashboard renders
fenced ```diff blocks specially — including an Open file button in
the diff header that drops the user into the file in the side panel.
That button only appears when the diff contains standard unified-diff
file headers. For artifact reverts, iterations, and any edit where you
have a source_path available, always include those headers so the
affordance works.
Required header lines, in order, at the top of the diff body:
--- <source_path>
+++ <source_path>
@@ -<oldStart>,<oldLines> +<newStart>,<newLines> @@
Use /dev/null on the --- line for new files, and on the +++
line for deletions. The dashboard's diff renderer accepts both this
plain form and git's --- a/<path> / +++ b/<path> form, but the
plain form matches KiroCrew's system prompt (config/prompt.md)
so emit it consistently.
Example for an artifact-revert summary where the artifact's
source_path is ~/notes/test-doc.md and you reverted to v2:
Reverted `test-doc-md` to v2's content, saved as v4.
```diff
--- ~/notes/test-doc.md
+++ ~/notes/test-doc.md
@@ -1,6 +1,6 @@
# Hello
This is **bold**
I am editing this from the side panel.
-
+This edit is from the Artifact's detail page.
```
For chat-backed artifacts (no source_path), there's no file to open,
so plain ```diff blocks without headers are fine — the dashboard simply
doesn't render the Open file button.
How to obtain the source path:
Artifact returned by artifact_get includes source_path
(empty string for chat-backed artifacts). Read it once at the start
of an edit and reuse for any diff you summarise.@@ -1 +1 @@ hunk header is acceptable — the file path is what
matters for the Open file button.