Menu
Generate well-formed user stories from technical context. Use when generating or improving story descriptions for an issue tracker.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Team quality gate as executable instruction. Use when reviewing completed work before merge, or when processing PR review comments received from other reviewers.
Type-safe validated configuration properties from application.yml. Use when adding any externalisable value.
Consistent error handling with named exceptions and global handler. Use when implementing any method that can fail with a business reason.
Consistent, safe log statements with correct levels and no PII. Use when adding or reviewing log statements.
Team standard for improving existing code without changing behaviour. Use when refactoring code.
Team threat model as executable instruction. Use when checking code for security issues before merge.
| name | business-story-narration |
| description | Generate well-formed user stories from technical context. Use when generating or improving story descriptions for an issue tracker. |
When to load it: When generating or improving story descriptions for an issue tracker (Jira, Linear, Azure DevOps, or equivalent). Load alongside the story documents for the current task.
Produces two layers for every story:
The separation matters. The business description sets intent. The acceptance criteria set the contract. Conflating the two produces stories that either over-specify implementation or under-specify expected behavior.
| Input | What it contributes |
|---|---|
| Story documents | Technical scope, components affected, decisions already made |
| Figma design or exported diagram | Visual representation of the user experience |
| Architecture docs | System boundaries, integration points |
| Existing story title or description | Starting point to translate or improve |
Figma: When a design is available, reference it explicitly in your prompt
(#file:figma-export.png or paste the link). The design shows what the user experiences —
the business description should describe that experience, not the components rendering it.
Produce in this order:
Before (technical language in story):
Story implements configuration change in the analytics provider setup. Updates the channel property in the tracking service initializer to read from consumer config rather than falling back to a hardcoded default value. Affects all downstream consumers of the shared component.
After (business language):
User story statement:
As a product team integrating the shared component, I want analytics events to be attributed to my application automatically, so that my reporting reflects accurate usage without manual correction.
Business description:
When a team deploys the component, analytics events are tagged with their application's identifier. No workaround is required. Each consumer sees their own data cleanly separated from others.
Acceptance criteria:
- Given a consumer has provided their identifier, when the component initializes, then all analytics events carry that identifier
- Given no identifier is provided, when the component initializes, then an error is logged and no events are sent with an incorrect default
Out of scope: Changes to the analytics event schema or tracking endpoint.
Technical notes:
Affected component: TrackingService initializer. The channel property currently falls back to a hardcoded default — fix is to read from consumer-supplied config. Tracked under PROJ-1234.
Open Copilot Chat with your story documents loaded. Ask:
"Using the /business-story-narration skill, produce a story description for [story title]."
Provide whatever inputs you have. Review the business layer before copying into your issue tracker.
This skill is a starting point, not a final answer. The output will be close but needs calibration to how your product owners and stakeholders communicate.
The Business description rules section is where language tuning happens. The structure and output format are stable — don't adjust those until the language quality is consistently right first.
