speckit-claim

Claim a spec and commit CLAIMED.md to update the build-order.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/GratefulJinx77/speckit-claude --skill speckit-claim
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: speckit-claim
Source: https://github.com/GratefulJinx77/speckit-claude/tree/main/skills/speckit-claim
Command: npx skills add https://github.com/GratefulJinx77/speckit-claude --skill speckit-claim

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Claiming a spec before starting planning work ensures the build-order page reflects the current development plan by creating CLAIMED.md and wiring the claim into the release workflow.

Core Features & Use Cases

  • Enforces origin/master freshness before a claim.
  • Writes and commits CLAIMED.md locally and pushes it to master via a PR-driven flow.
  • Spawns the speckit-workflow lead as the spec-lifecycle for the claim, coordinating branch creation and downstream tasks.
  • Keeps stakeholders informed by surfacing the claim status for the build-order viewer.

Quick Start

Provide the feature number and optional short name to initiate a claim and land CLAIMED.md on master.

Frequently Asked Questions about speckit-claim

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I claim a spec for development to update the build-order page?

To claim a spec, provide the feature number and optional short name. The workflow creates a feature branch from a fresh origin/master, writes CLAIMED.md locally, commits it, and pushes it via a pull request to update the build-order.

What does CLAIMED.md do in a git pull request workflow?

CLAIMED.md serves as a build-order entry that signals a spec is actively under development. Committing and landing it on master via a PR ensures stakeholders see the current development plan and prevents duplicate work.

Can I claim a spec that is already built or superseded?

No, the claim process enforces status checks to prevent claiming built or superseded specs. It validates the spec state before allowing you to create a feature branch and write the CLAIMED.md file.

How do I handle an existing CLAIMED.md when starting a feature branch?

If an existing CLAIMED.md is found, the workflow requires user confirmation before proceeding. This ensures you intentionally overwrite the previous claim state when fetching origin/master and creating your new branch.

Does claiming a spec require a fresh origin/master fetch?

Yes, the workflow enforces origin/master freshness before initiating a claim. It fetches the latest master state to ensure your feature branch and subsequent CLAIMED.md commit are built on the current codebase.

What happens after landing CLAIMED.md on master?

After landing CLAIMED.md on master, the workflow spawns the speckit-workflow lead to coordinate the spec lifecycle. It then refreshes pins to ensure downstream tasks align with the updated build-order.