Installs into .claude/skills of the current project.
Are you the author of Agent?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/ai-engineers-guild-agent)
---
description: "Purpose and safeguards of the canonical ai_stp Skill."
last_verified: "2026-09-16"
---
# Integration Skill
The canonical Skill contains the procedure for working with the CLI, but does not copy every schema.
It starts with `ai-stp task intents --json`, starts one shipped intent, and
executes continuation `argv` only when `actor` is `cli`. A human question is
relayed through `task answer`. An `external` payload is shown once; do not
execute that `argv`. `provider-too-old` is not login. A device-code wait
continues only after the browser, never in a tight loop.
The Skill itself contains
no command list: that list lives in the CLI registry, and a copy would diverge
from the implementation on the first change. Remaining parameters, schemas and
error handling come from machine help. The Skill then identifies the current
harness and project, reads passports, inspects unknown required fields, displays
composition, conflict, and conversion reports, applies the remaining stops in
`references/decisions.md`, does not remove its own control layer, and returns a
recovery command after a partial failure.
The only flags named directly by the Skill belong to compact intent discovery:
`task intents --json`. Everything else comes from continuation `argv` or machine
help, and a contract check enforces this.
The Skill interprets the `mutability` effect and the machine `confirmation` method separately:
`none` does not mean consent to write, `explicit_flag` requires a fresh decision, and
`plan_digest` is a machine binding of exact bytes. Shipped task intents bind that
digest in-process; do not run named plan leaves for `install`, `change`, or
`switch`. Expert families that still declare `plan_digest` take it from that
family's plan command. A stale plan is rebuilt inside the task; `next_actions`
remains advice rather than authority for the next effect.
The Skill is projected onto the native surfaces of every supported harness.
Projections are generated by `just back-gen` and checked by `just back-static`.
Each projection is the procedure plus harness metadata and a short native-surface
note (`ADR-0149`). It must not point at a repository path. Flags stay in machine
help; command paths may be named.
The canon, its `references/` playbooks, the Russian locale, and every harness
projection ship inside the package. `skill install` writes that package to a
named destination. Without this, a user who installed the wheel would receive an
executable but no procedure.
Installation uses an explicit destination rather than discovery. Where a harness looks for a native Skill is a fact about that harness and differs across the five; inventing five paths would present guesses as support. Discovery will arrive with the harness detectors under `SPEC-014`; until then, the caller—a person, agent, or website installer—specifies the path.
Nothing is overwritten silently. Installation places an ownership record beside the Skill; removal takes only what that record confirms, while a Skill written by someone else or changed after installation remains in place and is named in the response. The local registry and user-configured state are not part of the control layer and are never touched.
## Installed workflow
The entrypoint distinguishes the CLI, control Skill, provider, harness program
and setup. It reuses the installed command descriptors within one version and
opens the playbook relevant to the request. The ready-setup route is the
`install` intent: the task engine acquires, plans, approves and applies
in-process, then verifies target state. First-run indexing and adoption are
scoped to the requested project rather than performed for every discovered
component. A missing CLI uses the supported package installation before
`task intents --json`.
Every linked playbook is shipped in each installed language/harness package.
The generator discovers the canonical reference inventory and preserves its
routing description in native projections. Installation tests resolve the
links from the delivered package, independently of the generator's file list.