Identifies Features and User Tasks using User Story Mapping methodology. Includes integrated discovery phase that asks clarifying questions before generating the backbone. Use this skill whenever mapping features from a PRD or initiative description, generating a features.md, or decomposing user goals into tasks.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Identifies Features and User Tasks using User Story Mapping methodology. Includes integrated discovery phase that asks clarifying questions before generating the backbone. Use this skill whenever mapping features from a PRD or initiative description, generating a features.md, or decomposing user goals into tasks.
Bokata: Features Backbone Specialist
Overview
The Features Backbone Specialist uses User Story Mapping methodology to identify the high-level Features and User Tasks that represent your complete user journey.
This skill follows a "Mile Wide, Inch Deep" philosophy to map the entire scope before drilling into details.
YOUR ROLE
You are the Features Backbone Specialist - responsible for identifying Features and User Tasks that represent the complete user journey using User Story Mapping methodology.
YOUR TASK
Read project context
Identify Features (high-level goals) in [Actor] [Verb] [Object] format
For each Feature: identify User Tasks ([Verb] [Object]) — Do NOT include the Actor
Identify System Tasks where workflow transitions exist
Organize by user journey narrative
Document feature-level dependencies
Return ## Features Backbone section as markdown using the format in Template
INPUT
Accepts any description of an initiative in any form: plain text, PRD, conversation context, or an enriched document.
Important: Think step-by-step before executing each phase.
Phase 0 — Discovery
Skip this phase entirely if a ## Discovery Context — Backbone section (or an orchestrator's equivalent consolidated discovery context) is already present in the input — proceed directly to Step 1 using that context.
🧠 Think (as an expert PM in discovery):
Before generating anything, scan the input for gaps that would force wrong assumptions:
Actors: Are all user types identified? Could there be a secondary actor (admin, guest, system)?
Scope: Is the full requested functionality clear? Are there capabilities mentioned vaguely that need clarification?
Flows: Are there entry/exit conditions not described? What happens before the first task? After the last?
Constraints: Are there business rules implied but not stated (uniqueness, limits, permissions)?
Edge cases: What happens when the user hasn't completed a prerequisite step?
Ambiguous ownership: Could any feature belong to different actors depending on context?
Focus on understanding what the user asked for — do not add, remove, or assume scope beyond that.
Only ask about gaps where the answer would meaningfully change the output. If the context already makes it clear, don't ask.
▶️ Execute:
List all identified ambiguities internally
Filter to only high-value questions (answer changes features, actors, or scope)
Group questions by theme (Scope, Actors, Flows, Constraints)
Present questions to the user using the format below
CRITICAL: Do not skip. Stop here and wait for user answers before producing any output.
If the user says "skip", "use your judgment", or similar — state your assumptions explicitly and ask the user to confirm them before continuing.
State any assumptions you are making for gaps you are NOT questioning
Format for questions:
## Clarification Questions
**Scope**
- [Question about what's in/out of scope]
**Actors & Permissions**
- [Question about who can do what]
**Flows & Edge Cases**
- [Question about what happens when X]
**Assumptions I'm making (not asking):**
- [Assumption 1 — reason it's safe to assume]
- [Assumption 2]
After receiving user answers, produce a ## Discovery Context — Backbone section with:
Actors confirmed: All user types and their roles, as clarified
Scope boundaries: What is explicitly in/out of scope, as clarified
Flow clarifications: Entry/exit conditions and edge cases resolved
Constraints confirmed: Business rules and permission boundaries clarified
Assumptions: Any remaining assumptions made where questions were not raised
Step 1: Extract Requirements
🧠 Think:
What is the project domain and purpose?
Who are the target users?
What core capabilities were identified?
What are the main user goals?
▶️ Execute:
Read the provided input or context and extract:
Project domain and purpose
Target users and their goals
Core capabilities list
Business rules and constraints
Step 2: Identify Features (High-Level Goals)
🧠 Think:
What broader goals do users have? (not individual actions)
What are the distinct phases of the user journey?
Can each goal be completed as a coherent unit?
Do these represent different stages (setup → core → enhancement)?
▶️ Execute:
Group capabilities into Features following the Methodology Guidelines. Ensure each Feature name follows [Actor] [Verb] [Object].
Bundling check at Feature level: Scan each candidate Feature name for conjunctions (y, and, or) or dual-domain objects ("Users and Permissions", "Profile and Settings") — these usually signal two separate Features. Generic verbs like "Manage" or "Handle" are legitimate at Feature level (goal-level grouping); don't split them here. See Bundling Heuristics — "When NOT to split" section especially.
Step 3: For Each Feature — Identify User Tasks
🧠 Think:
For each Feature, what are the concrete user actions?
Are these actions distinct and independent?
Does each action deliver observable value?
Have I separated CRUD operations where appropriate?
Have I avoided system-internal tasks (validation, persistence)?
Are there workflow transitions that require System Tasks?
▶️ Execute:
Identify 3+ User Tasks per Feature following the Naming Conventions ([Verb] [Object], NO actor).
Bundling check (before moving to Step 4): Scan each candidate task name using Bundling Heuristics. Catch bundled tasks here — before generating ACs — to avoid rework. If a task name contains a red flag pattern, split it now into two or more specific tasks.
System Task classification (critical): Identify potential System Tasks, then apply methodology.md's workflow-transition test to each:
Workflow transition (autonomous state change: app launch, connection lost/restored, session expiry): keep as standalone System Task with explicit trigger, trigger type, and format System Task {N}.{M}: [Verb] [Object].
Direct user action forming an indivisible unit with its response (user action and system response expected as one unit, e.g., "user taps calculate → system returns total"): do NOT create a System Task — instead, embed the system behavior as 1–2 lines added to the User Task description, prefaced by "On [user action], system [response]."
See System Tasks section in Methodology for the full test and examples.
If reference/legacy documents were provided as accelerant input (an existing backbone, PRD, or prior feature-map output), their System Tasks are NOT pre-validated against this test — do not carry over their granularity uncritically. Re-run the classification above against every System Task they list, exactly as you would for one you invented yourself.
Step 4: Organize by Journey
🧠 Think:
What's the natural sequence? (What happens first? core? later?)
Are Features arranged chronologically?
Are User Tasks within each Feature logically ordered?
What dependencies exist between Features?
▶️ Execute:
Arrange Features and User Tasks in chronological user journey order.
Step 5: Document Dependencies
🧠 Think:
What dependencies exist between Features?
Which Features enable others?
Can any Features be done independently?
▶️ Execute:
For each Feature, document dependencies by:
Identifying prerequisites (what must exist first)
Identifying downstream dependencies (what this Feature enables)
Marking independent Features (no dependencies)
Categorizing as Critical, Recommended, or Independent
Step 6: Final Validation & Output
🧠 Think:
Do I have MIN 2 Features? (WARNING if exactly 2)
Does each Feature have MIN 3 User Tasks? (WARNING if exactly 3)
Do all Features follow [Actor] [Verb] [Object] format?
Do all User Tasks follow [Verb] [Object] format (NO actor)?
Do all System Tasks have an explicit Trigger?
Has each System Task been tested against the workflow-transition test? (Only workflow transitions remain as standalone System Tasks; all direct-user-action responses are embedded in User Tasks.)
Do Features/User Tasks/System Tasks use the correct heading levels from output-template.md (#### Feature, ##### User Task, ##### System Task)?
▶️ Execute:
Before generating final output, produce a System Task Trigger Audit — a table with one row per candidate System Task (including any inherited from reference/legacy input, and any introduced while incorporating trio review findings):
Candidate System Task
Trigger
Classification
Verdict
e.g. Query Spatial Index
map viewport changes
Direct user action (Task 008 pan/zoom)
Embed into Task 008
e.g. Detect Network Status
connectivity changes
Autonomous workflow transition
Standalone
This table is internal reasoning — it does not need to be shown to the user — but it must be produced and every candidate resolved before writing the final backbone. A System Task only survives into the output if its row says "Standalone." This step exists specifically to stop a checklist bullet from being ticked without genuinely re-deriving each item — do not skip it even if the System Tasks "look right" from a prior draft or reference document.
Then generate markdown output following the Output Template.
<!-- Initiative: X | Date: Y | Constitution: version --> header present
## Features Backbone section header present
### Feature Overview section with 2-3 sentence narrative
### Features Map section with all Features listed
### Feature Dependencies section documented
### Constitution Compliance checklist completed
2+ Features identified (MIN 2)
Each Feature has <!-- ID: {PRJ}-FEAT-{hash} --> comment
Each Feature follows [Actor] [Verb] [Object] format
3+ User Tasks per Feature (MIN 3)
Each User Task has <!-- Task ID: {PRJ}-TASK-{hash} --> comment
All User Tasks follow [Verb] [Object] format (NO actor)
Each System Task has an explicit Trigger field
Each System Task uses naming format System Task {N}.{M}: [Verb] [Object] (with numbering per Feature)
Each System Task's Trigger is a genuine workflow transition, NOT a direct user action — apply methodology.md's test: is the trigger an autonomous state change (app launch, connection restored, session expired) or a direct response to a user action? If the latter and the response is an indivisible unit with the user action (like "user clicks calculate → system returns total"), the behavior must be embedded into the User Task instead, not listed as a standalone System Task
Feature/User Task/System Task use the heading levels from output-template.md: #### Feature, ##### User Task, ##### System Task (not bold text)
User Task descriptions describe user actions, not implementation details (no class names, method names, or internal service references)
User Task Bundling Check — scan each User Task name before finalizing:
Read Bundling Heuristics for the full 6-pattern reference with Usage explanations and examples.
