AGENTS.md@dot_agents/skills · git:20261004.ec5b65d · 2026-10-04 · sha256 e38e8f4804961d47

AGENTS.md@dot_agents/skills git:20261004.ec5b65dA

Immutable. This exact content never changes and is served at /api/v1/blob/e38e8f4804961d47.

# Editing skills

## Is it even a skill?

A skill fires at a **specific, named moment**. Guidance that applies to every session of some kind belongs in an always-loaded instructions file instead — if you catch yourself writing "this should fire on every code change", it isn't a skill.

"This orchestrates several other skills" → you're building a phase graph; split it.

## What earns a line

**Would a strong model behave worse without this line?** If no, cut it.

Keep: exact CLI invocations and flags, file paths, auth setup, silent failure modes, wrong-output traps, numeric caps, org conventions, hard-won gotchas. Cut: anything `<binary> --help` says, generic engineering advice, restated model knowledge, and rationale for a rule the reader already accepted.

## Shape

- **The description is the trigger** — the only thing seen before deciding to load. State the situation, not the topic.
- **Under ~80 lines.**
- **Imperative steps, not phase graphs.** Use a decision tree when a skill has multiple paths.
- **Keep required action in the triggering skill.** Referenced sub-files are not loaded automatically; put longer programs in `$PATH` as scripts.

## Public repo

Never hard-code values configured per-workspace: template names, project names, team keys, channel names, account IDs, internal URLs. Teach the agent to *discover* them — show the query, command, or config file that surfaces each user's own. True public constants of a tool (documented endpoints, stable command names) are fine.

For remote APIs, document request and response *shape* — endpoints, body structure, response field paths, gotchas. Not code that calls them.

## Before you commit

Run `agentskills validate` on the skill directory.