Skills

A skill is a short SKILL.md document — YAML frontmatter with a name: and description:, then instructions. Skills carry reusable rules into coding-runtime workers at the moment they run. They are not the agent, and they do not own the process.

Manage them under Config → Skills or the JSON API:

Method	Path
GET / POST	/api/skills
PATCH / DELETE	/api/skills/{id}

Builtin vs user skills

• Builtin skills are compiled into the agent binary. They appear with a synthetic id (builtin:<name>), origin: builtin, and editable: false. You can view them but not edit, delete, or override them by name.
• User skills are stored in the database. Create one from its full SKILL.md text (the backend parses the name: field), and tag it to one or more worker-spawning steps.

Builtin skill names:

Skill	Purpose
clean-code	Testability and maintainability constraints for implementation
steelframe-harness	How the harness pack works; do not bypass hooks
steelframe-sdlc	The bound feature → staging → production flow
ubiquitous-language	Use the project’s shared domain terms
committed-memory	For steelframe:memory issues, edit only docs/memory/
grafana	Investigate with gcx (metrics, logs, alerts)
kubectl	Correlate with the cluster (read-only)

Where skills run

Default step bindings (compiled in; user skills merge additively on top):

Step	Default skills
task_lifecycle → waiting_for_worker	clean-code, steelframe-harness, steelframe-sdlc, ubiquitous-language, committed-memory
task_lifecycle → waiting_for_ci_fix_worker	the same five
investigate_incidents → waiting_for_investigator	grafana, kubectl
task_lifecycle → waiting_for_rebase_worker	none (deliberately)

The step picker only offers steps that actually spawn workers: waiting_for_worker, waiting_for_rebase_worker, waiting_for_ci_fix_worker, and waiting_for_investigator.

How skills load

At spawn, the agent writes the step’s skills into the active coding runtime’s skill directory inside the worker sandbox:

• Claude Code: <work_dir>/.claude/skills/<name>/SKILL.md
• Grok: <work_dir>/.grok/skills/…
• Codex: <work_dir>/.codex/skills/… plus a short AGENTS.md index
• OpenCode: .opencode/skills/…
• Pi: <work_dir>/.pi/skills/… (sandbox settings.json sets defaultProjectTrust: "always")

Because headless discovery by description can miss, the worker prompt also names every skill explicitly: “Before starting, load and follow these skills: …”.

The harness pack’s repo-level hooks and skills apply to humans, laptop CLIs, and workers after harness_converge merges the sf/harness PR. Workers always get the compiled-in skills in their sandbox, even if that PR is unmerged.

Tip

Use a user skill to add project-specific rules to implement or CI-fix without forking the harness. Tag it to waiting_for_worker.

Gotchas

• Builtin ids start with builtin:; any mutation returns 400 builtin skills are read-only.
• You cannot create or rename a user skill to a builtin name; the API rejects it.
• Creating a skill requires non-empty content with a name: frontmatter field.
• Skills are injected into the sandbox per run; editing one affects the next spawn, not a worker already running.