---
name: apx-skill-builder
scope: internal
description: Author a new APX skill — file location, frontmatter (name, description, scope), body style, on-demand loader. Load when creating or adding a skill to APX.
---

# apx-skill-builder

A **skill** is a Markdown file the super-agent loads on demand. Inspired by Anthropic's skill-creator, simplified for APX's daemon-served model.

## When to make a skill

- **Yes**: topic is bounded (a tool, a config domain, a recurring workflow), instructions need >50 tokens to be safe, not every conversation needs them.
- **No**: one-off explanations, casual chat, anything fitting in 2-3 lines of the base prompt.

## File location

Scanned in priority order:

1. `<repo>/.apc/skills/<slug>/SKILL.md` — project-scoped.
2. `~/.apx/skills/<slug>/SKILL.md` — user-global.
3. `<repo>/skills/<slug>/SKILL.md` in the APX source — bundled.

Layouts: `<slug>/SKILL.md` (dir-style, preferred — supports `references/`, `assets/`) or `<slug>.md` (flat, fine for short).

## Frontmatter

```yaml
---
name: my-skill
description: One-sentence trigger for the super-agent. Include user-phrases that should cause it to load. Short — appears in skill listings.
scope: public   # public (synced globally) | internal (repo/dev-only) | optional (not pushed by default)
---
```

`description` is what the model sees when deciding `load_skill`. Write it as the *trigger condition*, not a body summary. Omit `scope` → treated as public.

**Good**: `"How to register an MCP server. Load BEFORE running 'apx mcp add' — three scopes, gotchas with stdio commands, secrets handling."`
**Bad**: `"This skill describes APX's MCP system."` (no trigger).

## Body style

Opinionated, concrete, anti-example-driven. Read a sibling `skills/apx-*` before writing yours. Shape:

1. **One-paragraph "what this is"** — no preamble.
2. **Concrete CLI calls** — most common first.
3. **Schema / shape** if files/config are involved.
4. **Anti-examples** — at least one "DON'T" with reason. Stops the model inventing flags.
5. **Open questions / footnotes** if the surface is incomplete.

Length budget: 80-200 lines. Longer → split or move scripts to `<slug>/scripts/`.

## Loader + commands

```js
// Model emits:
load_skill({ slug: "my-skill", project_path: "/abs/path/optional" })
```

Returns the full body for the current turn; not persisted.

```bash
apx skills list          # this project's .apc/skills/ (run from project root)
apx skills sync          # push bundled/public skills to global skill dir
apx skills status        # what's installed vs available
```

## Workflow

```bash
# 1. Pick scope:
#    .apc/skills/<slug>/SKILL.md   (project)
#    ~/.apx/skills/<slug>/SKILL.md (user-global)
#    skills/<slug>/SKILL.md        (bundled, in repo)

# 2. Write
mkdir -p skills/my-thing
$EDITOR skills/my-thing/SKILL.md

# 3. Verify (daemon picks up on next listSkills() — no restart)
apx skills list | grep my-thing

# 4. Pre-test with the super-agent (default target)
apx exec "Load the my-thing skill and summarize it in 3 bullets"
```

## Anti-examples

```yaml
---
# DON'T omit description — the model can't trigger on slug alone.
name: vague-stuff
---

# DON'T pile general advice. ONE topic per skill. A grab-bag is dead weight.

# DON'T duplicate apx --help. Skills explain WHEN and WHY, not WHAT.
# Teach the decision tree ("shared vs runtime", "what to do if it fails").

# DON'T leave TODOs in production skills. Delete incomplete sections;
# move them to spec/backlog/.
```

## Optional scaffolding

```
skills/my-thing/
├── SKILL.md           ← always
├── references/        ← markdown the skill cites
├── assets/            ← images, schemas, sample inputs
└── scripts/           ← shell/node helpers the skill shells out to
```

Only `SKILL.md` is auto-loaded. Reference others by relative path from the body ("see references/examples.md").

## Existing skills — mimic the style

`skills/apx-routine`, `apx-mcp`, `apx-task`, `apx-telegram`, `apx-runtime`, `apx-sessions`, `apx-voice`, `apx-agent`, `apx-project`. Pick the closest topic, copy the structure.

## Maintainer contract

`AGENTS.md` rule 6 (regenerated by `apx agent add/import`) requires skills to move in lockstep with feature changes. Update or add the skill in the same PR as the behavior change — especially `skills/apx-*`.

## Don't

- Don't ship without frontmatter `description` — loader works, trigger is silent.
- Don't put secrets inside skills. They're read aloud by an LLM.
- Don't reference machine-only paths — use `<repo>` or `~/.apx` placeholders.
- Don't write in third person. The reader is the model. Write to it.