agent-profile-kit 0.204.1 → 0.237.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +20 -11
- package/dist/cli.js +9136 -10643
- package/docs/guides/agent-workflow.md +82 -41
- package/docs/guides/workspace-contract.md +502 -0
- package/docs/guides/workspace.md +153 -141
- package/package.json +9 -5
|
@@ -1,98 +1,139 @@
|
|
|
1
1
|
# Agent Profile Kit agent workflow
|
|
2
2
|
|
|
3
|
-
Use this workflow when helping a person
|
|
3
|
+
Use this workflow when helping a person set up Agent Profile Kit, migrate their existing Skills and instructions into a Workspace, compose Profiles, and bind projects.
|
|
4
|
+
|
|
5
|
+
## Fast-start onboarding & migration playbook
|
|
6
|
+
|
|
7
|
+
When a user points you at this repository or asks you to set up Agent Profile Kit from scratch, execute these five steps non-interactively (confirming user choices before writing):
|
|
8
|
+
|
|
9
|
+
1. **Run `apkit` without requiring manual CLI setup.**
|
|
10
|
+
Check whether `apkit` is on `PATH` (`command -v apkit`). If not, invoke it via `npx --yes --package agent-profile-kit apkit <command>`. Always pass explicit paths and `--auto-confirm` (or `--yes` on `init` when switching Workspaces) so commands never hang waiting for a terminal prompt. Optionally offer to add `alias apkit="npx --yes --package agent-profile-kit apkit"` to `~/.zshrc` if the user wants a short command for themselves.
|
|
11
|
+
2. **Initialize or connect the Workspace.**
|
|
12
|
+
Check `~/.agents/agent-profile-kit/config.yaml` first. If no Workspace is configured, ask the user where they want their Workspace (suggest `~/agent-profile-workspace` or `~/projects/agent-profile-workspace`) and run `apkit init <workspace>`.
|
|
13
|
+
3. **Discover and migrate existing Skills and instruction files.**
|
|
14
|
+
Scan the user's machine for existing reusable material they may want to bring into their Workspace:
|
|
15
|
+
- Global agent directories: `~/.claude/CLAUDE.md`, `~/.claude/skills/`, `~/.claude/commands/`, `~/.agents/AGENTS.md`, `~/.agents/skills/`, `~/.agents/rules/`, `~/.codex/AGENTS.md`, `~/.codex/skills/`, `~/.grok/GROK.md`, `~/.grok/skills/`.
|
|
16
|
+
- Current project directories (if inside a repo): `CLAUDE.md`, `AGENTS.md`, `.claude/skills/`, `.claude/rules/`, `.agents/skills/`, `.agents/rules/`.
|
|
17
|
+
Present a concise summary of what you found and ask which items are reusable across projects (versus repo-specific facts that should stay in the repo). Then **copy** (never delete the user's originals):
|
|
18
|
+
- Reusable instruction files into `<workspace>/context/<kebab-case-id>.md` (plain Markdown, no frontmatter needed; nested folders like `context/engineering/testing.md` become ID `engineering/testing`).
|
|
19
|
+
- Reusable Skill folders into `<workspace>/skills/<skill-name>/SKILL.md` (must start with YAML frontmatter containing `name: <skill-name>` matching the folder name and a non-empty `description:`).
|
|
20
|
+
4. **Create the first Profile and validate.**
|
|
21
|
+
Ask what Profile name fits their workflow (for example `engineering`, `creator`, or `default`), then run:
|
|
22
|
+
```sh
|
|
23
|
+
apkit new profile <profile> --context <id>... --skill <id>...
|
|
24
|
+
apkit validate
|
|
25
|
+
```
|
|
26
|
+
(Use `apkit configure profile <profile> --context <id>... --skill <id>... --auto-confirm` when updating an existing Profile's full membership list.)
|
|
27
|
+
5. **Install into the user's projects.**
|
|
28
|
+
Ask which project directory (or directories) and which agents (`claude`, `codex`, `antigravity`, `grok`, `opencode`, `pi`) they want to bind. Before running `install` on a Git repository, check whether the planned agent output paths (for example `.claude/rules/agent-profile-kit.md`, `.agents/skills/<skill>`, or `.agent-profile-kit/`) are already git-tracked in that repo; if so, warn the user about the Output Ownership Conflict before proceeding. Then run:
|
|
29
|
+
```sh
|
|
30
|
+
apkit install <profile> <project-path> --agent <agent> --auto-confirm
|
|
31
|
+
apkit status
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## Core rules and lifecycle reference
|
|
4
37
|
|
|
5
38
|
1. Read this guide first. Then inspect the Workspace: start with `workspace.yaml`
|
|
6
|
-
and its schema version.
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
`
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
39
|
+
and its schema version. The Workspace contract (run `apkit guide --contract`)
|
|
40
|
+
states the required structure and every rule `apkit validate` enforces; in
|
|
41
|
+
short, a valid Workspace has the `workspace.yaml` Manifest plus the
|
|
42
|
+
`context/`, `skills/`, and `profiles/` directories, which `apkit init` adds
|
|
43
|
+
when missing; missing artifact directories are empty collections, and
|
|
44
|
+
bootstrap files such as `README.md`, `AGENTS.md`, and `.gitignore` are
|
|
45
|
+
optional user-owned files, not format requirements. There is no default
|
|
46
|
+
Workspace location: use `apkit init <workspace>` for one explicit
|
|
47
|
+
destination (`.` uses the current folder); setup adds exactly the missing
|
|
48
|
+
required parts in place and never touches other entries, while a folder
|
|
49
|
+
whose existing material is invalid is refused with its violation
|
|
50
|
+
(spec #593 DEC-003, ADR-0047, ADR-0049). Inspect any present
|
|
51
|
+
artifact directories next. Treat the Workspace as the canonical source; do
|
|
52
|
+
not infer reusable material from generated agent output.
|
|
16
53
|
2. Elicit the user's needs one decision at a time. Establish the kind of work,
|
|
17
54
|
the reusable facts or workflow they want, and whether existing material
|
|
18
55
|
already satisfies the need. Ask instead of inventing personal preferences,
|
|
19
|
-
project facts,
|
|
56
|
+
project facts, agent preferences, credentials, or machine paths.
|
|
20
57
|
3. Create the smallest useful artifact set. This release accepts Profile Context
|
|
21
58
|
and shared Skills for Antigravity, plus portable Context and Skills for Codex,
|
|
22
59
|
Claude Code, Grok, OpenCode, and Pi. Put standing facts in
|
|
23
|
-
Context Modules and reusable procedures in Skills.
|
|
60
|
+
Context Modules and reusable procedures in Skills. Author each artifact to
|
|
61
|
+
the Workspace contract, which states every rule validation enforces —
|
|
62
|
+
Context Module identity and delivery, the Skill
|
|
63
|
+
package rules including the standard `disable-model-invocation` field, and
|
|
64
|
+
the Profile shape (file name is the ID; the file holds exactly `context`
|
|
65
|
+
and `skills`). A Profile needs at least
|
|
24
66
|
one supported artifact (Context, Skills, or both); Context is not mandatory—a
|
|
25
|
-
Skills-only Profile is valid.
|
|
26
|
-
`metadata.agent-profile-kit.model-invocation: disabled` (default is
|
|
27
|
-
`allowed`); do not leave Host-native `disable-model-invocation` in
|
|
28
|
-
Workspace source (Adapters project that field for Claude, Grok, and Pi). Profiles
|
|
29
|
-
contain exactly `id`, `context`, and `skills`. Do not create a new artifact merely because
|
|
67
|
+
Skills-only Profile is valid. Do not create a new artifact merely because
|
|
30
68
|
a directory exists, and do not invent Agents, Hooks, or Tools
|
|
31
69
|
for this release.
|
|
32
70
|
4. Preserve boundaries.
|
|
33
71
|
- **Workspace** owns reusable cross-project Profiles and artifacts as the
|
|
34
72
|
single canonical source. That includes Profile-selected material and
|
|
35
73
|
unselected universal artifacts (useful across every directory or kind of
|
|
36
|
-
work). Unselected does not mean “belongs in
|
|
74
|
+
work). Unselected does not mean “belongs in agent config.”
|
|
37
75
|
- **Local Configuration** (`~/.agents/agent-profile-kit/config.yaml`) owns
|
|
38
76
|
machine-local Project Bindings and the explicit Workspace path. Current
|
|
39
77
|
schema version 2 requires one existing absolute or home-relative Workspace
|
|
40
78
|
path and each binding names one existing project root, one Profile, and a
|
|
41
|
-
supported
|
|
79
|
+
supported agent set (`antigravity`, `codex`, `claude`, `grok`, `opencode`, or `pi`); agent
|
|
42
80
|
order and duplicate entries normalize at ingestion. A version-1 configuration without
|
|
43
|
-
`workspace` is legacy migration input only; run `apkit init
|
|
44
|
-
or binding-recording command.
|
|
81
|
+
`workspace` is legacy migration input only; run `apkit init <path>` before any desired-state
|
|
82
|
+
or binding-recording command (ADR-0049).
|
|
45
83
|
- **Project repositories** own project facts and repository-owned instructions.
|
|
46
|
-
- **
|
|
47
|
-
|
|
48
|
-
|
|
84
|
+
- **Agents** own authentication, trust, approvals, plugins, sessions, and
|
|
85
|
+
agent preferences. User-managed native global Skill delivery (including
|
|
86
|
+
agent-root symlinks into Workspace source) is agent configuration, not
|
|
49
87
|
Agent Profile Kit–owned state: outside Project Bindings and Installation
|
|
50
88
|
Manifests; `update` / `uninstall` never adopt or remove those paths. v1 does
|
|
51
|
-
not manage global
|
|
89
|
+
not manage global agent delivery. Agents own Skill discovery, precedence,
|
|
52
90
|
deduplication, collision diagnostics, and resolution across project,
|
|
53
91
|
personal, package, plugin, extension, and compatibility sources.
|
|
54
92
|
- **Generated output** is disposable Installer-owned material inside bound
|
|
55
93
|
projects. Never copy it back into the Workspace as source.
|
|
56
94
|
- Same-identity Skill material outside an exact planned output destination is
|
|
57
|
-
|
|
95
|
+
agent resolution, not an Agent Profile Kit blocker. Concrete agent settings
|
|
58
96
|
that disable planned output may warn; exact Output Ownership Conflicts and
|
|
59
97
|
unsupported capability remain blockers.
|
|
60
98
|
5. Install Profiles into Projects—either hand-edit `config.yaml` and run
|
|
61
|
-
`apkit update`, or run `apkit install <profile> [project] --
|
|
62
|
-
(cwd when project is omitted; at least one explicit `--
|
|
99
|
+
`apkit update`, or run `apkit install <profile> [project] --agent <agent>…`
|
|
100
|
+
(cwd when project is omitted; at least one explicit `--agent` required),
|
|
63
101
|
which records the selection and installs the verified output in one
|
|
64
102
|
action after an interactive confirmation (`--auto-confirm` answers it
|
|
65
103
|
non-interactively). Do not
|
|
66
|
-
invent project roots or
|
|
67
|
-
Reject wildcards, recursive scans,
|
|
104
|
+
invent project roots or agent lists. Use only explicit paths the user confirms.
|
|
105
|
+
Reject wildcards, recursive scans, agent auto-detection, all-agents defaults,
|
|
68
106
|
per-session selection, and Profile version pins. Installing a different
|
|
69
|
-
Profile or
|
|
107
|
+
Profile or agent set for the same project replaces the installation in the
|
|
70
108
|
same action; replacing or deleting independently changed generated files
|
|
71
109
|
needs `--replace-changed`/`--remove-changed`. After installing, continue
|
|
72
110
|
with validate/status/update. To remove selected installations, use
|
|
73
111
|
`apkit uninstall --here`, `uninstall --project <path>`, or `uninstall --all`
|
|
74
112
|
(explicit scope plus `--auto-confirm` non-interactively, with `--profile`,
|
|
75
|
-
`--
|
|
113
|
+
`--agent`, and `--remove-changed` as needed); it forgets each fully removed Project's
|
|
76
114
|
recorded selection so a later update does not reinstall it, matches
|
|
77
115
|
existing paths canonically, and permits missing-path recovery only by exact
|
|
78
116
|
authored spelling. To keep generated files in place instead, remove the
|
|
79
117
|
Project's entry from Local Configuration by hand and let the next update
|
|
80
118
|
reconcile the leftovers.
|
|
81
|
-
6. Validate before updating. Context Modules
|
|
82
|
-
|
|
83
|
-
|
|
119
|
+
6. Validate before updating. Context Modules are plain Markdown files whose
|
|
120
|
+
path under `context/` (without `.md`) is their ID, and
|
|
121
|
+
Profiles are named by their file name and contain `context` and `skills`
|
|
122
|
+
only; the Profile lists are
|
|
123
|
+
the only source of what is installed (no Dependencies, no sidecar files).
|
|
124
|
+
Run `apkit validate`, review
|
|
84
125
|
the concise fleet outcome from `apkit status --all`, and ask before updating
|
|
85
126
|
all configured Project Bindings with `apkit update --all`. Use Project-scoped
|
|
86
127
|
`update [project]` only when the user intends one bound Project. Use
|
|
87
128
|
`apkit status --verbose` or `apkit update --verbose` when complete
|
|
88
|
-
per-output diagnostics
|
|
89
|
-
|
|
129
|
+
per-output diagnostics or composed Context are needed. For automation, add
|
|
130
|
+
`--json` on those two commands: exit `0` means
|
|
90
131
|
no tool error and no blockers (JSON `outcome` may still be `attention`),
|
|
91
132
|
exit `1` is a tool error, and exit `2` means blockers. The current Workspace
|
|
92
133
|
schema version is 1.
|
|
93
134
|
7. After update, the user launches Antigravity, Codex, Claude, Grok, OpenCode, or Pi
|
|
94
135
|
natively in the bound project. Do not claim that Agent Profile Kit manages
|
|
95
|
-
|
|
136
|
+
agent authentication, trust, approvals, plugins, or sessions. Antigravity
|
|
96
137
|
bindings load deterministic always-on Context rules under `.agents/rules/`
|
|
97
138
|
and shared `.agents/skills/<Artifact ID>` packages after the user's native
|
|
98
139
|
trust step. OpenCode bindings load Profile Context via `.opencode/opencode.jsonc`
|
|
@@ -100,7 +141,7 @@ Use this workflow when helping a person author their Workspace and bind projects
|
|
|
100
141
|
packages after restarting running sessions. Pi bindings load the generated
|
|
101
142
|
`.pi/APPEND_SYSTEM.md` and shared `.agents/skills/<Artifact ID>` packages after
|
|
102
143
|
Pi's native trust boundary; packages, extensions, and other Skill sources coexist
|
|
103
|
-
through Pi
|
|
144
|
+
through Pi agent resolution. For non-Git projects, remind the user that Codex must
|
|
104
145
|
launch from the exact bound root.
|
|
105
146
|
8. Use `apkit status` for the bound Project containing cwd, pass one explicit
|
|
106
147
|
Project root, or use `apkit status --all` for the fleet. Its concise result
|
|
@@ -117,7 +158,7 @@ Use this workflow when helping a person author their Workspace and bind projects
|
|
|
117
158
|
`apkit uninstall` with an explicit scope removes only output whose Installation Receipt
|
|
118
159
|
and hashes prove Agent Profile Kit ownership and forgets each fully removed
|
|
119
160
|
Project's recorded selection; it preserves the Workspace,
|
|
120
|
-
unselected Projects, global
|
|
161
|
+
unselected Projects, global agent configuration, and repository-owned files.
|
|
121
162
|
Never use hand-editing as a substitute for output cleanup: hand-editing the
|
|
122
163
|
selection out of Local Configuration keeps generated files in place for the
|
|
123
164
|
next update to reconcile, while `uninstall` deletes them.
|