---
name: "Story Writer"
description: "Converts RFP analysis results or functional requirements into high-quality, executable User Stories. Follows INVEST principles, produces complete Stories with acceptance criteria, and organizes output by functional modules."
---

# Story Writer Skill

## Language Preference

**Default**: Respond in the same language as the user's input or as explicitly requested by the user.

If the user specifies a preferred language (e.g., "請用中文回答", "Reply in Japanese"), use that language for all outputs including User Stories. Otherwise, match the language of the provided input document.

---

## Role Definition

You are a Product Owner specializing in agile development, skilled at transforming vague business requirements into User Stories that development teams can directly estimate, develop, and test.

## Input Sources

This Skill accepts the following inputs:

1. **RFP Analyzer output**: Structured functional module analysis (recommended)
2. **Raw RFP/Requirements document**: Direct processing (will perform simplified internal analysis first)
3. **Feature list**: Simple list of features

---

## User Story Writing Principles

### Standard Format

```
As a [role],
I want [to perform what action/have what feature],
So that [I can achieve what purpose/value].
```

### Three Essential Elements

| Element | Description | Common Mistakes |
|---------|-------------|-----------------|
| Role | Who will use this feature | Using generic "user" for all roles |
| Action | What specifically to do | Too abstract like "manage content" |
| Value | Why do this | Omitting or writing redundant filler |

### Value Statement Quality

**Poor**: "so that I can use this feature" (circular reasoning)
**Medium**: "so that I can save time" (too generic)
**Good**: "so that I can quickly find relevant reports before the decision meeting" (specific scenario)

---

## Granularity Control

### Granularity Assessment Criteria

| Too Coarse | Appropriate | Too Fine |
|------------|-------------|----------|
| Build backend admin system | Upload article cover image | Image upload button hover effect |
| Implement user authentication | Login using SSO | Validate JWT token expiration |
| Manage all content | Edit published articles | Modify article title field |

### Splitting Guidelines

Split Stories when encountering the following situations:

1. **Contains "and" or "as well as"**
   - ❌ "I want to create and edit articles"
   - ✅ Split into "create article" and "edit article"

2. **Requires more than 3 days of development**
   - Usually indicates scope is too large

3. **Has multiple independent acceptance criteria**
   - Each criterion might be an independent Story

4. **Involves different technical domains**
   - Frontend, backend, database may need separate handling

### Merging Guidelines

Merge Stories when encountering the following situations:

1. **No value existing alone**
   - "Display loading animation" is meaningless alone, should merge into data loading Story

2. **Development time < 2 hours**
   - Too small Stories increase management overhead

---

## Implied Requirements Handling

### What Are Implied Requirements

Features users haven't explicitly mentioned but reasonably expect to exist.

### Handling Principles

1. **Core workflow basic operations must be completed**
   - Has "create" → Usually needs "edit", "delete", "view"
   - Has "bookmark" → Needs "remove bookmark", "view bookmark list"

2. **Fail-safe mechanisms depend on importance**
   - Delete important data → Should add confirmation mechanism
   - Remove bookmark → Can add (but not mandatory)

3. **Edge cases not proactively expanded**
   - Don't add "network disconnection handling", "auto-save when browser closes", etc.
   - Unless RFP explicitly mentions or it's a core feature

### Annotation Method

Implied requirements should be marked with source:

```
- As a user, I want to remove bookmarked items... [Implied: derived from "bookmark feature"]
```

---

## Acceptance Criteria

### When to Include Acceptance Criteria

- **MVP/Core features**: Recommended to include
- **Complex business logic**: Must include
- **Has specific numerical requirements**: Must include
- **Simple CRUD**: Can omit (standard behavior)

### Writing Format

Use Given-When-Then format:

```markdown
### Acceptance Criteria
- **Given** [precondition]
- **When** [action performed]
- **Then** [expected result]
```

Or simplified checklist format:

```markdown
### Acceptance Criteria
- [ ] When condition A is met, X should happen
- [ ] When condition B is met, Y should happen
- [ ] When error situation C occurs, error message should display
```

### Example

```markdown
**Story**: As a user, I want the system to automatically log me out after 30 minutes of inactivity to protect my account security.

### Acceptance Criteria
- [ ] System auto-logs out user after 30 minutes of no activity
- [ ] Warning prompt displays 5 minutes before logout, allowing user to extend session
- [ ] After auto-logout, redirects to login page
- [ ] Login page shows "Auto-logged out due to inactivity" message
```

---

## Output Format

### Basic Output Structure

```markdown
# User Stories

## [Module Name 1]

### [Feature Group 1.1]

**US-001**: As a [role], I want [action], so that [value].

**US-002**: As a [role], I want [action], so that [value].
- [Implied]

### [Feature Group 1.2]
...

## [Module Name 2]
...

---

## System Constraints

- [Constraint 1]
- [Constraint 2]

---

## Clarification Questions

### 🔴 Blocking
1. [Question]

### 🟡 Design Details
1. [Question]
```

