` convention (Title Case, confirmed against mi.docs.wso2.com and docs-integrator's pre-existing Twilio/HTTP pages) — `overview.md`/`setup-guide.md`/`action-reference.md`/`trigger-reference.md` get this from connector-doc-generator's templates directly; only `example.md`'s title is this skill's own responsibility, via `integrate_example.py` as just described. `validate_docs.py` then re-confirms the whole page set and sidebar are internally consistent, but it has no trigger-aware check: if Step 4 generated `trigger-reference.md` (the connector has a listener), separately confirm that file still exists and is non-empty in `docs_connector_dir` before reporting success — a missing or emptied trigger reference can otherwise pass `validate_docs.py` silently. If either script fails, fix the reported issue and rerun rather than hand-patching docs-integrator files directly. Leave every docs-integrator change as an uncommitted working-tree edit — never commit, push, or open a pull request against it. 13. **Offer to publish the sample project to `wso2/integration-samples`.** Step 11's "Try it yourself" section always links to `integrator-default-profile/connectors/` in that repo whether or not anything has ever been published there — until this step runs (and its PR merges), that link 404s. Resolve `SAMPLE_REPO_ROOT` the same way as `DOCS_REPO_ROOT` in Step 2 (already known from context, a sibling directory, or ask once with "2+1"). If the user has no local checkout, fork `wso2/integration-samples` to their account (`gh repo fork wso2/integration-samples --clone=false`) and clone the fork fresh into a scratch location — forking a public repo is low-risk and reversible, unlike the push/PR at the end of this step, so it doesn't need the same explicit confirmation. Then: ```shell python3 "${CLAUDE_SKILL_DIR}/scripts/prepare_sample_publish.py" \ --sample-dir SAMPLE_DIR --target-dir SAMPLE_REPO_ROOT/integrator-default-profile/connectors/SAMPLE_NAME ``` This copies only `.gitignore`, `Ballerina.toml`, and the `.bal` files — never `.vscode/`, `target/`, `Dependencies.toml`, or `Config.toml`, none of which any existing sample commits — and sets `[package] org` to `wso2`, matching every sibling sample (a WSO2 Integrator project is created locally under whatever org the developer's own environment happens to use). Run `bal build` in the target directory afterward to confirm it still compiles before going further; fix any issue by re-running Step 9 rather than hand-editing the copy. From there this follows the exact same boundary as the docs-integrator steps above: create a branch and commit freely, but only push and open the PR with the user's explicit confirmation, having disclosed that doing so opens a real pull request against a public WSO2 repository. Never treat generating the docs as implied consent to publish the sample — always ask, every time. 14. Stop the code-server process only when this run started it. Report the full set of pages produced (overview, setup guide, action reference, and the example page — noting whether Step 4 or Step 12 was skipped and why), the guide's `artifacts/` scratch location, its published location under `docs_connector_dir` when applicable, whether the sample was published to `wso2/integration-samples` and its PR URL if so, screenshot directory, sample directory, resolved package version, and validation status. ## Safety and boundaries - Keep all generated files under `artifacts/-/` in `${CLAUDE_PROJECT_DIR}` unless a docs-integrator or integration-samples target was resolved per Steps 2 and 13, in which case the example page, its screenshots, the `sidebars.ts` reconciliation, and the published sample project are the only things written outside it — everything else (the local sample project copy, run log, scratch copy of the guide) still stays under `artifacts/`. - Never overwrite a prior run automatically. - Never put credentials or secret values in the guide, screenshots, sample, logs, or config files. Leave configurable values empty or use obvious non-secret placeholders. - Generate **Try it yourself** links only through the finalization script. The links target the canonical future sample location; Step 13 is what actually makes that location real. - Generate **More code examples** only through `append_central_examples.py`. Never author, summarize, or alter Central example content manually. - Never run `connector-doc-generator` without first disclosing its real Claude API cost and getting explicit confirmation; never run it silently as an implied side effect of resolving a docs-integrator target. - Never publish the example page into docs-integrator without an existing `overview.md` — `integrate_example.py` enforces this; do not work around it with a standalone sidebar entry. - Never push or open a pull request against `wso2/integration-samples` (or docs-integrator) without the user's explicit, per-run confirmation — forking is the one exception, since it's low-risk and reversible. - Do not commit, push, or open a pull request in this skill's own repo. All docs-integrator and integration-samples changes are left uncommitted, or committed-but-unpushed, until the user explicitly says to publish them. - Do not support trigger packages or batch queues in this skill.