Files
ink-skills/skills/configure-ink-agent/SKILL.md
T
2026-08-11 16:24:21 +02:00

98 lines
3.7 KiB
Markdown

---
name: configure-ink-agent
description: >-
Use when the user asks to create, configure, audit, or explain an Ink subagent
definition, including its model, read/write scheduling class, or conjunctive
policy file. Produce the smallest startup-frozen agent definition and policy
boundary. Do not use for ordinary delegation, Ink implementation work, or
generic prompt/role authoring outside Ink.
---
# Configure an Ink agent
## One job
Define one inspectable Ink subagent identity without confusing scheduling class,
model choice, and authority.
```text
agent definition -> access class -> relative policy conjunct -> frozen child snapshot
```
## Trigger boundary
Use for explicit requests about files in `$INK_AGENT_HOME` (default
`$HOME/.ink/agents`) or a project `.ink/agents` directory, or when deciding the
policy of a named Ink child.
Do not load for launching an existing child, editing Ink source, installing
skills, or creating an external executable. `ink-cli` owns host audits;
`create-ink-agent-cli-tool` owns permission-bearing external tools.
## Contract
An agent definition is a plain text file with headers followed by one prompt
body:
```text
name: Frontend specialist
model: design
access: write
policy: frontend.policy
Implement the bounded frontend task and return proof.
```
- `name` is the human-facing identity.
- `model` is a startup-resolved alias such as `default`, `cheap`, `think`, or a
configured alias.
- `access` is mandatory: `read` or `write`.
- `policy` is optional and relative to the definition file. Its bytes become an
additional conjunct; it can narrow inherited authority but never broaden it.
- Unknown headers, unknown access values, and unreadable policy files fail
visibly.
`access` schedules actors; it does not grant tools:
- `read` children may overlap and receive an immutable host floor with no command,
file-mutation, lifecycle-mutation, or delegation authority.
- `write` children are exclusive, operate in the canonical parent cwd, pause
parent effects, and still receive only their inherited-and-narrowed effective
policy.
Agent definitions and referenced policy files are frozen at orchestrator startup.
Editing either requires restarting Ink before the change can take effect. Child
snapshots never reread cwd policy, and nested delegation is removed by the host.
## Decision loop
1. Choose `read` unless the child must produce a real effect.
2. Choose the smallest model alias that fits the specialist job.
3. Omit `policy` when the inherited parent policy is already the exact boundary.
4. Otherwise write one nearby policy file using ordinary Ink policy rows; include
only authority the role needs and rely on conjunctive narrowing.
5. Inspect the startup-frozen catalog with the operator surface before relying on
the role. Restart Ink after definition or policy changes.
6. Prove one allowed path and one denied near miss through the actual child path.
## Refusals
- Do not put policy rows in the prompt body.
- Do not use `access: write` as a substitute for command/tool policy.
- Do not grant `tool delegate` to a child; Ink removes nested delegation anyway.
- Do not create worktrees, copied workspaces, merge protocols, or per-role policy
DSLs.
- Do not use environment variables as a second mutable agent-policy channel.
## Behavior smoke
Positive: “Create a frontend writer child with only the admitted formatter and
file mutation tools” loads this skill and separates `access: write` from its
relative policy conjunct.
Negative: “Ask the existing reviewer to inspect this diff” does not load this
skill; it is ordinary delegation.
Safety: a reader request that asks for `run` or file writes remains denied even if
its role policy mentions them.