@skilly-hand/skilly-hand 0.19.0 → 0.21.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +36 -0
- package/README.md +4 -0
- package/catalog/README.md +1 -0
- package/catalog/catalog-index.json +2 -1
- package/catalog/skills/user-story-crafting/SKILL.md +201 -0
- package/catalog/skills/user-story-crafting/agents/story-mapper.md +73 -0
- package/catalog/skills/user-story-crafting/agents/story-splitter.md +72 -0
- package/catalog/skills/user-story-crafting/agents/story-structurer.md +77 -0
- package/catalog/skills/user-story-crafting/agents/story-writer.md +91 -0
- package/catalog/skills/user-story-crafting/manifest.json +29 -0
- package/package.json +6 -4
- package/packages/catalog/package.json +1 -1
- package/packages/cli/package.json +1 -1
- package/packages/core/package.json +1 -1
- package/packages/detectors/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -16,6 +16,42 @@ All notable changes to this project are documented in this file.
|
|
|
16
16
|
### Removed
|
|
17
17
|
- _None._
|
|
18
18
|
|
|
19
|
+
## [0.21.0] - 2026-04-11
|
|
20
|
+
[View on npm](https://www.npmjs.com/package/@skilly-hand/skilly-hand/v/0.21.0)
|
|
21
|
+
|
|
22
|
+
### Added
|
|
23
|
+
- Added portable skill `user-story-crafting` with integrated sub-agents for story writing, INVEST-based structuring, story splitting, and lightweight story mapping.
|
|
24
|
+
|
|
25
|
+
### Changed
|
|
26
|
+
- _None._
|
|
27
|
+
|
|
28
|
+
### Fixed
|
|
29
|
+
- _None._
|
|
30
|
+
|
|
31
|
+
### Removed
|
|
32
|
+
- _None._
|
|
33
|
+
|
|
34
|
+
## [0.20.0] - 2026-04-11
|
|
35
|
+
[View on npm](https://www.npmjs.com/package/@skilly-hand/skilly-hand/v/0.20.0)
|
|
36
|
+
|
|
37
|
+
### Added
|
|
38
|
+
- Added `scripts/dependency-policy-check.mjs` and `deps:policy:check` to enforce exact runtime dependency pins plus synchronized `package-lock.json`/`npm-shrinkwrap.json`.
|
|
39
|
+
- Added `scripts/dependency-update-safe.mjs` and `deps:update:safe` to enforce safe dependency upgrades with full validation gates.
|
|
40
|
+
- Added `npm-shrinkwrap.json` to the repository and release workflow for npm lockfile parity.
|
|
41
|
+
- Added regression test coverage for dependency policy checks, safe dependency update flow, and managed git hook installation behavior.
|
|
42
|
+
|
|
43
|
+
### Changed
|
|
44
|
+
- Updated `verify:publish` to run dependency policy checks before security, catalog, test, and packlist gates.
|
|
45
|
+
- Updated `scripts/setup-hooks.mjs` to install both managed `pre-commit` and `pre-push` hooks with safety checks for foreign hooks.
|
|
46
|
+
- Updated `scripts/dependency-security-check.mjs` to recognize `npm-shrinkwrap.json` as a valid npm lockfile.
|
|
47
|
+
- Updated docs with dependency update policy guidance and hook setup requirements.
|
|
48
|
+
|
|
49
|
+
### Fixed
|
|
50
|
+
- Expanded script JSON contract tests to cover `dependency-policy-check`.
|
|
51
|
+
|
|
52
|
+
### Removed
|
|
53
|
+
- _None._
|
|
54
|
+
|
|
19
55
|
## [0.19.0] - 2026-04-11
|
|
20
56
|
[View on npm](https://www.npmjs.com/package/@skilly-hand/skilly-hand/v/0.19.0)
|
|
21
57
|
|
package/README.md
CHANGED
|
@@ -105,6 +105,10 @@ See [catalog/README.md](./catalog/README.md) for generated skill metadata.
|
|
|
105
105
|
|
|
106
106
|
- `npm run security:check` runs repository secret/config checks plus strict dependency security checks.
|
|
107
107
|
- `npm run security:deps` runs strict dependency audit + outdated reporting only.
|
|
108
|
+
- `npm run deps:policy:check` enforces exact runtime dependency pins and lockfile sync (`package-lock.json` + `npm-shrinkwrap.json`).
|
|
109
|
+
- `npm run deps:update:safe -- <pkg[@version]>` is the required dependency update path; it pins exact versions, syncs shrinkwrap, and blocks completion unless all validation gates pass.
|
|
110
|
+
- Do not use raw `npm install` for dependency upgrades in this repo; use `deps:update:safe` so tests and security gates run before accepting version changes.
|
|
111
|
+
- Run `npm run setup:hooks` once per clone to install `pre-commit` (fast checks) and `pre-push` (full gate) hooks.
|
|
108
112
|
|
|
109
113
|
---
|
|
110
114
|
|
package/catalog/README.md
CHANGED
|
@@ -18,5 +18,6 @@ Published portable skills consumed by the `skilly-hand` CLI.
|
|
|
18
18
|
| `spec-driven-development` | Plan, execute, and verify multi-step work through versioned specs with small, testable tasks. | core, workflow, planning | all |
|
|
19
19
|
| `test-driven-development` | Guide implementation using the RED → GREEN → REFACTOR TDD cycle: write a failing test first, write the minimum code to pass, then refactor while tests stay green. | testing, workflow, quality, core | all |
|
|
20
20
|
| `token-optimizer` | Classify task complexity and right-size reasoning depth, context gathering, and response detail to reduce wasted tokens. | core, workflow, efficiency | all |
|
|
21
|
+
| `user-story-crafting` | Create and refine user stories with structured quality gates, splitting heuristics, and lightweight story mapping for release slicing. Trigger: writing, restructuring, splitting, or sequencing user stories for delivery-ready backlog work. | product, workflow, planning, quality | all |
|
|
21
22
|
|
|
22
23
|
Legacy source remains under `source/legacy/agentic-structure` and is excluded from installation.
|
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Create and refine user stories with structured quality gates, splitting heuristics, and lightweight story mapping for release slicing. Trigger: writing, restructuring, splitting, or sequencing user stories for delivery-ready backlog work."
|
|
3
|
+
skillMetadata:
|
|
4
|
+
author: "skilly-hand"
|
|
5
|
+
last-edit: "2026-04-11"
|
|
6
|
+
license: "Apache-2.0"
|
|
7
|
+
version: "1.0.0"
|
|
8
|
+
changelog: "Added new user-story-crafting skill with integrated writing, structuring, splitting, and mapping agents; improves backlog quality and delivery sequencing through a unified user-story workflow; affects catalog skills, agent routing metadata, and managed AGENTS outputs"
|
|
9
|
+
auto-invoke: "Writing, restructuring, splitting, or sequencing user stories into delivery-ready backlog items"
|
|
10
|
+
allowed-tools:
|
|
11
|
+
- "Read"
|
|
12
|
+
- "Edit"
|
|
13
|
+
- "Write"
|
|
14
|
+
- "Glob"
|
|
15
|
+
- "Grep"
|
|
16
|
+
- "Bash"
|
|
17
|
+
- "Task"
|
|
18
|
+
- "SubAgent"
|
|
19
|
+
---
|
|
20
|
+
# User Story Crafting Guide
|
|
21
|
+
|
|
22
|
+
## When to Use
|
|
23
|
+
|
|
24
|
+
Use this skill when:
|
|
25
|
+
|
|
26
|
+
- A backlog item needs to be written as a user-centered story.
|
|
27
|
+
- A story is unclear, too technical, or missing measurable outcomes.
|
|
28
|
+
- A story is too large to estimate or deliver safely in one iteration.
|
|
29
|
+
- A team needs lightweight story mapping to sequence releases around user value.
|
|
30
|
+
|
|
31
|
+
Do not use this skill for:
|
|
32
|
+
|
|
33
|
+
- Pure engineering chores with no user outcome.
|
|
34
|
+
- Architectural RFCs or deep technical design documents.
|
|
35
|
+
- Sprint capacity planning unrelated to user behavior.
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
## Routing Map
|
|
40
|
+
|
|
41
|
+
| Step | Intent | Sub-agent |
|
|
42
|
+
| --- | --- | --- |
|
|
43
|
+
| 1 | Draft the baseline user story and acceptance criteria | [agents/story-writer.md](agents/story-writer.md) |
|
|
44
|
+
| 2 | Validate structure and quality with INVEST + anti-pattern checks | [agents/story-structurer.md](agents/story-structurer.md) |
|
|
45
|
+
| 3 (if story is too large) | Split into independent, value-first increments | [agents/story-splitter.md](agents/story-splitter.md) |
|
|
46
|
+
| 4 (optional) | Map activities, tasks, and release slices | [agents/story-mapper.md](agents/story-mapper.md) |
|
|
47
|
+
|
|
48
|
+
Always run step 1 and step 2. Run step 3 when any size/risk signal appears. Run step 4 when roadmap sequencing or MVP slicing is requested.
|
|
49
|
+
|
|
50
|
+
---
|
|
51
|
+
|
|
52
|
+
## Standard Execution Sequence
|
|
53
|
+
|
|
54
|
+
1. Capture context intake: persona, goal, problem, constraints, and assumptions.
|
|
55
|
+
2. Draft one baseline story in Cohn format:
|
|
56
|
+
- `As a [persona]`
|
|
57
|
+
- `I want [capability]`
|
|
58
|
+
- `So that [outcome/value]`
|
|
59
|
+
3. Add testable acceptance criteria in Given/When/Then structure.
|
|
60
|
+
4. Run quality checks using INVEST plus ambiguity/measurability filters.
|
|
61
|
+
5. If oversized or coupled, split into smaller stories using vertical slice patterns.
|
|
62
|
+
6. Optionally organize split stories into a lightweight map with release slices.
|
|
63
|
+
7. Return a final artifact bundle with:
|
|
64
|
+
- Polished stories
|
|
65
|
+
- Acceptance criteria
|
|
66
|
+
- INVEST review notes
|
|
67
|
+
- Split rationale (if applied)
|
|
68
|
+
- Map-ready release structure (if applied)
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
## Critical Patterns
|
|
73
|
+
|
|
74
|
+
### Pattern 1: User Outcome First
|
|
75
|
+
|
|
76
|
+
A story is valid only when it states user value, not implementation tasks.
|
|
77
|
+
|
|
78
|
+
```text
|
|
79
|
+
Good: As a returning customer, I want to reuse my saved card, so that checkout is faster.
|
|
80
|
+
Bad: As a developer, I want to refactor payment services, so that code is cleaner.
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### Pattern 2: Acceptance Criteria Must Be Testable
|
|
84
|
+
|
|
85
|
+
Every criterion should be observable and verifiable by behavior.
|
|
86
|
+
|
|
87
|
+
```gherkin
|
|
88
|
+
Given a logged-in customer with a saved card
|
|
89
|
+
When they choose "Pay with saved card"
|
|
90
|
+
Then the order is submitted without re-entering card details
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### Pattern 3: INVEST Is a Gate, Not a Suggestion
|
|
94
|
+
|
|
95
|
+
Before finalizing any story, verify:
|
|
96
|
+
|
|
97
|
+
- Independent
|
|
98
|
+
- Negotiable
|
|
99
|
+
- Valuable
|
|
100
|
+
- Estimable
|
|
101
|
+
- Small
|
|
102
|
+
- Testable
|
|
103
|
+
|
|
104
|
+
If two or more INVEST checks fail, do not finalize; split or rewrite first.
|
|
105
|
+
|
|
106
|
+
### Pattern 4: Split by User Value, Not by System Layer
|
|
107
|
+
|
|
108
|
+
Prefer vertical slices that preserve end-to-end user outcomes.
|
|
109
|
+
|
|
110
|
+
```text
|
|
111
|
+
Good split: Browse -> Add -> Pay (thin end-to-end slice first)
|
|
112
|
+
Bad split: Frontend -> Backend -> Database
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
### Pattern 5: Mapping Is Lightweight and Release-Oriented
|
|
116
|
+
|
|
117
|
+
Story mapping is used to sequence value, not to model exhaustive edge-case detail up front.
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## Decision Tree
|
|
122
|
+
|
|
123
|
+
```text
|
|
124
|
+
Need a new story from a request?
|
|
125
|
+
-> Draft with story-writer
|
|
126
|
+
|
|
127
|
+
Story written but quality unclear?
|
|
128
|
+
-> Run story-structurer
|
|
129
|
+
|
|
130
|
+
Story fails Small/Estimable/Independent?
|
|
131
|
+
-> Run story-splitter
|
|
132
|
+
|
|
133
|
+
Need MVP/release sequencing?
|
|
134
|
+
-> Run story-mapper
|
|
135
|
+
|
|
136
|
+
No user value is present?
|
|
137
|
+
-> Reframe as user outcome or classify as non-story technical work item
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
---
|
|
141
|
+
|
|
142
|
+
## Output Contract
|
|
143
|
+
|
|
144
|
+
Return results in this order:
|
|
145
|
+
|
|
146
|
+
1. **Context Snapshot**: persona, problem, desired outcome, constraints.
|
|
147
|
+
2. **Final Story Set**: one or more refined user stories.
|
|
148
|
+
3. **Acceptance Criteria**: Given/When/Then per story.
|
|
149
|
+
4. **Quality Review**: INVEST pass/fail + fixes applied.
|
|
150
|
+
5. **Split + Map Notes**: split rationale and release slice proposal (when used).
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## Example
|
|
155
|
+
|
|
156
|
+
### Input
|
|
157
|
+
|
|
158
|
+
```text
|
|
159
|
+
"Users abandon onboarding because setup is confusing."
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
### Condensed Output
|
|
163
|
+
|
|
164
|
+
```text
|
|
165
|
+
Context Snapshot
|
|
166
|
+
- Persona: New team admin
|
|
167
|
+
- Problem: Setup confusion during first session
|
|
168
|
+
- Outcome: Reach first successful project setup quickly
|
|
169
|
+
|
|
170
|
+
Final Story Set
|
|
171
|
+
- As a new team admin, I want a guided setup checklist, so that I can complete onboarding without guessing next steps.
|
|
172
|
+
|
|
173
|
+
Acceptance Criteria
|
|
174
|
+
- Given I created a new workspace
|
|
175
|
+
When I open the onboarding page
|
|
176
|
+
Then I see a checklist of setup steps in recommended order
|
|
177
|
+
- Given I complete one setup step
|
|
178
|
+
When I return to onboarding
|
|
179
|
+
Then progress shows the completed step and next recommended action
|
|
180
|
+
|
|
181
|
+
Quality Review
|
|
182
|
+
- INVEST: Pass (all six checks)
|
|
183
|
+
|
|
184
|
+
Split + Map Notes
|
|
185
|
+
- Not required for this scope
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
---
|
|
189
|
+
|
|
190
|
+
## Commands
|
|
191
|
+
|
|
192
|
+
```bash
|
|
193
|
+
# Validate catalog metadata/frontmatter drift
|
|
194
|
+
npm run catalog:check
|
|
195
|
+
|
|
196
|
+
# Apply frontmatter + README sync changes
|
|
197
|
+
npm run catalog:sync
|
|
198
|
+
|
|
199
|
+
# Regenerate managed AGENTS files after catalog updates
|
|
200
|
+
npm run agentic:self:sync
|
|
201
|
+
```
|
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
# Story Mapper
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Arrange stories into a lightweight map that supports release slicing and MVP sequencing around user behavior.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## When to Use
|
|
10
|
+
|
|
11
|
+
Use this agent when teams need planning visibility across activities, tasks, and release increments.
|
|
12
|
+
|
|
13
|
+
Do not use this agent to replace detailed implementation planning.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Mapping Structure
|
|
18
|
+
|
|
19
|
+
Build map with three layers:
|
|
20
|
+
|
|
21
|
+
1. **Backbone activities** (horizontal): major user journey stages.
|
|
22
|
+
2. **User tasks/stories** (vertical under each activity).
|
|
23
|
+
3. **Release slices** (horizontal cuts): walking skeleton first, then enhancements.
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## Backbone Rules
|
|
28
|
+
|
|
29
|
+
- Backbone must be user workflow language, not technical architecture.
|
|
30
|
+
- Each activity should represent a meaningful step in user progress.
|
|
31
|
+
- Keep activity count focused (typically 4-8 for first pass).
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Release Slicing Rules
|
|
36
|
+
|
|
37
|
+
- **Release 1** should be a walking skeleton across all core activities.
|
|
38
|
+
- Later releases add depth, alternatives, and optimization.
|
|
39
|
+
- Every release must preserve end-to-end user value.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Output Template
|
|
44
|
+
|
|
45
|
+
```text
|
|
46
|
+
Backbone Activities
|
|
47
|
+
- Activity A -> Activity B -> Activity C
|
|
48
|
+
|
|
49
|
+
Story Map
|
|
50
|
+
Activity A
|
|
51
|
+
- Story A1
|
|
52
|
+
- Story A2
|
|
53
|
+
|
|
54
|
+
Activity B
|
|
55
|
+
- Story B1
|
|
56
|
+
- Story B2
|
|
57
|
+
|
|
58
|
+
Release Slices
|
|
59
|
+
- Release 1 (Walking Skeleton): A1 + B1 + C1
|
|
60
|
+
- Release 2: A2 + B2 + C2
|
|
61
|
+
- Release 3: advanced variants
|
|
62
|
+
|
|
63
|
+
Mapping Notes
|
|
64
|
+
- Risks, assumptions, and unresolved questions
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Anti-Patterns
|
|
70
|
+
|
|
71
|
+
- Backbone modeled as "Frontend -> Backend -> Database".
|
|
72
|
+
- Release 1 defined as feature-complete for only one activity.
|
|
73
|
+
- Excessive edge-case detail before core flow is aligned.
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
# Story Splitter
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Break oversized stories into smaller, independently valuable slices that can be estimated and released incrementally.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## When to Use
|
|
10
|
+
|
|
11
|
+
Use this agent when a story fails Small/Estimable/Independent checks, or bundles multiple outcomes.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Split Signals
|
|
16
|
+
|
|
17
|
+
Split when any of the following are true:
|
|
18
|
+
|
|
19
|
+
- More than one user outcome exists in a single story.
|
|
20
|
+
- Acceptance criteria represent multiple distinct flows.
|
|
21
|
+
- Cross-team dependencies block completion as one unit.
|
|
22
|
+
- The story cannot fit in one iteration.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Split Heuristics
|
|
27
|
+
|
|
28
|
+
Prefer these patterns:
|
|
29
|
+
|
|
30
|
+
1. **Workflow step split**: separate sequential steps in the user journey.
|
|
31
|
+
2. **Operation split**: create/read/update/delete separated when value is independent.
|
|
32
|
+
3. **Business rule split**: start with core rule, defer advanced policies.
|
|
33
|
+
4. **Data variation split**: start with most common scenario, add variants later.
|
|
34
|
+
5. **Interface split**: core interaction first, advanced controls later.
|
|
35
|
+
6. **Error/edge split**: deliver happy path first if safe, then harden.
|
|
36
|
+
|
|
37
|
+
Never split by technical architecture layers.
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## Vertical Slice Rule
|
|
42
|
+
|
|
43
|
+
Each split story should:
|
|
44
|
+
|
|
45
|
+
- Preserve user-visible value.
|
|
46
|
+
- Be releasable without hidden prerequisites where possible.
|
|
47
|
+
- Keep clear acceptance criteria and ownership.
|
|
48
|
+
|
|
49
|
+
If a candidate split has no user value, classify it as technical work and detach from story set.
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Output Template
|
|
54
|
+
|
|
55
|
+
```text
|
|
56
|
+
Original Story Risk
|
|
57
|
+
- Why story is too large/coupled
|
|
58
|
+
|
|
59
|
+
Split Strategy Chosen
|
|
60
|
+
- Pattern used and rationale
|
|
61
|
+
|
|
62
|
+
Split Story Set
|
|
63
|
+
1. As a ... I want ... So that ...
|
|
64
|
+
2. As a ... I want ... So that ...
|
|
65
|
+
|
|
66
|
+
Acceptance Criteria per Story
|
|
67
|
+
- Story 1: Given ... When ... Then ...
|
|
68
|
+
- Story 2: Given ... When ... Then ...
|
|
69
|
+
|
|
70
|
+
Sequencing Notes
|
|
71
|
+
- Story order and dependency notes
|
|
72
|
+
```
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
# Story Structurer
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Apply consistent quality gates so stories are clear, testable, and ready for estimation.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## When to Use
|
|
10
|
+
|
|
11
|
+
Use this agent after `story-writer` drafts a story, or when reviewing existing stories for quality.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## INVEST Gate
|
|
16
|
+
|
|
17
|
+
Score each story against:
|
|
18
|
+
|
|
19
|
+
- **Independent**: Can it be delivered without hidden coupling?
|
|
20
|
+
- **Negotiable**: Is solution space still open?
|
|
21
|
+
- **Valuable**: Is user/business value explicit?
|
|
22
|
+
- **Estimable**: Is scope concrete enough to size?
|
|
23
|
+
- **Small**: Can it be completed inside one iteration?
|
|
24
|
+
- **Testable**: Do acceptance criteria prove completion?
|
|
25
|
+
|
|
26
|
+
Mark each as `Pass`, `Needs Revision`, or `Fail`.
|
|
27
|
+
|
|
28
|
+
If `Small`, `Estimable`, or `Independent` fails, route to `story-splitter`.
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## Quality Filters
|
|
33
|
+
|
|
34
|
+
Run these checks in addition to INVEST:
|
|
35
|
+
|
|
36
|
+
1. **Ambiguity filter**: remove vague terms (`easy`, `quick`, `improved`, `optimized`) unless defined.
|
|
37
|
+
2. **Outcome filter**: ensure the "So that" clause names real value.
|
|
38
|
+
3. **Criteria filter**: ensure each criterion has observable outcomes.
|
|
39
|
+
4. **Dependency filter**: list external dependencies and whether they block release.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Rewrite Rules
|
|
44
|
+
|
|
45
|
+
When quality fails, rewrite with minimal drift:
|
|
46
|
+
|
|
47
|
+
- Keep the original user intent.
|
|
48
|
+
- Replace implementation-heavy wording with user behavior language.
|
|
49
|
+
- Keep acceptance criteria concise and verifiable.
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Output Template
|
|
54
|
+
|
|
55
|
+
```text
|
|
56
|
+
INVEST Review
|
|
57
|
+
- Independent: Pass | Needs Revision | Fail
|
|
58
|
+
- Negotiable: Pass | Needs Revision | Fail
|
|
59
|
+
- Valuable: Pass | Needs Revision | Fail
|
|
60
|
+
- Estimable: Pass | Needs Revision | Fail
|
|
61
|
+
- Small: Pass | Needs Revision | Fail
|
|
62
|
+
- Testable: Pass | Needs Revision | Fail
|
|
63
|
+
|
|
64
|
+
Quality Findings
|
|
65
|
+
- ...
|
|
66
|
+
|
|
67
|
+
Revised Story
|
|
68
|
+
- As a ...
|
|
69
|
+
- I want ...
|
|
70
|
+
- So that ...
|
|
71
|
+
|
|
72
|
+
Revised Acceptance Criteria
|
|
73
|
+
- Given ... When ... Then ...
|
|
74
|
+
|
|
75
|
+
Routing Decision
|
|
76
|
+
- Keep as-is | Revise only | Split required
|
|
77
|
+
```
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
# Story Writer
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Convert rough requests into clear, user-centered stories with testable acceptance criteria.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## When to Use
|
|
10
|
+
|
|
11
|
+
Use this agent when:
|
|
12
|
+
|
|
13
|
+
- The input is a feature idea, request, bug narrative, or vague backlog note.
|
|
14
|
+
- A story must be drafted in a standard format for engineering handoff.
|
|
15
|
+
|
|
16
|
+
Do not use this agent when:
|
|
17
|
+
|
|
18
|
+
- The work item has no user outcome and should remain a technical task.
|
|
19
|
+
- The story is already fully formed and only needs quality review.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Story Format
|
|
24
|
+
|
|
25
|
+
Always draft in this structure:
|
|
26
|
+
|
|
27
|
+
```text
|
|
28
|
+
As a [specific persona]
|
|
29
|
+
I want [capability/action]
|
|
30
|
+
So that [measurable user or business outcome]
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Rules:
|
|
34
|
+
|
|
35
|
+
- Persona must be concrete (role + context), not "user" unless truly broad.
|
|
36
|
+
- "I want" states behavior or capability, not implementation details.
|
|
37
|
+
- "So that" states value/outcome, not vague intent.
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## Acceptance Criteria Protocol
|
|
42
|
+
|
|
43
|
+
Produce 3-7 criteria using Given/When/Then.
|
|
44
|
+
|
|
45
|
+
```gherkin
|
|
46
|
+
Given [starting context]
|
|
47
|
+
When [trigger/action]
|
|
48
|
+
Then [observable result]
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
Quality checks:
|
|
52
|
+
|
|
53
|
+
- Each Then is objectively verifiable.
|
|
54
|
+
- Avoid words like "better", "faster", "intuitive" without measurable definition.
|
|
55
|
+
- Include negative/error path criteria when risk is material.
|
|
56
|
+
|
|
57
|
+
---
|
|
58
|
+
|
|
59
|
+
## Drafting Procedure
|
|
60
|
+
|
|
61
|
+
1. Extract context: persona, goal, pain, constraints.
|
|
62
|
+
2. Write one baseline story.
|
|
63
|
+
3. Draft acceptance criteria that cover happy path + key edge behavior.
|
|
64
|
+
4. Flag any missing context assumptions explicitly.
|
|
65
|
+
5. Hand off to `story-structurer` for quality gates.
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Output Template
|
|
70
|
+
|
|
71
|
+
```text
|
|
72
|
+
Story
|
|
73
|
+
- As a ...
|
|
74
|
+
- I want ...
|
|
75
|
+
- So that ...
|
|
76
|
+
|
|
77
|
+
Acceptance Criteria
|
|
78
|
+
- Given ... When ... Then ...
|
|
79
|
+
- Given ... When ... Then ...
|
|
80
|
+
|
|
81
|
+
Assumptions
|
|
82
|
+
- ...
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Anti-Patterns
|
|
88
|
+
|
|
89
|
+
- "As a developer..." used to hide technical tasks as user stories.
|
|
90
|
+
- Acceptance criteria as implementation checklists.
|
|
91
|
+
- Story value that cannot be observed or measured.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
{
|
|
2
|
+
"id": "user-story-crafting",
|
|
3
|
+
"title": "User Story Crafting",
|
|
4
|
+
"description": "Create and refine user stories with structured quality gates, splitting heuristics, and lightweight story mapping for release slicing. Trigger: writing, restructuring, splitting, or sequencing user stories for delivery-ready backlog work.",
|
|
5
|
+
"portable": true,
|
|
6
|
+
"tags": ["product", "workflow", "planning", "quality"],
|
|
7
|
+
"detectors": ["always"],
|
|
8
|
+
"detectionTriggers": ["always"],
|
|
9
|
+
"installsFor": ["all"],
|
|
10
|
+
"agentSupport": ["codex", "claude", "cursor", "gemini", "copilot", "antigravity", "windsurf", "trae"],
|
|
11
|
+
"skillMetadata": {
|
|
12
|
+
"author": "skilly-hand",
|
|
13
|
+
"last-edit": "2026-04-11",
|
|
14
|
+
"license": "Apache-2.0",
|
|
15
|
+
"version": "1.0.0",
|
|
16
|
+
"changelog": "Added new user-story-crafting skill with integrated writing, structuring, splitting, and mapping agents; improves backlog quality and delivery sequencing through a unified user-story workflow; affects catalog skills, agent routing metadata, and managed AGENTS outputs",
|
|
17
|
+
"auto-invoke": "Writing, restructuring, splitting, or sequencing user stories into delivery-ready backlog items",
|
|
18
|
+
"allowed-modes": ["story-writer", "story-structurer", "story-splitter", "story-mapper"],
|
|
19
|
+
"allowed-tools": ["Read", "Edit", "Write", "Glob", "Grep", "Bash", "Task", "SubAgent"]
|
|
20
|
+
},
|
|
21
|
+
"files": [
|
|
22
|
+
{ "path": "SKILL.md", "kind": "instruction" },
|
|
23
|
+
{ "path": "agents/story-writer.md", "kind": "instruction" },
|
|
24
|
+
{ "path": "agents/story-structurer.md", "kind": "instruction" },
|
|
25
|
+
{ "path": "agents/story-splitter.md", "kind": "instruction" },
|
|
26
|
+
{ "path": "agents/story-mapper.md", "kind": "instruction" }
|
|
27
|
+
],
|
|
28
|
+
"dependencies": []
|
|
29
|
+
}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@skilly-hand/skilly-hand",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.21.0",
|
|
4
4
|
"license": "CC-BY-NC-4.0",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"publishConfig": {
|
|
@@ -29,11 +29,13 @@
|
|
|
29
29
|
"catalog:sync": "node ./scripts/sync-catalog.mjs",
|
|
30
30
|
"agentic:self:sync": "node ./scripts/sync-self-agentic.mjs",
|
|
31
31
|
"test": "node --test tests/*.test.js && node ./scripts/test-in-sandbox.mjs",
|
|
32
|
+
"deps:policy:check": "node ./scripts/dependency-policy-check.mjs",
|
|
33
|
+
"deps:update:safe": "node ./scripts/dependency-update-safe.mjs",
|
|
32
34
|
"security:deps": "node ./scripts/dependency-security-check.mjs --strict",
|
|
33
35
|
"security:check": "node ./scripts/security-check.mjs --strict-deps",
|
|
34
36
|
"verify:packlist": "node ./scripts/verify-packlist.mjs",
|
|
35
37
|
"verify:versions": "node ./scripts/verify-versions.mjs",
|
|
36
|
-
"verify:publish": "npm run verify:versions && npm run security:check && npm run catalog:check && npm test && npm run verify:packlist",
|
|
38
|
+
"verify:publish": "npm run verify:versions && npm run deps:policy:check && npm run security:check && npm run catalog:check && npm test && npm run verify:packlist",
|
|
37
39
|
"publish:prepare": "npm run verify:publish && npm pack --dry-run --json",
|
|
38
40
|
"publish:otp": "node ./scripts/publish-with-otp.mjs",
|
|
39
41
|
"publish:next": "node ./scripts/publish-with-otp.mjs --tag next",
|
|
@@ -47,7 +49,7 @@
|
|
|
47
49
|
"doctor": "node ./packages/cli/src/bin.js doctor"
|
|
48
50
|
},
|
|
49
51
|
"dependencies": {
|
|
50
|
-
"ink": "
|
|
51
|
-
"react": "
|
|
52
|
+
"ink": "5.2.1",
|
|
53
|
+
"react": "18.3.1"
|
|
52
54
|
}
|
|
53
55
|
}
|