Skip to content
Back to skills

Agent

ASecurity

Purpose and safeguards of the canonical ai_stp Skill.

  • 5 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 19, 2026
ai-agents

Works with

  • cli

Security analysis

A100/100

Pro scans all 6 files and shows the line behind each finding

Scanned September 19, 2026

npx -y skills add ai-engineers-guild/ai-stp --skill agent --agent claude-code

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.

Security grade badge for Agent
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/ai-engineers-guild-agent/badge)](https://www.skillsdirectory.com/skills/ai-engineers-guild-agent)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Files in this skill

  • harness-projections.md1.5 KB
  • index.md806 B
  • integration-skill.md4 KB
  • interaction-policy.md4.1 KB
  • machine-help.md6.5 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.