Specrail Plan Features

Discovery behavior

• Do not assume the full workflow structure from a brief request.
• Ask targeted follow-up questions when features, outcomes, or scope boundaries are unclear.
• Gather all planned features first, or work feature-by-feature if that is easier for the user.
• For each feature, continue asking for additional outcomes until the user says that feature is complete.
• After finishing one feature, ask whether there is another feature to add.
• Continue this loop until the user explicitly says they are done adding features and outcomes.
• If the user gives a broad feature, help break it into smaller, outcome-sized slices.
• If the user gives a broad outcome, ask how to split it into narrower sibling outcomes under the same feature.
• Before creating anything, restate the current feature and outcome list in a compact structure for confirmation.

Validation and ambiguity resolution

• If the user is starting from scratch, gather missing project context before locking in features and outcomes. Ask for platform, language, stack/framework, interface type, and deployment/runtime target when those details are missing.
• If the request is ambiguous, ask clarifying questions before proposing a feature or outcome structure.
• If the user references a feature, outcome, or test that does not exist yet, verify that with specrail_feature_list, specrail_feature_show, specrail_outcome_list, specrail_outcome_show, and specrail_test_list, then ask whether to create it or correct the reference.
• If the request is too broad, say so explicitly and ask whether to continue as-is or refine it into narrower features or outcomes first.
• Keep the conversation anchored in TDD: the feature and outcome structure should lead to clear required tests, and tests must be defined before implementation begins.

Workflow scope rules

• Each feature should describe one clear product capability.
• Each outcome should describe one clear behavior or slice of that feature.
• Do not bundle multiple distinct behaviors into a single outcome.
• If a feature has several behaviors, create multiple sibling outcomes under the same parent feature.

Response formatting

When presenting features and outcomes to confirm, use a compact structured list:

Features to create:
  • calculator — Basic arithmetic operations
    Outcomes:
      1. addition — Verify 2 + 2 = 4
      2. subtraction — Verify 2 - 1 = 1
      3. multiplication — Verify 3 × 4 = 12

After each creation, confirm with: "✓ Created feature calculator with 3 outcomes."

Example

• For a calculator feature, create separate outcomes for addition, subtraction, multiplication, and division.
• Do not create one broad outcome like "calculator operations" that mixes all operations together.
• For the addition outcome, keep the scope focused on addition-specific behavior such as 2 + 2 = 4, 5 + 0 = 5, and 0 + 0 = 0.
• For the subtraction outcome, keep the scope focused on subtraction-specific behavior such as 2 - 2 = 0, 2 - 0 = 2, and 0 - 2 = -2.

If the MCP server was not launched from the project root, pass the workspace path through the cwd argument.

This skill is the planning conversation; the specrail_* tools perform the actual create and activate actions.