> For the complete documentation index, see [llms.txt](https://mozarkdocs.gitbook.io/appx_documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mozarkdocs.gitbook.io/appx_documentation/agent-workspace-documentation/author-agent/overview.md). # Overview ## Author Agent Author Agent helps you generate structured test cases for a feature, flow, or requirement. Use it when you want to build test coverage faster, review suggested cases before saving them, and add new cases directly to TCM. ### Open Author Agent Open **Test Cases** from the sidebar. In the top-right toolbar, click **✦ AI Author**. A drawer opens from the right side of the page. The drawer header shows **AI Test Case Generator**.
### Knowledge Corpus Knowledge Base stores the context Author Agent uses to generate accurate, context-aware test cases. Add screenshots, Figma frames, or documents so the agent understands your product before it generates test cases.\ \ If your project has no Knowledge Base data, Author Agent shows a warning banner in the chat panel: **No Knowledge Base data**, with a prompt to add your app requirements, user stories, or design docs.
Click **+ Add sources to Knowledge Base →** to open the Knowledge Base drawer. **Source types:** * **Images & Screenshots** — product screenshots or design images (PNG, JPG, WebP, up to 100 MB each, multiple files supported) * **Figma** — live frames pulled directly from a connected Figma file * **Other Docs** — requirement docs, specs, or PRDs (PDF, DOCX, up to 100 MB each)
**Add images or screenshots**
1. Open the **Images & Screenshots** tab. 2. Drag and drop files onto the upload area, or click **Browse files**. 3. After upload, you'll see **"X images uploaded — Select which to annotate."** All uploaded images are selected by default; use **Deselect all** or **+ Add more** to adjust the batch. 4. Click **Annotate (X) →** to start processing. While annotation runs, each file shows its status in order: **Done**, a live percentage, or **Waiting**. **Review detected elements**
Once annotation finishes, each image opens in a three-panel review view: * Left: thumbnail strip to navigate between files * Center: the image itself * Right: a table of detected elements — **Element Name** and **Type** (Text, Icon, Button, Image, Input) From here you can: * Click **+ Element** to manually add an element the auto-detection missed * Remove individual elements using the trash icon in their row * Click **Remove** (top right) to discard the whole file * Click **Add to Knowledge Base →** to save the current file, or **Add all (X)** to save every file in the batch * ```
``` If a file has already been saved, this button changes to **Update Knowledge Base**, so you can push edits to an existing source. **Connect a Figma file**
1. Open the **Figma** tab. 2. Paste the **Figma file URL**. 3. Paste your **Personal access token** (get this from Figma → Account Settings → Personal Access Tokens). 4. Click **Extract Frames →**. Every frame is pulled from the file. From there, review and annotate frames the same way as uploaded images — each frame goes through element detection, and you can edit, add, or remove elements before saving. **Add other docs**
1. Open the **Other Docs** tab. 2. Drag and drop a file, or click **Browse files**. 3. Supported formats: PDF, DOCX, up to 100 MB each. Unlike images and Figma frames, documents don't go through element annotation — they're added straight to the Knowledge Base and marked **In Knowledge Base** once uploaded. **Manage existing sources**
Every source you've added appears under **Already in Knowledge Base**, showing its name, file size, and detected element count (for images/frames). Each row has: * **Edit** — reopen the file to adjust its saved elements * **Delete** — remove the source from the Knowledge Base entirely The drawer footer always shows a running total, e.g. **Knowledge Base: 12 sources**, broken down by type (e.g. **11 images**, **1 doc**). ### Generate test cases Author Agent guides you through a short setup before it starts generating test cases. #### 1. Choose test case types Start by selecting one or more test case types. You can choose from: * **Functional** — core product behavior * **Edge** — boundary conditions and unusual inputs * **Automation** — atomic, machine-executable steps
After you select at least one type, click **Continue with X type(s) →**. You can select multiple types in a single run. If you need help choosing, read [Author Agent test case types](broken://spaces/MhLDAQDUuKnEzEkcw9Ya/pages/SvBiLkRbcDfcAoDGF6QJ). #### Functional Use **Functional** test cases for high-level, human-readable coverage. Choose this type when you want to verify that a feature behaves as expected from a user point of view. Functional test cases work well for day-to-day manual review and broad feature validation. #### Automation Use **Automation** test cases when you want steps broken into small, atomic actions. Choose this type when you need cleaner handoff into automation design or script creation. These outputs stay human-readable. They are not executable scripts. #### Edge Use **Edge** test cases to cover boundary conditions and extreme inputs. Choose this type when you want to test how the app behaves at the limits of supported input or usage. This is useful for validating graceful handling of unusual but important scenarios. #### 2. Choose polarity Next, choose the kind of scenarios you want: * **Positive** for expected successful flows * **Negative** for invalid input, failure paths, and error handling You can choose one or both depending on the coverage you need, then click **Continue**.
#### 3. Enter a feature name Enter the feature, flow, or user journey you want to cover. Examples include `Login`, `Checkout`, and `Password Reset`. When the field is complete, click **Search & Preview Modules →** to start generation.
### Review generated test cases When generation finishes, Author Agent returns a set of suggested test cases for your request. Each test case appears as a card with a title, a checkbox, and metadata tags. Selected test cases are checked by default, so you can move quickly into review and save.
### Open and edit a test case Click any generated test case card to open its detail panel. The detail view slides in from the left and includes: * title * description * preconditions * ordered test steps * supporting metadata such as status, priority, type, labels, people, and timeline Use **Edit** to update the content before saving. You can save your edits or cancel to discard them. When you finish reviewing, close the panel using the back arrow or **X**.
### Save test cases At the bottom of the drawer, the **Add to Repository** area shows how many test cases are selected. Select the cases you want to keep, then click **Add 'x' Test Cases to Repository**. After the save completes, the new test cases appear in **Test Cases** with an **AI Generated** badge. If nothing is selected, you need to select at least one test case before saving. ### Resume previous work
Use **Past Sessions** in the drawer header to reopen earlier conversations. Each saved session shows its message count and timestamp. Select a session to continue where you left off. To start over, click **New Session**. This clears the current conversation and returns you to the first setup step. ### Tips for better results * Add Knowledge Base sources for more accurate, context-aware output. * Use clear feature or journey names such as `Login` or `Checkout`. * Start with **Functional** if you are unsure which type to use. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://mozarkdocs.gitbook.io/appx_documentation/agent-workspace-documentation/author-agent/overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.