Optimise ADK on Google Cloud

Reduce avoidable work while preserving correct, authorised and complete results. This one skill covers all three parts of Chapter 4: application optimisation, Cloud Run, Agent Runtime and GKE. The book and companion repository are optional provenance, never runtime dependencies.

Inspect and define acceptance

1. Read project instructions, status, dependency declarations and locks, agent exports, serving and tool code, deployment definitions and relevant tests. Establish whether the user wants advice, an audit, an implementation or a live comparison. Preserve the domain, package manager, versions and customisations.
2. Use the existing project interpreter. The read-only project inspector (its baseline gate records ADK 2.8.0; baseline_gate_passed: false on a newer pin means "not the recorded baseline", so read the dated 2.12 notes in the references rather than treating it as a project failure) accepts --project, --mode (auto, application, cloud-run, agent-runtime, gke) and --require-baseline. It reads bounded dependency manifests and reports configuration presence; it does not import application code, read .env contents or execute cloud commands. Manually inspect its uncovered files and lock resolution. Read compatibility.md before using an ADK recipe. Compare installed distribution metadata with declared Python and ADK pins. A mismatch requires contract verification or a specific blocked path, never an automatic upgrade or downgrade.
3. Trace the actual request: server and session service, ADK App or bare agent, model requests, tools, child handoffs, result storage and client consumption. Record model/backend and configuration keys without exposing secret values. Nested environment files can override root configuration. Inspect the image's actual source package and entrypoint, not just a similarly named example.
4. Separate external request time, platform startup/queueing and application spans. Identify one candidate boundary and its evidence. If measurements are absent, deliver an instrumentation/comparison plan; do not invent a bottleneck. Define correct output, permitted effects, completion, work limits and relevant quality checks before selecting an optimisation.

Inspection ends with the current architecture, version status, selected mode, acceptance criteria and missing prerequisites. Missing cloud credentials still permit local inspection, implementation and offline validation.

Select the smallest useful mode

Combine modes only when the request needs them. A general deployment, SQL security overhaul or UI rewrite is not an implied optimisation task.

Implement or recommend

1. Present a short plan before broad changes: affected files, one principal mechanism, preserved behaviour and validation. For advice/review, provide the decision and actionable changes without generating an unsolicited application.
2. Adapt the current implementation. Keep trusted policy at tool/backend boundaries; model instructions, Skills and structured output cannot grant access. Wire new components into the actual Runner/server and build inputs. An unused formatter or unshipped file is not an implemented optimisation.
3. Preserve explicit failure and uncertainty. Provider failure must not become fabricated fallback data. A token cap, timeout, nonempty answer or HTTP 200 does not establish completion. Limit logical calls, provider attempts, nested work and elapsed time independently where the task needs bounds.
4. Read lifecycle.md before preparing a cloud mutation, paid comparison, export, cache experiment or cleanup. Finish reviewable configuration and exact commands before seeking approval. For Agent Runtime packaging or operation recovery, also read runtime-lifecycle.md. For GKE deployment, capacity retries or teardown, read gke-lifecycle.md. A saved reference manifest is not necessarily the applied configuration; inspect the actual delivery path.

Authority and safety

Inspection is read-only, and code generation authorises no deployment, paid call or live test. Before any consequential operation (an API, billing or quota change, a billable resource, a secret, IAM, a data migration, a deployment, a deletion, or a paid or destructive test), read consequential operations, present the exact scope and limits, obtain explicit approval and end the turn to wait for it. Cleanup is a separate confirmed operation on resources this workflow created.

Billing linkage and quota increases require their own approval. Verify owned cleanup of caches separately from sessions.

Validate and finish

Read validation.md for mode-specific tests, the offline saved-event checker and the offline context budget helper, which estimates request composition, tool-result sizes and compaction coverage from a saved session export. Run relevant local tests and static/build checks first, after inspecting their side effects. Check the actual boundary: tool results and correlation, outgoing child input, complete outputs, result durability or revision configuration. Mocked execution proves only the exercised local contract. Historical companion PASS results do not verify this target.

For an approved live experiment, retain failed observations, compare equivalent workloads and report sample counts, cold/warm/cache state and errors. Verify owned cleanup, including caches separately from sessions. Repeat the local adaptation to check for duplicate wiring or needless changes.

Report files changed, commands actually executed, exact versions, actual results, manual steps and remaining uncertainty. State what the change improves and what the evidence cannot establish.

Label each result with its tier (offline, local, live or release) and outcome (pass, fail, blocked or not run) as evidence labels defines them; earlier, vendor and documentation-only results are historical, vendor-measured or guidance, never this session's evidence.

Independent community project; not affiliated with or endorsed by Google.