# Installation and first workspace Release 1.6.0-rc.4. This is a MULTI-SKILL PLUGIN archive, not a single SKILL.md upload. Read COMPATIBILITY.md and SOURCES.md for current official host paths and limitations. ## 1. Verify and import once After extracting into a new folder: ```sh python3 tools/verify_release.py . python3 -m unittest discover -s tests -v ``` The integrity verifier needs only Python 3.10+ and the standard library. A real host may not have Python or an authorized shell; use equivalent authorized file hashing instead of requesting OS developer tools automatically. This package never runs code on import. ### Claude Desktop / Cowork Open Cowork, then Customize -> Plugins. Use the current custom-plugin upload control and select this complete ZIP. The .claude-plugin manifest points at the root skills convention. If organization policy hides plugin import, ask the administrator for the approved plugin distribution path; don't paste eight SKILL.md files into chat or assume an uploaded attachment was installed. ### ChatGPT desktop Work / Codex with plugin support The same extracted plugin has a portable root plugin.json plus .codex-plugin compatibility metadata. OpenAI documents local/repository marketplace installation for Work/Codex; availability varies by surface and organization. Use that documented path below for the complete plugin. A single-Skill upload is a separate flow and is not an established importer for this eight-skill ZIP: 1. Place the extracted contents in YOUR_REPO/plugins/ollie-runtime-pack/. 2. Merge the included examples/openai-marketplace.json entry into YOUR_REPO/.agents/plugins/marketplace.json. Preserve existing plugins/settings; do not replace a shared marketplace file blindly. source.path is relative to YOUR_REPO. 3. Open that authorized repository/local context in the supported desktop surface and restart the app as documented. Verify the plugin appears and enable/install it as the UI requires. A local plugin appearing in Work/Codex does not prove availability in every ordinary ChatGPT chat. No common 'Save skill' button or raw ZIP installer across all desktop accounts is promised. If the host only supports single-Skill imports, export complete individual packages using `python3 tools/export_single_skills.py --output NEW_EXPORT_DIRECTORY`, then import each through that host's supported Skill flow. The bootstrap dependency check still applies. ### Required read-back, either host Confirm all eight skill names are discoverable, and resolve plugin namespaces/actual installed paths. Runtime prerequisites are authority, access, email, then bootstrapper; import as one plugin normally makes them available together. Verify each installed version and content digest against MANIFEST.json using authorized file tools. No access to installed bytes means installation is reported unverified, not assumed from a card. Retain prior approved release outside active skill search paths; never click a rollback archive as the current installation. ## 2. Prepare one real client workspace Operations must authorize first-time runtime deployment. Keep one human operator on the workstation. Use the client's approved agent identity, connected account/resources, secure credential store and Outloop workspace; never request raw secrets in chat. Confirm the actual host folder is connected in THIS session. Resolve immutable workspace ID and the bridge tenant alias separately from labels. Inspect the Outloop-generated contract; don't rewrite it. Prove the actual Local Bridge before assuming any provider route works. Ask only the minimal unresolved identity/access/timezone question. Read the real live schema and provider metadata. Discover the PM intake scope, intended agent's immutable provider user/account ID, status labels and control-record exclusions; mailbox/shared- mail routing; actual timezone; supported scheduler and device; currently permitted MCP/browser capabilities. Context holds client truth; tenant bindings hold resource/host identities. Global hints do not grant access. Missing optional KPIs do not cancel unrelated work. ## 3. Bootstrap prompt (copy into the connected host workspace) > Use the installed OLLIE Workspace Bootstrapper for this connected workspace. Confirm actual > host-folder access, immutable identity and Local Bridge first. Discover approved accounts and > the intended PM agent ID. Preserve existing bindings/ownership/occurrence history. Stage and > validate the local Dispatcher/Operator, install through the host-supported path, and read back > the installed bytes. Create or repair one approved schedule with actual folder and scope proof. > Preserve the intended cadence and do not change permissions or use Computer Use unless approved. > Finish with a controlled and an autonomous run receipt, or the exact remaining external action. > Do not call the workspace operational merely because a skill or schedule was saved. The optional scripts/generate_runtime.py under the bootstrapper generates scratch output only. Supply verified inputs and the bootstrapper's approved SHA from MANIFEST.json. It refuses to replace an existing directory. It does not perform any of the live installation steps for you. ## 4. Schedule correctly, without repeating the earlier failure Read the current scheduling owner. Prefer Project -> Scheduled or a supported API preserving scope. Verify three independent things: real project association, correct host folder, actual local run. If project scope is unavailable, use an account-level schedule only with the owner's explicit exception and preserve that limitation. Without host-folder execution, a cloud task is not usable for the Local Bridge. Do not force a new Computer Use permission to solve scheduling. Default requested cadence: 08:00 through 20:00 every two hours, Sunday-Friday, verified workspace timezone. Preserve approved alternatives and any approved staggering. If the UI only supports Hourly/Daily/Weekly/Weekdays/Manual, don't silently increase to 24 scans/day; negotiate one supported choice. Existing custom cron is tested, not assumed broken. Record UTC conversion/DST maintenance only when the host cannot store the actual IANA timezone. Safe replacement: create the replacement DISABLED; verify its settings; disable old, drain active work, verify old stopped; then enable/fire new. Keep one active owner and dispatcher across all hosts. Retain old disabled until the new proof passes. Do not delete a working schedule as the first fix. A compact tenant-specific scheduled prompt can be generated from this shape: > You are the unattended intake run for this verified connected workspace. Resolve its actual host > folder and tenant bindings; load the installed dispatcher identified there and its referenced > Run order. Begin with the Local Bridge preflight. No mount/bridge means an unverified failure, > not no-work. Use current Context, canonical runtime skills and actual permitted tools; do not > copy old chat assumptions. Record start/phase/terminal evidence, process stable occurrence keys, > finish independent authorized work and verify required delivery. Return one terminal receipt. Insert the actual discovered dispatcher path/namespace and workspace reference at deployment time. Do not embed secrets, an obsolete global-scope claim or a full duplicate of runtime doctrine. ## 5. Acceptance before customer activation Use SMOKE_TEST.md. At minimum: host mount/bridge proof, provider read, correct PM worker binding, one controlled in-scope task, stable claim/no duplicate, requested output saved/read back, internal email send/read-back when that capability is in scope, and a complete autonomous schedule firing. Test the installed generated version, not an older runtime's evidence. A read-only pilot can be accepted while unrelated spend/client-send capabilities remain disabled, but don't advertise those as proven. Every declared production capability must pass its own actual runtime gate. ## 6. Teach and reuse After useful real work, remain in the same chat and run Reflective. Approve the narrow canonical update; validate/package/install/read-back. Ask for the shortest fresh-chat prompt to reproduce the business outcome. Test it in a new connected workspace chat. Repeat for missing knowledge, without turning the prompt into an implementation manual or copying client facts into global skills. ## Reproduce this candidate build From a copy of the complete reviewed source, run the unit tests and the S18-S22 commands described in PROOF.md. Finalize sanitized QA/docs before sealing. Then run: ```sh python3 tools/build_release.py --root . --output ../new-dist python3 tools/verify_release.py . ``` The output directory must be new and outside source. The builder seals component content hashes, MANIFEST.json, then CHECKSUMS.txt, and writes a fixed-metadata skill.zip plus external SHA256SUMS.txt. It never bumps versions, installs or publishes. Never change published bytes under a reused version. With identical source and Python/zlib toolchain, rebuilding produces the same archive SHA. Extract into a fresh directory and run the verifier again; compare the full inventory and ZIP SHA as well.