agent-profile-kit 0.204.1 → 0.237.0

package/docs/guides/workspace.md

@@ -3,10 +3,10 @@
 Agent Profile Kit keeps your reusable, cross-project agent material in one
 Workspace. The Workspace is the single canonical source. Profiles select a flat
 set of portable artifacts for a kind of work. The Installer installs each bound
-Profile into explicitly bound projects as disposable, Host-native output.
-Supported Hosts then load that material through ordinary project discovery.
+Profile into explicitly bound projects as disposable, agent-native output.
+Supported agents then load that material through ordinary project discovery.
 
-Keep project facts in the relevant project repository. Keep Host preferences,
+Keep project facts in the relevant project repository. Keep agent preferences,
 authentication, credentials, and machine-specific values outside the Workspace.
 Edit Workspace files and Local Configuration directly.
 
@@ -18,44 +18,58 @@ Source ownership and managed delivery are separate:
   **unselected universal** artifacts (material useful across every directory or
   kind of work, not only one Profile’s selection). Leaving an artifact unselected
   by every Profile does not make it invalid and does not move its canonical
-  source into Host configuration.
+  source into agent configuration.
 - **Profiles** select the artifacts scoped to a kind of work for Agent Profile
   Kit–managed project-bound delivery. A Project Binding selects a project root,
-  one Profile, and Hosts; only selected (and Dependency-resolved) artifacts from
-  that Profile enter Installation Receipts and the managed lifecycle
+  one Profile, and agents; only the artifacts that Profile selects enter
+  Installation Receipts and the managed lifecycle
   (`status`, `update`, and `uninstall`).
 - Agent Profile Kit v1 does not install, project, synchronize, or remove material in
-  personal/global Host roots. Global Host delivery is not APK-owned state: it is
+  personal/global agent roots. Global agent delivery is not APK-owned state: it is
   outside Project Bindings and Installation Receipts, and `update` / `uninstall`
   never adopt, record as managed output, or mutate those paths. `status` does not
   treat global roots as managed output.
 - You may still manage native global delivery yourself—for example by symlinking
-  a Host Skill root entry to canonical Workspace source—but that delivery is
-  user-managed Host configuration, not Agent Profile Kit–owned state. Agent
+  an agent Skill root entry to canonical Workspace source—but that delivery is
+  user-managed agent configuration, not Agent Profile Kit–owned state. Agent
   Profile Kit never adopts, tracks, or uninstalls those global paths.
-- A Skill may be both universally delivered through Host configuration and
-  selected into a bound Profile. The Host owns discovery, precedence,
+- A Skill may be both universally delivered through agent configuration and
+  selected into a bound Profile. The agent owns discovery, precedence,
   deduplication, collision diagnostics, and resolution between those sources.
   Agent Profile Kit blocks only an exact planned destination it cannot safely
   own, not same-identity material elsewhere.
 
 ## Initialize
 
