15 Commits

  • docs: fix name field character range to include digits
    The body text described valid characters as '(a-z)' but the summary
    table above correctly states 'Lowercase letters, numbers, and hyphens
    only'. Updated the range to '(a-z, 0-9)' for consistency.
  • Point "progressive disclosure" links at specification.mdx
    Two links in `best-practices.mdx` and `optimizing-descriptions.mdx`
    pointed at `/what-are-skills#how-skills-work`, blocking the eventual
    removal of `what-are-skills.mdx`. Redirect them to the existing
    `## Progressive disclosure` section in `specification.mdx`, which is a
    more natural reference target for the concept.
    
    Also expand that section's lead-in from "Skills should be structured for
    efficient use of context:" to a sentence that names progressive
    disclosure as a loading mechanism, so readers who follow the link land
    on a definition rather than a bare set of structural guidelines. The
    original three-level list and `SKILL.md` line-count guidance are
    preserved unchanged.
    
    Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
  • Use precise type name for allowed-tools field
    Replace "space-delimited list" with "space-separated string" in both the
    frontmatter table and the `allowed-tools` field section. This better
    reflects that the value is a YAML scalar, per the given example.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Add runtime version example to compatibility field
    Add a third example showing a Python version requirement alongside `uv`.
    This complements the existing examples (product targeting and system
    tool requirements) by demonstrating version-pinned runtime requirements
    — the kind of non-obvious constraint that the `compatibility` field is
    useful for.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Remove redundant intro sentence from specification doc
    The frontmatter `description` already serves as the page subtitle in
    Mintlify, so the "This document defines the Agent Skills format." line
    was just restating it.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Add ... entry to directory tree in specification doc
    The directory listing is not exhaustive — skill authors can include
    other files and subdirectories beyond those shown. Adding a `...` entry
    makes this explicit.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Move frontmatter field table above examples in specification doc
    Place the field constraints table immediately after the `Frontmatter`
    heading so readers see the reference before the examples. Also remove
    "(required)" from the heading, wrap examples in a `<Card>`, and relabel
    "With optional fields:" to "Example with optional fields:".
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Add SKILL.md filename annotations to code blocks in specification doc
    The fenced code blocks showing `SKILL.md` content were labeled as `yaml`
    or plain `markdown`. Changing them to `markdown SKILL.md` adds a
    filename hint and more accurately reflects that they contain full
    `SKILL.md` snippets (including `---` frontmatter delimiters), not just
    raw YAML.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Wrap examples in <Card> components in specification doc
    The `####` field headings didn't stand out enough amongst all the code
    blocks, making the page hard to scan. Wrapping each field's examples in
    a `<Card>` draws a border around them and adds padding, so each
    subsection looks more contained instead of bleeding into the next. Also
    bolds the example labels within each card.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Expand directory tree in specification doc
    Show optional directories (`scripts/`, `references/`, `assets/`)
    directly in the directory tree with inline annotations, replacing the
    separate `<Tip>` block.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Improve clarity of name field constraints in specification doc
    Place inline code examples next to the terms they describe (e.g.,
    "`a-z`" next to "alphanumeric characters") rather than grouping them at
    the end. Also add the word "hyphen" before the code-formatted `-` for
    readability.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Format directory and file names as inline code in specification doc
    Wrap `SKILL.md`, `scripts/`, `references/`, and `assets/` headings in
    backticks for consistency with the rest of the document, which already
    uses inline code formatting for these names in body text.
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
  • Fix example description to include "when to use" guidance
    The example `description` values in what-are-skills.mdx and
    specification.mdx only described what the skill does, but omitted
    when to use it. This contradicted the spec's own guidance that
    description should cover both. Added a "Use when..." clause while
    keeping the line short enough to avoid clipping in the rendered
    code block on the docs site.
  • Document reference SDK (#3)
    * Document reference SDK
    
    * Update docs/integrate-skills.mdx
    
    Co-authored-by: Keith Lazuka <klazuka@anthropic.com>
    
    ---------
    
    Co-authored-by: Keith Lazuka <klazuka@anthropic.com>