Kit Assistant

The Chat tab in the AI Dev Kit dashboard. It answers, but it cannot do anything, and this page is the plan for fixing that.

:::note Status: Phase 1 under way The first two tasks are built — the chat now carries a brief describing the kit, and states which model is answering. It still has no tools, so it cannot fetch a page itself; what changed is that it can now point at the part of the kit that can. The summary below is detected from the kit source, not ticked by hand. :::

2 of 11 tasks completenot yet scaffolded

Verified against the extension source on 2026-10-21.

What is actually wrong with it

Not the model, and not the prompt wording. The panel is a passthrough: /local-ai/chat takes the last twelve turns, prepends one sentence of system prompt, and sends them on. No tools, no context, no knowledge of the service it is running inside.

That single design choice produces every unhelpful answer people hit:

Asked	It says	What is actually true
"What's your AI model?"	"I don't have access to my underlying model name."	The server returns out.model on every reply, and the dashboard header shows the provider.
"Can you make a short scene on the Studio?"	"I don't have browser/network access."	The Studio bridge runs on this service — the home screen reports its last call.
"Can you connect to this URL?"	"I can't browse it."	The kit is a browser: capture.mjs drives Playwright and /capture is an HTTP endpoint.

The third one is the clearest. A converter assistant that cannot look at a page is refusing the job it exists for — and it is refusing with a capability its own process already has.

The shape of the fix

Three phases, in dependency order, each useful on its own:

1. Context — tell it where it is. No new infrastructure; the service already holds all of it.
2. Tools — let it use the kit's hands. Reading only: look at a page, read a report, search the docs.
3. Actions — let it change things, behind an explicit confirm.

Reading is safe and lands first. Writing comes last and never runs on the strength of a sentence typed in a chat box.

Phase 1 — Let it know where it isIn progress

2/3

Today the chat is a passthrough: a one-sentence system prompt, the last twelve turns, and nothing else. It does not know which model is answering it, that a capture service is running beside it, or that a capture-out/ folder exists a few paths away. Every unhelpful answer in the current panel traces back to that. This phase costs no new infrastructure — it is context the service already holds and simply never sends.

• ✓
  A system prompt that describes the kit — Done

  Replace the single sentence in CHAT_SYSTEM with a brief that states what the kit is, what sits beside the chat (the capture service, the converter, the Studio bridge, the recipes and styles), and — critically — what it must not claim it cannot do. The current prompt leaves the model to guess, and it guesses that it is a generic chatbot with no abilities.

• ✓
  Tell it which model is answering — Done

  Asked "what's your AI model?" the panel says it has no access to that — while the server returns out.model on every single reply and the dashboard header shows the provider. The answering backend and model go into the turn, so the chat can state them plainly. This is the cheapest possible fix and the most visibly silly failure.

• ○
  Know what has been captured — Planned

  A list of the sites in the watched capture-out/ folder, with each one's section count and conversion-report headline, injected as context. It turns "I can't see anything" into "the last capture has 11 sections; two still fall back to code_block" — which is the question people actually open the panel to ask.

Phase 2 — Give it the kit's own handsPlanned

0/5

The kit is a browser. capture.mjs drives Playwright, /capture is an HTTP endpoint, and the conversion pipeline runs locally. So "I don't have network/browser access to external sites" is not a limitation — it is the chat being unaware of the machinery it is sitting inside. This phase exposes that machinery as tools the model can call, with every call reported in the panel so nothing happens invisibly.

• ○
  A tool-calling loop — Planned

  The chat currently sends one message and renders one reply. It needs a loop: offer tools, run the ones the model asks for, feed the results back, repeat to a bounded depth. The OpenAI-shaped tool_calls translation already exists in to-ai.mjs for the endpoint backends — this reuses it rather than inventing a second path.

• ○
  Tool: look at a URL — Planned

  The exact request the panel refused twice. Fetch a page through the kit's own browser and return its title, headings, text and a screenshot path — not a raw capture run, which is heavier than a question deserves. A read-only look at a page is the single most-wanted thing a converter assistant can do.

• ○
  Tool: read a conversion report — Planned

  Return a captured site's conversion report — per-section coverage, the fallbacks, the style-coverage number — so the chat can answer "why did this section come out as a code block?" from the data rather than from guesswork.

• ○
  Tool: search the kit's own docs — Planned

  The kit ships the recipes, the styles, the option references and the build protocol. Let the chat search and quote them, so "how do I set a hero?" is answered from docs/site-creator/recipes/heroes.md rather than from the model's memory of some other page builder.

• ○
  Every tool call is visible — Planned

  The panel renders each call and its result as a collapsible row, so the person can see what was read and from where. A tool-using assistant that works invisibly is one nobody can check — and this panel sits next to real site data.

Phase 3 — Let it act, behind a gatePlanned

0/3

Reading is safe; writing is not. Everything in this phase changes something on disk or on a site, so each tool asks first and nothing runs on the strength of a sentence in a chat box. The gate is the feature, not an obstacle to it.

• ○
  Tool: run a capture (confirmed) — Planned

  Start a real capture of a URL into capture-out/, after an explicit confirm in the panel. Long-running, so it reports progress rather than blocking the turn.

• ○
  Writes are confirmed, never inferred — Planned

  One approval path for every tool that changes anything — capture, convert, write a theme setting — with a dry-run that shows what would change. The rule the rest of the kit already follows: localhost is fair game, a push or a live site is never automatic.

• ○
  Hand off to Kinetic Scenes — Planned

  "Make me a short scene" should reach the Studio bridge that already exists on this service, instead of being declined. The chat composes the request and hands it over; the Studio remains where the scene is edited.

Two rules this plan does not bend

Every tool call is visible. Each call and its result renders in the panel as a row the person can open. An assistant that reads your files invisibly is one you cannot check, and this panel sits next to real site data.

Nothing writes without a confirm. Localhost is fair game across this project; a push, a live site or a destructive local change is never automatic. A chat box is the easiest place in the product to type something you did not quite mean, so the gate matters more here than anywhere else.

How this page stays current

Status is detected, not ticked by hand: src/data/kit-assistant-roadmap.json names the files and symbols that make each task real, and scripts/gen-roadmap.mjs checks them against the kit source tree. Tasks carrying pin: true are the exception — they are set by hand, for work no file can prove.

EXT_DIR="D:/Web Dev/UnysonPlus-AI-Dev-Kit" node scripts/gen-roadmap.mjs src/data/kit-assistant-roadmap.json

The EXT_DIR matters: without it the scanner resolves the push clone, which only carries what has been pushed, and reports finished work as planned.