ADK operational guardrails

Make the application decide whether another model call, tool action or expensive invocation may run. Deliver the smallest coherent implementation or an evidence-based audit, with enforcement at the actual execution boundary. The book and companion repository are not prerequisites.

Inspect before choosing a mode

1. Read project instructions, dependency declarations and locks, Python constraints, package-manager configuration and existing tests. Inspect import/startup side effects before executing project code or collecting tests. Record the selected interpreter and installed google-adk/google-genai versions. Keep pins unchanged. Use compatibility before copying or adapting an ADK API.
2. For a repeatable, read-only inventory, run the inspector with the target project's Python when it is 3.11 or later, otherwise with any available 3.11+ interpreter for the helper alone (interpreter rules), reporting which one ran. Run python "$SKILL_DIR/scripts/inspect_project.py" --project "$PROJECT_ROOT", resolving SKILL_DIR to this skill's directory and setting PROJECT_ROOT to the target directory first. Inspect the reported files yourself; the helper does not prove safety or execute project code. Credentials are unnecessary for this step.
3. Trace each served path (CLI, web agent, API, worker) to its runner, registered tools, identity source, state stores and error handling. Record which controls actually wrap each path by following the call from the server to the wrapper. For example, a budget_guard module that only the CLI imports leaves the web path unguarded.
4. Establish the units and scope: model calls, tool calls, workflow rounds, wall-clock seconds, tokens per invocation/session/user/tenant, and currency costs are different limits. Determine concurrency, restart requirements, external side effects and whether approval means permission or completed execution.

Inspection is complete when each relevant entry point has an identified enforcement boundary, version baseline and state lifetime. Ask only for unresolved product limits, deployment targets or authority decisions that materially change the work; continue offline work while those answers are pending.

If no project interpreter exists, use an available Python only for read-only inspection and label its package metadata as the inspector environment. A successful scan with no relevant source/configuration files establishes no application coverage. Inspect a plan or inventory fixture with the available interpreter and install nothing for it.

Choose the relevant mode

Modes compose within this one skill. Read only the references needed for the request.

For a greenfield project, confirm Python/ADK selection before installing dependencies; prepare a dependency-free design and tests meanwhile. For an existing project, adapt its interfaces and persistence rather than installing the demonstration architecture. Preserve custom statuses, policy thresholds, public APIs and test tools unless the requested fix requires a change.

When the project has agents-cli-manifest.yaml, consult the installed google-agents-cli-adk-code skill (references/adk-python.md, or the long-horizon-harness, ambient-expense-agent and deep-search recipes) for the native confirmation and resume wiring the scaffold expects; if it is not installed, adk-engineer explains how to get it. The enforcement boundary and the evidence rules in this skill still govern.

Implement and validate

1. State a short plan naming the boundary to change, affected files and observable acceptance test before broad edits. Separate local implementation from external operations.
2. Implement only the selected controls. The invocation guard asset is an optional, tested local starter for asynchronous tools. Read runtime guidance before adapting it: it supplies neither ADK orchestration nor distributed budgets, authentication, durable approval or provider idempotency. Compare with existing code before copying and preserve its licence notice.
3. Bind user/tenant and operation authority outside the model's arguments. Enforce permission and repeat policy before dispatch, in the code that dispatches; a prompt or a pending_approval string is the message that gate sends, and the gate itself is the code.
4. Record spent usage even when output delivery is stopped. Return a bounded, static explanation when a guard fires; spending another model call to explain exhausted allowance defeats the control.
5. Run the target project's tests using its existing environment and conventions. Select the relevant cases from validation, including a real runner with a fake model for ADK boundary changes. Test the served path as well as the helper, and assert actual outgoing configuration and effects. Repeat the invocation to check cumulative state and avoid duplicate files or registrations.
6. Stop only when the relevant invariants have evidence or are explicitly unverified. New offline tests, historical live evidence, mocks (local (mocked)) and proposed production work (guidance) stay apart. Record a fixture response as fixture evidence; live provider and human-review success each need their own observation. Evidence records this skill's prior evidence.

Permissions and safe execution

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.

Use a separate operator identity for emergency infrastructure controls, inaccessible to the agent. For paid tests, specify maximum submissions and actual provider attempts.

Report the result

Report files changed, commands executed, actual results, the entry points covered, versions used, remaining manual steps and unverified behaviour. Identify any retained resources and the scope of cleanup if external work was approved. Do not commit, push, publish or deploy without explicit authorisation.

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.

This is an independent community project, not affiliated with or endorsed by Google. Design provenance and the distinction between the companion's local implementation and production advice are in evidence.