> For the complete documentation index, see [llms.txt](https://docs.appmixer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appmixer.com/build-connectors-with-a-coding-agent/review.md). # Review Before Publishing Your tests are green in all three layers. One more pass before you publish — the only one in this guide that changes nothing. ## Two checks, not one | | `appmixer connector validate` | `review-connector` | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **What it is** | A fixed set of rules over your source files | An agent reading your connector | | **Checks** | Things with a right answer: does the trigger export `test()`, does the out port declare a schema *or* options, are required inputs asserted | Things that need judgement: does this component match its siblings, does the operation finish later than it appears to | | **Determinism** | Same input, same output | Reasoned each time | | **Runs in CI** | Yes — offline, stable exit code | No | | **When** | Continuously, from chapter 3 | Once, before publishing | The mechanical half of review is already a command; run it in CI. The skill covers the half that has no mechanical form: * **The standard is your own connector.** It judges a component against its siblings — their HTTP client, auth pattern, output shape — so there is no fixed rule to encode. * **Some smells span files.** An asynchronous component looks like an ordinary action; you spot it from a "get status" sibling or a wait step in its test flow. * **It is told to report real issues only**, which a linter cannot be told. ## It changes nothing The skill is **read-only**: it reads files, may run small local experiments to confirm a suspicion, and changes no file. So you can review someone else's connector safely, and you apply fixes as a separate step — a review that fixed things quietly would hide what it found. ## What it looks at * **`component.json`** — structure, port schemas, the shared item-schema contract, dynamic-source caching. * **The behaviour file** — request patterns, error handling, input assertions. * **Asynchronous components** — self-callback versus continuation, correlation ids on both ports, `context.response()` inside a `finally`. * **Triggers** — the `test()` method and Flow Test Mode. * **Cross-cutting** — naming consistent with siblings, inspector labels matching output fields. ## Reading the output Findings come back as a table, most severe first: | Severity | Meaning | | --------- | ----------------------------------- | | `error` | Violates a mandatory rule — fix it | | `warning` | Should be fixed; may cause problems | | `info` | An improvement, optional | A clean review still lists what it checked, so "nothing found" differs from "did not look". An example, abridged: | Severity | Component | Rule | Finding | | -------- | ------------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | warning | `CreateEvent` | `input.datetime-timezone-ignored` | A date with no offset, such as `2026-10-21T19:00:00`, is read in the **Appmixer server's** timezone, not the event's Timezone input | | info | `CreateEvent` | `input.select-candidate` | Timezone is free text, although the service publishes its list of zones | | info | `FindEvents` | `schema.enum-on-filter` | The status filter's `enum` rejects mapped values such as `all` | | info | all actions | `error.context` | API errors arrive as `Request failed with status code 400`; the service's own error text is clearer | The warning is typical of what review finds and tests do not: every test sent dates with an offset, so every test passed, while a user typing a local time would get an event at the wrong hour. **Rule ids are the agent's own labels**, made up per review — they appear nowhere in the skill, and the next review may name the same finding differently. Use them within one review, not as stable identifiers. **A review is right about what it reviewed, not about everything it mentions.** It may end with advice on other steps — such as removing components to republish — that [Shipping Changes](/build-connectors-with-a-coding-agent/shipping-changes.md) tells you not to follow. ## Waivers Nothing in the process makes anyone answer a review. Unless you ask, a warning is neither fixed nor recorded — it just stops being mentioned. A waiver is the answer, written down, so that "we decided not to" can be told from "we missed it". It names: 1. **The finding**, in words — not only by rule id. 2. **Why it is acceptable** — the actual reason, not "low priority". 3. **What would change the answer** — a version, a condition, a check. For example: > Create Event reads offset-less dates in the server's timezone, not the event's. Accepted for 1.1.0: the Designer's date picker always sends an offset, and the tooltip now says a time must carry one. Revisit if users map dates from sources that drop the offset. Keep waivers wherever your team keeps decisions — beside the code or in the changelog, not in memory. {% hint style="info" %} **`aiDescription` is checked by nothing** — neither the validators nor the review. Copilot falls back to `description`, so a component without one is found less reliably. If you want it, ask for it in chapter 3. {% endhint %} ## Verify Ask for a review in plain words ("Review the connector before I publish it.") or by name: ``` /appmixer:review-connector . ``` It also takes one component (`...`). The exit condition is not "no findings" but **no finding unaccounted for**: every `error` fixed, every `warning` fixed or waived in writing. Next: [Shipping Changes](/build-connectors-with-a-coding-agent/shipping-changes.md). --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.appmixer.com/build-connectors-with-a-coding-agent/review.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.