بنقرة واحدة
create-user-story
Create or import a SpecForge user story through MCP without touching .specs files directly.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Create or import a SpecForge user story through MCP without touching .specs files directly.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use in this repository after completing any new functionality or functional subtask. Enforces a functional commit for the delivered change, followed by a separate version bump using the repository's versionbumper tool and its own independent commit.
SpecForge-local guardrails for workflow views, CLI portal rendering, browser shims, and runtime entrypoints. Use when modifying src-vscode, workflow renderers, portal HTML generation, CLI browser bridges, or SpecForge runtime entrypoints.
Inspect SpecForge user stories, workflow state, current phase, runtime status, lineage, and files through MCP.
Use SpecForge.AI from Codex through the compact MCP facade. Trigger for creating, inspecting, advancing, approving, regressing, or operating on SpecForge user stories.
Advance or approve a SpecForge user-story phase through MCP.
Submit refinement or approval answers for a SpecForge user story through MCP.
| name | create-user-story |
| description | Create or import a SpecForge user story through MCP without touching .specs files directly. |
Use specforge_action.
If the user request is broad, vague, or describes a product goal instead of a concrete user story, do not create stories yet. Ask targeted clarification questions first.
Reach enough detail to identify:
Use 3-7 practical questions per round. Continue asking only while blocking ambiguity remains. Do not invent business-critical requirements just to proceed.
When the answers are concrete enough, split broad goals into small user stories. Each story should deliver one narrow functional increment, be independently reviewable, preserve traceability to the original goal, and avoid over-engineered scope.
For free text:
{
"workspaceRoot": "<absolute repo path>",
"action": "create_user_story",
"params": {
"usId": "US-123",
"title": "Short title",
"kind": "feature",
"category": "core",
"sourceText": "User-story intent",
"actor": "user"
}
}
For a concrete broad goal that should become multiple small stories, use action: "create_user_stories_from_goal":
{
"workspaceRoot": "<absolute repo path>",
"action": "create_user_stories_from_goal",
"params": {
"goalText": "<original user goal plus relevant clarified answers>",
"goalId": "GOAL-123",
"strategy": "small-user-stories",
"actor": "model-on-behalf-of-user",
"stories": [
{
"title": "Narrow functional increment",
"kind": "feature",
"category": "core",
"sourceText": "As a <actor>, I want <behavior> so that <outcome>. Include concrete scope, boundaries, and relevant context.",
"acceptanceCriteria": [
"Concrete observable criterion."
],
"dependencies": [],
"clarifiedAnswers": [
"Relevant answer from the intake conversation."
],
"nonGoals": [
"Explicitly excluded scope."
],
"mvpOutcome": "The customer-visible MVP outcome this slice enables.",
"sliceRationale": "Why this is one small independent increment."
}
]
}
}
For an existing Markdown file, use action: "import_user_story" with sourcePath, usId, title, kind, and category.
Never create .specs/us/** folders or files by hand.