# Story Forge

> Analyze ServiceNow user stories and requirements for completeness, testability, and platform fit. Identifies missing acceptance criteria, ambiguous language, and ServiceNow-specific gaps before development starts.

- Skill: `jxrlabs/story-forge` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jxrlabs/story-forge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jxrlabs/story-forge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: JXRLABS (https://skillmd.com/u/jxrlabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jxrlabs/story-forge

---


# Story Forge

## Purpose

Analyze ServiceNow user stories, requirements, and acceptance criteria for completeness, clarity, and platform-specific feasibility before they enter a sprint.

## When to Use

- A business analyst or product owner has drafted a story and wants a second opinion before refinement
- A developer is picking up a story and suspects the acceptance criteria are incomplete
- A team is doing story refinement and wants to catch gaps early
- Someone pasted a story from Jira/ServiceNow/Excel and wants structured feedback

## Analysis Framework

For every story or requirement provided, evaluate across these dimensions:

### 1. INVEST Check
- **Independent**: Can this story be delivered without hard dependencies on other unfinished stories?
- **Negotiable**: Is there room to discuss scope, or is it overly prescriptive about implementation?
- **Valuable**: Is the business value clear? Who benefits and how?
- **Estimable**: Can a developer roughly size this? If not, what’s missing?
- **Small**: Is this appropriately scoped for a single sprint? If not, suggest a split.
- **Testable**: Are acceptance criteria specific enough that a tester could verify them?

### 2. ServiceNow Platform Fit
- Does the story assume capabilities ServiceNow doesn't have out of the box?
- Are there platform-native alternatives to custom development (e.g., Flow Designer vs. custom script)?
- Does it reference tables, fields, or relationships that don't exist or need creation?
- Is the proposed solution maintainable within ServiceNow's upgrade-safe patterns?

### 3. Acceptance Criteria Quality
- Are criteria written in Given/When/Then or equivalent structured format?
- Are they mutually exclusive and collectively exhaustive?
- Do they cover positive paths, negative paths, and edge cases?
- Are boundaries and thresholds explicit (e.g., "up to 100 records" not "a large number")?

### 4. Role and Permission Clarity
- Is it clear which user roles interact with this functionality?
- Are there implied admin vs. end-user experiences that aren't specified?
- Does the story assume elevated privileges without stating them?

## Output Format

Respond with a structured analysis:

```
## Overall Readiness: [Ready / Needs Work / Blocked]

## Strengths
- [List 2-4 things the story does well]

## Gaps & Risks
| Issue | Severity | Recommendation |
|-------|----------|----------------|
| [Description] | High/Med/Low | [Specific fix] |

## ServiceNow-Specific Notes
- [Platform considerations]

## Suggested Acceptance Criteria Additions
- [Criteria that should be added]

## Refined Story (Optional)
[If the original story is very rough, offer a rewritten version]
```

## Severity Ratings
- **High**: Story cannot be estimated or would likely fail UAT as written
- **Medium**: Would cause friction, rework, or scope creep during development
- **Low**: Minor clarity improvement; nice to have

## Tone
Be direct but constructive. The goal is to catch problems before a developer starts coding, not to criticize the author. Frame gaps as "here's what a developer will ask in refinement" rather than "this is wrong."