Spec
warpdotdev-demos/cloud-factory-demo
Coordinate spec-driven development for a GitHub, Jira, Linear, or other issue-tracker issue marked ready-to-spec by using write-product-spec and write-tech-spec, creating PRODUCT.md and TECH.md…
Support spec-driven development in projects that use OpenFastTrace, a system-requirements document in doc/systemrequirements.md, an arc42-style design in doc/design.md, and per-issue task plans in…
Install Oft Spec Driven Development
$ npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install itsallcode/openfasttrace oft-spec-driven-development --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/itsallcode/openfasttrace.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/openfasttrace-spec-driven-development .claude/skills/oft-spec-driven-development && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "oft-spec-driven-development" agent skill from https://github.com/itsallcode/openfasttrace/tree/main/.agents/skills/openfasttrace-spec-driven-development into .claude/skills/oft-spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "oft-spec-driven-development", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/itsallcode/openfasttrace/tree/main/.agents/skills/openfasttrace-spec-driven-developmentType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install itsallcode/openfasttrace oft-spec-driven-development --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/itsallcode/openfasttrace.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/openfasttrace-spec-driven-development .agents/skills/oft-spec-driven-development && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "oft-spec-driven-development" agent skill from https://github.com/itsallcode/openfasttrace/tree/main/.agents/skills/openfasttrace-spec-driven-development into .agents/skills/oft-spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "oft-spec-driven-development", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install itsallcode/openfasttrace oft-spec-driven-development --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/itsallcode/openfasttrace.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/openfasttrace-spec-driven-development .cursor/skills/oft-spec-driven-development && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "oft-spec-driven-development" agent skill from https://github.com/itsallcode/openfasttrace/tree/main/.agents/skills/openfasttrace-spec-driven-development into .cursor/skills/oft-spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "oft-spec-driven-development", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/itsallcode/openfasttrace.git --path .agents/skills/openfasttrace-spec-driven-development--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install itsallcode/openfasttrace oft-spec-driven-development --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/itsallcode/openfasttrace.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/openfasttrace-spec-driven-development .gemini/skills/oft-spec-driven-development && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "oft-spec-driven-development" agent skill from https://github.com/itsallcode/openfasttrace/tree/main/.agents/skills/openfasttrace-spec-driven-development into .gemini/skills/oft-spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "oft-spec-driven-development", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install itsallcode/openfasttrace oft-spec-driven-developmentInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/itsallcode/openfasttrace.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/openfasttrace-spec-driven-development .github/skills/oft-spec-driven-development && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "oft-spec-driven-development" agent skill from https://github.com/itsallcode/openfasttrace/tree/main/.agents/skills/openfasttrace-spec-driven-development into .github/skills/oft-spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "oft-spec-driven-development", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install itsallcode/openfasttrace oft-spec-driven-development --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/itsallcode/openfasttrace.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/openfasttrace-spec-driven-development .opencode/skills/oft-spec-driven-development && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "oft-spec-driven-development" agent skill from https://github.com/itsallcode/openfasttrace/tree/main/.agents/skills/openfasttrace-spec-driven-development into .opencode/skills/oft-spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "oft-spec-driven-development", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
oft-spec-driven-development- GitHub stars
- 198
- Token cost
- ~2k tokens
- SKILL.md length
- 828 words
- Files
- 1
- Skills in repo
- 3
- Repo updated
- First seen
- Licence
- GPL-3.0
At a glance
Support spec-driven development in projects that use OpenFastTrace, a system-requirements document in doc/systemrequirements.md, an arc42-style design in doc/design.md, and per-issue task plans in…
- Works in 5 steps: Read Before Planning → Create Or Update The Changeset → Derive The Plan From The Spec → …
- AI agent must turn a new GitHub issue
- SKILL.md covers Project Contract, OFT Reference, Operating Mode and Required Workflow, plus 4 more sections
- Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
What it does
Oft Spec Driven Development is an agent skill from itsallcode/openfasttrace. Support spec-driven development in projects that use OpenFastTrace, a system-requirements document in doc/systemrequirements.md, an arc42-style design in doc/design.md, and per-issue task plans in doc/changesets/. Use when AI agent must turn a new GitHub issue or Jira ticket into a changeset plan, update traced requirements and design before or alongside code, and keep all implementation and verification work aligned with the project's quality requirements.
Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Development, covering Spec-driven development, Design tokens and PRD writing. It works with GitHub, Jira and Java. The repository describes itself as: Open source requirement tracing suite. The licence is GPL-3.0.
When your agent uses it
- AI agent must turn a new GitHub issue
- Jira ticket into a changeset plan
- Update traced requirements and design before
- Keep all implementation and verification work aligned with the projects quality requirements
Example prompts
- “/oft-spec-driven-development”
Workflow steps
5 steps, taken from the step headings in SKILL.md.
What it can do on your machine
Read from SKILL.md and the folder at commit be8537e. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Oft Spec Driven Development loads about 2k tokens when it runs. Until then it costs about 124 tokens; SKILL.md has 828 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from itsallcode/openfasttrace at commit be8537e, republished under its GPL-3.0 licence (© itsallcode). 828 words, ~2,030 tokens.
Download SKILL.mdSave it as
.claude/skills/oft-spec-driven-development/SKILL.md (or your agent's skills folder).- name
- oft-spec-driven-development
- description
- Support spec-driven development in projects that use OpenFastTrace, a system-requirements document in `doc/system_requirements.md`, an arc42-style design in `doc/design.md`, and per-issue task plans in `doc/changesets/`. Use when AI agent must turn a new GitHub issue or Jira ticket into a changeset plan, update traced requirements and design before or alongside code, and keep all implementation and verification work aligned with the project's quality requirements.
OFT Spec-Driven Development
Work from specification to implementation. Treat the requirements, design, and quality documents as the source of truth for both planning and changes.
Project Contract
Use these repository conventions unless the user explicitly says this project differs:
- System requirements live in
doc/system_requirements.mdand use OpenFastTrace notation. - Design lives in
doc/design.mdand its referenced arc42 chapters underdoc/design/. - Per-issue implementation plans live in
doc/changesets/using<issue-number>-<short-kebab-title>.md. - Quality requirements are authoritative for code, tests, tracing, and build gates. See
doc/design/quality_requirements.mdordoc/spec/design/quality_requirements.md.
OFT Reference
For OFT syntax, tracing behavior, selective tracing, and common error handling, read the upstream OpenFastTrace skill first:
https://raw.githubusercontent.com/itsallcode/openfasttrace/refs/heads/main/.agents/skills/openfasttrace/SKILL.md
Do not restate OFT rules from memory when the upstream reference is available. Use it as the normative workflow for:
- specification item syntax and IDs
Needs,Covers, forwarding, and coverage tags- selective tracing and trace interpretation
- diagnosing broken trace links
Operating Mode
When the user gives you a new issue link, derive the work plan from:
- the issue or ticket itself
doc/system_requirements.mddoc/design.mdand the relevant linked design chapters- the quality requirements document
- the current code and tests
Do not jump straight to code. First, determine whether the issue changes:
- user-visible behavior
- traced requirements or scenarios
- design decisions, building blocks, runtime behavior, or constraints
- verification expectations from the quality requirements
If the ticket conflicts with the existing specification or design, surface that conflict and repair the documents before or together with implementation.
Required Workflow
1. Read Before Planning
Before drafting or editing a changeset, inspect:
doc/system_requirements.mddoc/design.md- the specific design chapters relevant to the issue
doc/design/quality_requirements.mddoc/changesets/README.md- existing changesets that touch the same feature area
Read code only after you understand the spec and design impact.
2. Create Or Update The Changeset
For a new issue, create doc/changesets/<issue-number>-<short-kebab-title>.md.
Use the established repository style:
- title with tracker reference and short summary
GoalScopewith explicit in-scope and out-of-scope bulletsDesign References- optional
Strategywhen the issue needs implementation direction Task List
Keep the task list ordered. Put specification and design work before production-code work unless the issue is strictly internal and does not affect traced artifacts.
3. Derive The Plan From The Spec
When building the task list, map the issue onto the requirement hierarchy from the quality requirements:
featreqscndsnimplutestoritest
Use that mapping to decide what must change:
- If behavior changes for users, update or add
reqandscnitems indoc/system_requirements.md. - If architecture or technical behavior changes, update or add
dsnitems and relevant arc42 design sections. - If a lower layer adds no new information, prefer OFT forwarding instead of redundant new items.
- Ensure each runtime design item covers only one scenario unless forwarding is the better fit.
4. Treat Quality Requirements As Non-Negotiable
Every plan and implementation must satisfy doc/design/quality_requirements.md.
Always derive verification tasks from that document, including as applicable:
- clean trace results for the requirement and design artifact types in scope
- tests that follow the naming, assertion, and parameter-validation rules
- coverage expectations
- plugin verification and build checks
- dependency-policy constraints
- static-analysis and security gates
If an issue required violating a documented quality rule, stop and raise it explicitly instead of silently proceeding.
Show full SKILL.md (301 more words)Show less
5. Implement In Spec-First Order
Preferred order:
- requirements updates
- design updates
- changeset task-plan update
- production code
- tests
- OFT trace and project verification
For small internal refactors, you may keep the docs unchanged only when the traced requirements and design remain fully accurate.
Changeset Template
Use this template and adapt it to the issue:
# GH-<number> <title>
## Goal
<What the issue achieves and why it matters.>
## Scope
In scope:
* <planned change>
Out of scope:
* <explicit non-goal>
## Design References
* [System Requirements](<path-to-specs>/system_requirements.md)
* [Quality Requirements](<path-to-specs>/design/quality_requirements.md)
* [<Relevant design chapter>](<path-to-specs>/design/<chapter>.md)
## Strategy
<Only include when useful. Describe the intended implementation direction.>
## Task List
- [ ] Create and checkout a new Git branch `<issue-type>/<issue-number>-<issue-title-lower-kebab-case>`
### Requirements And Design
- [ ] <system requirements update>
- [ ] Stop and ask user for a review of the system requirements
- [ ] <design update>
- [ ] Stop and ask user for a review of the design
### Implementation
- [ ] <production code task>
### Verification
- [ ] <tests derived from quality requirements>
- [ ] Keep the OpenFastTrace trace clean
- [ ] Keep required build and plugin verification tasks green
### Update user documentation
- [ ] Update the end user documentation in `README.md` and / or `doc/user_guide/user_guide.md`
## Version and Changelog Update
- [ ] Raise the version to 0.3.0 (this is a feature release)
- [ ] Write the changelog entry for 0.3.0Keep verification items concrete. Do not leave them as generic "run tests" placeholders when the quality requirements demand more specific checks.
Issue Intake Rules
When the user provides a tracker link:
- extract the issue number for the changeset filename
- derive a short kebab-case title from the issue title
- summarize the requested outcome in repository terms
- identify impacted requirements, scenarios, design sections, code areas, and tests
- draft the changeset before substantial implementation
If the issue text is unavailable, ask the user for the issue content or a short summary. Do not invent requirements from the URL alone.
Editing Rules
- Preserve existing OFT IDs unless the semantics changed.
- When semantics change, revise the item thoughtfully instead of making arbitrary ID churn.
- Keep requirements user-facing and design technical; do not duplicate the same text in both places.
- Prefer precise task items over broad epics in changesets.
- Keep comments in code minimal and let naming carry intent, consistent with the quality requirements.
- Avoid adding dependencies unless a documented design decision approves them.
Verification Rules
Before closing work, verify at the level the issue changed:
- OFT artifacts stay syntactically valid and traceable.
- Requirement, scenario, design, implementation, and tests remain consistent.
- Automated tests cover the new behavior at the correct level.
- Repository quality gates required by
doc/design/quality_requirements.mdare either run or explicitly called out as not run.
If you cannot run a required verification step, state that clearly in the final report and leave the changeset task unchecked.
© itsallcode, GPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in .agents/skills/openfasttrace-spec-driven-development of itsallcode/openfasttrace.
Open the folder on GitHubat commit be8537e
Compare with similar skills
Oft Spec Driven Development next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Oft Spec Driven Development this skillitsallcode/openfasttrace | 198 | — | ~2k | Automated safety check: Pass | GPL-3.0 | |
| Specwarpdotdev-demos/cloud-factory-demo | 320 | — | ~2.1k | Automated safety check: Pass | MIT | |
| PRP Implementation PlannerWirasm/prp | 2.3k | — | ~4.1k | Automated safety check: Pass | MIT | |
| PRP PlanWirasm/prp | 2.3k | — | ~4k | Automated safety check: Pass | MIT | |
| CCPM Project Managementautomazeio/ccpm | 8.4k | — | ~1.1k | Automated safety check: Pass | MIT | |
| Creating Description For Gh PRredis/jedis | 12k | — | ~838 | Automated safety check: Pass | MIT |
Similar skills
PRP Implementation Planner
Wirasm/prp
Turns a PRD, issue or description into an implementation-ready plan grounded in codebase evidence, adding root-cause analysis for bugs and publishing issue plans back to the issue.
PRP Plan
Wirasm/prp
Writes an implementation-ready plan for a feature, bug fix, refactor or chore from a PRD, issue or description, grounded in codebase evidence, and can post it back to the source issue.
CCPM Project Management
automazeio/ccpm
Runs a spec-driven workflow from PRD to epic to GitHub issues to parallel agents, with status, standup and blocked-work reports from bundled scripts.
- Official
Creating Description For Gh PR
redis/jedis
Generate a clear, concise GitHub PR title and description from the diff between two local git branches, and save it to prDescription.md in the repo root.
Review Spd
zhu1090093659/spec_driven_develop
Findings-first code review workflow for AI coding agents. An agent skill from zhu1090093659/spec_driven_develop.
More from itsallcode/openfasttrace
Openfasttrace Reverse Specs
itsallcode/openfasttrace
Reverse-engineer missing or incomplete OpenFastTrace system requirements and arc42-style design documentation from a project's user guide, existing documentation, tests, and code.
Openfasttrace
itsallcode/openfasttrace
Work with OpenFastTrace requirement tracing, including specification items, artifact IDs, coverage markers, Markdown and Gherkin syntax, and trace validation.
Related
Categories
Questions about Oft Spec Driven Development
What does Oft Spec Driven Development do?
Support spec-driven development in projects that use OpenFastTrace, a system-requirements document in doc/systemrequirements.md, an arc42-style design in doc/design.md, and per-issue task plans in…. Oft Spec Driven Development is an agent skill from itsallcode/openfasttrace.md, and per-issue task plans in doc/changesets/.
When should I use Oft Spec Driven Development?
Oft Spec Driven Development fits situations like: AI agent must turn a new GitHub issue; jira ticket into a changeset plan; update traced requirements and design before; keep all implementation and verification work aligned with the projects quality requirements.
How do I install Oft Spec Driven Development in Claude Code?
Run `npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a claude-code`. Or copy the skill folder (.agents/skills/openfasttrace-spec-driven-development in itsallcode/openfasttrace) into .claude/skills/oft-spec-driven-development in your project. Claude Code loads it when a task matches its description.
How do I install Oft Spec Driven Development in Codex?
Run `npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a codex`. Or copy the skill folder (.agents/skills/openfasttrace-spec-driven-development in itsallcode/openfasttrace) into .agents/skills/oft-spec-driven-development in your project. Codex loads it when a task matches its description.
Can I use Oft Spec Driven Development in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add itsallcode/openfasttrace --skill oft-spec-driven-development -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/oft-spec-driven-development, .gemini/skills/oft-spec-driven-development, .github/skills/oft-spec-driven-development and .opencode/skills/oft-spec-driven-development in your project.
What does Oft Spec Driven Development need to run?
SKILL.md names no scripts, command-line tools or credentials: Oft Spec Driven Development is instructions for the agent only.
Does Oft Spec Driven Development access the network?
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Is Oft Spec Driven Development safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Oft Spec Driven Development use?
Oft Spec Driven Development is published under the GPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Oft Spec Driven Development use?
About 2k tokens (SKILL.md is roughly 8.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Oft Spec Driven Development?
Skills that share tags, products or a category with Oft Spec Driven Development: Spec (warpdotdev-demos/cloud-factory-demo, 320 stars), PRP Implementation Planner (Wirasm/prp, 2.3k stars), PRP Plan (Wirasm/prp, 2.3k stars) and CCPM Project Management (automazeio/ccpm, 8.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Oft Spec Driven Development?
itsallcode (a GitHub organization) maintains it in itsallcode/openfasttrace, which has 198 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on October 7, 2026.
Source: itsallcode/openfasttrace on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.