workbench-adopt

# Adopt Workbench Make the destination project easier to engineer using its established tools. Preserve the user's requested scope and working architecture. This skill supports both an audit and implementation; an audit request does not authorize infrastructure changes. ## Establish the current loop Read the destination README, repository instructions, maintained project/package manifests, CI, and relevant scripts. Identify who currently owns project generation, dependency resolution, build/test, runtime interaction, and delivery. Check declared tool versions and actual installed capabilities before assuming setup is absent. Map what a fresh developer can currently do: - Install or resolve normal development dependencies using their native managers. - Build and run a meaningful test without release credentials. - Launch isolated state, interact with the product, and inspect its actual behavior. - Find useful logs, failed test results, and visual evidence. - Repeat the same verification in CI. For Apple projects, read [the Apple profile](references/apple.md) when deciding ownership or setup boundaries. Its examples are a starting point, not a requirement to migrate a working project. ## Improve the highest-value gap Choose a small outcome with a concrete acceptance check. Examples: make a failed UI run retain its real screenshot; make a documented build work without an unrelated account credential; make one important view launch with deterministic state. Use the existing formatter, test runner, package manager, runtime tooling, and CI extension points. Remove a custom wrapper only after exercising its replacement. Avoid adding a dispatcher to make unrelated commands look uniform. Do not turn an ordinary adoption into an application rewrite or a signing migration. Prefer executable guardrails where they help: a compiler setting, fixture readiness assertion, native lane, or retained test result. Instructions should explain decisions the tools cannot enforce. Keep app-specific invariants and fixture data in the app. ## Leave reproducible setup Pin tools and dependencies through the mechanisms that own them. Document every new environment input, what capability needs it, and where its actual value belongs. Commit safe samples where inputs exist; do not invent empty secret configuration for a project that needs none. Validate prerequisites at the boundary where they become necessary. Formatting should not need a simulator; local tests should not need store credentials; comparing saved images should not require launching the product. For a missing dependency, report what is missing, why this operation needs it, and the normal installation or configuration step. Use [the setup inventory pattern](references/setup-inventory.md) when a project has hidden machine dependencies. Retain successful existing setup rather than replacing it with guessed defaults. ## Prove the improvement Run the new or changed workflow yourself. For visual work, inspect the actual artifact and assert that expected content rendered. For interaction, verify the resulting state, not merely the input tool's success response. Preserve useful failure evidence. Report the concrete change, commands exercised, observed results, and unresolved prerequisites. Distinguish a clean checkout test from an actually clean machine. A passing linter is not proof that an agent, simulator, device, or deployment workflow works.