docs(forge): PromptForge (UI prompts) + ToolForge (custom tools)

content/docs/extending/custom-tools.mdx

@@ -29,7 +29,40 @@ or the AskUI Solution Engineering team, not edited ad hoc by test authors.
 - **Warnings**: the same NuGet package requested at different versions
   across files is flagged; the higher version wins at run start.
 
-There is no in-app code editor, write tools in your own IDE.
+There is no in-app code editor, write tools in your own IDE — or let the app
+draft one for you (below).
+
+## Forge a tool (ToolForge)
+
+If you'd rather not write the C# yourself, click **Forge a tool** on the
+Custom Tools tab. Describe the tool in plain language — what it does, its
+input fields, what it returns, and which device it needs — and the model
+drafts it following the tool contract.
+
+1. Write a **structured description** and click **Verify**. The model checks
+   it and echoes back its understanding.
+2. If something's missing, it tells you what to add — correct it and verify
+   again. Repeat until it's ready.
+3. Click **Accept & Forge Tool**. The `.cs` file is written into
+   `utils/custom_tools/`, and the
+   [inference cost](/docs/troubleshooting/performance-cost) of generating it
+   is shown.
+
+<Callout type="info" title="Review before you rely on it">
+A generated tool is a starting point — read it, and validate it like any
+other custom tool before trusting it in a run.
+</Callout>
+
+**Not everything is a tool.** A custom tool is code the agent calls during a
+run — it can't install software on the machine, change system or network
+settings, or duplicate a built-in tool from the Tool Store. If your request
+falls outside those boundaries, generation is **rejected** instead and you're
+pointed to an AskUI solution engineer. Your description is preserved and
+copyable, so you can send it to <support@askui.com> without retyping it.
+
+You choose which model powers Forge under **Settings → Forge Model**; by
+default it's the same model as your test runs. See
+[Model providers](/docs/extending/model-providers).
 
 ## Create a tool
 

content/docs/writing-tests/agents-and-prompts.mdx

@@ -84,6 +84,23 @@ A suite that tests a different part of the system can carry its own
 `tests/ui.md` first, then each folder's on the way to the test. `ui.md` is
 never executed as a test, the Tests page marks it **Context only**.
 
+### PromptForge — generate it from screenshots
+
+You don't have to write `ui.md` by hand. Open it in the Tests editor and
+click **Forge from screenshots**:
+
+1. Upload screenshots of the app (up to 30) and write a short bullet-point
+   description (at least 160 characters), then click **Verify**. The model
+   checks the inputs and echoes back its understanding of your UI.
+2. If it needs more, it tells you what to add — correct it and verify again.
+3. Click **Accept & Update ui.md** to write the section, or **Add another UI
+   section** to describe another screen first. Every section lands in the
+   same `tests/ui.md`.
+
+The model is the same one your tests run on by default; change it under
+**Settings → Forge Model**. Generated context is a draft — read it and
+refine it, since it's what steers every run.
+
 ## Report format
 
 `utils/format.md`, the template for every report the agent writes: title,