メニュー
Use when a product manager or product owner wants to create a new story, bug, or task - guides them interactively through writing quality issues with proper acceptance criteria and technical details. Supports Jira and Azure DevOps.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when asked for a codebase scorecard, quality audit, 9-dimension assessment, post-merge/refactor/release health review, or due-diligence review.
Guide a product owner through defining a feature — UI, backend, or full-stack. Conducts a structured interview that branches based on feature type, then produces a structured Feature document. Use when a PO wants to define a new feature, plan a screen flow, document an API, or describe a backend capability. Examples: "let's define a new feature", "I want to plan a UI flow", "help me define an API feature", "plan a backend service", "/feature-writer".
Break a Feature into individual stories — one per user action, CRUD operation, or backend operation — and create each one interactively using the story-writer skill. Use after /feature-writer, or when given a Feature to decompose. Supports UI, backend, and full-stack features. Supports Jira and Azure DevOps. Examples: "break this feature into stories", "split this feature into stories", "/story-splitter".
Use when asked to evaluate, review, or score a story or bug for quality, readiness, or completeness - especially when a product owner wants feedback before refinement or sprint planning. Supports Jira, Azure DevOps, or pasted content.
Use this skill when performing a security review of a codebase, app, or system design. Triggers include pre-launch security checks, post-incident audits, reviewing auth/authz systems, evaluating third-party integrations, or any request for adversarial threat modeling.
Systematically analyze bugs, failures, or unexpected behavior to identify root causes. Examines code, data, dependencies, and logs without proposing fixes, producing a structured analysis that surfaces assumptions, evidence, gaps, and the simplest path forward.
| name | story-writer |
| description | Use when a product manager or product owner wants to create a new story, bug, or task - guides them interactively through writing quality issues with proper acceptance criteria and technical details. Supports Jira and Azure DevOps. |
Interactive guided interview for writing high-quality work items. Collects all required information through conversation, produces a structured document, and optionally creates the item in a tracking system (Jira or Azure DevOps).
Announce at start: "I'm using the story-writer skill to help you create a quality work item."
Check $ARGUMENTS for a story brief (passed from story-splitter) and/or a TRACKING SYSTEM block.
If a brief is present, extract what's already provided and skip or pre-fill the corresponding interview questions:
| Brief field | Pre-fills | Action |
|---|---|---|
Type: Story | Step 1 (Issue Type) | Skip — announce "Creating a Story" |
Title: | Q2 (Title) | Pre-fill — show and confirm: "Proposed title: [title]. Does this work, or would you like to change it?" |
CRUD Verb: | Q4 (CRUD Verb) | Pre-fill — show and confirm |
This story covers: | Q3 (Description) | Use as starting context — still ask the PO to expand it into a full user journey |
Relevant screens / resources: | Q1 (Component), Q5 (UI Elements) | Use as context — still confirm component and ask about specific inputs |
Non-happy paths: | Q6 (Validation), Q8 (AC) | Use as context — weave into AC draft |
Story Scope: Backend | Step 1 (Issue Type) | Skip scope question — use Step 2C |
Story Scope: UI or Story Scope: Vertical Slice | Step 1 (Issue Type) | Skip scope question — use Step 2A |
TRACKING SYSTEM block | Step 4 (Create Work Item) | Use directly — skip asking which system |
For any field not in the brief, ask the question as normal.
When running standalone (no brief), run the full interview from Step 1.
Ask:
"Are we writing a Story, Bug, or Task?"
Then determine the story scope:
How to determine scope: If the brief includes a Story Scope: Backend field, use Step 2C. If the PO says "Story", ask: "Does this story involve UI changes, or is it a backend-only change (API, service, data pipeline, infrastructure)?" UI or vertical slice -> Step 2A. Backend-only -> Step 2C.
Ask each question one at a time. Wait for the answer before asking the next. Do not batch questions.
"Which component(s) or area(s) of the product does this affect?"
"Write the story title. A good title completes the sentence: 'After this story, the [persona] will be able to...' — state the deliverable, not the task steps.
Good: 'Flagging a message for SMS responses when a user creates a new template' Bad: 'Change navigation order and rename My Business Rules to My BRs'"
"Describe the user journey. Include: who is the persona (admin, member, guest, etc.), what they see, and what they do. Start with 'As a [persona]...' and describe the experience from the user's perspective — not the database schema or code changes."
"What is the primary CRUD verb for this story?
- Create — user adds something new
- Read — user views or lists something
- Update — user edits something existing
- Delete — user removes something
If more than one applies, we should consider splitting the story."
"What input fields, buttons, or UI elements are involved? For each input, what is its data type? (text, number, date, dropdown, checkbox, image, etc.)"
"For each input field, what validation rules apply?
- What makes it invalid?
- What error message should appear?
- Does a failed validation block the action (prevent save/navigation)?
- Are there any format masks? (phone, zip, date, etc.)"
"What feedback does the user receive after completing the action? For example: success toast, confirmation modal, redirect to another page. Please specify the exact message text if possible."
"Let's write the Acceptance Criteria. Based on your answers, here's a draft — review and expand it:
[Generate a numbered draft AC from all prior answers. Group with sub-points. Cover Screen Events, UI Definition, User Actions, User Feedback, and Validation as applicable to the CRUD verb.]
Make sure each criterion is numbered and specific. Avoid vague statements like 'data is saved correctly' — specify the exact field, value, and outcome."
"Are there any technical details developers should know? For example: API endpoints to call, data model changes, third-party integrations, known constraints, or performance considerations. Skip if none."
"What priority should this be assigned? Blocker / High / Medium (default) / Low / Lowest"
"Is this a child of an existing Feature or Epic? If so, provide the work item key or ID. Otherwise, skip."
Ask each question one at a time. Do not batch questions.
"Which component(s) or area(s) of the product is this bug in?"
"Write the bug title. A good title names the broken behavior AND the affected area.
Good: 'Payment form does not validate expiration date on submit' Bad: 'Payment not working'"
"Provide numbered steps to reproduce the bug. Be specific enough that someone unfamiliar with the feature can follow them from scratch."
"What should happen — what is the correct behavior?"
"What actually happens — what is the broken behavior?"
"Provide environment context:
- Browser and version
- Operating system
- User role / account type
- Any relevant data context (e.g., specific feature flag state, contract status)"
"What does 'fixed' look like? Write the acceptance criteria — what must be true for this bug to be considered resolved? Be specific, not just 'it works'."
"Any technical details, error logs, console output, or stack traces that would help developers? Skip if none."
"What priority? Blocker / High / Medium (default) / Low / Lowest"
Use this path for stories that are purely backend — no UI component. Ask each question one at a time.
"Which service(s) or area(s) of the system does this affect?"
"Write the story title. A good title names the operation and resource — what the system will be able to do when this is done.
Good: 'Create order via REST API', 'Process payment.failed events from Stripe webhook' Bad: 'Update database schema', 'Backend work for orders'"
"Describe what this operation does and who/what consumes it. Start with 'This operation allows [consumer] to...' and describe the behavior from the caller's perspective — not the internal implementation."
"What type of operation is this?
- API endpoint — a synchronous request/response operation
- Event handler — processes an async event
- Event publisher — emits an event for other services
- Scheduled job — runs on a schedule or trigger
- Data migration — one-time or versioned data transformation
- Integration — connects to an external system
If more than one applies, we should consider splitting the story."
"What data goes in? Describe the categories of input (e.g., 'customer details', 'order line items') and any required vs. optional fields at a high level. For APIs: what does the request look like?"
"What data comes out? Describe the response or output. For APIs: what does a successful response look like? What status codes are used?"
"What are the error scenarios and how should each be handled?
- What makes a request invalid? (validation errors)
- What happens if a dependency is unavailable? (timeouts, retries, fallbacks)
- What error codes or messages should be returned?
- Are there idempotency requirements?"
"Let's write the Acceptance Criteria. Based on your answers, here's a draft — review and expand it:
[Generate a numbered draft AC from all prior answers. Cover: operation behavior, input validation, success response, error responses, edge cases, and any non-functional requirements.]
Make sure each criterion is numbered and specific. Avoid vague statements like 'handles errors gracefully' — specify the exact error, response code, and behavior."
"Any technical details developers should know? For example: auth requirements, rate limits, data model changes, migration steps, infrastructure dependencies, or performance constraints. Skip if none."
"What priority should this be assigned? Blocker / High / Medium (default) / Low / Lowest"
"Is this a child of an existing Feature or Epic? If so, provide the work item key or ID. Otherwise, skip."
Before creating the work item, show a structured preview:
Issue Preview
---------------------------------------------
Type: [Story / Bug / Task / Feature]
Summary: [title]
Component(s): [component(s)]
Priority: [priority]
Description:
[description text]
Acceptance Criteria:
[AC text]
Technical Details:
[tech details or "(none)"]
---------------------------------------------
Shall I create this work item? (yes / edit [section name] / cancel)
If a TRACKING SYSTEM block was provided (from story-splitter or feature-writer), use it directly — do not re-ask the PO which system to use. Set the parent from the block if provided and Q11 was skipped.
If no tracking context was provided (standalone mode), ask:
"Would you like me to create this in a tracking system? If so, which one — Jira, Azure DevOps, or none (just keep the document)?"
Ask for the project key and cloud ID if not already known from the tracking context. Use the appropriate Jira MCP tool to create the issue with:
| Field | Value |
|---|---|
projectKey | from tracking context or PO |
issueTypeName | Story / Bug / Task / Feature (as selected) |
summary | from Q2 |
description | structured description (see format below) |
parent | from tracking context or Q11, if provided |
priority | from Q10 |
components | from Q1, if the project supports components |
Ask for the organization and project name if not already known from the tracking context. Use the appropriate Azure DevOps MCP tool to create the work item with:
| Field | Value |
|---|---|
| Work item type | Story / Bug / Task / Feature (as selected) |
| Title | from Q2 |
| Description | structured description (see format below) |
| Acceptance Criteria | from Q8 |
| Priority | from Q10 |
| Area Path | from Q1, if applicable |
| Parent | from tracking context or Q11, if provided |
Present the final formatted document for the PO to copy into their system manually.
Construct from interview answers:
*Steps to Reproduce:*
1. [step]
2. [step]
*Expected Behavior:*
[expected]
*Actual Behavior:*
[actual]
*Environment:*
- Browser: [browser]
- OS: [OS]
- User Role: [role]
- Context: [context]
After the work item is created (or document delivered):
Output confirmation:
"Created [work item ID] — [title]"
If the incoming brief contained PREFINEMENT: defer (story-writer was invoked by story-splitter as part of a batch), skip the prefinement offer — the splitter runs a single batch review over all stories at the end. Just return after confirmation.
Otherwise (run standalone), ask: "Would you like me to run a quality review on this work item?"
If yes, invoke the story-prefinement skill, passing the work item details and the TRACKING SYSTEM block if available.
| Situation | Coaching Response |
|---|---|
| Title describes a task ("Add checkbox to form") | Redirect: "After this story, the [persona] will be able to..." — what's the deliverable? |
| Description lists database columns or code changes | Redirect: "Describe what the user sees and does, not what changes in the code." |
| AC is vague ("data saves correctly") | Push back: "Be specific — which field? What valid values? What exact error message?" |
| Multiple CRUD verbs in one story | Flag: "This story covers both Create and Update. Should we split it into two?" |
| No validation rules for inputs | Ask: "For [field name]: what's invalid? What's the error message? Does it block saving?" |
| Bug title is too vague ("it's broken") | Require: "Name the broken behavior + the area. What exactly doesn't work, where?" |
| Missing bug environment | Always follow up: "What browser, OS, and user role were you using when this occurred?" |
| AC for bug is just "it works" | Push back: "What specifically must be true? What outcome verifies the fix?" |