chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,175 @@
|
||||
# Preset System Architecture
|
||||
|
||||
This document describes the internal architecture of the preset system — how template resolution, command registration, and catalog management work under the hood.
|
||||
|
||||
For usage instructions, see [README.md](README.md).
|
||||
|
||||
## Template Resolution
|
||||
|
||||
When Spec Kit needs a template (e.g. `spec-template`), the `PresetResolver` walks a priority stack and returns the first match:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["resolve_template('spec-template')"] --> B{Override exists?}
|
||||
B -- Yes --> C[".specify/templates/overrides/spec-template.md"]
|
||||
B -- No --> D{Preset provides it?}
|
||||
D -- Yes --> E[".specify/presets/‹preset-id›/templates/spec-template.md"]
|
||||
D -- No --> F{Extension provides it?}
|
||||
F -- Yes --> G[".specify/extensions/‹ext-id›/templates/spec-template.md"]
|
||||
F -- No --> H[".specify/templates/spec-template.md"]
|
||||
|
||||
E -- "multiple presets?" --> I["lowest priority number wins"]
|
||||
I --> E
|
||||
|
||||
style C fill:#4caf50,color:#fff
|
||||
style E fill:#2196f3,color:#fff
|
||||
style G fill:#ff9800,color:#fff
|
||||
style H fill:#9e9e9e,color:#fff
|
||||
```
|
||||
|
||||
| Priority | Source | Path | Use case |
|
||||
|----------|--------|------|----------|
|
||||
| 1 (highest) | Override | `.specify/templates/overrides/` | One-off project-local tweaks |
|
||||
| 2 | Preset | `.specify/presets/<id>/templates/` | Shareable, stackable customizations |
|
||||
| 3 | Extension | `.specify/extensions/<id>/templates/` | Extension-provided templates |
|
||||
| 4 (lowest) | Core | `.specify/templates/` | Shipped defaults |
|
||||
|
||||
When multiple presets are installed, they're sorted by their `priority` field (lower number = higher precedence). This is set via `--priority` on `specify preset add`.
|
||||
|
||||
The resolution is implemented three times to ensure consistency:
|
||||
- **Python**: `PresetResolver` in `src/specify_cli/presets.py`
|
||||
- **Bash**: `resolve_template()` in `scripts/bash/common.sh`
|
||||
- **PowerShell**: `Resolve-Template` in `scripts/powershell/common.ps1`
|
||||
|
||||
### Composition Strategies
|
||||
|
||||
Templates, commands, and scripts support a `strategy` field that controls how a preset's content is combined with lower-priority content instead of fully replacing it:
|
||||
|
||||
| Strategy | Description | Templates | Commands | Scripts |
|
||||
|----------|-------------|-----------|----------|---------|
|
||||
| `replace` (default) | Fully replaces lower-priority content | ✓ | ✓ | ✓ |
|
||||
| `prepend` | Places content before lower-priority content (separated by a blank line) | ✓ | ✓ | — |
|
||||
| `append` | Places content after lower-priority content (separated by a blank line) | ✓ | ✓ | — |
|
||||
| `wrap` | Content contains `{CORE_TEMPLATE}` (templates/commands) or `$CORE_SCRIPT` (scripts) placeholder replaced with lower-priority content | ✓ | ✓ | ✓ |
|
||||
|
||||
Composition is recursive — multiple composing presets chain. The `PresetResolver.resolve_content()` method walks the full priority stack bottom-up and applies each layer's strategy.
|
||||
|
||||
Content resolution functions for composition:
|
||||
- **Python**: `PresetResolver.resolve_content()` in `src/specify_cli/presets.py` (templates, commands, and scripts)
|
||||
- **Bash**: `resolve_template_content()` in `scripts/bash/common.sh` (templates only; command/script composition is handled by the Python resolver)
|
||||
- **PowerShell**: `Resolve-TemplateContent` in `scripts/powershell/common.ps1` (templates only; command/script composition is handled by the Python resolver)
|
||||
|
||||
## Command Registration
|
||||
|
||||
When a preset is installed with `type: "command"` entries, the `PresetManager` registers them into all detected agent directories using the shared `CommandRegistrar` from `src/specify_cli/agents.py`.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["specify preset add my-preset"] --> B{Preset has type: command?}
|
||||
B -- No --> Z["done (templates only)"]
|
||||
B -- Yes --> C{Extension command?}
|
||||
C -- "speckit.myext.cmd\n(3+ dot segments)" --> D{Extension installed?}
|
||||
D -- No --> E["skip (extension not active)"]
|
||||
D -- Yes --> F["register command"]
|
||||
C -- "speckit.specify\n(core command)" --> F
|
||||
F --> G["detect agent directories"]
|
||||
G --> H[".claude/commands/"]
|
||||
G --> I[".gemini/commands/"]
|
||||
G --> J[".github/agents/"]
|
||||
G --> K["... (17+ agents)"]
|
||||
H --> L["write .md (Markdown format)"]
|
||||
I --> M["write .toml (TOML format)"]
|
||||
J --> N["write .agent.md + .prompt.md"]
|
||||
|
||||
style E fill:#ff5722,color:#fff
|
||||
style L fill:#4caf50,color:#fff
|
||||
style M fill:#4caf50,color:#fff
|
||||
style N fill:#4caf50,color:#fff
|
||||
```
|
||||
|
||||
### Extension safety check
|
||||
|
||||
Command names follow the pattern `speckit.<ext-id>.<cmd-name>`. When a command has 3+ dot segments, the system extracts the extension ID and checks if `.specify/extensions/<ext-id>/` exists. If the extension isn't installed, the command is skipped — preventing orphan files referencing non-existent extensions.
|
||||
|
||||
Core commands (e.g. `speckit.specify`, with only 2 segments) are always registered.
|
||||
|
||||
### Agent format rendering
|
||||
|
||||
The `CommandRegistrar` renders commands differently per agent:
|
||||
|
||||
| Agent | Format | Extension | Arg placeholder |
|
||||
|-------|--------|-----------|-----------------|
|
||||
| Claude, Kilo Code, opencode, etc. | Markdown | `.md` | `$ARGUMENTS` |
|
||||
| Copilot | Markdown | `.agent.md` + `.prompt.md` | `$ARGUMENTS` |
|
||||
| Gemini, Qwen, Tabnine | TOML | `.toml` | `{{args}}` |
|
||||
|
||||
### Cleanup on removal
|
||||
|
||||
When `specify preset remove` is called, the registered commands are read from the registry metadata and the corresponding files are deleted from each agent directory, including Copilot companion `.prompt.md` files.
|
||||
|
||||
## Catalog System
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["specify preset search"] --> B["PresetCatalog.get_active_catalogs()"]
|
||||
B --> C{SPECKIT_PRESET_CATALOG_URL set?}
|
||||
C -- Yes --> D["single custom catalog"]
|
||||
C -- No --> E{.specify/preset-catalogs.yml exists?}
|
||||
E -- Yes --> F["project-level catalog stack"]
|
||||
E -- No --> G{"~/.specify/preset-catalogs.yml exists?"}
|
||||
G -- Yes --> H["user-level catalog stack"]
|
||||
G -- No --> I["built-in defaults"]
|
||||
I --> J["default (install allowed)"]
|
||||
I --> K["community (discovery only)"]
|
||||
|
||||
style D fill:#ff9800,color:#fff
|
||||
style F fill:#2196f3,color:#fff
|
||||
style H fill:#2196f3,color:#fff
|
||||
style J fill:#4caf50,color:#fff
|
||||
style K fill:#9e9e9e,color:#fff
|
||||
```
|
||||
|
||||
Catalogs are fetched with a 1-hour cache (per-URL, SHA256-hashed cache files). Each catalog entry has a `priority` (for merge ordering) and `install_allowed` flag.
|
||||
|
||||
## Repository Layout
|
||||
|
||||
```
|
||||
presets/
|
||||
├── ARCHITECTURE.md # This file
|
||||
├── PUBLISHING.md # Guide for submitting presets to the catalog
|
||||
├── README.md # User guide
|
||||
├── catalog.json # Official preset catalog
|
||||
├── catalog.community.json # Community preset catalog
|
||||
├── scaffold/ # Scaffold for creating new presets
|
||||
│ ├── preset.yml # Example manifest
|
||||
│ ├── README.md # Guide for customizing the scaffold
|
||||
│ ├── commands/
|
||||
│ │ ├── speckit.specify.md # Core command override example
|
||||
│ │ └── speckit.myext.myextcmd.md # Extension command override example
|
||||
│ └── templates/
|
||||
│ ├── spec-template.md # Core template override example
|
||||
│ └── myext-template.md # Extension template override example
|
||||
└── self-test/ # Self-test preset (overrides all core templates)
|
||||
├── preset.yml
|
||||
├── commands/
|
||||
│ └── speckit.specify.md
|
||||
└── templates/
|
||||
├── spec-template.md
|
||||
├── plan-template.md
|
||||
├── tasks-template.md
|
||||
├── checklist-template.md
|
||||
├── constitution-template.md
|
||||
└── agent-file-template.md
|
||||
```
|
||||
|
||||
## Module Structure
|
||||
|
||||
```
|
||||
src/specify_cli/
|
||||
├── agents.py # CommandRegistrar — shared infrastructure for writing
|
||||
│ # command files to agent directories
|
||||
├── presets.py # PresetManifest, PresetRegistry, PresetManager,
|
||||
│ # PresetCatalog, PresetCatalogEntry, PresetResolver
|
||||
└── __init__.py # CLI commands: specify preset list/add/remove/search/
|
||||
# resolve/info, specify preset catalog list/add/remove
|
||||
```
|
||||
@@ -0,0 +1,357 @@
|
||||
# Preset Publishing Guide
|
||||
|
||||
This guide explains how to publish your preset to the Spec Kit preset catalog, making it discoverable by `specify preset search`.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Prerequisites](#prerequisites)
|
||||
2. [Prepare Your Preset](#prepare-your-preset)
|
||||
3. [Submit to Catalog](#submit-to-catalog)
|
||||
4. [Verification Process](#verification-process)
|
||||
5. [Release Workflow](#release-workflow)
|
||||
6. [Best Practices](#best-practices)
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before publishing a preset, ensure you have:
|
||||
|
||||
1. **Valid Preset**: A working preset with a valid `preset.yml` manifest
|
||||
2. **Git Repository**: Preset hosted on GitHub (or other public git hosting)
|
||||
3. **Documentation**: A preset-scoped README.md that explains how to use **this preset**, including a valid `specify preset add ...` install command (see [Usage README Requirements](#usage-readme-requirements))
|
||||
4. **License**: Open source license file (MIT, Apache 2.0, etc.)
|
||||
5. **Versioning**: Semantic versioning (e.g., 1.0.0)
|
||||
6. **Testing**: Preset tested on real projects with `specify preset add --dev`
|
||||
|
||||
---
|
||||
|
||||
## Prepare Your Preset
|
||||
|
||||
### 1. Preset Structure
|
||||
|
||||
Ensure your preset follows the standard structure:
|
||||
|
||||
```text
|
||||
your-preset/
|
||||
├── preset.yml # Required: Preset manifest
|
||||
├── README.md # Required: Documentation
|
||||
├── LICENSE # Required: License file
|
||||
├── CHANGELOG.md # Recommended: Version history
|
||||
│
|
||||
├── templates/ # Template overrides
|
||||
│ ├── spec-template.md
|
||||
│ ├── plan-template.md
|
||||
│ └── ...
|
||||
│
|
||||
└── commands/ # Command overrides (optional)
|
||||
└── speckit.specify.md
|
||||
```
|
||||
|
||||
Start from the [scaffold](scaffold/) if you're creating a new preset.
|
||||
|
||||
### 2. preset.yml Validation
|
||||
|
||||
Verify your manifest is valid:
|
||||
|
||||
```yaml
|
||||
schema_version: "1.0"
|
||||
|
||||
preset:
|
||||
id: "your-preset" # Unique lowercase-hyphenated ID
|
||||
name: "Your Preset Name" # Human-readable name
|
||||
version: "1.0.0" # Semantic version
|
||||
description: "Brief description (one sentence)"
|
||||
author: "Your Name or Organization"
|
||||
repository: "https://github.com/your-org/spec-kit-preset-your-preset"
|
||||
license: "MIT"
|
||||
|
||||
requires:
|
||||
speckit_version: ">=0.1.0" # Required spec-kit version
|
||||
|
||||
provides:
|
||||
templates:
|
||||
- type: "template"
|
||||
name: "spec-template"
|
||||
file: "templates/spec-template.md"
|
||||
description: "Custom spec template"
|
||||
replaces: "spec-template"
|
||||
|
||||
tags: # 2-5 relevant tags
|
||||
- "category"
|
||||
- "workflow"
|
||||
```
|
||||
|
||||
**Validation Checklist**:
|
||||
|
||||
- ✅ `id` is lowercase with hyphens only (no underscores, spaces, or special characters)
|
||||
- ✅ `version` follows semantic versioning (X.Y.Z)
|
||||
- ✅ `description` is concise (under 200 characters)
|
||||
- ✅ `repository` URL is valid and public
|
||||
- ✅ All template and command files exist in the preset directory
|
||||
- ✅ Template names are lowercase with hyphens only
|
||||
- ✅ Command names use dot notation (e.g. `speckit.specify`)
|
||||
- ✅ Tags are lowercase and descriptive
|
||||
|
||||
### 3. Test Locally
|
||||
|
||||
```bash
|
||||
# Install from local directory
|
||||
specify preset add --dev /path/to/your-preset
|
||||
|
||||
# Verify templates resolve from your preset
|
||||
specify preset resolve spec-template
|
||||
|
||||
# Verify preset info
|
||||
specify preset info your-preset
|
||||
|
||||
# List installed presets
|
||||
specify preset list
|
||||
|
||||
# Remove when done testing
|
||||
specify preset remove your-preset
|
||||
```
|
||||
|
||||
If your preset includes command overrides, verify they appear in the agent directories:
|
||||
|
||||
```bash
|
||||
# Check Claude commands (if using Claude)
|
||||
ls .claude/commands/speckit.*.md
|
||||
|
||||
# Check Copilot commands (if using Copilot)
|
||||
ls .github/agents/speckit.*.agent.md
|
||||
|
||||
# Check Gemini commands (if using Gemini)
|
||||
ls .gemini/commands/speckit.*.toml
|
||||
```
|
||||
|
||||
### 4. Create GitHub Release
|
||||
|
||||
Create a GitHub release for your preset version:
|
||||
|
||||
```bash
|
||||
# Tag the release
|
||||
git tag v1.0.0
|
||||
git push origin v1.0.0
|
||||
```
|
||||
|
||||
The release archive URL will be:
|
||||
|
||||
```text
|
||||
https://github.com/your-org/spec-kit-preset-your-preset/archive/refs/tags/v1.0.0.zip
|
||||
```
|
||||
|
||||
### 5. Test Installation from Archive
|
||||
|
||||
```bash
|
||||
specify preset add --from https://github.com/your-org/spec-kit-preset-your-preset/archive/refs/tags/v1.0.0.zip
|
||||
```
|
||||
|
||||
### Usage README Requirements
|
||||
|
||||
The catalog `documentation` field must point at a README that explains how to use
|
||||
**this preset** — not a product pitch for a broader framework or a separate CLI.
|
||||
|
||||
The submission workflow **mechanically enforces** that the linked README is a GitHub-hosted
|
||||
URL whose path ends with `README.md`, resolves to a readable file, and contains at least one
|
||||
valid `specify preset add ...` command. The remaining items (preferring a preset-scoped README
|
||||
in monorepos, covering the minimum structure) are expectations a human reviewer checks —
|
||||
follow them so your submission isn't sent back for changes.
|
||||
|
||||
- **Point `documentation` at the preset-scoped README.** In a monorepo where the preset
|
||||
lives in a subdirectory (e.g. `presets/<id>/`), link the README inside that directory
|
||||
(`presets/<id>/README.md`) rather than the repository-root README. The root README is
|
||||
often a marketing/overview page; the catalog should surface preset usage instead. The key
|
||||
requirement is that this README is reachable at the `documentation` URL so users can read
|
||||
it *before* downloading the release artifact — it's fine for the same file to also ship
|
||||
inside the release ZIP.
|
||||
- **Include a valid Spec Kit CLI install command** *(enforced)*. The linked README must
|
||||
contain at least one `specify preset add ...` invocation. Preferably use the
|
||||
catalog-install form whose URL matches your Download URL:
|
||||
|
||||
```bash
|
||||
# <download-url> is the same URL you submit as the catalog Download URL —
|
||||
# either the tag archive or a release asset, e.g.:
|
||||
specify preset add --from https://github.com/<org>/<repo>/archive/refs/tags/vX.Y.Z.zip
|
||||
specify preset add --from https://github.com/<org>/<repo>/releases/download/vX.Y.Z/<id>-X.Y.Z.zip
|
||||
```
|
||||
|
||||
`specify preset add <id>` and `specify preset add --dev <path>` are also accepted, but the
|
||||
`--from <download-url>` form is the clearest signal that the README documents this exact
|
||||
preset release.
|
||||
- **Cover the minimum structure** so a reader can decide whether the preset fits:
|
||||
- What the preset does / what it provides
|
||||
- The install command using Spec Kit CLI syntax (above)
|
||||
- When to use it / when not to use it
|
||||
|
||||
A submission whose linked README lacks a valid `specify preset add ...` command **fails
|
||||
validation** (workflow check 2d) and will not be added until corrected.
|
||||
|
||||
---
|
||||
|
||||
## Submit to Catalog
|
||||
|
||||
### Understanding the Catalogs
|
||||
|
||||
Spec Kit uses a dual-catalog system:
|
||||
|
||||
- **`catalog.json`** — Official, verified presets (install allowed by default)
|
||||
- **`catalog.community.json`** — Community-contributed presets (discovery only by default)
|
||||
|
||||
All community presets should be submitted to `catalog.community.json`.
|
||||
|
||||
### 1. Fork the spec-kit Repository
|
||||
|
||||
```bash
|
||||
git clone https://github.com/YOUR-USERNAME/spec-kit.git
|
||||
cd spec-kit
|
||||
```
|
||||
|
||||
### 2. Add Preset to Community Catalog
|
||||
|
||||
Edit `presets/catalog.community.json` and add your preset.
|
||||
|
||||
> **⚠️ Entries must be sorted alphabetically by preset ID.** Insert your preset in the correct position within the `"presets"` object.
|
||||
|
||||
```json
|
||||
{
|
||||
"schema_version": "1.0",
|
||||
"updated_at": "2026-03-10T00:00:00Z",
|
||||
"catalog_url": "https://raw.githubusercontent.com/github/spec-kit/main/presets/catalog.community.json",
|
||||
"presets": {
|
||||
"your-preset": {
|
||||
"name": "Your Preset Name",
|
||||
"id": "your-preset",
|
||||
"description": "Brief description of what your preset provides",
|
||||
"author": "Your Name",
|
||||
"version": "1.0.0",
|
||||
"download_url": "https://github.com/your-org/spec-kit-preset-your-preset/archive/refs/tags/v1.0.0.zip",
|
||||
"sha256": "OPTIONAL: SHA-256 hex digest of the archive above; verified before install",
|
||||
"repository": "https://github.com/your-org/spec-kit-preset-your-preset",
|
||||
"documentation": "https://github.com/your-org/spec-kit-preset-your-preset/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.1.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 3,
|
||||
"commands": 1
|
||||
},
|
||||
"tags": [
|
||||
"category",
|
||||
"workflow"
|
||||
],
|
||||
"created_at": "2026-03-10T00:00:00Z",
|
||||
"updated_at": "2026-03-10T00:00:00Z"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Update Community Presets Table
|
||||
|
||||
Add your preset to the Community Presets table on the docs site at `docs/community/presets.md`:
|
||||
|
||||
```markdown
|
||||
| Your Preset Name | Brief description of what your preset does | N templates, M commands[, P scripts] | — | [repo-name](https://github.com/your-org/spec-kit-preset-your-preset) |
|
||||
```
|
||||
|
||||
Insert your row in alphabetical order by preset **name** (the first column of the table).
|
||||
|
||||
### 4. Submit Pull Request
|
||||
|
||||
```bash
|
||||
git checkout -b add-your-preset
|
||||
git add presets/catalog.community.json docs/community/presets.md
|
||||
git commit -m "Add your-preset to community catalog
|
||||
|
||||
- Preset ID: your-preset
|
||||
- Version: 1.0.0
|
||||
- Author: Your Name
|
||||
- Description: Brief description
|
||||
"
|
||||
git push origin add-your-preset
|
||||
```
|
||||
|
||||
**Pull Request Checklist**:
|
||||
|
||||
```markdown
|
||||
## Preset Submission
|
||||
|
||||
**Preset Name**: Your Preset Name
|
||||
**Preset ID**: your-preset
|
||||
**Version**: 1.0.0
|
||||
**Repository**: https://github.com/your-org/spec-kit-preset-your-preset
|
||||
|
||||
### Checklist
|
||||
- [ ] Valid preset.yml manifest
|
||||
- [ ] Usage README with a valid `specify preset add ...` command, linked from `documentation` (preset-scoped README recommended for monorepos)
|
||||
- [ ] LICENSE file included
|
||||
- [ ] GitHub release created
|
||||
- [ ] Preset tested with `specify preset add --dev`
|
||||
- [ ] Templates resolve correctly (`specify preset resolve`)
|
||||
- [ ] Commands register to agent directories (if applicable)
|
||||
- [ ] Commands match template sections (command + template are coherent)
|
||||
- [ ] Added to presets/catalog.community.json
|
||||
- [ ] Added row to docs/community/presets.md table
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Verification Process
|
||||
|
||||
After submission, maintainers will review:
|
||||
|
||||
1. **Manifest validation** — valid `preset.yml`, all files exist
|
||||
2. **Template quality** — templates are useful and well-structured
|
||||
3. **Command coherence** — commands reference sections that exist in templates
|
||||
4. **Security** — no malicious content, safe file operations
|
||||
5. **Documentation** — the README linked from `documentation` explains how to use *this* preset and contains a valid `specify preset add ...` command
|
||||
|
||||
> **Reviewer note:** the workflow can mechanically check *structure* (the linked README
|
||||
> resolves and contains a valid `specify preset add ...` snippet; when that snippet uses the
|
||||
> `--from <url>` form, its URL must match the submitted download URL exactly — other accepted
|
||||
> forms like `specify preset add <id>` don't reference the download URL at all). Whether the
|
||||
> README genuinely documents *this* preset is partly a content judgment, so a human reviewer
|
||||
> should still confirm the linked doc isn't just a funnel to a separate product or CLI before
|
||||
> approving.
|
||||
|
||||
Once verified, `verified: true` is set and the preset appears in `specify preset search`.
|
||||
|
||||
---
|
||||
|
||||
## Release Workflow
|
||||
|
||||
When releasing a new version:
|
||||
|
||||
1. Update `version` in `preset.yml`
|
||||
2. Update CHANGELOG.md
|
||||
3. Tag and push: `git tag v1.1.0 && git push origin v1.1.0`
|
||||
4. Submit PR to update `version` and `download_url` in `presets/catalog.community.json`
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Template Design
|
||||
|
||||
- **Keep sections clear** — use headings and placeholder text the LLM can replace
|
||||
- **Match commands to templates** — if your preset overrides a command, make sure it references the sections in your template
|
||||
- **Document customization points** — use HTML comments to guide users on what to change
|
||||
|
||||
### Naming
|
||||
|
||||
- Preset IDs should be descriptive: `healthcare-compliance`, `enterprise-safe`, `startup-lean`
|
||||
- Avoid generic names: `my-preset`, `custom`, `test`
|
||||
|
||||
### Stacking
|
||||
|
||||
- Design presets to work well when stacked with others
|
||||
- Only override templates you need to change
|
||||
- Document which templates and commands your preset modifies
|
||||
|
||||
### Command Overrides
|
||||
|
||||
- Only override commands when the workflow needs to change, not just the output format
|
||||
- If you only need different template sections, a template override is sufficient
|
||||
- Test command overrides with multiple agents (Claude, Gemini, Copilot)
|
||||
@@ -0,0 +1,158 @@
|
||||
# Presets
|
||||
|
||||
Presets are stackable, priority-ordered collections of template and command overrides for Spec Kit. They let you customize both the artifacts produced by the Spec-Driven Development workflow (specs, plans, tasks, checklists, constitutions) and the commands that guide the LLM in creating them — without forking or modifying core files.
|
||||
|
||||
## How It Works
|
||||
|
||||
When Spec Kit needs a template (e.g. `spec-template`), it walks a resolution stack:
|
||||
|
||||
1. `.specify/templates/overrides/` — project-local one-off overrides
|
||||
2. `.specify/presets/<preset-id>/templates/` — installed presets (sorted by priority)
|
||||
3. `.specify/extensions/<ext-id>/templates/` — extension-provided templates
|
||||
4. `.specify/templates/` — core templates shipped with Spec Kit
|
||||
|
||||
If no preset is installed, core templates are used — exactly the same behavior as before presets existed.
|
||||
|
||||
Template resolution happens **at runtime** — although preset files are copied into `.specify/presets/<id>/` during installation, Spec Kit walks the resolution stack on every template lookup rather than merging templates into a single location.
|
||||
|
||||
For detailed resolution and command registration flows, see [ARCHITECTURE.md](ARCHITECTURE.md).
|
||||
|
||||
## Command Overrides
|
||||
|
||||
Presets can also override the commands that guide the SDD workflow. Templates define *what* gets produced (specs, plans, constitutions); commands define *how* the LLM produces them (the step-by-step instructions).
|
||||
|
||||
Unlike templates, command overrides are applied **at install time**. When a preset includes `type: "command"` entries, the commands are registered into all detected agent directories (`.claude/commands/`, `.gemini/commands/`, etc.) in the correct format (Markdown or TOML with appropriate argument placeholders). When the preset is removed, the registered commands are cleaned up.
|
||||
|
||||
## Quick Start
|
||||
|
||||
```bash
|
||||
# Search available presets
|
||||
specify preset search
|
||||
|
||||
# Install a preset from the catalog
|
||||
specify preset add healthcare-compliance
|
||||
|
||||
# Install from a local directory (for development)
|
||||
specify preset add --dev ./my-preset
|
||||
|
||||
# Install with a specific priority (lower = higher precedence)
|
||||
specify preset add healthcare-compliance --priority 5
|
||||
|
||||
# List installed presets
|
||||
specify preset list
|
||||
|
||||
# See which template a name resolves to
|
||||
specify preset resolve spec-template
|
||||
|
||||
# Get detailed info about a preset
|
||||
specify preset info healthcare-compliance
|
||||
|
||||
# Remove a preset
|
||||
specify preset remove healthcare-compliance
|
||||
```
|
||||
|
||||
## Stacking Presets
|
||||
|
||||
Multiple presets can be installed simultaneously. The `--priority` flag controls which one wins when two presets provide the same template (lower number = higher precedence):
|
||||
|
||||
```bash
|
||||
specify preset add enterprise-safe --priority 10 # base layer
|
||||
specify preset add healthcare-compliance --priority 5 # overrides enterprise-safe
|
||||
specify preset add pm-workflow --priority 1 # overrides everything
|
||||
```
|
||||
|
||||
Presets **override by default**, they don't merge. If two presets both provide `spec-template` with the default `replace` strategy, the one with the lowest priority number wins entirely. However, presets can use **composition strategies** to augment rather than replace content.
|
||||
|
||||
### Composition Strategies
|
||||
|
||||
Presets can declare a `strategy` per template to control how content is combined. The `name` field identifies which template to compose with in the priority stack, while `file` points to the actual content file (which can differ from the convention path `templates/<name>.md`):
|
||||
|
||||
```yaml
|
||||
provides:
|
||||
templates:
|
||||
- type: "template"
|
||||
name: "spec-template"
|
||||
file: "templates/spec-addendum.md"
|
||||
strategy: "append" # adds content after the core template
|
||||
```
|
||||
|
||||
| Strategy | Description |
|
||||
|----------|-------------|
|
||||
| `replace` (default) | Fully replaces the lower-priority template |
|
||||
| `prepend` | Places content **before** the resolved lower-priority template, separated by a blank line |
|
||||
| `append` | Places content **after** the resolved lower-priority template, separated by a blank line |
|
||||
| `wrap` | Content contains `{CORE_TEMPLATE}` placeholder (or `$CORE_SCRIPT` for scripts) replaced with the lower-priority content |
|
||||
|
||||
**Supported combinations:**
|
||||
|
||||
| Type | `replace` | `prepend` | `append` | `wrap` |
|
||||
|------|-----------|-----------|----------|--------|
|
||||
| **template** | ✓ (default) | ✓ | ✓ | ✓ |
|
||||
| **command** | ✓ (default) | ✓ | ✓ | ✓ |
|
||||
| **script** | ✓ (default) | — | — | ✓ |
|
||||
|
||||
Multiple composing presets chain recursively. For example, a security preset with `prepend` and a compliance preset with `append` will produce: security header + core content + compliance footer.
|
||||
|
||||
## Catalog Management
|
||||
|
||||
Presets are discovered through catalogs. By default, Spec Kit uses the official and community catalogs:
|
||||
|
||||
> [!NOTE]
|
||||
> Community presets are independently created and maintained by their respective authors. Maintainers only verify that catalog entries are complete and correctly formatted — they do **not review, audit, endorse, or support the preset code itself**. Review preset source code before installation and use at your own discretion.
|
||||
|
||||
```bash
|
||||
# List active catalogs
|
||||
specify preset catalog list
|
||||
|
||||
# Add a custom catalog
|
||||
specify preset catalog add https://example.com/catalog.json --name my-org --install-allowed
|
||||
|
||||
# Remove a catalog
|
||||
specify preset catalog remove my-org
|
||||
```
|
||||
|
||||
## Creating a Preset
|
||||
|
||||
See [scaffold/](scaffold/) for a scaffold you can copy to create your own preset.
|
||||
|
||||
1. Copy `scaffold/` to a new directory
|
||||
2. Edit `preset.yml` with your preset's metadata
|
||||
3. Add or replace templates in `templates/`
|
||||
4. Test locally with `specify preset add --dev .`
|
||||
5. Verify with `specify preset resolve spec-template`
|
||||
|
||||
## Environment Variables
|
||||
|
||||
| Variable | Description | Default |
|
||||
|----------|-------------|---------|
|
||||
| `SPECKIT_PRESET_CATALOG_URL` | Override the full catalog stack with a single URL (replaces all defaults) | Built-in default stack |
|
||||
| `GH_TOKEN` / `GITHUB_TOKEN` | GitHub token for authenticated requests to GitHub-hosted URLs (`raw.githubusercontent.com`, `github.com`, `api.github.com`, `codeload.github.com`). Required when your catalog JSON or preset ZIPs are hosted in a private GitHub repository. | None |
|
||||
|
||||
#### Example: Using a private GitHub-hosted catalog
|
||||
|
||||
```bash
|
||||
# Authenticate with a token (gh CLI, PAT, or GITHUB_TOKEN in CI)
|
||||
export GITHUB_TOKEN=$(gh auth token)
|
||||
|
||||
# Search a private catalog added via `specify preset catalog add`
|
||||
specify preset search my-template
|
||||
|
||||
# Install from a private catalog
|
||||
specify preset add my-template
|
||||
```
|
||||
|
||||
The token is attached automatically to requests targeting GitHub domains. Non-GitHub catalog URLs are always fetched without credentials.
|
||||
|
||||
## Configuration Files
|
||||
|
||||
| File | Scope | Description |
|
||||
|------|-------|-------------|
|
||||
| `.specify/preset-catalogs.yml` | Project | Custom catalog stack for this project |
|
||||
| `~/.specify/preset-catalogs.yml` | User | Custom catalog stack for all projects |
|
||||
|
||||
## Future Considerations
|
||||
|
||||
The following enhancements are under consideration for future releases:
|
||||
|
||||
- **Structural merge strategies** — Parsing Markdown sections for per-section granularity (e.g., "replace only ## Security").
|
||||
- **Conflict detection** — `specify preset lint` / `specify preset doctor` for detecting composition conflicts.
|
||||
@@ -0,0 +1,699 @@
|
||||
{
|
||||
"schema_version": "1.0",
|
||||
"updated_at": "2026-06-30T00:00:00Z",
|
||||
"catalog_url": "https://raw.githubusercontent.com/github/spec-kit/main/presets/catalog.community.json",
|
||||
"presets": {
|
||||
"a11y-governance": {
|
||||
"name": "A11Y Governance",
|
||||
"id": "a11y-governance",
|
||||
"version": "0.4.0",
|
||||
"description": "Adds accessibility (WCAG 2.2 AA), bilingual DE/EN delivery, CEFR-B2 readability, inclusive-content governance, didactic inline-code-comment review, and audit-ready Spec Kit run evidence.",
|
||||
"author": "Thorsten Hindermann",
|
||||
"repository": "https://github.com/hindermath/spec-kit-preset-a11y-governance",
|
||||
"download_url": "https://github.com/hindermath/spec-kit-preset-a11y-governance/archive/refs/tags/v0.4.0.zip",
|
||||
"homepage": "https://github.com/hindermath/spec-kit-preset-a11y-governance",
|
||||
"documentation": "https://github.com/hindermath/spec-kit-preset-a11y-governance/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.8.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 10,
|
||||
"commands": 3
|
||||
},
|
||||
"tags": [
|
||||
"a11y",
|
||||
"accessibility",
|
||||
"bilingual",
|
||||
"wcag",
|
||||
"wcag-2-2",
|
||||
"cefr-b2",
|
||||
"inclusion",
|
||||
"include-everyone",
|
||||
"didactic-comments"
|
||||
],
|
||||
"created_at": "2026-04-27T00:00:00Z",
|
||||
"updated_at": "2026-06-14T00:00:00Z"
|
||||
},
|
||||
"agent-parity-governance": {
|
||||
"name": "Agent Parity Governance",
|
||||
"id": "agent-parity-governance",
|
||||
"version": "0.3.0",
|
||||
"description": "Adds shared-guidance parity, audit-ready Spec-Kit run evidence, and agent-neutral model-routing guidance across a project's declared AI-agent instruction surfaces so agent guidance does not drift.",
|
||||
"author": "Thorsten Hindermann",
|
||||
"repository": "https://github.com/hindermath/spec-kit-preset-agent-parity-governance",
|
||||
"download_url": "https://github.com/hindermath/spec-kit-preset-agent-parity-governance/archive/refs/tags/v0.3.0.zip",
|
||||
"homepage": "https://github.com/hindermath/spec-kit-preset-agent-parity-governance",
|
||||
"documentation": "https://github.com/hindermath/spec-kit-preset-agent-parity-governance/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.8.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 6,
|
||||
"commands": 3
|
||||
},
|
||||
"tags": [
|
||||
"agents",
|
||||
"governance",
|
||||
"parity",
|
||||
"agent-md",
|
||||
"agent-guidance",
|
||||
"model-routing",
|
||||
"multi-agent"
|
||||
],
|
||||
"created_at": "2026-04-27T00:00:00Z",
|
||||
"updated_at": "2026-06-14T00:00:00Z"
|
||||
},
|
||||
"aide-in-place": {
|
||||
"name": "AIDE In-Place Migration",
|
||||
"id": "aide-in-place",
|
||||
"version": "1.0.0",
|
||||
"description": "Adapts the AIDE workflow for in-place technology migrations (X → Y pattern). Overrides vision, roadmap, progress, and work item commands with migration-specific guidance.",
|
||||
"author": "mnriem",
|
||||
"repository": "https://github.com/mnriem/spec-kit-presets",
|
||||
"download_url": "https://github.com/mnriem/spec-kit-presets/releases/download/aide-in-place-v1.0.0/aide-in-place.zip",
|
||||
"homepage": "https://github.com/mnriem/spec-kit-presets",
|
||||
"documentation": "https://github.com/mnriem/spec-kit-presets/blob/main/aide-in-place/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.2.0",
|
||||
"extensions": [
|
||||
"aide"
|
||||
]
|
||||
},
|
||||
"provides": {
|
||||
"templates": 2,
|
||||
"commands": 8
|
||||
},
|
||||
"tags": [
|
||||
"migration",
|
||||
"in-place",
|
||||
"brownfield",
|
||||
"aide"
|
||||
]
|
||||
},
|
||||
"architecture-governance": {
|
||||
"name": "Architecture Governance",
|
||||
"id": "architecture-governance",
|
||||
"version": "0.5.0",
|
||||
"description": "Adds secure software architecture, STRIDE+CAPEC threat modeling, arc42 security cross-cutting concepts, S-ADRs, Zero Trust applicability, OWASP SAMM governance, BSI C3A cloud autonomy, BSI C5 cloud compliance assurance, and audit-ready Spec Kit run evidence.",
|
||||
"author": "Thorsten Hindermann",
|
||||
"repository": "https://github.com/hindermath/spec-kit-preset-architecture-governance",
|
||||
"download_url": "https://github.com/hindermath/spec-kit-preset-architecture-governance/archive/refs/tags/v0.5.0.zip",
|
||||
"homepage": "https://github.com/hindermath/spec-kit-preset-architecture-governance",
|
||||
"documentation": "https://github.com/hindermath/spec-kit-preset-architecture-governance/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.8.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 13,
|
||||
"commands": 3
|
||||
},
|
||||
"tags": [
|
||||
"architecture",
|
||||
"governance",
|
||||
"threat-modeling",
|
||||
"stride",
|
||||
"capec",
|
||||
"arc42",
|
||||
"adr",
|
||||
"zero-trust",
|
||||
"samm",
|
||||
"isaqb",
|
||||
"cloud",
|
||||
"sovereignty",
|
||||
"c3a",
|
||||
"c5",
|
||||
"assurance"
|
||||
],
|
||||
"created_at": "2026-04-27T00:00:00Z",
|
||||
"updated_at": "2026-06-14T00:00:00Z"
|
||||
},
|
||||
"canon-core": {
|
||||
"name": "Canon Core",
|
||||
"id": "canon-core",
|
||||
"version": "0.1.0",
|
||||
"description": "Adapts original Spec Kit workflow to work together with Canon extension.",
|
||||
"author": "Maxim Stupakov",
|
||||
"download_url": "https://github.com/maximiliamus/spec-kit-canon/releases/download/v0.1.0/spec-kit-canon-core-v0.1.0.zip",
|
||||
"repository": "https://github.com/maximiliamus/spec-kit-canon",
|
||||
"homepage": "https://github.com/maximiliamus/spec-kit-canon",
|
||||
"documentation": "https://github.com/maximiliamus/spec-kit-canon/blob/master/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.4.3"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 2,
|
||||
"commands": 8
|
||||
},
|
||||
"tags": [
|
||||
"baseline",
|
||||
"canon",
|
||||
"spec-first"
|
||||
]
|
||||
},
|
||||
"claude-ask-questions": {
|
||||
"name": "Claude AskUserQuestion",
|
||||
"id": "claude-ask-questions",
|
||||
"version": "1.0.0",
|
||||
"description": "Upgrades /speckit.clarify and /speckit.checklist on Claude Code from Markdown-table prompts to the native AskUserQuestion picker, with a recommended option and reasoning on every question.",
|
||||
"author": "0xrafasec",
|
||||
"repository": "https://github.com/0xrafasec/spec-kit-preset-claude-ask-questions",
|
||||
"download_url": "https://github.com/0xrafasec/spec-kit-preset-claude-ask-questions/archive/refs/tags/v1.0.0.zip",
|
||||
"homepage": "https://github.com/0xrafasec/spec-kit-preset-claude-ask-questions",
|
||||
"documentation": "https://github.com/0xrafasec/spec-kit-preset-claude-ask-questions/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.6.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 0,
|
||||
"commands": 2
|
||||
},
|
||||
"tags": [
|
||||
"claude",
|
||||
"ask-user-question",
|
||||
"clarify",
|
||||
"checklist"
|
||||
],
|
||||
"created_at": "2026-04-13T00:00:00Z",
|
||||
"updated_at": "2026-04-13T00:00:00Z"
|
||||
},
|
||||
"command-density": {
|
||||
"name": "Command Density",
|
||||
"id": "command-density",
|
||||
"version": "1.0.0",
|
||||
"description": "Compacts the nine core Spec Kit command prompts while preserving scripts, handoffs, placeholders, hook output blocks, and rule structure.",
|
||||
"author": "Maksim Kudriavtsev",
|
||||
"repository": "https://github.com/Xopoko/spec-kit-preset-command-density",
|
||||
"download_url": "https://github.com/Xopoko/spec-kit-preset-command-density/archive/refs/tags/v1.0.0.zip",
|
||||
"homepage": "https://github.com/Xopoko/spec-kit-preset-command-density",
|
||||
"documentation": "https://github.com/Xopoko/spec-kit-preset-command-density/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.10.3"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 0,
|
||||
"commands": 9
|
||||
},
|
||||
"tags": [
|
||||
"commands",
|
||||
"tokens",
|
||||
"compact",
|
||||
"workflow",
|
||||
"prompt-density"
|
||||
],
|
||||
"created_at": "2026-06-16T00:00:00Z",
|
||||
"updated_at": "2026-06-16T00:00:00Z"
|
||||
},
|
||||
"cross-platform-governance": {
|
||||
"name": "Cross-Platform Governance",
|
||||
"id": "cross-platform-governance",
|
||||
"version": "0.2.0",
|
||||
"description": "Adds Bash + PowerShell parity, Unix man-pages, bilingual comment-based help, Verb-Noun Cmdlet discipline, and audit-ready Spec Kit run evidence for scripting projects managed with Spec Kit.",
|
||||
"author": "Thorsten Hindermann",
|
||||
"repository": "https://github.com/hindermath/spec-kit-preset-cross-platform-governance",
|
||||
"download_url": "https://github.com/hindermath/spec-kit-preset-cross-platform-governance/archive/refs/tags/v0.2.0.zip",
|
||||
"homepage": "https://github.com/hindermath/spec-kit-preset-cross-platform-governance",
|
||||
"documentation": "https://github.com/hindermath/spec-kit-preset-cross-platform-governance/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.8.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 8,
|
||||
"commands": 3
|
||||
},
|
||||
"tags": [
|
||||
"cross-platform",
|
||||
"governance",
|
||||
"bash",
|
||||
"powershell",
|
||||
"man-page",
|
||||
"cmdlet",
|
||||
"verb-noun",
|
||||
"windows",
|
||||
"macos",
|
||||
"linux"
|
||||
],
|
||||
"created_at": "2026-04-27T00:00:00Z",
|
||||
"updated_at": "2026-06-14T00:00:00Z"
|
||||
},
|
||||
"explicit-task-dependencies": {
|
||||
"name": "Explicit Task Dependencies",
|
||||
"id": "explicit-task-dependencies",
|
||||
"version": "1.0.0",
|
||||
"description": "Adds explicit (depends on T###) dependency declarations and an Execution Wave DAG to tasks.md for dependency-resolved parallel scheduling",
|
||||
"author": "Quratulain-bilal",
|
||||
"repository": "https://github.com/Quratulain-bilal/spec-kit-preset-explicit-task-dependencies",
|
||||
"download_url": "https://github.com/Quratulain-bilal/spec-kit-preset-explicit-task-dependencies/archive/refs/tags/v1.0.0.zip",
|
||||
"homepage": "https://github.com/Quratulain-bilal/spec-kit-preset-explicit-task-dependencies",
|
||||
"documentation": "https://github.com/Quratulain-bilal/spec-kit-preset-explicit-task-dependencies/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.4.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 1,
|
||||
"commands": 1
|
||||
},
|
||||
"tags": [
|
||||
"dependencies",
|
||||
"parallel",
|
||||
"scheduling",
|
||||
"wave-dag"
|
||||
]
|
||||
},
|
||||
"fiction-book-writing": {
|
||||
"name": "Fiction Book Writing",
|
||||
"id": "fiction-book-writing",
|
||||
"version": "1.9.0",
|
||||
"description": "Spec-Driven Development for novel and long-form fiction. 34 AI commands from idea to submission: story bible governance, 9 POV modes, all major plot structure frameworks, scene-by-scene drafting with quality gates, audiobook pipeline (SSML/ElevenLabs), cover design, illustrations, sensitivity review, pacing and prose statistics, and pandoc-based export to DOCX/EPUB/LaTeX. Two style modes: author voice sample extraction or humanized-AI prose with 5 craft profiles. 12 languages supported. Support for offline semantic search.",
|
||||
"author": "Andreas Daumann",
|
||||
"repository": "https://github.com/adaumann/speckit-preset-fiction-book-writing",
|
||||
"download_url": "https://github.com/adaumann/speckit-preset-fiction-book-writing/archive/refs/tags/v1.9.0.zip",
|
||||
"homepage": "https://github.com/adaumann/speckit-preset-fiction-book-writing",
|
||||
"documentation": "https://github.com/adaumann/speckit-preset-fiction-book-writing/blob/main/fiction-book-writing/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.5.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 26,
|
||||
"commands": 34,
|
||||
"scripts": 2
|
||||
},
|
||||
"tags": [
|
||||
"writing",
|
||||
"novel",
|
||||
"fiction",
|
||||
"storytelling",
|
||||
"creative-writing",
|
||||
"kdp",
|
||||
"multi-pov",
|
||||
"export",
|
||||
"book",
|
||||
"brainstorming",
|
||||
"roleplay",
|
||||
"audiobook",
|
||||
"language-support"
|
||||
],
|
||||
"created_at": "2026-04-09T08:00:00Z",
|
||||
"updated_at": "2026-06-02T08:00:00Z"
|
||||
},
|
||||
"game-narrative-writing": {
|
||||
"name": "Game Narrative Writing",
|
||||
"id": "game-narrative-writing",
|
||||
"version": "1.1.0",
|
||||
"description": "Preset for game narrative design and interactive storytelling. It adapts the Spec-Driven Development workflow for game narratives: features become story mechanics, specs become narrative briefs, plans become story maps, and tasks become dialogue and scene-writing tasks. Supports branching narratives, player agency systems, state machines, and interactive dialogue trees.",
|
||||
"author": "Andreas Daumann",
|
||||
"repository": "https://github.com/adaumann/speckit-preset-game-narrative-writing",
|
||||
"download_url": "https://github.com/adaumann/speckit-preset-game-narrative-writing/releases/download/v1.1.0/v1.1.0-import.zip",
|
||||
"homepage": "https://github.com/adaumann/speckit-preset-game-narrative-writing",
|
||||
"documentation": "https://github.com/adaumann/speckit-preset-game-narrative-writing/blob/main/game-narrative-writing/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.5.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 37,
|
||||
"commands": 34,
|
||||
"scripts": 5
|
||||
},
|
||||
"tags": [
|
||||
"interactive-fiction",
|
||||
"game-narrative",
|
||||
"branching",
|
||||
"twine",
|
||||
"ink"
|
||||
],
|
||||
"created_at": "2026-05-05T08:00:00Z",
|
||||
"updated_at": "2026-06-22T00:00:00Z"
|
||||
},
|
||||
"isaqb-architecture-governance": {
|
||||
"name": "iSAQB Architecture Governance",
|
||||
"id": "isaqb-architecture-governance",
|
||||
"version": "0.2.0",
|
||||
"description": "Adds general iSAQB/CPSA-F and arc42 software-architecture governance, including audit-ready Spec Kit run evidence for architecture goals, views, quality scenarios, ADRs, risks, and technical debt.",
|
||||
"author": "Thorsten Hindermann",
|
||||
"repository": "https://github.com/hindermath/spec-kit-preset-isaqb-architecture-governance",
|
||||
"download_url": "https://github.com/hindermath/spec-kit-preset-isaqb-architecture-governance/archive/refs/tags/v0.2.0.zip",
|
||||
"homepage": "https://github.com/hindermath/spec-kit-preset-isaqb-architecture-governance",
|
||||
"documentation": "https://github.com/hindermath/spec-kit-preset-isaqb-architecture-governance/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.8.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 13,
|
||||
"commands": 3
|
||||
},
|
||||
"tags": [
|
||||
"architecture",
|
||||
"governance",
|
||||
"isaqb",
|
||||
"cpsa-f",
|
||||
"arc42",
|
||||
"adr",
|
||||
"quality-attributes",
|
||||
"architecture-views",
|
||||
"technical-debt"
|
||||
],
|
||||
"created_at": "2026-04-27T00:00:00Z",
|
||||
"updated_at": "2026-06-14T00:00:00Z"
|
||||
},
|
||||
"jira": {
|
||||
"name": "Jira Issue Tracking",
|
||||
"id": "jira",
|
||||
"version": "1.0.0",
|
||||
"description": "Overrides speckit.taskstoissues to create Jira epics, stories, and tasks instead of GitHub Issues via Atlassian MCP tools.",
|
||||
"author": "luno",
|
||||
"repository": "https://github.com/luno/spec-kit-preset-jira",
|
||||
"download_url": "https://github.com/luno/spec-kit-preset-jira/archive/refs/tags/v1.0.0.zip",
|
||||
"homepage": "https://github.com/luno/spec-kit-preset-jira",
|
||||
"documentation": "https://github.com/luno/spec-kit-preset-jira/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.1.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 0,
|
||||
"commands": 1
|
||||
},
|
||||
"tags": [
|
||||
"jira",
|
||||
"atlassian",
|
||||
"issue-tracking",
|
||||
"preset"
|
||||
],
|
||||
"created_at": "2026-04-15T00:00:00Z",
|
||||
"updated_at": "2026-04-15T00:00:00Z"
|
||||
},
|
||||
"mde": {
|
||||
"name": "Model Driven Engineering",
|
||||
"id": "mde",
|
||||
"version": "0.5.1",
|
||||
"description": "Focuses on streamlined commands, app repository support, cross-spec support, and capability-aware project memory for model-driven engineering workflows.",
|
||||
"author": "Ralph Hanna",
|
||||
"repository": "https://github.com/AI-MDE/spec-kit-preset-mde",
|
||||
"download_url": "https://github.com/AI-MDE/spec-kit-preset-mde/archive/refs/tags/v0.5.1.zip",
|
||||
"homepage": "https://github.com/AI-MDE/spec-kit-preset-mde",
|
||||
"documentation": "https://github.com/AI-MDE/spec-kit-preset-mde/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.1.0",
|
||||
"extensions": [
|
||||
"mde"
|
||||
]
|
||||
},
|
||||
"provides": {
|
||||
"templates": 6,
|
||||
"commands": 11
|
||||
},
|
||||
"tags": [
|
||||
"model-driven-engineering",
|
||||
"software-lifecycle",
|
||||
"business-analysis",
|
||||
"business-application",
|
||||
"multi-layered-architecture"
|
||||
],
|
||||
"created_at": "2026-05-08T00:00:00Z",
|
||||
"updated_at": "2026-05-08T00:00:00Z"
|
||||
},
|
||||
"multi-repo-branching": {
|
||||
"name": "Multi-Repo Branching",
|
||||
"id": "multi-repo-branching",
|
||||
"version": "1.0.0",
|
||||
"description": "Coordinates feature branch creation across multiple git repositories (independent repos and submodules) during plan and tasks phases.",
|
||||
"author": "sakitA",
|
||||
"repository": "https://github.com/sakitA/spec-kit-preset-multi-repo-branching",
|
||||
"download_url": "https://github.com/sakitA/spec-kit-preset-multi-repo-branching/archive/refs/tags/v1.0.0.zip",
|
||||
"homepage": "https://github.com/sakitA/spec-kit-preset-multi-repo-branching",
|
||||
"documentation": "https://github.com/sakitA/spec-kit-preset-multi-repo-branching/blob/master/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.4.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 0,
|
||||
"commands": 2
|
||||
},
|
||||
"tags": [
|
||||
"multi-repo-branching",
|
||||
"multi-module",
|
||||
"submodules",
|
||||
"monorepo"
|
||||
],
|
||||
"created_at": "2026-04-09T00:00:00Z",
|
||||
"updated_at": "2026-04-09T00:00:00Z"
|
||||
},
|
||||
"pirate": {
|
||||
"name": "Pirate Speak (Full)",
|
||||
"id": "pirate",
|
||||
"version": "1.0.0",
|
||||
"description": "Arrr! Transforms all Spec Kit output into pirate speak. Specs, plans, and tasks be written fer scallywags.",
|
||||
"author": "mnriem",
|
||||
"repository": "https://github.com/mnriem/spec-kit-presets",
|
||||
"download_url": "https://github.com/mnriem/spec-kit-presets/releases/download/pirate-v1.0.0/pirate.zip",
|
||||
"homepage": "https://github.com/mnriem/spec-kit-presets",
|
||||
"documentation": "https://github.com/mnriem/spec-kit-presets/blob/main/pirate/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.1.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 6,
|
||||
"commands": 9
|
||||
},
|
||||
"tags": [
|
||||
"pirate",
|
||||
"theme",
|
||||
"fun",
|
||||
"experimental"
|
||||
]
|
||||
},
|
||||
"screenwriting": {
|
||||
"name": "Screenwriting",
|
||||
"id": "screenwriting",
|
||||
"version": "1.0.0",
|
||||
"description": "Spec-Driven Development for screenwriting/scriptwriting/tutorials: feature films, television (pilot, episode, limited series), and stage plays. Adapts the Spec Kit workflow to screenplay craft — slug lines, action lines, act breaks, beat sheets, and industry-standard pitch documents replace prose fiction conventions. Supports three-act, Save the Cat, TV pilot, network episode, cable/streaming episode, and stage-play structural frameworks.",
|
||||
"author": "Andreas Daumann",
|
||||
"repository": "https://github.com/adaumann/speckit-preset-screenwriting",
|
||||
"download_url": "https://github.com/adaumann/speckit-preset-screenwriting/archive/refs/tags/v1.0.0.zip",
|
||||
"homepage": "https://github.com/adaumann/speckit-preset-screenwriting",
|
||||
"documentation": "https://github.com/adaumann/speckit-preset-screenwriting/blob/main/screenwriting/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.5.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 26,
|
||||
"commands": 32,
|
||||
"scripts": 1
|
||||
},
|
||||
"tags": [
|
||||
"writing",
|
||||
"screenplay",
|
||||
"scriptwriting",
|
||||
"film",
|
||||
"tv",
|
||||
"fountain",
|
||||
"fountain-format",
|
||||
"beat-sheet",
|
||||
"teleplay",
|
||||
"drama",
|
||||
"comedy",
|
||||
"storytelling",
|
||||
"tutorial",
|
||||
"education"
|
||||
],
|
||||
"created_at": "2026-04-23T08:00:00Z",
|
||||
"updated_at": "2026-04-23T08:00:00Z"
|
||||
},
|
||||
"security-governance": {
|
||||
"name": "Security Governance",
|
||||
"id": "security-governance",
|
||||
"version": "0.6.0",
|
||||
"description": "Adds memory-safe-language preference, language-specific secure coding profiles, audit-ready Spec-Kit run evidence, ASVS verification, SBOM/AI-SBOM supply-chain transparency, CRA awareness, and regulatory applicability screening for NIS2, CRA, EU AI Act, and DORA to Spec Kit.",
|
||||
"author": "Thorsten Hindermann",
|
||||
"repository": "https://github.com/hindermath/spec-kit-preset-security-governance",
|
||||
"download_url": "https://github.com/hindermath/spec-kit-preset-security-governance/archive/refs/tags/v0.6.0.zip",
|
||||
"homepage": "https://github.com/hindermath/spec-kit-preset-security-governance",
|
||||
"documentation": "https://github.com/hindermath/spec-kit-preset-security-governance/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.8.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 14,
|
||||
"commands": 3
|
||||
},
|
||||
"tags": [
|
||||
"security",
|
||||
"governance",
|
||||
"msl",
|
||||
"ssdf",
|
||||
"asvs",
|
||||
"supply-chain",
|
||||
"sbom",
|
||||
"ai-sbom",
|
||||
"vex",
|
||||
"slsa",
|
||||
"cwe-top-25",
|
||||
"secure-coding",
|
||||
"rust",
|
||||
"go",
|
||||
"swift",
|
||||
"java",
|
||||
"kotlin",
|
||||
"python",
|
||||
"typescript",
|
||||
"g7",
|
||||
"bsi",
|
||||
"cra",
|
||||
"cyber-resilience-act",
|
||||
"nis2",
|
||||
"ai-act",
|
||||
"dora",
|
||||
"regulatory"
|
||||
],
|
||||
"created_at": "2026-04-27T00:00:00Z",
|
||||
"updated_at": "2026-06-14T00:00:00Z"
|
||||
},
|
||||
"sicario-core": {
|
||||
"name": "SicarioSpec Core",
|
||||
"id": "sicario-core",
|
||||
"version": "0.5.1",
|
||||
"description": "Baseline secure-by-default Spec Kit governance profile.",
|
||||
"author": "SicarioSpec Contributors",
|
||||
"repository": "https://github.com/dfirs1car1o/sicario-spec",
|
||||
"download_url": "https://github.com/dfirs1car1o/sicario-spec/releases/download/v0.5.1/sicario-core-0.5.1.zip",
|
||||
"homepage": "https://github.com/dfirs1car1o/sicario-spec",
|
||||
"documentation": "https://github.com/dfirs1car1o/sicario-spec/blob/main/presets/sicario-core/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.9.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 5,
|
||||
"commands": 0
|
||||
},
|
||||
"tags": [
|
||||
"governance",
|
||||
"security-ops",
|
||||
"secure-by-default",
|
||||
"evidence"
|
||||
],
|
||||
"created_at": "2026-06-22T00:00:00Z",
|
||||
"updated_at": "2026-06-25T00:00:00Z"
|
||||
},
|
||||
"spec2cloud": {
|
||||
"name": "Spec2Cloud",
|
||||
"id": "spec2cloud",
|
||||
"version": "1.1.0",
|
||||
"description": "Spec-driven workflow tuned for shipping to Azure: spec → plan → tasks → implement → deploy.",
|
||||
"author": "Azure Samples",
|
||||
"repository": "https://github.com/Azure-Samples/Spec2Cloud",
|
||||
"download_url": "https://github.com/Azure-Samples/Spec2Cloud/releases/download/spec-kit-spec2cloud-v1.1.0/preset.zip",
|
||||
"homepage": "https://aka.ms/spec2cloud",
|
||||
"documentation": "https://github.com/Azure-Samples/Spec2Cloud/blob/main/spec-kit/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.1.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 5,
|
||||
"commands": 8
|
||||
},
|
||||
"tags": [
|
||||
"azure",
|
||||
"spec2cloud",
|
||||
"workflow",
|
||||
"deployment"
|
||||
],
|
||||
"created_at": "2026-04-30T00:00:00Z",
|
||||
"updated_at": "2026-04-30T00:00:00Z"
|
||||
},
|
||||
"toc-navigation": {
|
||||
"name": "Table of Contents Navigation",
|
||||
"id": "toc-navigation",
|
||||
"version": "1.0.0",
|
||||
"description": "Adds a navigable Table of Contents to generated spec.md, plan.md, and tasks.md documents",
|
||||
"author": "Quratulain-bilal",
|
||||
"repository": "https://github.com/Quratulain-bilal/spec-kit-preset-toc-navigation",
|
||||
"download_url": "https://github.com/Quratulain-bilal/spec-kit-preset-toc-navigation/archive/refs/tags/v1.0.0.zip",
|
||||
"homepage": "https://github.com/Quratulain-bilal/spec-kit-preset-toc-navigation",
|
||||
"documentation": "https://github.com/Quratulain-bilal/spec-kit-preset-toc-navigation/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.4.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 3,
|
||||
"commands": 3
|
||||
},
|
||||
"tags": [
|
||||
"navigation",
|
||||
"toc",
|
||||
"documentation"
|
||||
]
|
||||
},
|
||||
"vscode-ask-questions": {
|
||||
"name": "VS Code Ask Questions",
|
||||
"id": "vscode-ask-questions",
|
||||
"version": "1.0.0",
|
||||
"description": "Enhances the clarify command to use vscode/askQuestions for batched interactive questioning, reducing API request costs in GitHub Copilot.",
|
||||
"author": "fdcastel",
|
||||
"repository": "https://github.com/fdcastel/spec-kit-presets",
|
||||
"download_url": "https://github.com/fdcastel/spec-kit-presets/releases/download/vscode-ask-questions-v1.0.0/vscode-ask-questions.zip",
|
||||
"homepage": "https://github.com/fdcastel/spec-kit-presets",
|
||||
"documentation": "https://github.com/fdcastel/spec-kit-presets/blob/main/vscode-ask-questions/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.1.0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 0,
|
||||
"commands": 1
|
||||
},
|
||||
"tags": [
|
||||
"vscode",
|
||||
"askquestions",
|
||||
"clarify",
|
||||
"interactive"
|
||||
]
|
||||
},
|
||||
"workflow-preset": {
|
||||
"name": "Workflow Preset",
|
||||
"id": "workflow-preset",
|
||||
"version": "1.3.11",
|
||||
"description": "Behavior-first specification, design artifacts, and agent-native handoff orchestration",
|
||||
"author": "bigsmartben",
|
||||
"repository": "https://github.com/bigsmartben/spec-kit-workflow-preset",
|
||||
"download_url": "https://github.com/bigsmartben/spec-kit-workflow-preset/releases/download/v1.3.11/spec-kit-workflow-preset-v1.3.11.zip",
|
||||
"homepage": "https://github.com/bigsmartben/spec-kit-workflow-preset",
|
||||
"documentation": "https://github.com/bigsmartben/spec-kit-workflow-preset/blob/main/README.md",
|
||||
"license": "MIT",
|
||||
"requires": {
|
||||
"speckit_version": ">=0.8.10.dev0"
|
||||
},
|
||||
"provides": {
|
||||
"templates": 22,
|
||||
"commands": 8
|
||||
},
|
||||
"tags": [
|
||||
"behavior",
|
||||
"bdd",
|
||||
"planning",
|
||||
"implementation",
|
||||
"handoff"
|
||||
],
|
||||
"created_at": "2026-05-27T00:00:00Z",
|
||||
"updated_at": "2026-06-30T00:00:00Z"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,30 @@
|
||||
{
|
||||
"schema_version": "1.0",
|
||||
"updated_at": "2026-04-24T00:00:00Z",
|
||||
"catalog_url": "https://raw.githubusercontent.com/github/spec-kit/main/presets/catalog.json",
|
||||
"presets": {
|
||||
"lean": {
|
||||
"name": "Lean Workflow",
|
||||
"id": "lean",
|
||||
"version": "1.0.0",
|
||||
"description": "Minimal core workflow commands - just the prompt, just the artifact",
|
||||
"author": "github",
|
||||
"repository": "https://github.com/github/spec-kit",
|
||||
"license": "MIT",
|
||||
"bundled": true,
|
||||
"requires": {
|
||||
"speckit_version": ">=0.6.0"
|
||||
},
|
||||
"provides": {
|
||||
"commands": 5,
|
||||
"templates": 0
|
||||
},
|
||||
"tags": [
|
||||
"lean",
|
||||
"minimal",
|
||||
"workflow",
|
||||
"core"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,45 @@
|
||||
# Lean Workflow
|
||||
|
||||
A minimal preset that strips the Spec Kit workflow down to its essentials — just the prompt, just the artifact.
|
||||
|
||||
## When to Use
|
||||
|
||||
Use Lean when you want the structured specify → plan → tasks → implement pipeline without the ceremony of the full templates. Each command produces a single focused Markdown file with no boilerplate sections to fill in.
|
||||
|
||||
## Commands Included
|
||||
|
||||
| Command | Output | Description |
|
||||
|---------|--------|-------------|
|
||||
| `speckit.specify` | `spec.md` | Create a specification from a feature description |
|
||||
| `speckit.plan` | `plan.md` | Create an implementation plan from the spec |
|
||||
| `speckit.tasks` | `tasks.md` | Create dependency-ordered tasks from spec and plan |
|
||||
| `speckit.implement` | *(code)* | Execute all tasks in order, marking progress |
|
||||
| `speckit.constitution` | `constitution.md` | Create or update the project constitution |
|
||||
|
||||
## What It Replaces
|
||||
|
||||
Lean overrides the five core workflow commands with self-contained prompts that produce each artifact directly — no separate template files involved. The result is a shorter, more direct workflow.
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
# Lean is a bundled preset — no download needed
|
||||
specify preset add lean
|
||||
```
|
||||
|
||||
## Development
|
||||
|
||||
```bash
|
||||
# Test from local directory
|
||||
specify preset add --dev ./presets/lean
|
||||
|
||||
# Verify commands resolve
|
||||
specify preset resolve speckit.specify
|
||||
|
||||
# Remove when done
|
||||
specify preset remove lean
|
||||
```
|
||||
|
||||
## License
|
||||
|
||||
MIT
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
description: Create or update the project constitution.
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
## Outline
|
||||
|
||||
1. Create or update the project constitution and store it in `.specify/memory/constitution.md`.
|
||||
- Project name, guiding principles, non-negotiable rules
|
||||
- Derive from user input and existing repo context (README, docs)
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
description: Execute the implementation plan by processing all tasks in tasks.md.
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
## Outline
|
||||
|
||||
1. Read `.specify/feature.json` to get the feature directory path.
|
||||
|
||||
2. **Load context**: `.specify/memory/constitution.md` and `<feature_directory>/spec.md` and `<feature_directory>/plan.md` and `<feature_directory>/tasks.md`.
|
||||
|
||||
3. **Execute tasks** in order:
|
||||
- Complete each task before moving to the next
|
||||
- Mark completed tasks by changing `- [ ]` to `- [x]` in `<feature_directory>/tasks.md`
|
||||
- Halt on failure and report the issue
|
||||
|
||||
4. **Validate**: Verify all tasks are completed and the implementation matches the spec.
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
description: Create a plan and store it in plan.md.
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
## Outline
|
||||
|
||||
1. Read `.specify/feature.json` to get the feature directory path.
|
||||
|
||||
2. **Load context**: `.specify/memory/constitution.md` and `<feature_directory>/spec.md`.
|
||||
|
||||
3. Create an implementation plan and store it in `<feature_directory>/plan.md`.
|
||||
- Technical context: tech stack, dependencies, project structure
|
||||
- Design decisions, architecture, file structure
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
description: Create a specification and store it in spec.md.
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
## Outline
|
||||
|
||||
1. **Ask the user** for the feature directory path (e.g., `specs/my-feature`). Do not proceed until provided.
|
||||
|
||||
2. Create the directory and write `.specify/feature.json`:
|
||||
```json
|
||||
{ "feature_directory": "<feature_directory>" }
|
||||
```
|
||||
|
||||
3. Create a specification from the user input and store it in `<feature_directory>/spec.md`.
|
||||
- Overview, functional requirements, user scenarios, success criteria
|
||||
- Every requirement must be testable
|
||||
- Make informed defaults for unspecified details
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
description: Create the tasks needed for implementation and store them in tasks.md.
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
## Outline
|
||||
|
||||
1. Read `.specify/feature.json` to get the feature directory path.
|
||||
|
||||
2. **Load context**: `.specify/memory/constitution.md` and `<feature_directory>/spec.md` and `<feature_directory>/plan.md`.
|
||||
|
||||
3. Create dependency-ordered implementation tasks and store them in `<feature_directory>/tasks.md`.
|
||||
- Every task uses checklist format: `- [ ] [TaskID] Description with file path`
|
||||
- Organized by phase: setup, foundational, user stories in priority order, polish
|
||||
@@ -0,0 +1,51 @@
|
||||
schema_version: "1.0"
|
||||
|
||||
preset:
|
||||
id: "lean"
|
||||
name: "Lean Workflow"
|
||||
version: "1.0.0"
|
||||
description: "Minimal core workflow commands - just the prompt, just the artifact"
|
||||
author: "github"
|
||||
repository: "https://github.com/github/spec-kit"
|
||||
license: "MIT"
|
||||
|
||||
requires:
|
||||
speckit_version: ">=0.6.0"
|
||||
|
||||
provides:
|
||||
templates:
|
||||
- type: "command"
|
||||
name: "speckit.specify"
|
||||
file: "commands/speckit.specify.md"
|
||||
description: "Lean specify - create spec.md from a feature description"
|
||||
replaces: "speckit.specify"
|
||||
|
||||
- type: "command"
|
||||
name: "speckit.plan"
|
||||
file: "commands/speckit.plan.md"
|
||||
description: "Lean plan - create plan.md from the spec"
|
||||
replaces: "speckit.plan"
|
||||
|
||||
- type: "command"
|
||||
name: "speckit.tasks"
|
||||
file: "commands/speckit.tasks.md"
|
||||
description: "Lean tasks - create tasks.md from plan and spec"
|
||||
replaces: "speckit.tasks"
|
||||
|
||||
- type: "command"
|
||||
name: "speckit.implement"
|
||||
file: "commands/speckit.implement.md"
|
||||
description: "Lean implement - execute tasks from tasks.md"
|
||||
replaces: "speckit.implement"
|
||||
|
||||
- type: "command"
|
||||
name: "speckit.constitution"
|
||||
file: "commands/speckit.constitution.md"
|
||||
description: "Lean constitution - create or update project constitution"
|
||||
replaces: "speckit.constitution"
|
||||
|
||||
tags:
|
||||
- "lean"
|
||||
- "minimal"
|
||||
- "workflow"
|
||||
- "core"
|
||||
@@ -0,0 +1,46 @@
|
||||
# My Preset
|
||||
|
||||
A custom preset for Spec Kit. Copy this directory and customize it to create your own.
|
||||
|
||||
## Templates Included
|
||||
|
||||
| Template | Type | Description |
|
||||
|----------|------|-------------|
|
||||
| `spec-template` | template | Custom feature specification template (overrides core and extensions) |
|
||||
| `myext-template` | template | Override of the myext extension's report template |
|
||||
| `speckit.specify` | command | Custom specification command (overrides core) |
|
||||
| `speckit.myext.myextcmd` | command | Override of the myext extension's myextcmd command |
|
||||
|
||||
## Development
|
||||
|
||||
1. Copy this directory: `cp -r presets/scaffold my-preset`
|
||||
2. Edit `preset.yml` — set your preset's ID, name, description, and templates
|
||||
3. Add or modify templates in `templates/`
|
||||
4. Test locally: `specify preset add --dev ./my-preset`
|
||||
5. Verify resolution: `specify preset resolve spec-template`
|
||||
6. Remove when done testing: `specify preset remove my-preset`
|
||||
|
||||
## Manifest Reference (`preset.yml`)
|
||||
|
||||
Required fields:
|
||||
- `schema_version` — always `"1.0"`
|
||||
- `preset.id` — lowercase alphanumeric with hyphens
|
||||
- `preset.name` — human-readable name
|
||||
- `preset.version` — semantic version (e.g. `1.0.0`)
|
||||
- `preset.description` — brief description
|
||||
- `requires.speckit_version` — version constraint (e.g. `>=0.1.0`)
|
||||
- `provides.templates` — list of templates with `type`, `name`, and `file`
|
||||
|
||||
## Template Types
|
||||
|
||||
- **template** — Document scaffolds (spec-template.md, plan-template.md, tasks-template.md, etc.)
|
||||
- **command** — AI agent workflow prompts (e.g. speckit.specify, speckit.plan)
|
||||
- **script** — Custom scripts (reserved for future use)
|
||||
|
||||
## Publishing
|
||||
|
||||
See the [Preset Publishing Guide](../PUBLISHING.md) for details on submitting to the catalog.
|
||||
|
||||
## License
|
||||
|
||||
MIT
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
description: "Override of the myext extension's myextcmd command"
|
||||
---
|
||||
|
||||
<!-- Preset override for speckit.myext.myextcmd -->
|
||||
|
||||
You are following a customized version of the myext extension's myextcmd command.
|
||||
|
||||
When executing this command:
|
||||
|
||||
1. Read the user's input from $ARGUMENTS
|
||||
2. Follow the standard myextcmd workflow
|
||||
3. Additionally, apply the following customizations from this preset:
|
||||
- Add compliance checks before proceeding
|
||||
- Include audit trail entries in the output
|
||||
|
||||
> CUSTOMIZE: Replace the instructions above with your own.
|
||||
> This file overrides the command that the "myext" extension provides.
|
||||
> When this preset is installed, all agents (Claude, Gemini, Copilot, etc.)
|
||||
> will use this version instead of the extension's original.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
description: "Create a feature specification (preset override)"
|
||||
scripts:
|
||||
sh: scripts/bash/create-new-feature.sh "{ARGS}"
|
||||
ps: scripts/powershell/create-new-feature.ps1 "{ARGS}"
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
Given the feature description above:
|
||||
|
||||
1. **Create the feature branch** by running the script:
|
||||
- Bash: `{SCRIPT} --json --short-name "<short-name>" "<description>"`
|
||||
- The JSON output contains BRANCH_NAME and SPEC_FILE paths.
|
||||
|
||||
2. **Read the spec-template** to see the sections you need to fill.
|
||||
|
||||
3. **Write the specification** to SPEC_FILE, replacing the placeholders in each section
|
||||
(Overview, Requirements, Acceptance Criteria) with details from the user's description.
|
||||
@@ -0,0 +1,120 @@
|
||||
schema_version: "1.0"
|
||||
|
||||
preset:
|
||||
# CUSTOMIZE: Change 'my-preset' to your preset ID (lowercase, hyphen-separated)
|
||||
id: "my-preset"
|
||||
|
||||
# CUSTOMIZE: Human-readable name for your preset
|
||||
name: "My Preset"
|
||||
|
||||
# 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 preset provides"
|
||||
|
||||
# CUSTOMIZE: Your name or organization name
|
||||
author: "Your Name"
|
||||
|
||||
# CUSTOMIZE: GitHub repository URL (create before publishing)
|
||||
repository: "https://github.com/your-org/spec-kit-preset-my-preset"
|
||||
|
||||
# REVIEW: License (MIT is recommended for open source)
|
||||
license: "MIT"
|
||||
|
||||
# Requirements for this preset
|
||||
requires:
|
||||
# CUSTOMIZE: Minimum spec-kit version required
|
||||
speckit_version: ">=0.1.0"
|
||||
|
||||
# Templates provided by this preset
|
||||
provides:
|
||||
templates:
|
||||
# CUSTOMIZE: Define your template overrides
|
||||
# Templates are document scaffolds (spec-template.md, plan-template.md, etc.)
|
||||
#
|
||||
# Strategy options (optional, defaults to "replace"):
|
||||
# replace - Fully replaces the lower-priority template (default)
|
||||
# prepend - Places this content BEFORE the lower-priority template
|
||||
# append - Places this content AFTER the lower-priority template
|
||||
# wrap - Uses {CORE_TEMPLATE} placeholder (templates/commands) or
|
||||
# $CORE_SCRIPT placeholder (scripts), replaced with lower-priority content
|
||||
#
|
||||
# Note: Scripts only support "replace" and "wrap" strategies.
|
||||
- type: "template"
|
||||
name: "spec-template"
|
||||
file: "templates/spec-template.md"
|
||||
description: "Custom feature specification template"
|
||||
replaces: "spec-template" # Which core template this overrides (optional)
|
||||
|
||||
# ADD MORE TEMPLATES: Copy this block for each template
|
||||
# - type: "template"
|
||||
# name: "plan-template"
|
||||
# file: "templates/plan-template.md"
|
||||
# description: "Custom plan template"
|
||||
# replaces: "plan-template"
|
||||
|
||||
# COMPOSITION EXAMPLES:
|
||||
# The `file` field points to the content file (can differ from the
|
||||
# convention path `templates/<name>.md`). The `name` field identifies
|
||||
# which template to compose with in the priority stack.
|
||||
#
|
||||
# Append additional sections to an existing template:
|
||||
# - type: "template"
|
||||
# name: "spec-template"
|
||||
# file: "templates/spec-addendum.md"
|
||||
# description: "Add compliance section to spec template"
|
||||
# strategy: "append"
|
||||
#
|
||||
# Wrap a command with preamble/sign-off:
|
||||
# - type: "command"
|
||||
# name: "speckit.specify"
|
||||
# file: "commands/specify-wrapper.md"
|
||||
# description: "Wrap specify command with compliance checks"
|
||||
# strategy: "wrap"
|
||||
# # In the wrapper file, use {CORE_TEMPLATE} where the original content goes
|
||||
|
||||
# OVERRIDE EXTENSION TEMPLATES:
|
||||
# Presets sit above extensions in the resolution stack, so you can
|
||||
# override templates provided by any installed extension.
|
||||
# For example, if the "myext" extension provides a spec-template,
|
||||
# the preset's version above will take priority automatically.
|
||||
|
||||
# Override a template provided by the "myext" extension:
|
||||
- type: "template"
|
||||
name: "myext-template"
|
||||
file: "templates/myext-template.md"
|
||||
description: "Override myext's report template"
|
||||
replaces: "myext-template"
|
||||
|
||||
# Command overrides (AI agent workflow prompts)
|
||||
# Presets can override both core and extension commands.
|
||||
# Commands are automatically registered into all detected agent
|
||||
# directories (.claude/commands/, .gemini/commands/, etc.)
|
||||
|
||||
# Override a core command:
|
||||
- type: "command"
|
||||
name: "speckit.specify"
|
||||
file: "commands/speckit.specify.md"
|
||||
description: "Custom specification command"
|
||||
replaces: "speckit.specify"
|
||||
|
||||
# Override an extension command (e.g. from the "myext" extension):
|
||||
- type: "command"
|
||||
name: "speckit.myext.myextcmd"
|
||||
file: "commands/speckit.myext.myextcmd.md"
|
||||
description: "Override myext's myextcmd command with custom workflow"
|
||||
replaces: "speckit.myext.myextcmd"
|
||||
|
||||
# Script templates (reserved for future use)
|
||||
# - type: "script"
|
||||
# name: "create-new-feature"
|
||||
# file: "scripts/bash/create-new-feature.sh"
|
||||
# description: "Custom feature creation script"
|
||||
# replaces: "create-new-feature"
|
||||
|
||||
# CUSTOMIZE: Add relevant tags (2-5 recommended)
|
||||
# Used for discovery in catalog
|
||||
tags:
|
||||
- "example"
|
||||
- "preset"
|
||||
@@ -0,0 +1,24 @@
|
||||
# MyExt Report
|
||||
|
||||
> This template overrides the one provided by the "myext" extension.
|
||||
> Customize it to match your needs.
|
||||
|
||||
## Summary
|
||||
|
||||
Brief summary of the report.
|
||||
|
||||
## Details
|
||||
|
||||
- Detail 1
|
||||
- Detail 2
|
||||
|
||||
## Actions
|
||||
|
||||
- [ ] Action 1
|
||||
- [ ] Action 2
|
||||
|
||||
<!--
|
||||
CUSTOMIZE: This template takes priority over the myext extension's
|
||||
version of myext-template. The extension's original is still available
|
||||
if you remove this preset.
|
||||
-->
|
||||
@@ -0,0 +1,18 @@
|
||||
# Feature Specification: [FEATURE NAME]
|
||||
|
||||
**Created**: [DATE]
|
||||
**Status**: Draft
|
||||
|
||||
## Overview
|
||||
|
||||
[Brief description of the feature]
|
||||
|
||||
## Requirements
|
||||
|
||||
- [ ] Requirement 1
|
||||
- [ ] Requirement 2
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
description: "Self-test override of the specify command"
|
||||
---
|
||||
|
||||
<!-- preset:self-test -->
|
||||
|
||||
You are following the self-test preset's version of the specify command.
|
||||
|
||||
When creating a specification, follow this process:
|
||||
|
||||
1. Read the user's requirements from $ARGUMENTS
|
||||
2. Create a specification document using the spec-template
|
||||
3. Include all standard sections plus the self-test marker
|
||||
|
||||
> This command is provided by the self-test preset.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
description: "Self-test wrap command — pre/post around core"
|
||||
strategy: wrap
|
||||
---
|
||||
|
||||
## Preset Pre-Logic
|
||||
|
||||
preset:self-test wrap-pre
|
||||
|
||||
{CORE_TEMPLATE}
|
||||
|
||||
## Preset Post-Logic
|
||||
|
||||
preset:self-test wrap-post
|
||||
@@ -0,0 +1,66 @@
|
||||
schema_version: "1.0"
|
||||
|
||||
preset:
|
||||
id: "self-test"
|
||||
name: "Self-Test Preset"
|
||||
version: "1.0.0"
|
||||
description: "A preset that overrides all core templates for testing purposes"
|
||||
author: "github"
|
||||
repository: "https://github.com/github/spec-kit"
|
||||
license: "MIT"
|
||||
|
||||
requires:
|
||||
speckit_version: ">=0.1.0"
|
||||
|
||||
provides:
|
||||
templates:
|
||||
- type: "template"
|
||||
name: "spec-template"
|
||||
file: "templates/spec-template.md"
|
||||
description: "Self-test spec template"
|
||||
replaces: "spec-template"
|
||||
|
||||
- type: "template"
|
||||
name: "plan-template"
|
||||
file: "templates/plan-template.md"
|
||||
description: "Self-test plan template"
|
||||
replaces: "plan-template"
|
||||
|
||||
- type: "template"
|
||||
name: "tasks-template"
|
||||
file: "templates/tasks-template.md"
|
||||
description: "Self-test tasks template"
|
||||
replaces: "tasks-template"
|
||||
|
||||
- type: "template"
|
||||
name: "checklist-template"
|
||||
file: "templates/checklist-template.md"
|
||||
description: "Self-test checklist template"
|
||||
replaces: "checklist-template"
|
||||
|
||||
- type: "template"
|
||||
name: "constitution-template"
|
||||
file: "templates/constitution-template.md"
|
||||
description: "Self-test constitution template"
|
||||
replaces: "constitution-template"
|
||||
|
||||
- type: "template"
|
||||
name: "agent-file-template"
|
||||
file: "templates/agent-file-template.md"
|
||||
description: "Self-test agent file template"
|
||||
replaces: "agent-file-template"
|
||||
|
||||
- type: "command"
|
||||
name: "speckit.specify"
|
||||
file: "commands/speckit.specify.md"
|
||||
description: "Self-test override of the specify command"
|
||||
replaces: "speckit.specify"
|
||||
|
||||
- type: "command"
|
||||
name: "speckit.wrap-test"
|
||||
file: "commands/speckit.wrap-test.md"
|
||||
description: "Self-test wrap strategy command"
|
||||
|
||||
tags:
|
||||
- "testing"
|
||||
- "self-test"
|
||||
@@ -0,0 +1,9 @@
|
||||
# Agent File (Self-Test Preset)
|
||||
|
||||
<!-- preset:self-test -->
|
||||
|
||||
> This template is provided by the self-test preset.
|
||||
|
||||
## Agent Instructions
|
||||
|
||||
Follow these guidelines when working on this project.
|
||||
@@ -0,0 +1,15 @@
|
||||
# Checklist (Self-Test Preset)
|
||||
|
||||
<!-- preset:self-test -->
|
||||
|
||||
> This template is provided by the self-test preset.
|
||||
|
||||
## Pre-Implementation
|
||||
|
||||
- [ ] Spec reviewed
|
||||
- [ ] Plan approved
|
||||
|
||||
## Post-Implementation
|
||||
|
||||
- [ ] Tests passing
|
||||
- [ ] Documentation updated
|
||||
@@ -0,0 +1,15 @@
|
||||
# Constitution (Self-Test Preset)
|
||||
|
||||
<!-- preset:self-test -->
|
||||
|
||||
> This template is provided by the self-test preset.
|
||||
|
||||
## Principles
|
||||
|
||||
1. Principle 1
|
||||
2. Principle 2
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Guideline 1
|
||||
- Guideline 2
|
||||
@@ -0,0 +1,22 @@
|
||||
# Implementation Plan (Self-Test Preset)
|
||||
|
||||
<!-- preset:self-test -->
|
||||
|
||||
> This template is provided by the self-test preset.
|
||||
|
||||
## Approach
|
||||
|
||||
Describe the implementation approach.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Step 1
|
||||
2. Step 2
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Dependency 1
|
||||
|
||||
## Risks
|
||||
|
||||
- Risk 1
|
||||
@@ -0,0 +1,23 @@
|
||||
# Feature Specification (Self-Test Preset)
|
||||
|
||||
<!-- preset:self-test -->
|
||||
|
||||
> This template is provided by the self-test preset.
|
||||
|
||||
## Overview
|
||||
|
||||
Brief description of the feature.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Requirement 1
|
||||
- Requirement 2
|
||||
|
||||
## Design
|
||||
|
||||
Describe the design approach.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
@@ -0,0 +1,17 @@
|
||||
# Tasks (Self-Test Preset)
|
||||
|
||||
<!-- preset:self-test -->
|
||||
|
||||
> This template is provided by the self-test preset.
|
||||
|
||||
## Task List
|
||||
|
||||
- [ ] Task 1
|
||||
- [ ] Task 2
|
||||
|
||||
## Estimation
|
||||
|
||||
| Task | Estimate |
|
||||
|------|----------|
|
||||
| Task 1 | TBD |
|
||||
| Task 2 | TBD |
|
||||
Reference in New Issue
Block a user