-`apkit init` creates an empty, schema-versioned Workspace at the
-fixed default path `~/.agents/agent-profile-kit/workspace/` and a version-2
-machine-local Local Configuration at `~/.agents/agent-profile-kit/config.yaml`
-that explicitly records that path when Local Configuration is absent. Pass one
-explicit absolute or home-relative path to choose another destination:
+There is no default Workspace location: setup records a folder the user names
+(spec #593 DEC-001, ADR-0049). `apkit init <workspace>` adds exactly the
+missing required parts to that folder and a version-2 machine-local Local
+Configuration at `~/.agents/agent-profile-kit/config.yaml` that explicitly
+records the authored path when Local Configuration is absent:
 
 ```sh
 apkit init ~/projects/agent-profile-workspace
 ```
 
-When Local Configuration is absent, an explicit missing or empty non-symlink
-destination is fully scaffolded and recorded. A valid existing Workspace,
-including a symlink alias, is adopted without changing its source. Rerunning is
-safe: it never overwrites the Workspace or current configuration, and it does
-not restore optional scaffolding that you removed from a valid Workspace.
+`apkit init .` uses the current folder. With a terminal, `init` asks whether
+to use the current folder — shown as its full path — or another path, and
+confirms the chosen folder before any write: it states that Context and Skill
+files will be stored in and loaded from it and lists the parts setup will add
+(or that nothing needs to be added); declining or cancelling writes nothing
+(spec #593 #603). Without a path on a machine that has no selected Workspace
+and without a terminal, `init` writes nothing and prints those two forms;
+supplying the path counts as the confirmation.
+
+When Local Configuration is absent, setup adds exactly the missing required
+parts — `workspace.yaml`, `context/`, `skills/`, and `profiles/` — in place to
+the named folder and records the selection (spec #593 DEC-003, ADR-0047). A
+path that does not exist is created only when its parent directory exists; a
+parent that is missing too is refused, and nothing is written outside the
+named path. A valid existing Workspace, including a symlink alias, is adopted,
+adding only its still-missing required parts; existing entries are never
+changed, moved, or deleted. A folder whose existing material is invalid is
+refused with its violation and nothing is added. Rerunning is safe: it never
+overwrites the Workspace or current configuration.
 
 To keep the Workspace as an independent Git repository elsewhere, set the
 required `workspace` field in Local Configuration to one existing absolute or
@@ -82,14 +96,16 @@ only `schema_version: 1`. Local Configuration schema version is 2 and its
 ### Legacy Local Configuration migration and version compatibility
 
 Version-1 Local Configuration without `workspace` is supported only as migration
-input. Run `apkit init` to upgrade it before using `validate`, `status`, `update`,
-`install`, or `uninstall`. Those commands never migrate
-the file implicitly: they fail closed with actionable `apkit init`
-guidance while leaving migration to the explicit `init` command.
-
-For a legacy file that omitted `workspace`, migration records the conventional
-default `~/.agents/agent-profile-kit/workspace/`. For a legacy file with an
-authored path, migration preserves that path. `init` validates the selected
+input. Run `apkit init <path>` to upgrade it before using `validate`, `status`,
+`update`, `install`, or `uninstall`. Those commands never migrate
+the file implicitly: they fail closed with actionable upgrade guidance while
+leaving migration to the explicit `init` command.
+
+A legacy file that omitted `workspace` has no selection to preserve and is
+never upgraded to a default: zero-argument `init` refuses, and
+`apkit init <path>` upgrades it to the path the user gives (spec #593
+DEC-011, ADR-0049). For a legacy file with an authored path, migration
+preserves that path. `init` validates the selected
 Workspace before atomically replacing only Local Configuration, preserving
 Project Bindings, comments, line endings, and file mode; it never moves or
 rewrites Workspace source. If validation fails, the configuration remains
@@ -118,89 +134,77 @@ The restored file preserves the pre-migration Workspace selection and Project
 Bindings. This reverses only the Local Configuration schema transition; it does
 not undo later Workspace content changes.
 
-### Required structure vs initialization scaffolding
+### Required structure vs optional files
 
-A valid Workspace needs only a supported `workspace.yaml`. That Manifest is the
-Workspace marker. Missing artifact directories are treated as empty categories;
-present ones are validated and ingested normally. `README.md`, `AGENTS.md`, and
+The Workspace contract (run `apkit guide --contract`) states the required
+structure and every rule validation enforces. In short: a valid Workspace needs a
+supported `workspace.yaml` — the Workspace marker — plus the `context/`,
+`skills/`, and `profiles/` artifact directories, which setup adds when
+missing; missing categories are treated as empty collections, and present
+ones are validated and ingested normally. `README.md`, `AGENTS.md`, and
 `.gitignore` are optional user-owned files that the engine never requires.
 
-When creating a **new** Workspace, `init` still scaffolds a friendly layout so
-you can discover where material belongs:
-
-- artifact directories `profiles/`, `context/`, `skills/`, `agents/`, `hooks/`,
-  and `tools/` (with `.gitkeep` placeholders)
-- a bindable `profiles/example.yaml` and its `context/example-context.md`
-- short bootstrap `README.md` and `AGENTS.md` pointers to the current guides
-- a starter `.gitignore`
-
-The example gives a new user one complete `install` → `status` → `update` path.
-Delete both `profiles/example.yaml` and `context/example-context.md` together,
-unused empty directories, or bootstrap docs if you prefer a minimal tree;
-later `init` runs do not restore removed optional scaffolding; validation,
-status, update, and uninstall keep working. Do not treat generated Host
-output as source material.
+When creating a **new** Workspace, `init` adds only the required parts and no
+example material (spec #593 DEC-003, ADR-0047). For a complete worked example
+— a bindable `profiles/example.yaml` and its `context/example-context.md` —
+run `apkit guide profile`, which prints both files' example bytes, or see
+`apkit guide context` and `apkit guide skill` for single artifacts. The
+contract's minimal valid Workspace shows all four required parts together.
 
 ## Author the Workspace
 
+The Workspace contract (run `apkit guide --contract`) states the complete
+authoring format: Context Module identity and delivery, the Skill package
+rules, the Profile shape, and model-invocation policy. This guide covers how
+that material reaches each agent.
+
 This release supports Profile Context and Context Modules for Antigravity,
 Codex, Claude Code, Grok, OpenCode, and Pi, and portable Skills for Antigravity,
 Codex, Claude Code, Grok, OpenCode, and Pi. Antigravity Context uses `.agents/rules/`;
 Antigravity, Codex, OpenCode, and Pi Skills install through the qualified shared
 `.agents/skills/<Artifact ID>/` projection after project-surface capability checks;
 Pi and OpenCode resolve other Skills, extensions, and packages through native
-Host behavior.
+agent behavior.
 Disabled model-invocation Skills are projected with the shared
 `disable-model-invocation: true` field while explicit `/skill:<Artifact ID>`
 activation (or OpenCode `/<Artifact ID>` command activation) remains available.
-Profiles contain only `id`, `context`, and `skills`; Agents, Hooks, and Tools
-are not delivered by this release. A Profile must select at least one supported
-artifact overall (Context Module, Skill, or both); no individual category is
-mandatory. Context-only, Skills-only, and combined Profiles are valid.
-
-A Context Module is a Markdown file under `context/` with frontmatter containing
-one stable, lowercase kebab-case `id`; the Markdown body is the Context. A Skill
-is a standard Agent Skills package under `skills/`, rooted at `SKILL.md`; its
-standard `name` is its stable Artifact ID. The frontmatter needs a lowercase
-hyphenated `name` and a non-empty `description`. Scripts, references, and assets
-remain ordinary standard Skill content. If a Skill needs Agent Profile Kit-only
-dependency metadata, put it in an optional `agent-profile-kit.yaml` sidecar.
+Agents, Hooks, and Tools are not delivered by this release.
 
 ### Skill model-invocation policy
 
-By default, Hosts may invoke a Skill implicitly when the model matches its
+By default, agents may invoke a Skill implicitly when the model matches its
 description. To require explicit user invocation while keeping the Skill
-available on request, set optional standard namespaced metadata:
+available on request, set the standard top-level `disable-model-invocation`
+field in `SKILL.md`:
 
 ```yaml
-metadata:
-  agent-profile-kit.model-invocation: disabled
+disable-model-invocation: true
 ```
 
-Accepted values are the strings `allowed` and `disabled`. Absence normalizes to
-`allowed`. Invalid types or values fail at Workspace ingestion.
+The field is a boolean: `true` disables model invocation, and absence (or
+`false`) allows it; non-boolean values fail at Workspace ingestion with the
+fix.
 
-This is the only portable spelling. Host-native top-level
-`disable-model-invocation` and Codex-only `agents/openai.yaml` policy are not
-canonical source fields for Agent Profile Kit: migrate Host-shaped Skills to
-the namespaced metadata key above rather than relying on Host-specific
-frontmatter. The Installer never rewrites Workspace `SKILL.md` during
-validate, status, or update.
+The standard field is the only policy authority (ADR-0018); the Workspace
+contract states the full rule set, including the retired
+`agent-profile-kit.model-invocation` metadata key and the accepted-and-ignored
+other top-level fields. The Installer never rewrites
+Workspace `SKILL.md` during validate, status, or update.
 
-Adapters translate the trusted policy only in generated Host output:
+Adapters translate the trusted policy only in generated agent output:
 
 | Canonical policy | Claude / Grok generated output | Antigravity / Codex / OpenCode / Pi shared output |
 | --- | --- | --- |
-| `allowed` (default) | No Host restriction field | No Host restriction field |
+| `allowed` (default) | No agent restriction field | No agent restriction field |
 | `disabled` | `disable-model-invocation: true` in generated `SKILL.md` | `disable-model-invocation: true` in generated `SKILL.md` plus `policy.allow_implicit_invocation: false` in generated `agents/openai.yaml` and `"permission": { "skill": { "<id>": "deny" } }` in generated `.opencode/opencode.jsonc` |
 
 Existing source `agents/openai.yaml` content is preserved. An equivalent
 invocation policy coalesces; malformed, wrong-type, or conflicting policy
 produces one structured project Blocker naming the Workspace and shared
-Host-policy authorities with a Workspace repair remedy before any project write. Generated
+Agent-policy authorities with a Workspace repair remedy before any project write. Generated
 policy fields carry short deterministic comments. When any selected Skill
 disables model invocation, update-time capability probing checks each selected
-Host's enforcement floor: Claude Code CLI
+agent's enforcement floor: Claude Code CLI
 `2.0.64+` (same floor as unscoped rules and native Skill discovery, which
 honors `disable-model-invocation`), Grok CLI `0.2.0+` (same floor as project
 rules and native Skill discovery, which honors `disable-model-invocation`),
@@ -219,43 +223,48 @@ shapes. Probing is advisory: an older, missing, or unreadable CLI produces a
 warning, and the planned policy fields are written regardless — the Adapter
 never silently omits or weakens what it plans.
 
-Artifacts may declare required Dependencies with explicit typed references. Put
-Context Module Dependencies in their frontmatter and Skill Dependencies in each
-Skill's Agent Profile Kit sidecar. Each reference contains `type` (`context` or
-`skill`) and its stable `id`. Dependencies are resolved transitively and every resolved reason remains
-available in live planning. Inclusion reasons are not
-persisted in Installation State.
-
-A Profile is a YAML file under `profiles/` with exactly an `id`, a `context`
-array, and a `skills` array. At least one of `context` or `skills` must be
-non-empty. A Skills-only Profile installs only selected Skill packages for Hosts that
+Profiles are the only place that says what gets installed together (ADR-0045):
+list each needed Context Module and Skill explicitly. A Profile's `context`
+and `skills` lists install exactly what they name — nothing is pulled in
+transitively. The Workspace contract states the Profile shape; a
+Skills-only Profile installs only selected Skill packages for agents that
 support them and Installer lifecycle metadata—no Context snapshot, Codex
 SessionStart hooks, or Claude Context rule. Antigravity Skills-only bindings
-check only the shared `.agents` and `.agents/skills` surfaces. Host capability
+check only the shared `.agents` and `.agents/skills` surfaces. Agent capability
 probing is scoped to the selected categories (Skills-only does not require Context
-machinery). Profiles do not inherit, use wildcards, or carry Host settings.
+machinery). Renaming a Profile file renames its ID; Project Bindings select
+Profiles by that name.
+
+Rollback caveat: this Profile shape is a **CLI 0.208.0+** acceptance change.
+A Workspace whose Profiles carry no `id` line fails validation on an older
+binary — before rolling a CLI back, re-add an `id` line matching each
+Profile's file name, or keep every shared Workspace on 0.208+.
 
 ```md
----
-id: engineering-rules
-dependencies:
-  - type: context
-    id: security-rules
----
+<!-- context/engineering-rules.md -->
 Keep project facts in the project repository.
-```
 
-```yaml
-# skills/review-pr/agent-profile-kit.yaml
-dependencies:
-  - type: skill
-    id: write-release-notes
+<!-- context/engineering/review-findings.md -->
+Review findings and the reasoning behind them.
 ```
 
+A Context Module is a plain Markdown file: no frontmatter is required or
+read (the Workspace contract states the full rule). A Context file that still
+carries frontmatter from an earlier release
+is valid — its bytes are delivered as written — and you can delete the
+frontmatter at your leisure.
+
+Rollback caveat: Context path identity is a **CLI 0.210.0+** acceptance
+change. A Workspace whose Context Modules carry no frontmatter `id` fails
+validation on an older binary — before rolling a CLI back, re-add an `id`
+line matching each file's path-derived ID, or keep every shared Workspace on
+0.210+.
+
 ```yaml
-id: coding
+# profiles/coding.yaml
 context:
   - engineering-rules
+  - engineering/review-findings
 skills:
   - review-pr
 ```
@@ -275,8 +284,7 @@ description: Review a pull request. Use when asked to review code changes.
 ---
 name: to-spec
 description: Turn the current conversation into a spec.
-metadata:
-  agent-profile-kit.model-invocation: disabled
+disable-model-invocation: true
 ---
 
 # To spec
@@ -287,22 +295,22 @@ metadata:
 Project Bindings live only in machine-local
 `~/.agents/agent-profile-kit/config.yaml`. Each binding names exactly one
 existing absolute or home-relative project root, one Profile, and a non-empty set
-of supported Hosts (`antigravity`, `codex`, `claude`, `grok`, `opencode`, `pi`). Host order
+of supported agents (`antigravity`, `codex`, `claude`, `grok`, `opencode`, `pi`). Agent order
 and duplicate entries normalize at ingestion. There are no wildcards, recursive scans,
-hidden default projects, Host auto-detection, per-session Profile selection, or
+hidden default projects, agent auto-detection, per-session Profile selection, or
 Profile version pins. A project root may appear in only one binding.
 
 Hand-edit `config.yaml`, or record one binding and install it in one action
 with `apkit install` (confirms interactively; `--auto-confirm` answers it):
 
 ```sh
-apkit install coding --host codex --auto-confirm
-apkit install coding ~/projects/tools/agent-profile-kit --host antigravity --host codex --host claude --host grok --host opencode --host pi --auto-confirm
+apkit install coding --agent codex --auto-confirm
+apkit install coding ~/projects/tools/agent-profile-kit --agent antigravity --agent codex --agent claude --agent grok --agent opencode --agent pi --auto-confirm
 ```
 
 Omit the project argument to use the current working directory. At least one
-`--host` flag is required. An identical installation is left unchanged; a different
-Profile or Host set for the same project replaces the installation in the same
+`--agent` flag is required. An identical installation is left unchanged; a different
+Profile or agent set for the same project replaces the installation in the same
 action. Do not
 hand-edit `config.yaml` while `install` is running: cooperating lifecycle commands
 serialize, but a text editor does not participate in that lock. Installing a
@@ -341,13 +349,13 @@ bindings:
 
 For Codex bindings that select Context, the Adapter requires Codex CLI 0.145.0 or
 newer so the generated SessionStart handler can deliver the complete Context
-envelope without Codex's default head-and-tail spill. Host capability probing is
+envelope without Codex's default head-and-tail spill. Agent capability probing is
 advisory: during `update`, an older, missing, or unreadable Codex CLI produces a
 warning while the planned project and Installation State writes proceed
-regardless. `status` performs no Agent Host process execution and no capability
+regardless. `status` performs no agent process execution and no capability
 probing; a Project-scoped `status` or `update` plans only its
 selected binding. `update --all` writes every selected Project including any with
-Host capability warnings; global Blockers still stop every fleet write.
+agent capability warnings; global Blockers still stop every fleet write.
 Skills-only Codex bindings do
 not require this floor. Review and trust the generated project SessionStart hook
 in Codex for each bound project. Lifecycle hooks are enabled by default. Agent Profile Kit checks the effective global and project configuration
@@ -380,8 +388,8 @@ directory, one explicit existing absolute or home-relative bound Project root,
 or `--project <path>`; `--all` states the fleet scope explicitly. Scoped
 planning, Git and ownership inspection, reconciliation, reports,
 and writes exclude unrelated Projects; a shared Git exclusion file changes only
-through the selected installation's contribution-aware union. Host capability
-probing is advisory and happens only during `update`: a missing or outdated Host
+through the selected installation's contribution-aware union. Agent capability
+probing is advisory and happens only during `update`: a missing or outdated agent
 CLI produces a warning and the planned output is written regardless; capability
 problems never block application and do not mark generated files as drifted.
 
@@ -396,7 +404,7 @@ Installation output must be exclusively Installer-owned.
 Git is optional. For a Git binding, `update` installs only into the exact bound
 project directory. The Installer uses Git for tracked-path protection and local
 exclusions but does not inspect or report worktree topology. Bind any additional
-root explicitly only when Hosts must be launched directly from that root; it
+root explicitly only when agents must be launched directly from that root; it
 then follows the same lifecycle as any other binding.
 
 For every bound project root, the ordinary removal order is:
@@ -422,9 +430,9 @@ independently changed generated file only with your explicit consent. The
 claimed OpenCode configuration file carries the same generated-source notice
 with project-file guidance instead of the Workspace pointer. Supporting Skill
 resources keep their bytes. See ADR-0041. Unrelated project files,
-repository-owned instructions, global Host configuration, authentication, trust,
+repository-owned instructions, global agent configuration, authentication, trust,
 approvals, plugins, and sessions remain untouched. Agent Profile Kit does not
-merge selected fields into Host or repository configuration, install a watcher or
+merge selected fields into agent or repository configuration, install a watcher or
 Git hook, or modify shared `.gitignore` files.
 
 For a currently bound installation, `update` recreates a
@@ -434,24 +442,29 @@ still matches its recorded hash; when no recorded root matches, ownership
 continuity cannot be proven and `status` blocks until you restore or remove the
 generated files. Unexpected directory members are never overwritten.
 
-## Use Hosts natively
+## Use agents natively
 
 After `update`, launch Antigravity, Codex, Claude Code, Grok, OpenCode, or Pi from the
 bound project the way you normally would. Agent Profile Kit does not manage their
 authentication, trust, approvals, plugins, or sessions, and does not launch
-Hosts.
+agents.
 
 ### Antigravity
 
 Antigravity receives Profile Context through deterministic always-on rules under
 `.agents/rules/`. The Adapter requires `agy` CLI 1.1.13 or newer and writes one
 rule for the Profile envelope followed by one complete rule per Context Module.
+A nested Context Module ID's `/` separators become `.` in the rule file name
+(the ID itself is preserved in the rule's boundary markers); each rule file
+stays directly inside `.agents/rules/`.
 Each generated rule contains `trigger: always_on` frontmatter and must stay at or
 below 12,000 characters. If one Context Module is too large, status reports a
-structured blocker instead of truncating it.
+structured blocker instead of truncating it. A Context Module's own frontmatter,
+when it has any, is delivered as written inside the rule's boundary markers and
+never replaces the generated `trigger: always_on` frontmatter.
 
 Antigravity discovers the rules from the current bound project; you do not need
-to create or select an Antigravity Project. Trust is Host-owned: after `update`,
+to create or select an Antigravity Project. Trust is agent-owned: after `update`,
 trust the bound project in Antigravity if it asks. Agent Profile Kit does not
 read or change trust, settings, authentication, plugins, Project records,
 `AGENTS.md`, or `GEMINI.md`. A standing trust reminder appears for every
@@ -464,7 +477,7 @@ each `SKILL.md` body after frontmatter (ADR-0041) — and, for disabled Skills,
 both the generated `disable-model-invocation: true` field and Codex
 `agents/openai.yaml` policy.
 Antigravity's native discovery, trust, settings, and effective inventory remain
-Host-owned.
+agent-owned.
 
 ### Codex
 
@@ -473,7 +486,7 @@ discovers selected Skills under `.agents/skills/<Artifact ID>/`. When Context is
 installed, Codex asks you to review the generated hook: review its contents and
 approve it when they match the expected SessionStart behavior, because declining
 it prevents Profile Context from loading. Before launching Codex,
-trust each bound project in Codex — project trust is Host-owned and is not
+trust each bound project in Codex — project trust is agent-owned and is not
 configured by Agent Profile Kit.
 Ordinary launches from a Git project's bound directory or its descendants receive
 that material. For a non-Git project, launch Codex from the exact bound root;
@@ -496,9 +509,8 @@ Context writes; Skill-bearing Profiles instead prove the shared `.agents` and
 `.agents/skills` surfaces. Profiles with portable Skills receive one shared
 package per resolved Artifact ID under `.agents/skills/<Artifact ID>/`;
 standard package bytes and modes are preserved apart from the generated-source
-notice that opens each projected `SKILL.md` body (ADR-0041), and
-`agent-profile-kit.yaml` is omitted. Codex and Pi co-own one normalized package when both are selected;
-the package carries every required Host policy field without adding consumer
+notice that opens each projected `SKILL.md` body (ADR-0041). Codex and Pi co-own one normalized package when both are selected;
+the package carries every required agent policy field without adding consumer
 metadata to Skill source. Pi owns Skill resolution across personal, project,
 ancestor, package, extension, and configured sources. Disabled
 model-invocation Skills receive top-level `disable-model-invocation: true` in
@@ -506,7 +518,7 @@ generated `SKILL.md` while the canonical Workspace source remains unchanged
 and explicit `/skill:<Artifact ID>` activation remains available. Malformed or
 unreadable relevant settings warn without blocking. Pi's native project trust,
 authentication, settings, prompt files, and per-session overrides remain
-Host-owned.
+agent-owned.
 
 ### OpenCode
 
@@ -518,7 +530,7 @@ user-authored slots via native additive merging, and the Project-relative
 reference continues to load Context when OpenCode is launched from any subdirectory.
 The OpenCode Adapter requires CLI 1.18.23 or newer. When configuration is planned
 (Context or disabled Skills), the Adapter emits one transition launch-constraint
-Host Setup Step tied to `.opencode/opencode.jsonc` reminding you to restart
+Agent setup step tied to `.opencode/opencode.jsonc` reminding you to restart
 running OpenCode sessions.
 
 OpenCode discovers selected Skills through the qualified shared
@@ -531,13 +543,13 @@ remains available. When Claude and OpenCode are co-selected in a Project Binding
 with Skills, OpenCode natively discovers Skills under both `.claude/skills` and
 `.agents/skills` and reports duplicate Skill names; the OpenCode Adapter emits
 one non-blocking diagnostic warning naming both roots. OpenCode's native
-discovery, configuration slots, and session commands remain Host-owned.
+discovery, configuration slots, and session commands remain agent-owned.
 
 ### Precedence and conflicts
 
 Repository-owned project instructions take precedence over Profile Context on
 conflict. Agent Profile Kit does not detect or resolve contradictions in prose;
-conflicting guidance remains visible to you and the Host. Global Host
+conflicting guidance remains visible to you and the agent. Global agent
 configuration and repository-owned files stay live and unchanged.
 
 ### Installation State compatibility and recovery
@@ -576,9 +588,9 @@ ownership you independently verify, including any
 recreate the desired Project Bindings and run `apkit update` to establish fresh
 ownership receipts. This manual path is intentionally fail-closed.
 
-### Host Resolution and project-bound Profiles
+### Agent resolution and project-bound Profiles
 
-This section is the Host-path detail for the
+This section is the agent-path detail for the
 [Universal Workspace material](#universal-workspace-material) boundary.
 
 Agent Profile Kit installs selected Skills only into the bound **project**
@@ -586,11 +598,11 @@ Agent Profile Kit installs selected Skills only into the bound **project**
 `.claude/skills/<Artifact ID>/` for Claude, `.grok/skills/<Artifact ID>/` for
 Grok). Antigravity Profile Context uses `.agents/rules/` alongside its shared
 Skill packages. It never installs into, adopts, disables, or removes
-personal/global Host Skill folders. Unselected Workspace
+personal/global agent Skill folders. Unselected Workspace
 Skills are not installed into projects either; they may remain valid Workspace
 source without any APK-managed delivery.
 
-Those global folders remain Host-owned:
+Those global folders remain agent-owned:
 
 - Codex: `~/.agents/skills/` and `~/.codex/skills/`
 - Claude Code: `~/.claude/skills/`
@@ -600,12 +612,12 @@ Those global folders remain Host-owned:
 - Pi: `~/.pi/skills/` (plus configured sources)
 
 Selected Skills may share an identity with material from these roots, packages,
-plugins, extensions, compatibility sources, or other Host-native locations.
-The Host owns discovery, precedence, deduplication, collision diagnostics, and
+plugins, extensions, compatibility sources, or other agent-native locations.
+The agent owns discovery, precedence, deduplication, collision diagnostics, and
 resolution across those sources. Agent Profile Kit neither scans an effective
 inventory nor asks you to remove same-identity material.
 
-Where a disable is detectable without reconstructing Host Resolution, the
+Where a disable is detectable without reconstructing agent resolution, the
 Adapter warns: Codex checks SessionStart hooks and Grok checks
 `[skills].disabled` and `[skills].ignore`. Malformed or unreadable
 configuration that an Adapter reads for planned output also warns; Pi's
@@ -618,12 +630,12 @@ planned project destination remain blockers.
 Use `apkit status` for the bound Project containing the current directory, pass
 one explicit Project root, or use `apkit status --all` to inspect every binding.
 It reports current, not installed, stale source, drifted output (including wholly absent
-owned output), malformed ownership, and blocked installations, while keeping Host
+owned output), malformed ownership, and blocked installations, while keeping agent
 configuration warnings visible.
 
-Use `apkit uninstall --here`, `uninstall --project <path>`, or `uninstall --all` (with `--auto-confirm` non-interactively, plus `--profile <name>`, `--host <host>`, and `--remove-changed` as needed) to remove selected installations and forget their recorded selection. `--host <host>` (repeatable) removes only those Hosts within the scope while the remaining Hosts keep working. It removes only Installation Receipt-proven output and preserves the Workspace and unselected Projects. It writes no teardown provenance. Because a fully removed Project is forgotten, the next `status` no longer selects it, rather than reporting it as unsafe unexplained missing output.
+Use `apkit uninstall --here`, `uninstall --project <path>`, or `uninstall --all` (with `--auto-confirm` non-interactively, plus `--profile <name>`, `--agent <agent>`, and `--remove-changed` as needed) to remove selected installations and forget their recorded selection. `--agent <agent>` (repeatable) removes only those agents within the scope while the remaining agents keep working. It removes only Installation Receipt-proven output and preserves the Workspace and unselected Projects. It writes no teardown provenance. Because a fully removed Project is forgotten, the next `status` no longer selects it, rather than reporting it as unsafe unexplained missing output.
 
-To stop managing a Project but keep its Git-owned files in place, remove its entry from `~/.agents/agent-profile-kit/config.yaml` by hand; the next `update` reconciles the leftovers. Neither path modifies personal/global Host configuration or repository-owned files.
+To stop managing a Project but keep its Git-owned files in place, remove its entry from `~/.agents/agent-profile-kit/config.yaml` by hand; the next `update` reconciles the leftovers. Neither path modifies personal/global agent configuration or repository-owned files.
 
 Review personal content before publishing this Workspace. Agent Profile Kit does
 not classify private material, and credential values do not belong in a Workspace

package/package.json

@@ -1,7 +1,12 @@
 {
   "name": "agent-profile-kit",
-  "version": "0.204.1",
+  "version": "0.237.0",
   "description": "Compose portable agent material into host-native profiles.",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/kenneth-liao/agent-profile-kit.git"
+  },
   "type": "module",
   "bin": {
     "apkit": "./dist/cli.js"
@@ -29,12 +34,11 @@
     "darwin"
   ],
   "devDependencies": {
+    "@inquirer/core": "^12.0.3",
     "@types/bun": "^1.4.0",
     "@types/node": "^26",
-    "@types/prompts": "^2.4.9",
-    "prompts": "^2.4.2",
-    "smol-toml": "^1.8.0",
+    "smol-toml": "^1.9.0",
     "typescript": "^7.0.2",
-    "yaml": "^2.9.0"
+    "yaml": "^2.9.1"
   }
 }