Set up with your coding agent

Give your agent the authorized package, expected checksum, repository and prompt below. It prepares one operation for review. You decide what counts as success and approve spending and CI integration.

Before you start

Package access is by invitation. Request access with your operation and paid APIs, or use your existing invitation. Have these items ready:

Your authorized marginci-0.3.0-alpha.16.tgz, SHA256SUMS and customer instructions.
The expected archive SHA-256 supplied independently of the package.
The application repository where your agent will work.

Evaluation and private-CI permissions come with your invitation. Your agent checks compatibility before preparing the operation. Manual installation is available too.

Copy the setup prompt

Copy the whole field into your coding agent. Replace the three placeholders with your repository, local archive location and expected SHA-256. Keep credentials out of the message. The agent uses public guides and your authorized delivery; it does not need MarginCI’s development repository.

Customer setup prompt

Select the field, then Select All and Copy: Command+A, Command+C on macOS; Ctrl+A, Ctrl+C on other desktops. On mobile, use the text selection menu. The field scrolls and is read-only; replace placeholders in your agent message.

Help me set up one supported MarginCI operation in my application.

Customer repository: [CUSTOMER_REPOSITORY]
Privately supplied local archive: [LOCAL_ARCHIVE_PATH]
Independently supplied expected SHA-256: [EXPECTED_SHA256]

1. Read these current public customer guides before acting:
   https://marginci.com/docs/support-boundary/
   https://marginci.com/docs/getting-started/
   https://marginci.com/docs/first-adoption/
   https://marginci.com/docs/configuration/
   https://marginci.com/docs/providers/
   https://marginci.com/docs/measurement/
   https://marginci.com/docs/security/
   https://marginci.com/docs/github-actions/
   Use my authorized package's customer instructions too. Work locally on a setup branch, preserve independent work and existing configuration, and show reviewable changes. This prompt authorizes inspection, verified separate-tooling installation and nonpaid setup checks. It does not authorize paid calls, remote writes, secret provisioning or enforcement changes.

2. Inspect the repository and existing tests. Propose one operation that uses a supported provider route, runs in one Node.js process and awaits all paid work. Derive candidate cases and meaningful success assertions from tests; explain their coverage and limits. Identify incompatibilities and proposed application adaptations before proceeding. Ask for approval before dependency, build or application changes requiring owner judgment. Do not replace the provider route or weaken assertions to fit the tool. Classify existing tests as nonpaid before running them.

3. Verify the local archive against the independently supplied expected SHA-256 before installation, and check the supplied checksum file. Stop if either identity is missing or mismatched. Follow the private-alpha installation guide for 0.3.0-alpha.16: exactly Node.js 24.21.0, the documented npm qualification guidance and supported integrity-pinned application lockfile; provision an application's exact pnpm pin separately if applicable. Install with scripts disabled into a new tooling directory outside the application, add its bin directory to PATH and invoke marginci from there. Do not download a missing CLI or create an application-local file dependency. Ask before changing my machine's toolchain. Run marginci init, preserve unrelated ignore rules and keep .marginci/ ignored. Report incomplete lock metadata; review dependency identity through my normal workflow rather than automatically enriching or replacing the dependency graph.

4. Prepare the wrapper, marginci.yml, cases and frozen comparison_files following Repository setup. Include the wrapper and input/success helpers; keep application implementation and build output revision-owned. If committed JavaScript is needed, propose the application's normal build with required assets, commit each revision's own output and check that output matches source. Stage only reviewed setup inputs and make the local setup commit needed for a baseline that contains the harness. Run marginci doctor for the chosen operation against HEAD without paid calls. Doctor success does not prove every application import can execute. Explain how setup must land before later comparisons or a required economic check; never copy candidate implementation onto the baseline.

5. Before any paid comparison, present one compact approval request: operation and cases; success criteria; provider endpoint and exact model; rates, units and dated source; regression threshold; whole-check spending limit, per-request bound, case/attempt/request limits, native provider limits and timeouts; credential handling; any dependency or build changes; and exact comparison command, baseline and candidate identities. Use reviewed rates, not illustrative prices. Explain that the modeled spend guard cannot guarantee a provider-bill cap. Credentials belong only in my approved environment, never in this prompt or committed files. MarginCI does not load .env files; credential_env checks presence and is not an environment allowlist. Application code and dependency installers must be trusted with their inherited environment. Do not request or print credential values. If credential provisioning is needed, ask me to arrange it through my approved method. Keep run files private and review logs before sharing; arbitrary application and installer logs are outside credential redaction.

6. Run paid comparisons only after my explicit approval of those settings and commands, starting with the documented setup comparison against HEAD. Do not retry or expand spending beyond that approval. Prepare CI changes locally from the delivered private-alpha template, retaining the independently verified package identity and immutable PR base/head comparison. Keep proprietary package bytes out of public repositories. Obtain separate approval before pushes or other remote writes, secret provisioning or repository rules. A failing workflow alone does not prevent merging: an active required-check rule and the applicable private-repository GitHub plan/feature are needed. Verify credential delivery, fork rejection and actual enforcement under my repository policy before relying on CI.

7. Explain the observed PASS, FAIL, INCONCLUSIVE or ERROR, measured identities, cost basis, workload coverage and remaining limitations. A synthetic check is not live-provider evidence; a cost result is not an automatic business decision. Report setup errors and unresolved compatibility issues. Do not change success criteria, cases, rates or thresholds merely to obtain PASS. Summarize what ran, what was authorized and what still needs my decision.

Review the proposed setup

The agent should leave a local diff and a compact proposal covering the operation, cases, success checks, provider rates and spending limits. Resolve incompatibilities and proposed dependency, build or application changes before approving paid work.

A successful doctor check validates setup prerequisites; it does not prove that every import will execute or produce an economic PASS. Review cost calculation and results and credential handling. Supply credentials through your approved environment, never in the prompt or committed files.

Approve comparisons and CI separately

Explicitly authorize the first paid comparison and its limits. Land the shared repository setup before comparing later application changes.

Review GitHub Actions locally, then separately authorize remote integration, credential provisioning and required-check rules. A failed workflow blocks merging only when an active repository rule requires it; verify plan eligibility and actual enforcement.

Agent-assisted setup has been demonstrated on one adapted application with synthetic provider responses. This establishes neither live-provider results nor general compatibility, setup time or a business decision.