awesome-goose

A curated catalog of Agent Skills, Tool contracts, capability packages, and official local-model metadata compatible with Goose.

This repository is intended to become the public ecosystem registry for Goose capabilities. It separates three concepts:

• Tool: a capability interface exposed by Goose Runtime.
• Skill: a reusable agent behavior/workflow that uses Tools.
• Capability Package: an installable distribution unit.

Architecture model

Community Skill
        |
        | documents exact Tool use
        v
Goose Tool Contract
        |
        v
Goose ToolRouter / Harness
        |
        v
Native Runtime Implementation

The repository contains the public contract and distribution metadata. Goose app keeps security-sensitive runtime implementations, native frameworks, permissions, and execution boundaries.

Repository layout

awesome-goose/
├── artifacts/
│   └── skills/
├── models/
│   ├── README.md
│   ├── catalog.json
│   └── schema.json
├── tools/
│   ├── README.md
│   ├── schema.json
│   ├── snapshot.schema.json
│   ├── goose-tool-snapshot.json
│   ├── core/
│   ├── system/
│   └── tool-os/
├── skills/
│   ├── index.json
│   └── */
├── catalog.json
├── templates/
├── scripts/
├── tests/
└── CONTRIBUTING.md

The registry pins one Goose source revision in tools/goose-tool-snapshot.json. Its 90 exact Tool names are mirrored across 26 grouped contracts and covered by 12 focused workflow Skills. The committed Skill ZIPs are deterministic build outputs whose SHA-256 digests are enforced against Catalog metadata.

Local Model Registry

models/catalog.json is the official, manually maintained allowlist used by Goose's on-device MLX model Provider. Entries pin one immutable upstream revision plus the size and SHA-256 digest of every required snapshot file. Model tags are also maintained here and may be changed without an App release. The registry contains metadata only; model weights remain hosted and licensed by their upstream publishers.

See models/README.md for the contract and maintenance checklist.

Tool Registry

tools/ describes capabilities available from Goose Runtime.

Example:

{
  "schemaVersion": 1,
  "identifier": "goose.system.calendar",
  "type": "system-tool",
  "description": "Expose Calendar capabilities from the pinned Goose Runtime contract.",
  "actions": [
    {
      "name": "createCalendarEvent",
      "description": "Create a calendar event",
      "effect": "write",
      "risk": "high",
      "requiredInput": ["title", "startDate"],
      "optionalInput": ["endDate", "notes", "location", "calendarReference"],
      "permissions": ["calendar"],
      "availability": {
        "mode": "bundled-skill",
        "runtimeIdentifier": "calendar"
      }
    }
  ],
  "runtime": "native-goose"
}

Tool definitions do not contain Swift implementation code. An action name must exactly match the name exported by Goose Runtime; documentation-only aliases are not Tool contracts.

Skills

Skills are installable packages containing prompts, resources, and optional sandbox logic.

Example:

my-skill/
├── SKILL.md
├── goose.json
├── references/
└── assets/

A Skill must document the exact Goose Tools used by its workflow in SKILL.md, for example:

## Required Goose Tools

- `createCalendarEvent`
- `queryCurrentWeather`

Current Goose package manifests are schema V1 or V2 and deliberately reject unknown top-level keys. Do not add requires or requires.tools to goose.json; it will make the package invalid. The repository-level skills/index.json provides machine-verifiable Tool-to-Skill coverage without changing the runtime package format. Goose still resolves and executes available Tools through its own Provider, Harness, policy, approval, and ToolRouter boundaries.

Built-in capabilities

Native iOS capabilities such as Calendar, Reminders, Contacts, Weather, Maps, Message/Mail, Health, Notifications, Music, Home, PDF, Media, and Photos & Vision are represented as 13 independent bundled System capability packages. Catalog presence and public contracts still do not bypass runtime enablement, OS permission, device, account, entitlement, or policy gates.

Their execution remains inside Goose because they depend on Apple frameworks, OS permissions, and Goose safety boundaries.

Home is intentionally feature-gated unavailable: production HomeKit support and the required entitlement are not enabled. Its public contract reserves the exact Tool surface, while Goose fails closed and never substitutes a remote execution path.

Skill compatibility

See:

• templates/ for package templates.
• CONTRIBUTING.md for submission rules.

Existing Agent Skills can be adapted by adding supported Goose metadata and an exact Tool section to SKILL.md.

Validation

The validator has two modes:

• foundation mode validates the schemas, current contracts, package templates, and Catalog structure;
• final coverage mode activates automatically when the pinned Tool snapshot and skills/index.json are both present, then requires exact contract parity, 100% Tool-to-Skill coverage, Catalog/manifest agreement, and verified committed release ZIPs.

Run both checks without writing repository artifacts:

PYTHONDONTWRITEBYTECODE=1 python3 scripts/validate_registry.py --root .
PYTHONDONTWRITEBYTECODE=1 python3 scripts/validate_registry.py --root . --require-final-coverage
PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_*.py'

Maintainers rebuild deterministic Skill ZIPs with python3 scripts/build_skill_artifacts.py --root .. The current release URLs pin the exact source commit that contains each validated artifact. They are immutable source-distribution URLs, not GitHub Release assets; a formal release may replace them with separately published immutable assets.

License

See LICENSE.