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

3.7 KiB

name, description
name description
configure-ink-agent 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.

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:

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.