name: ak-ak description: Reason safely about the real AgentKit product control plane when the user specifically asks to inspect, configure, install, recover or remove AgentKit-managed state. metadata: {port: angent-fallback, mode: degraded}

AgentKit product administration

This Skill teaches the safe operating judgment for actual AgentKit installations. It is not the default way to run Engineer, and it does not make the ak executable a prerequisite for tasks. The ordinary work of planning, journaling, coding, testing, browsing or coordinating belongs to the corresponding Engineer Skill, selected by ak-agentkit.

Activate this Skill only when the user's object of change is AgentKit itself: its installed kits, CLI version, runtime adapter, licenses, credentials, project registration, backups or managed services. A user asking to "plan" or "run a Skill" is not automatically asking to manage AgentKit.

Establish the real object of change

Before an AgentKit operation, distinguish:

• Product state: installer, user/global registration, kit receipts, AgentKit login/licensing or daemon.
• Project work: a roadmap, code review, journal, task board, skill instructions or source files. Route this to its domain Skill.
• Host capability: runtime agents, browser, secret manager, package management or scheduling. Use a real supported host capability when the user wants its result.

For product state, determine whether the operation is observation, a project-local write, a user-global write, an external account/network action, or a potentially destructive recovery. Identify the exact installation, target environment, owner and scope. A local ak command can affect an adapter's global home; current working directory alone does not establish the target.

Decide and act safely

Prefer read-only inspection and live version/help over remembered syntax. A configured binary's current --help is authoritative for that binary; a version-pinned Skill reference may lag. For material mutations, inspect ownership, uncommitted files, backup/recovery path, pending effects and conflicts first. Do not infer that "doctor", dry-run, or a status-like command has zero external effect without checking its actual implementation.

Execute only when a real product CLI/provider is available and the effect is authorized. For risky installation/uninstall/recovery tests use an isolated environment, never a maintainer's actual home. Preserve unknown files. Afterward inspect actual changed product/provider state; command success alone does not establish that the requested runtime can use the installed kit.

If no AgentKit installation/provider exists, explain precisely which product-admin capability is missing. Do not fabricate installation status, account/session data or an ak shim. If the underlying request was an engineering task, use ak-agentkit and the relevant Skill instead.

Official references: https://agentkit.best and https://docs.agentkit.best/en/stable.