Skip to content

Skills

A skill is a named set of instructions the agent can pull in on demand. Instead of pasting the same guidance into every prompt, you write it once as a skill, and the agent loads it when the task calls for it.

What skills are good for

  • Repeatable procedures — "how we cut a release", "how to add a database migration in this project".
  • House style and conventions — coding standards, commit message format, review checklist.
  • Domain knowledge — background the agent needs for a particular area of your codebase.

A skill stays out of the way until it's relevant, so it doesn't clutter every conversation.

How a skill is written

A skill is a Markdown file with a short front-matter header — a name and a one-line description — followed by the instructions themselves. The description is what the agent uses to decide when the skill is relevant, so make it clear and specific.

---
name: cut-release
description: Steps to tag and publish a new release of this project.
---

1. Make sure the working tree is clean and tests pass.
2. Bump the version in the manifest.
3. Update the changelog.
4. Tag the release and push.

Where skills live

Place skill files in a directory gdc scans, and point to it in configuration:

~/.gdc/config.toml
[skills]
paths = ["~/gdc-skills", "./.gdc/skills"]

Project-local skills (under the project's .gdc/) are a good way to share project-specific procedures with everyone who works on it.

Skills vs. memory vs. output styles

These three shape the agent in different ways:

Purpose
Skill A procedure or knowledge set the agent loads when relevant.
Memory Durable facts kept in view across sessions.
Output style How the agent phrases its replies.