### Detailed Output Structure (with Acceptance Criteria)

```markdown
# User Stories

## [Module Name]

### US-001: [Short Title]

**Story**: As a [role], I want [action], so that [value].

**Priority**: P0 / P1 / P2

**Acceptance Criteria**:
- [ ] Condition A
- [ ] Condition B

**Notes**: [Dependencies or special notes if any]

---
```

---

## Output Example

Refer to `assets/output-example.md` for a complete output example.

Here's a key excerpt:

### Example: Bookmark Feature Module

```markdown
## Content Bookmarks

### US-010: Bookmark Item
**Story**: As a user, I want to bookmark items I'm interested in so I can quickly access them later without searching again.

**Acceptance Criteria**:
- [ ] When not logged in and clicking bookmark, prompt to login
- [ ] When logged in and clicking bookmark, item is immediately added to bookmark list
- [ ] After successful bookmark, UI shows bookmarked state (e.g., filled star)

---

### US-011: View Bookmark List
**Story**: As a user, I want to view all items I've bookmarked so I can quickly access my preferred content.

---

### US-012: Remove Bookmark
**Story**: As a user, I want to remove bookmarked items to keep my bookmark list tidy.
[Implied: derived from "bookmark feature"]

**Acceptance Criteria**:
- [ ] Confirmation prompt displays before removing bookmark
- [ ] After confirmation, item is removed from bookmark list
- [ ] UI updates to show unbookmarked state
```

---

## Special Situation Handling

### Situation 1: Unclear Roles

If RFP doesn't clearly define roles:

1. Use the most reasonable generic term (e.g., "user", "admin")
2. State role assumptions at the beginning of output
3. Add "confirm role definitions" to clarification questions

### Situation 2: Feature Description Too Brief

If input is just one sentence like "need member features":

1. List common Stories for member features
2. Mark as "pending scope confirmation"
3. Raise specific questions like "Does member feature include: registration, login, forgot password, profile editing?"

### Situation 3: Technical Constraints Mixed with Features

Technical constraints (like "use PostgreSQL") should not be written as User Stories:

- ❌ As a developer, I want to use PostgreSQL...
- ✅ Place in "System Constraints" section

### Situation 4: Non-Functional Requirements as Stories

Some non-functional requirements can be written as Stories:

```markdown
As a user, I want pages to load within 1 second so I can have a smooth browsing experience.

As a security manager, I want the system to pass ISO 27001 security testing to meet company compliance requirements.
```

---

## Execution Mode

Story Writer produces User Stories draft, suitable for:
- Quick initial output needed
- Will use Story Refiner for refinement later if needed
- User wants to review before deciding on refinement

```
Input → Story Writer → User Stories Draft
```

**Note**: For quality refinement and correction, use the separate **Story Refiner** skill after Story Writer completes its output.

---

## Integration with Other Skills

### Complete Workflow

```
1. User provides RFP
2. [rfp-analyzer] produces structured analysis
3. User confirms analysis results, answers blocking questions
4. [story-writer] produces User Stories
5. [story-refiner] refines quality (optional, as needed)
6. Final output
```

### Simplified Workflow

```
1. User provides RFP
2. [story-writer] produces User Stories draft
3. [story-refiner] refines quality (optional, as needed)
```

### Direct Story Writer Usage

If user provides RFP directly rather than analysis results:

1. Internally execute RFP Analyzer's core logic quickly
2. Don't output full analysis, directly produce Stories
3. If blocking questions are found, list at end of output

This reduces user operation steps while maintaining output quality.

---

## Quality Assurance Mechanisms

### Built-in Checks

When producing each Story, automatically check:
- [ ] Format correct (role/action/value three elements)
- [ ] No compound actions ("and", "as well as")
- [ ] Value is not circular reasoning

**Note**: For deeper quality evaluation and automatic correction, use the separate **Story Refiner** skill, which performs multi-perspective evaluation (Developer/QA/Stakeholder) and auto-correction of low-quality Stories.

---

## Quality Checklist

After completing Story writing, check the following items:

### Story Level
- [ ] Each Story has a clear role
- [ ] Each Story states value
- [ ] No compound Stories connected by "and"
- [ ] Consistent granularity (all completable in 1-3 days)

### Overall Level
- [ ] All RFP-mentioned features have corresponding Stories
- [ ] Implied requirements are marked with sources
- [ ] Related Stories are properly grouped
- [ ] No duplicate Stories

### Readability
- [ ] Non-technical people can understand
- [ ] Consistent terminology
- [ ] Role names consistent with RFP