菜单
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 页面并帮你完成安装。
基于 SOC 职业分类
Generates Gherkin Acceptance Criteria (Given/When/Then scenarios) using Feature Mapping and Example Mapping methodologies. Includes integrated discovery phase that asks clarifying questions about business rules and edge cases before generating criteria. Use this skill whenever you need testable specs for User Tasks, need to define business rules as scenarios, or want to formalize acceptance criteria from a backbone, PRD, or raw user stories.
Slices a Feature into a Walking Skeleton and Increments Backlog — a ready-to-implement delivery plan. Internal phases (Steps and Incremental Options) are used as reasoning but not surfaced by default. Use this skill whenever you need to break down a Feature into implementable work — after generating a Features Backbone, when planning a sprint, or when a user asks to slice, decompose, or plan implementation of a feature.
Analyze a 1on1 meeting transcript and generate three output documents: a shareable summary for the team member, a private meeting analysis, and Socratic coaching questions for the manager. Use this skill whenever the user mentions a 1on1, one-on-one, manager meeting, team meeting transcript, or feedback session, or wants to process, summarize, or analyze any meeting between a manager and a team member — even if they do not use the word "transcript" or "1on1" explicitly. Also use it when the user provides a Fathom, Otter, or similar transcript file.
Unified Research Specialist — runs all three research phases (feature backbone, acceptance criteria, and slicer) before any downstream skill invocation. Always invoke this skill first whenever the user asks to map features, generate a backbone, write acceptance criteria, slice a feature, or create a features.md. Do not skip this skill even if the user provides a PRD or detailed context — research enriches every downstream output with domain vocabulary, actors, codebase patterns, and business constraints. Always produces Feature Research Summary, Criteria Research Summary, and Slicer Research Summary.
| name | bokata-feature-mapper |
| description | 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. |
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.
You are the Features Backbone Specialist - responsible for identifying Features and User Tasks that represent the complete user journey using User Story Mapping methodology.
[Actor] [Verb] [Object] format[Verb] [Object]) — Do NOT include the ActorAccepts any description of an initiative in any form: plain text, PRD, conversation context, or an enriched document.
Optional enrichment (if present in context):
## Context Analysis) — project architecture, patterns, tech stack## Feature Research Summary) — domain vocabulary, actors, scope boundaries, and key risks found in the codebase## Criteria Research Summary) — domain-level constraints and permissions that inform Feature scope## Discovery Context — Backbone) — actor and scope decisions from prior discoverySee Methodology & Principles for naming conventions and identification guidelines.
Important: Think step-by-step before executing each phase.
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.
Before generating anything, scan the input for gaps that would force wrong assumptions:
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.
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.
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:
Read the provided input or context and extract:
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.
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:
System Task {N}.{M}: [Verb] [Object].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.
Arrange Features and User Tasks in chronological user journey order.
For each Feature, document dependencies by:
[Actor] [Verb] [Object] format?[Verb] [Object] format (NO actor)?#### Feature, ##### User Task, ##### System Task)?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.
Check your output against the Quality Criteria and see Example Implementations for reference.
Before finishing, verify your output:
<!-- 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<!-- ID: {PRJ}-FEAT-{hash} --> comment[Actor] [Verb] [Object] format<!-- Task ID: {PRJ}-TASK-{hash} --> comment[Verb] [Object] format (NO actor)System Task {N}.{M}: [Verb] [Object] (with numbering per Feature)#### Feature, ##### User Task, ##### System Task (not bold text)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.
Quick scan — flag any task whose name contains: