Turn a raw bug report into a user story with acceptance criteria, expected/actual behavior, and a reproduction script.
Reads a raw bug report (Jira ticket, GitHub issue, customer email) and produces a structured user story: persona, problem, expected vs actual, acceptance criteria in Given/When/Then form, and a minimal reproduction script.
report_path: a markdown or text file with the raw report.personas: a list of known personas to pick from ({id, label, description}).priority: P0, P1, P2, P3; otherwise inferred from severity language in the report.As a <persona>, I want <outcome>, so that <value>. Outcome is the corrected behavior, value is one sentence on impact.Given <precondition>, When <action>, Then <expected outcome>. Provide at least one happy-path AC and one edge-case AC.crash, data loss, production, customer-facing -> P0/P1; cosmetic -> P3.story-<id>.md with sections: Title, Persona, Problem, Expected Behavior, Actual Behavior, Acceptance Criteria, Reproduction, Environment, Priority, Definition of Done. Stdout prints inferred priority and persona.
Read the AC and confirm each is testable: every Then must reference a verifiable system state (returns 200, displays message, persists row). If any Then is vague ("works correctly"), refine it. Run the reproduction script literally if possible (e.g., curl commands) and confirm the bug occurs; if it doesn't, mark "needs repro confirmation". Cross-check that the persona matches a known one rather than inventing a new role.
Other publishers' experience with this skill. Self-rating is blocked.
Ratings are limited to publishers while the registry is small — sign in and publish a public skill to rate.
No ratings yet. Be the first.
Same domains or capabilities as amitte/user-story-from-bug-report.
Write Given/When/Then acceptance criteria from a user story — happy path plus two edge cases — phrased so QA can write tests against them directly.
Turn a discussion log plus a decision into an Architecture Decision Record with Context, Decision, Consequences, and Alternatives Considered.
Diff two OpenAPI YAML files and produce a backwards-compatibility changelog grouped into breaking, non-breaking, and additive changes.
Detect weeks with meeting overload from a calendar export, suggest blocks to decline, and propose a recurring focus-time policy.
Calendar helper — list_events, get_event, find_free_time (read-only) plus a mutating schedule_event that writes only into allowlisted calendars.
Group a list of commit subjects into Keep-a-Changelog sections (Added, Changed, Fixed, Removed) using Conventional Commits prefixes and content heuristics.