create-runner-adapter skill

Add a native Runner adapter

Use this skill to add a harness to the new, native Paperclip Runner execution system. Here, adapter means the provider translation and launch integration behind a Runner harness driver. Preserve existing direct adapters and historical records as compatibility constraints; do not route this work through their package-authoring recipe or migrate agents as a side effect.

The complete procedure is the Runner integration playbook. Use its working templates for the release contract, capability inventory, acceptance ledger, and failure record. These repository files contain the decision rules and test criteria themselves. No private chat, task, prior campaign, or separate private repository is required. Source links identify code to inspect, not evidence that a new integration passed.

If this skill was installed separately, locate the target checkout from the current workspace or git rev-parse --show-toplevel. Verify it contains packages/paperclip-runner and tests/runner-e2e; resolve doc/ paths there. Follow that checkout's AGENTS.md and scoped rules before editing.

Work sequence

outcome, first environment, supported platforms, setup/auth, required capabilities, selected acceptance model, spending limits, and delivery target. Keep the complete capability inventory separate from the release requirements.

1. Define a finite release. Read playbook sections 1–3. Record the user

docs, native source or shipped code, real protocol traffic, and account/model behavior. Track every capability through native harness, wrapper, Runner, controller, and UI. Distinguish documented, observed, and qualified support.

1. Investigate the actual harness. Use section 4. Inspect versioned official

instruction admission, scoped tools and credentials, then complete one real Paperclip task with independently verified output and physical cleanup. Exercise ordinary connect/save/reopen/Test/reconnect in the selected environment; check database constraints and account/model routing as well as driver execution.

1. Prove one complete slice. Use sections 5–7. Establish exact model and

durable human decisions, callback identity, recovery, cancellation, and terminal settlement. Keep provider-specific semantics in provider code.

1. Complete the promised behavior. Use sections 8–10. Preserve rich events,

agreed execution environment; verify the complete runtime closure and immutable image identity. A source checkout or startup probe is insufficient delivery proof.

1. Prove delivery. Use section 11. Exercise clean installed packages and the

dependency checks, then run exact Product E2E cells through browser/server/DB/ Runner/provider. Section 12 includes a repository-contained test-authoring path. Freeze the candidate and retain original failures, cost coverage, and cleanup.

1. Qualify the release. Use sections 12–15. Begin with deterministic and real

repository checks, exact passing evidence, remaining limits, installation, operation, and rollback. Keep merge, publish, deploy, and canary claims distinct.

1. Hand off an operable result. Use section 16 and the templates. Account for

Rules that must survive implementation pressure

Verify the caller's exact model at the native boundary before the first prompt.

• A qualification model is a repeatable test choice, not a product allowlist.

and load, reject missing acknowledgments, and verify resulting behavior.

• Instruction transport success is insufficient: bind exact content on create

contracts. Preserve identity and prove delivery; queued does not mean answered.

• A native question, semantic question, plan, and permission request are distinct

Stop must reach the owned native work and prevent late callbacks from reviving it.

• Same conversation does not establish same process or recoverable pending input.

independent file/artifact/state/cleanup checks through the promised user path.

• A screenshot, model-authored success claim, or green unit suite cannot replace

and grader before another paid attempt. Preserve the original grade.

• Diagnose the first divergence across arguments, transport, files, persistence,

their original runtime, model, environment, and fixture identity.

• Changes after a pass require an evidence-impact decision. Old results retain

invoked by a test. Preserve durable expiry for each supported request kind.

• Prove spontaneous native-child loss and bounded shutdown, not only cleanup

a Stop case must reach real pending work before its observation window closes.

• Establish the concurrency being graded: attached work must overlap finish;

across interruptions. Reconcile shipping dependencies before final qualification.

• Keep campaign evidence, budget history, and candidate/publication state durable

runtime conversion, and migration are not part of adding a native integration.

• Preserve legacy behavior through focused regression checks. Legacy authoring,

Keep new guidance shareable: put the complete lesson and reproducible acceptance condition in tracked documentation. Do not substitute personal session links, private task URLs, inaccessible evidence archives, or workstation-specific paths.