speckit-specify

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Spec-Forge Setup (replaces file-based Pre-Execution Checks)

This variant persists the specification in the Spec-Forge database (via its MCP server) instead of creating specs/NNN-name/spec.md. There are no git-branch or extension-hook prerequisites to check here — just resolve the project:

1. Determine the current repository root (absolute path).
2. Call get_or_create_project_by_repo with { repoPath: <repo root> } → note projectId.

Outline

The text the user typed after /speckit-specify in the triggering message is the feature description. Assume you always have it available in this conversation even if $ARGUMENTS appears literally below. Do not ask the user to repeat it unless they provided an empty command.

Given that feature description, do this:

1. Generate a concise short name (2-4 words) for the feature:

   • Analyze the feature description and extract the most meaningful keywords
   • Create a 2-4 word short name that captures the essence of the feature
   • Use action-noun format when possible (e.g., "add-user-auth", "fix-payment-bug")
   • Preserve technical terms and acronyms (OAuth2, API, JWT, etc.)
   • Keep it concise but descriptive enough to understand the feature at a glance
   • Examples:
     • "I want to add user authentication" → "user-auth"
     • "Implement OAuth2 integration for the API" → "oauth2-api-integration"
     • "Create a dashboard for analytics" → "analytics-dashboard"
     • "Fix payment processing timeout bug" → "fix-payment-timeout"

2. Create the feature in Spec-Forge (replaces "Create the spec feature directory"):

   • Call create_feature with { projectId, title: <human-readable title derived from the short name / description> }.
   • This returns a featureId and an auto-numbered slug (e.g. 001-user-auth) — Spec-Forge assigns the sequence number, mirroring the old NNN-<short-name> directory convention.
   • Persist the pointer to .specify/feature.json (this file is already gitignored by the Spec Kit installer — it is machine-local, per-checkout state, exactly like the original feature_directory pointer it replaces):

     {
       "spec_forge_project_id": "<projectId>",
       "spec_forge_feature_id": "<featureId>",
       "feature_slug": "<slug>",
       "feature_title": "<title>"
     }
     

     This allows downstream commands (/speckit-plan, /speckit-tasks, etc.) to locate the feature without relying on git branch name conventions or scanning specs/.