Files
github-spec-kit/extensions/template/extension.yml
Manfred Riem 40e48ed22c feat: add category and effect as first-class fields in extension schema (#2899)
* feat: add category and effect as first-class fields in extension schema

Add `category` and `effect` as optional fields in the extension schema
(`extension.yml`) and community catalog (`catalog.community.json`).

Schema changes:
- Valid categories: docs, code, process, integration, visibility
- Valid effects: read-only, read-write
- Both fields are optional (backward-compatible with existing extensions)
- Validation raises ValidationError for invalid values when present

Propagation:
- Added `category` and `effect` to all 108 entries in catalog.community.json
  (populated from the existing docs/community/extensions.md table)
- Updated extension template with commented category/effect fields
- Updated add-community-extension skill with new JSON template fields
- Updated `specify extension info` CLI output to display category/effect
- Added properties to ExtensionManifest class

Tests:
- test_valid_category: all 5 category values pass
- test_valid_effect: both effect values pass
- test_invalid_category: invalid value raises ValidationError
- test_invalid_effect: invalid value raises ValidationError
- test_category_and_effect_optional: omitting fields still works

Closes #2874

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* fix: make category free-form, keep effect validated

Category is a free-form string (only validated as non-empty when present),
while effect remains restricted to 'read-only' or 'read-write'.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* fix: address PR review feedback

- Add type guard before 'in' check for effect to prevent TypeError on
  unhashable YAML values (list/dict)
- Comment out category/effect in template so authors must opt in
- Use VALID_EFFECTS constant in test instead of hard-coded values

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* fix: update category docstring to reflect free-form semantics

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* docs: clarify canonical extension effect values

---------

Co-authored-by: Manfred Riem <mnriem@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
2026-06-10 07:44:27 -05:00

114 lines
3.5 KiB
YAML

schema_version: "1.0"
extension:
# CUSTOMIZE: Change 'my-extension' to your extension ID (lowercase, hyphen-separated)
id: "my-extension"
# CUSTOMIZE: Human-readable name for your extension
name: "My Extension"
# CUSTOMIZE: Update version when releasing (semantic versioning: X.Y.Z)
version: "1.0.0"
# CUSTOMIZE: Brief description (under 200 characters)
description: "Brief description of what your extension does"
# CUSTOMIZE: Extension category — describes what the extension operates on
# Common values: docs, code, process, integration, visibility
# category: "process"
# CUSTOMIZE: Extension effect — whether it modifies project files
# One of: read-only | read-write
# effect: "read-write"
# CUSTOMIZE: Your name or organization name
author: "Your Name"
# CUSTOMIZE: GitHub repository URL (create before publishing)
repository: "https://github.com/your-org/spec-kit-my-extension"
# REVIEW: License (MIT is recommended for open source)
license: "MIT"
# CUSTOMIZE: Extension homepage (can be same as repository)
homepage: "https://github.com/your-org/spec-kit-my-extension"
# Requirements for this extension
requires:
# CUSTOMIZE: Minimum spec-kit version required
# Use >=X.Y.Z for minimum version
# Use >=X.Y.Z,<Y.0.0 for version range
speckit_version: ">=0.1.0"
# CUSTOMIZE: Add MCP tools or other dependencies
# Remove if no external tools required
tools:
- name: "example-mcp-server"
version: ">=1.0.0"
required: true
# Commands provided by this extension
provides:
commands:
# CUSTOMIZE: Define your commands
# Pattern: speckit.{extension-id}.{command-name}
- name: "speckit.my-extension.example"
file: "commands/example.md"
description: "Example command that demonstrates functionality"
# Optional: Add aliases in the same namespaced format
aliases: ["speckit.my-extension.example-short"]
# ADD MORE COMMANDS: Copy this block for each command
# - name: "speckit.my-extension.another-command"
# file: "commands/another-command.md"
# description: "Another command"
# CUSTOMIZE: Define configuration files
config:
- name: "my-extension-config.yml"
template: "config-template.yml"
description: "Extension configuration"
required: true # Set to false if config is optional
# CUSTOMIZE: Define hooks (optional)
# Remove if no hooks needed
hooks:
# Hook that runs after /speckit.tasks
after_tasks:
command: "speckit.my-extension.example"
optional: true # User will be prompted
prompt: "Run example command?"
description: "Demonstrates hook functionality"
condition: null # Future: conditional execution
# ADD MORE HOOKS: Copy this block for other events
# after_implement:
# command: "speckit.my-extension.another"
# optional: false # Auto-execute without prompting
# description: "Runs automatically after implementation"
# MULTIPLE COMMANDS ON ONE EVENT: use a list of entries.
# Add optional `priority` (integer >= 1, default 10) to order them, lowest first.
# after_plan:
# - command: "speckit.my-extension.verify"
# priority: 5
# - command: "speckit.my-extension.report"
# priority: 10
# CUSTOMIZE: Add relevant tags (2-5 recommended)
# Used for discovery in catalog
tags:
- "example"
- "template"
# ADD MORE: "category", "tool-name", etc.
# CUSTOMIZE: Default configuration values (optional)
# These are merged with user config
defaults:
# Example default values
feature:
enabled: true
auto_sync: false
# ADD MORE: Any default settings for your extension