@houseofwolvesllc/claude-scrum-skill 1.0.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/LICENSE +200 -0
- package/README.md +256 -0
- package/bin/install.js +52 -0
- package/package.json +33 -0
- package/skills/project-emulate/SKILL.md +155 -0
- package/skills/project-scaffold/SKILL.md +173 -0
- package/skills/project-scaffold/references/CONVENTIONS.md +170 -0
- package/skills/sprint-plan/SKILL.md +116 -0
- package/skills/sprint-release/SKILL.md +100 -0
- package/skills/sprint-status/SKILL.md +95 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,200 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to the Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by the Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding any notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. Please also get an in-depth
|
|
186
|
+
understanding of this license before applying it.
|
|
187
|
+
|
|
188
|
+
Copyright [yyyy] [name of copyright owner]
|
|
189
|
+
|
|
190
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
191
|
+
you may not use this file except in compliance with the License.
|
|
192
|
+
You may obtain a copy of the License at
|
|
193
|
+
|
|
194
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
195
|
+
|
|
196
|
+
Unless required by applicable law or agreed to in writing, software
|
|
197
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
198
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
199
|
+
See the License for the specific language governing permissions and
|
|
200
|
+
limitations under the License.
|
package/README.md
ADDED
|
@@ -0,0 +1,256 @@
|
|
|
1
|
+
# Claude Scrum Skill
|
|
2
|
+
|
|
3
|
+
An open-source npm package of Claude Code skills that give you a complete scrum pipeline — from PRD to production release — with Claude as your scrum master. Includes project scaffolding, sprint planning, status tracking, sprint releases, and full-project emulation testing. One PR per sprint. You stay in the executive seat.
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
PRD → /project-scaffold → GitHub Project with sprints, stories, branches
|
|
7
|
+
↓
|
|
8
|
+
/sprint-plan → populate the next sprint
|
|
9
|
+
↓
|
|
10
|
+
Claude works stories → auto-merge to release branch
|
|
11
|
+
↓
|
|
12
|
+
/sprint-status → check progress anytime
|
|
13
|
+
↓
|
|
14
|
+
/sprint-release → wrap up sprint, open release PR
|
|
15
|
+
↓
|
|
16
|
+
You review one PR → merge to main
|
|
17
|
+
↓
|
|
18
|
+
/sprint-plan → next cycle
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## Installation
|
|
22
|
+
|
|
23
|
+
### npm (recommended)
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
npm install -g @houseofwolvesllc/claude-scrum-skill
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
This copies all skills into `~/.claude/skills/`. All six skills are installed as siblings so relative paths to shared conventions resolve correctly.
|
|
30
|
+
|
|
31
|
+
### Claude Code Plugin Marketplace
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
/plugin marketplace add houseofwolvesllc/claudescrumskill
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
### Manual
|
|
38
|
+
|
|
39
|
+
Clone the repo and copy the `skills/` contents into `~/.claude/skills/` (global) or `your-repo/.claude/skills/` (per-project). All skill directories must be siblings — `sprint-plan`, `sprint-status`, and `sprint-release` reference `../project-scaffold/references/CONVENTIONS.md` via relative path.
|
|
40
|
+
|
|
41
|
+
## Quick Start
|
|
42
|
+
|
|
43
|
+
### 1. Create a Fine-Grained GitHub Personal Access Token
|
|
44
|
+
|
|
45
|
+
These skills use `gh` for all GitHub operations. You need a fine-grained PAT scoped to the repos you want to manage.
|
|
46
|
+
|
|
47
|
+
**Step 1:** Go to [github.com/settings/personal-access-tokens](https://github.com/settings/personal-access-tokens) and click **Generate new token**.
|
|
48
|
+
|
|
49
|
+
**Step 2:** Fill in the token details:
|
|
50
|
+
- **Token name** — Something descriptive like `claude-code-pm`
|
|
51
|
+
- **Expiration** — Set a reasonable window (90 days is a good default)
|
|
52
|
+
- **Resource owner** — Your account (or your org if the repos live there)
|
|
53
|
+
- **Repository access** — Select **Only select repositories**, then pick the repos these skills will manage
|
|
54
|
+
|
|
55
|
+
**Step 3:** Under **Permissions → Repository permissions**, grant:
|
|
56
|
+
|
|
57
|
+
| Permission | Access | Why |
|
|
58
|
+
|---|---|---|
|
|
59
|
+
| Contents | Read & Write | Create branches, push commits |
|
|
60
|
+
| Issues | Read & Write | Create and update stories on the project board |
|
|
61
|
+
| Metadata | Read | Required by GitHub for all fine-grained PATs |
|
|
62
|
+
| Pull requests | Read & Write | Open PRs for story branches and releases |
|
|
63
|
+
|
|
64
|
+
**Step 4:** Under **Permissions → Account permissions**, grant:
|
|
65
|
+
|
|
66
|
+
| Permission | Access | Why |
|
|
67
|
+
|---|---|---|
|
|
68
|
+
| Projects | Read & Write | Create project boards, custom fields, and views |
|
|
69
|
+
|
|
70
|
+
**Step 5:** Click **Generate token** and copy it immediately — you won't see it again.
|
|
71
|
+
|
|
72
|
+
**Step 6:** Authenticate the GitHub CLI with your new token:
|
|
73
|
+
|
|
74
|
+
```bash
|
|
75
|
+
echo "YOUR_TOKEN" | gh auth login --with-token
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
Verify it worked:
|
|
79
|
+
|
|
80
|
+
```bash
|
|
81
|
+
gh auth status
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
**Security tip:** Do not grant write access to your `main` branch via the token. Set up branch protection rules so merges to `main` always require your manual review. This is the gate that keeps you in control.
|
|
85
|
+
|
|
86
|
+
### 2. Write a PRD
|
|
87
|
+
|
|
88
|
+
Create a markdown file with your project requirements. The more structured, the better the scaffold. At minimum, include:
|
|
89
|
+
- Project name and description
|
|
90
|
+
- Phases or milestones with clear boundaries
|
|
91
|
+
- User stories or features per phase
|
|
92
|
+
- Acceptance criteria for each story
|
|
93
|
+
|
|
94
|
+
### 3. Scaffold the Project
|
|
95
|
+
|
|
96
|
+
Open Claude Code in your repo and run:
|
|
97
|
+
|
|
98
|
+
```
|
|
99
|
+
/project-scaffold path/to/your-prd.md
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
This creates:
|
|
103
|
+
- A GitHub Project board with custom fields (Status, Sprint, Priority, Executor, Story Points, Phase)
|
|
104
|
+
- Board views: Current Sprint, Claude Queue, My Tasks, Backlog, Phase Overview
|
|
105
|
+
- Issues for every story, labeled with type, priority, phase, and executor
|
|
106
|
+
- Milestones for each phase
|
|
107
|
+
- A release branch for the first phase
|
|
108
|
+
- Branch protection on main
|
|
109
|
+
|
|
110
|
+
### 4. Plan a Sprint
|
|
111
|
+
|
|
112
|
+
```
|
|
113
|
+
/sprint-plan owner/repo
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
The skill pulls stories from the backlog, assigns them to the next sprint iteration, and sets up the release branch. It respects your velocity target (default: 20 story points) and prioritizes by the Priority field.
|
|
117
|
+
|
|
118
|
+
### 5. Assign an Executor
|
|
119
|
+
|
|
120
|
+
Label stories to tell Claude what's its responsibility:
|
|
121
|
+
|
|
122
|
+
```bash
|
|
123
|
+
# Assign all Phase 1 stories to Claude
|
|
124
|
+
gh issue list --label "phase:1" --json number -q '.[].number' | \
|
|
125
|
+
xargs -I {} gh issue edit {} --add-label "executor:claude"
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
Three executor labels:
|
|
129
|
+
|
|
130
|
+
| Label | Who | When |
|
|
131
|
+
|---|---|---|
|
|
132
|
+
| `executor:claude` | Claude Code | Clear implementation path, no human judgment needed |
|
|
133
|
+
| `executor:human` | You | Business decisions, credentials, external approvals |
|
|
134
|
+
| `executor:cowork` | Cowork agent | Research, drafting, web-based tasks |
|
|
135
|
+
|
|
136
|
+
### 6. Hand Off to Claude Code
|
|
137
|
+
|
|
138
|
+
In Claude Code, tell it to work the sprint:
|
|
139
|
+
|
|
140
|
+
> "Pick up the current sprint. Work through all stories labeled executor:claude in priority order. For each story, create a feature branch off the release branch, implement, open a PR back to the release branch, and move the issue to Done."
|
|
141
|
+
|
|
142
|
+
Claude works autonomously — branching, committing, opening PRs with auto-merge to the release branch.
|
|
143
|
+
|
|
144
|
+
### 7. Check Progress
|
|
145
|
+
|
|
146
|
+
```
|
|
147
|
+
/sprint-status owner/repo
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
Get a progress report: stories completed vs. remaining, burndown, blockers, and what Claude is working on.
|
|
151
|
+
|
|
152
|
+
### 8. Release the Sprint
|
|
153
|
+
|
|
154
|
+
```
|
|
155
|
+
/sprint-release owner/repo
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
This closes the sprint, opens a release PR from the release branch into main, and summarizes everything that shipped. You review one PR, merge it, and you're done.
|
|
159
|
+
|
|
160
|
+
### 9. Emulate the Project
|
|
161
|
+
|
|
162
|
+
```
|
|
163
|
+
/project-emulate
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
Claude reads the entire codebase, discovers every role, every action, and every permission boundary, then walks through the full lifecycle — from infrastructure deployment through normal operations to teardown. Outputs a coverage report with a permission matrix and categorized issues.
|
|
167
|
+
|
|
168
|
+
### 10. Repeat
|
|
169
|
+
|
|
170
|
+
```
|
|
171
|
+
/sprint-plan owner/repo
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
Start the next sprint. The cycle continues until the project is complete.
|
|
175
|
+
|
|
176
|
+
## How It Works
|
|
177
|
+
|
|
178
|
+
### Branch Strategy
|
|
179
|
+
|
|
180
|
+
```
|
|
181
|
+
main (protected — requires your review)
|
|
182
|
+
└── release/phase-1-core-api
|
|
183
|
+
├── story/1-init-project → auto-merge ✓
|
|
184
|
+
├── story/2-database-schema → auto-merge ✓
|
|
185
|
+
└── story/3-auth-endpoints → auto-merge ✓
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
Story branches auto-merge into the release branch when CI passes. You only review the release PR to `main`. This keeps Claude unblocked while giving you a single approval gate per sprint.
|
|
189
|
+
|
|
190
|
+
### GitHub Project Board
|
|
191
|
+
|
|
192
|
+
The scaffold creates a GitHub Project (the newer Projects experience, not classic project boards) with these custom fields:
|
|
193
|
+
|
|
194
|
+
| Field | Type | Purpose |
|
|
195
|
+
|---|---|---|
|
|
196
|
+
| Status | Single select | Workflow state: Backlog → Ready → In Progress → In Review → Done |
|
|
197
|
+
| Sprint | Iteration (2-week) | Time-boxed sprint assignment. Filter views by Milestone to scope to a sprint |
|
|
198
|
+
| Priority | Single select | P0-Critical through P3-Low |
|
|
199
|
+
| Executor | Single select | Who works this: `claude`, `human`, or `cowork` |
|
|
200
|
+
| Story Points | Number | Fibonacci estimation (1, 2, 3, 5, 8, 13) |
|
|
201
|
+
| Phase | Single select | Maps back to PRD phases/milestones |
|
|
202
|
+
|
|
203
|
+
**Board views** use GitHub's view system:
|
|
204
|
+
|
|
205
|
+
- **Current Sprint** — Board layout, filtered by Milestone to the active sprint, columns by Status
|
|
206
|
+
- **Claude Queue** — Table layout, filtered to `Executor = claude` and `Status = Ready`, sorted by Priority
|
|
207
|
+
- **By Sprint** — Board layout, grouped by Sprint (creates swimlanes per sprint)
|
|
208
|
+
- **Phase Overview** — Table layout, grouped by Phase, with field sums on Story Points
|
|
209
|
+
- **Backlog** — Table layout, filtered to `Status = Backlog`, sorted by Priority
|
|
210
|
+
|
|
211
|
+
You can also use **Slice by** on any field to quickly filter the current view from a side panel — useful for slicing a sprint view by Executor or Priority.
|
|
212
|
+
|
|
213
|
+
### Shared Conventions
|
|
214
|
+
|
|
215
|
+
All skills reference a single `CONVENTIONS.md` file that defines labels, branch naming, custom fields, executor guidelines, and story point standards. Edit it once and every skill inherits the changes.
|
|
216
|
+
|
|
217
|
+
Located at: `project-scaffold/references/CONVENTIONS.md`
|
|
218
|
+
|
|
219
|
+
## Skills Reference
|
|
220
|
+
|
|
221
|
+
| Skill | Command | What It Does |
|
|
222
|
+
|---|---|---|
|
|
223
|
+
| `project-scaffold` | `/project-scaffold <prd-path>` | Full project setup from PRD |
|
|
224
|
+
| `sprint-plan` | `/sprint-plan [owner/repo]` | Plan and populate the next sprint |
|
|
225
|
+
| `sprint-status` | `/sprint-status [owner/repo]` | Progress report and burndown |
|
|
226
|
+
| `sprint-release` | `/sprint-release [owner/repo]` | Close sprint, open release PR |
|
|
227
|
+
| `project-emulate` | `/project-emulate` | Full walkthrough coverage of all roles, actions, and lifecycle stages |
|
|
228
|
+
|
|
229
|
+
## Customization
|
|
230
|
+
|
|
231
|
+
### Sprint Length
|
|
232
|
+
Edit `CONVENTIONS.md` → "Sprint Cadence" section. Default is 2 weeks.
|
|
233
|
+
|
|
234
|
+
### Velocity Target
|
|
235
|
+
The `sprint-plan` skill asks for velocity or defaults to 20 story points. Adjust as you calibrate.
|
|
236
|
+
|
|
237
|
+
### Label Colors
|
|
238
|
+
All label hex colors are defined in the `project-scaffold` skill. Modify to match your preferences.
|
|
239
|
+
|
|
240
|
+
### Executor Criteria
|
|
241
|
+
Edit `CONVENTIONS.md` → "Executor Assignment Guidelines" to tune what gets assigned to Claude vs. you vs. Cowork.
|
|
242
|
+
|
|
243
|
+
### Adding Phases
|
|
244
|
+
Phases map to your PRD structure. If you add new phases later, create a new milestone and add the corresponding value to the Phase custom field.
|
|
245
|
+
|
|
246
|
+
## Tips
|
|
247
|
+
|
|
248
|
+
- **Chunk large phases** into multiple sprints for natural review gates. If Phase 1 has 30 stories, split it into 2-3 sprints rather than one massive batch.
|
|
249
|
+
- **Filter views by Milestone** to scope board views to the active sprint. Update the filter when you move to the next sprint.
|
|
250
|
+
- **Start small.** Scaffold a real but small project first to calibrate your conventions before relying on it for bigger work.
|
|
251
|
+
- **Branch protection is your safety net.** The PAT should not have write access to main. Merges to main always go through your review.
|
|
252
|
+
- **Run `/project-emulate` before releases** to catch permission gaps, missing flows, and dead code before shipping.
|
|
253
|
+
|
|
254
|
+
## License
|
|
255
|
+
|
|
256
|
+
Apache 2.0 — See [LICENSE](LICENSE) for details.
|
package/bin/install.js
ADDED
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
const fs = require('fs');
|
|
4
|
+
const path = require('path');
|
|
5
|
+
|
|
6
|
+
const HOME = process.env.HOME || process.env.USERPROFILE;
|
|
7
|
+
const SKILLS_DIR = path.join(HOME, '.claude', 'skills');
|
|
8
|
+
const SOURCE_DIR = path.join(__dirname, '..', 'skills');
|
|
9
|
+
|
|
10
|
+
const skills = [
|
|
11
|
+
'project-scaffold',
|
|
12
|
+
'sprint-plan',
|
|
13
|
+
'sprint-status',
|
|
14
|
+
'sprint-release',
|
|
15
|
+
'project-emulate'
|
|
16
|
+
];
|
|
17
|
+
|
|
18
|
+
function copyRecursive(src, dest) {
|
|
19
|
+
if (!fs.existsSync(src)) return;
|
|
20
|
+
|
|
21
|
+
if (fs.statSync(src).isDirectory()) {
|
|
22
|
+
fs.mkdirSync(dest, { recursive: true });
|
|
23
|
+
for (const item of fs.readdirSync(src)) {
|
|
24
|
+
copyRecursive(path.join(src, item), path.join(dest, item));
|
|
25
|
+
}
|
|
26
|
+
} else {
|
|
27
|
+
fs.copyFileSync(src, dest);
|
|
28
|
+
}
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
console.log('\n📋 Installing claude-scrum-skill...\n');
|
|
32
|
+
|
|
33
|
+
// Ensure ~/.claude/skills exists
|
|
34
|
+
fs.mkdirSync(SKILLS_DIR, { recursive: true });
|
|
35
|
+
|
|
36
|
+
let installed = 0;
|
|
37
|
+
for (const skill of skills) {
|
|
38
|
+
const src = path.join(SOURCE_DIR, skill);
|
|
39
|
+
const dest = path.join(SKILLS_DIR, skill);
|
|
40
|
+
|
|
41
|
+
if (fs.existsSync(src)) {
|
|
42
|
+
copyRecursive(src, dest);
|
|
43
|
+
console.log(` ✅ ${skill}`);
|
|
44
|
+
installed++;
|
|
45
|
+
} else {
|
|
46
|
+
console.log(` ⚠️ ${skill} — source not found, skipping`);
|
|
47
|
+
}
|
|
48
|
+
}
|
|
49
|
+
|
|
50
|
+
console.log(`\n✨ Installed ${installed} skills to ${SKILLS_DIR}`);
|
|
51
|
+
console.log(' Skills are available in Claude Code immediately.\n');
|
|
52
|
+
console.log(' Run /project-scaffold <prd-path> to get started.\n');
|
package/package.json
ADDED
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@houseofwolvesllc/claude-scrum-skill",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "Claude Code skills for scrum project management — PRD to production release pipeline with project scaffolding, sprint planning, status tracking, sprint releases, and full-project emulation testing.",
|
|
5
|
+
"bin": {},
|
|
6
|
+
"scripts": {
|
|
7
|
+
"postinstall": "node bin/install.js"
|
|
8
|
+
},
|
|
9
|
+
"keywords": [
|
|
10
|
+
"claude",
|
|
11
|
+
"claude-code",
|
|
12
|
+
"skills",
|
|
13
|
+
"scrum",
|
|
14
|
+
"sprint",
|
|
15
|
+
"project-management",
|
|
16
|
+
"agile",
|
|
17
|
+
"github-projects"
|
|
18
|
+
],
|
|
19
|
+
"author": "House of Wolves LLC",
|
|
20
|
+
"license": "Apache-2.0",
|
|
21
|
+
"repository": {
|
|
22
|
+
"type": "git",
|
|
23
|
+
"url": "https://github.com/houseofwolvesllc/claudescrumskill.git"
|
|
24
|
+
},
|
|
25
|
+
"homepage": "https://github.com/houseofwolvesllc/claudescrumskill#readme",
|
|
26
|
+
"bugs": {
|
|
27
|
+
"url": "https://github.com/houseofwolvesllc/claudescrumskill/issues"
|
|
28
|
+
},
|
|
29
|
+
"files": [
|
|
30
|
+
"skills/",
|
|
31
|
+
"bin/"
|
|
32
|
+
]
|
|
33
|
+
}
|
|
@@ -0,0 +1,155 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: project-emulate
|
|
3
|
+
description: Systematically walk through every user-facing workflow in a project by reading the codebase, discovering all roles and functionality, then emulating each role through the complete lifecycle from deployment to teardown. Claude Code figures out the roles, permissions, actions, and permutations itself — no manifests or configuration needed.
|
|
4
|
+
allowed-tools: Bash, Read, Grep, Glob, Write
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Project Emulate
|
|
8
|
+
|
|
9
|
+
Claude Code reads the codebase, discovers everything, and walks through it all. No config files. No role manifests. No manual setup. Claude is smart enough to figure out what exists and what every role can do.
|
|
10
|
+
|
|
11
|
+
## The Job
|
|
12
|
+
|
|
13
|
+
1. **Read the project** — understand what it is, what it does, how it's structured
|
|
14
|
+
2. **Discover every role** — find all user types, service accounts, admin levels, anonymous access
|
|
15
|
+
3. **Discover every action** — find all routes, commands, workflows, infrastructure operations
|
|
16
|
+
4. **Map permissions** — determine what each role can and cannot do
|
|
17
|
+
5. **Walk through everything** — emulate each role executing each action across the full lifecycle
|
|
18
|
+
6. **Report coverage** — what works, what's broken, what's missing, what's unreachable
|
|
19
|
+
|
|
20
|
+
## Phase 1: Discovery
|
|
21
|
+
|
|
22
|
+
Read the entire project. Build a complete mental model. Scan for:
|
|
23
|
+
|
|
24
|
+
**Roles** — Look everywhere roles are defined or referenced:
|
|
25
|
+
- Auth middleware, RBAC configs, policy files, guard decorators
|
|
26
|
+
- Role enums, permission constants, user type definitions
|
|
27
|
+
- Database seeds/fixtures/migrations that create default roles
|
|
28
|
+
- IAM policies, service account definitions, API key scopes
|
|
29
|
+
- Environment-specific roles (dev vs staging vs prod)
|
|
30
|
+
- Don't forget: anonymous/unauthenticated users, system/cron jobs, CI/CD service accounts
|
|
31
|
+
|
|
32
|
+
**Actions** — Find every thing a user or system can do:
|
|
33
|
+
- Route files, controllers, API handlers (REST, GraphQL, gRPC, WebSocket)
|
|
34
|
+
- CLI commands and subcommands
|
|
35
|
+
- UI pages, forms, buttons, workflows
|
|
36
|
+
- Background jobs, scheduled tasks, event handlers
|
|
37
|
+
- Infrastructure operations (deploy, scale, configure, destroy)
|
|
38
|
+
- Database operations (migrate, seed, backup, restore)
|
|
39
|
+
- Admin-only operations (user management, config changes, feature flags)
|
|
40
|
+
|
|
41
|
+
**Permission Boundaries** — Map which roles can do which actions:
|
|
42
|
+
- Route-level guards and middleware chains
|
|
43
|
+
- Field-level permissions (what data each role can see/edit)
|
|
44
|
+
- Resource ownership rules (users can edit their own, admins can edit all)
|
|
45
|
+
- State-dependent permissions (e.g., only draft posts can be deleted by authors)
|
|
46
|
+
- Rate limits or quotas that differ by role
|
|
47
|
+
|
|
48
|
+
**Lifecycle Stages** — Identify the natural ordering of operations:
|
|
49
|
+
- Infrastructure provisioning and deployment
|
|
50
|
+
- Initial setup and configuration
|
|
51
|
+
- User/account creation and onboarding
|
|
52
|
+
- Normal CRUD operations
|
|
53
|
+
- Advanced/power-user workflows
|
|
54
|
+
- Administrative operations
|
|
55
|
+
- Maintenance and migration
|
|
56
|
+
- Teardown and destruction
|
|
57
|
+
|
|
58
|
+
## Phase 2: Build the Permutation Matrix
|
|
59
|
+
|
|
60
|
+
After discovery, construct the complete matrix:
|
|
61
|
+
|
|
62
|
+
```
|
|
63
|
+
Roles × Actions × Lifecycle Stages = Total Permutations
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
Organize this as a structured walkthrough plan:
|
|
67
|
+
|
|
68
|
+
For each **lifecycle stage** (in order):
|
|
69
|
+
For each **role** (from most privileged to least):
|
|
70
|
+
For each **action available at this stage**:
|
|
71
|
+
- What should happen (success path)
|
|
72
|
+
- What should be denied (permission boundary)
|
|
73
|
+
- What edge cases exist (empty states, conflicts, limits)
|
|
74
|
+
|
|
75
|
+
**Critical**: Include negative cases. For every action a role CAN do, verify that less-privileged roles CANNOT. Permission boundaries are as important as happy paths.
|
|
76
|
+
|
|
77
|
+
## Phase 3: Walkthrough
|
|
78
|
+
|
|
79
|
+
Execute the walkthrough by narrating through every cell in the matrix. For each action:
|
|
80
|
+
|
|
81
|
+
1. **State the context**: "As [role], during [lifecycle stage], attempting to [action]"
|
|
82
|
+
2. **Trace the code path**: Follow the request through middleware → handler → service → database
|
|
83
|
+
3. **Identify the outcome**: Success, permission denied, validation error, or missing implementation
|
|
84
|
+
4. **Note edge cases**: What happens with empty data, concurrent access, invalid input
|
|
85
|
+
5. **Flag issues**: Anything that looks broken, missing, inconsistent, or insecure
|
|
86
|
+
|
|
87
|
+
### Walkthrough Order
|
|
88
|
+
|
|
89
|
+
Follow the natural lifecycle:
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
1. INFRASTRUCTURE — Deploy, configure, verify (health checks, smoke tests)
|
|
93
|
+
2. BOOTSTRAP — Database migration, seed data, initial admin creation
|
|
94
|
+
3. ADMIN OPERATIONS — User/role management, system settings, feature flags
|
|
95
|
+
4. USER ONBOARDING — Registration, authentication, profile setup
|
|
96
|
+
5. CORE FUNCTIONALITY — All CRUD operations, search, relationships, file handling
|
|
97
|
+
6. ADVANCED WORKFLOWS — Multi-step processes, integrations, batch operations, notifications
|
|
98
|
+
7. EDGE CASES & BOUNDARIES — Empty states, limits, concurrent access, error handling
|
|
99
|
+
8. MAINTENANCE — Backup/restore, data migration, upgrades, cleanup jobs
|
|
100
|
+
9. TEARDOWN — Account deletion, resource cleanup, infrastructure destruction, data export
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
Not every project will have all stages. Skip what doesn't apply. Add stages unique to the project.
|
|
104
|
+
|
|
105
|
+
## Phase 4: Coverage Report
|
|
106
|
+
|
|
107
|
+
After the walkthrough, produce a structured report:
|
|
108
|
+
|
|
109
|
+
### Summary
|
|
110
|
+
- Total roles discovered
|
|
111
|
+
- Total actions discovered
|
|
112
|
+
- Total permutations walked
|
|
113
|
+
- Coverage percentage (walked / total possible)
|
|
114
|
+
|
|
115
|
+
### Issues Found
|
|
116
|
+
Categorize by severity:
|
|
117
|
+
- **Critical**: Permission escalation paths, missing auth checks, broken core flows
|
|
118
|
+
- **Warning**: Inconsistent behavior, missing error handling, undocumented features
|
|
119
|
+
- **Info**: Dead code, unreachable features, minor edge cases
|
|
120
|
+
|
|
121
|
+
### Missing Coverage
|
|
122
|
+
- Actions that exist in code but aren't reachable by any role
|
|
123
|
+
- Roles referenced in code but never fully defined
|
|
124
|
+
- Lifecycle stages with no corresponding implementation
|
|
125
|
+
- Permission checks that reference non-existent roles or actions
|
|
126
|
+
|
|
127
|
+
### Permission Matrix
|
|
128
|
+
A clean table: Roles as rows, Actions as columns, cells showing allowed / denied / ambiguous / not applicable
|
|
129
|
+
|
|
130
|
+
## Output
|
|
131
|
+
|
|
132
|
+
Save results to:
|
|
133
|
+
|
|
134
|
+
```
|
|
135
|
+
emulation-report/
|
|
136
|
+
├── SUMMARY.md # High-level findings and coverage stats
|
|
137
|
+
├── DISCOVERY.md # All roles, actions, and permissions found
|
|
138
|
+
├── WALKTHROUGH.md # The complete narrated walkthrough
|
|
139
|
+
├── PERMISSION-MATRIX.md # Role × Action matrix table
|
|
140
|
+
└── ISSUES.md # All issues found, categorized by severity
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
For large projects, split the walkthrough by lifecycle stage into a `walkthrough/` subdirectory.
|
|
144
|
+
|
|
145
|
+
## Execution Notes
|
|
146
|
+
|
|
147
|
+
**Be exhaustive but structured.** The whole point is 100% coverage. Don't skip actions because they seem trivial. Walk through everything.
|
|
148
|
+
|
|
149
|
+
**Follow the code, not the docs.** The code is the source of truth. If docs say one thing and code does another, report the discrepancy.
|
|
150
|
+
|
|
151
|
+
**Think like each role.** Including things they shouldn't be able to do.
|
|
152
|
+
|
|
153
|
+
**Track state across the walkthrough.** Walk in lifecycle order so dependencies are naturally satisfied.
|
|
154
|
+
|
|
155
|
+
**Report, don't fix.** Discover and document. Flag everything clearly for separate prioritization.
|
|
@@ -0,0 +1,173 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: project-scaffold
|
|
3
|
+
description: Scaffold a complete GitHub Project from PRD or spec documents. Creates the project board with custom fields and views, milestones for each phase, issues for every story with proper labels and dependencies, and sets up the branch strategy. Use when starting a new project, onboarding a new PRD, or bootstrapping a GitHub Project structure from requirements documents.
|
|
4
|
+
allowed-tools: Bash, Read, Write, Glob, Grep
|
|
5
|
+
argument-hint: <path-to-prd-or-spec-files>
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Project Scaffold
|
|
9
|
+
|
|
10
|
+
Scaffold a complete GitHub Project from one or more PRD or spec documents.
|
|
11
|
+
|
|
12
|
+
## Before You Start
|
|
13
|
+
|
|
14
|
+
1. Read `references/CONVENTIONS.md` in this skill's directory for all project management standards including label taxonomy, branch strategy, issue templates, custom fields, and executor assignment guidelines. Follow these conventions exactly.
|
|
15
|
+
2. Confirm the `gh` CLI is authenticated by running `gh auth status`.
|
|
16
|
+
3. Identify the target repository. If the user doesn't specify, ask which repo to use.
|
|
17
|
+
|
|
18
|
+
## Input
|
|
19
|
+
|
|
20
|
+
The user provides `$ARGUMENTS` which should be one or more file paths to PRD or spec documents (markdown, text, or similar). If no arguments are provided, ask the user to specify the PRD location.
|
|
21
|
+
|
|
22
|
+
Read all provided documents thoroughly before proceeding.
|
|
23
|
+
|
|
24
|
+
## Scaffolding Procedure
|
|
25
|
+
|
|
26
|
+
### Step 1: Parse the PRD
|
|
27
|
+
|
|
28
|
+
Extract from the documents:
|
|
29
|
+
- Project name and description
|
|
30
|
+
- Phases/milestones (ordered)
|
|
31
|
+
- User stories per phase with acceptance criteria
|
|
32
|
+
- Dependencies between stories
|
|
33
|
+
- Any technical architecture notes
|
|
34
|
+
|
|
35
|
+
### Step 2: Create Labels
|
|
36
|
+
|
|
37
|
+
Create all labels defined in CONVENTIONS.md on the target repo:
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
# Executor labels
|
|
41
|
+
gh label create "executor:claude" --color 0E8A16 --description "Claude Code handles this" --repo <owner/repo>
|
|
42
|
+
gh label create "executor:human" --color 1D76DB --description "Requires human judgment" --repo <owner/repo>
|
|
43
|
+
gh label create "executor:cowork" --color D4C5F9 --description "Cowork agent task" --repo <owner/repo>
|
|
44
|
+
|
|
45
|
+
# Status signal labels
|
|
46
|
+
gh label create "ready-for-work" --color 0E8A16 --repo <owner/repo>
|
|
47
|
+
gh label create "needs-context" --color FBCA04 --repo <owner/repo>
|
|
48
|
+
gh label create "blocked" --color B60205 --repo <owner/repo>
|
|
49
|
+
gh label create "deferred" --color D93F0B --repo <owner/repo>
|
|
50
|
+
gh label create "rolled-over" --color E99695 --repo <owner/repo>
|
|
51
|
+
|
|
52
|
+
# Type labels
|
|
53
|
+
gh label create "type:story" --color C2E0C6 --repo <owner/repo>
|
|
54
|
+
gh label create "type:bug" --color D73A4A --repo <owner/repo>
|
|
55
|
+
gh label create "type:spike" --color D4C5F9 --repo <owner/repo>
|
|
56
|
+
gh label create "type:infra" --color 0075CA --repo <owner/repo>
|
|
57
|
+
gh label create "type:chore" --color FEF2C0 --repo <owner/repo>
|
|
58
|
+
|
|
59
|
+
# Priority labels
|
|
60
|
+
gh label create "P0-critical" --color B60205 --repo <owner/repo>
|
|
61
|
+
gh label create "P1-high" --color D93F0B --repo <owner/repo>
|
|
62
|
+
gh label create "P2-medium" --color FBCA04 --repo <owner/repo>
|
|
63
|
+
gh label create "P3-low" --color 0E8A16 --repo <owner/repo>
|
|
64
|
+
|
|
65
|
+
# Phase labels (one per PRD phase)
|
|
66
|
+
# gh label create "phase:<N>" --color <color> --repo <owner/repo>
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
### Step 3: Create Milestones
|
|
70
|
+
|
|
71
|
+
For each phase in the PRD:
|
|
72
|
+
|
|
73
|
+
```bash
|
|
74
|
+
gh api repos/<owner/repo>/milestones -f title="Phase N: <Phase Name>" -f description="<Phase summary from PRD>" -f state="open"
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
### Step 4: Create the GitHub Project
|
|
78
|
+
|
|
79
|
+
```bash
|
|
80
|
+
# Create the project (org-level or user-level depending on repo ownership)
|
|
81
|
+
gh project create --owner <owner> --title "<Project Name>"
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
Note the project number returned. Then configure custom fields as defined in CONVENTIONS.md. Use the GraphQL API via `gh api graphql` to add:
|
|
85
|
+
- Status (single select with values: Backlog, Ready, In Progress, In Review, Done)
|
|
86
|
+
- Priority (single select with values: P0-Critical, P1-High, P2-Medium, P3-Low)
|
|
87
|
+
- Executor (single select with values: claude, human, cowork)
|
|
88
|
+
- Story Points (number field)
|
|
89
|
+
- Phase (single select with values derived from PRD phases)
|
|
90
|
+
- Sprint (iteration field with 2-week cycles)
|
|
91
|
+
|
|
92
|
+
### Step 5: Create Issues
|
|
93
|
+
|
|
94
|
+
For each story extracted from the PRD, create an issue following the template in CONVENTIONS.md:
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
gh issue create \
|
|
98
|
+
--repo <owner/repo> \
|
|
99
|
+
--title "<Story title>" \
|
|
100
|
+
--body "<Issue body from template>" \
|
|
101
|
+
--label "type:story,executor:<type>,<priority>,ready-for-work" \
|
|
102
|
+
--milestone "<Phase N: Phase Name>"
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
For each issue:
|
|
106
|
+
- Assign executor label based on the executor assignment guidelines in CONVENTIONS.md
|
|
107
|
+
- Assign priority based on PRD emphasis and dependencies
|
|
108
|
+
- Assign to the correct milestone
|
|
109
|
+
- Estimate story points based on the guidelines in CONVENTIONS.md
|
|
110
|
+
- Note dependencies in the issue body
|
|
111
|
+
|
|
112
|
+
After creating issues, add them to the GitHub Project and set their custom field values.
|
|
113
|
+
|
|
114
|
+
### Step 6: Link Dependencies
|
|
115
|
+
|
|
116
|
+
For any stories with dependencies, add cross-references:
|
|
117
|
+
- Edit blocking issues to mention "Blocks #<number>" in the body
|
|
118
|
+
- Edit blocked issues to mention "Blocked by #<number>" in the body
|
|
119
|
+
|
|
120
|
+
### Step 7: Create Branch Structure
|
|
121
|
+
|
|
122
|
+
```bash
|
|
123
|
+
# Ensure main is up to date
|
|
124
|
+
git checkout main && git pull
|
|
125
|
+
|
|
126
|
+
# Create release branch for the first phase/sprint
|
|
127
|
+
git checkout -b release/<first-milestone-slug>
|
|
128
|
+
git push -u origin release/<first-milestone-slug>
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
### Step 8: Configure Branch Protection
|
|
132
|
+
|
|
133
|
+
Attempt to set branch protection rules as defined in CONVENTIONS.md. If permissions are insufficient, output the recommended settings for the user to configure manually.
|
|
134
|
+
|
|
135
|
+
### Step 9: Generate Summary
|
|
136
|
+
|
|
137
|
+
Output a complete summary:
|
|
138
|
+
|
|
139
|
+
```
|
|
140
|
+
## Project Scaffold Complete
|
|
141
|
+
|
|
142
|
+
**Project:** <name>
|
|
143
|
+
**Repository:** <owner/repo>
|
|
144
|
+
**Project Board:** <link to GitHub Project>
|
|
145
|
+
|
|
146
|
+
### Milestones
|
|
147
|
+
- Phase 1: <name> — <N> stories, <total points> points
|
|
148
|
+
- Phase 2: <name> — <N> stories, <total points> points
|
|
149
|
+
...
|
|
150
|
+
|
|
151
|
+
### Story Breakdown by Executor
|
|
152
|
+
- executor:claude — <N> stories (<points> points)
|
|
153
|
+
- executor:human — <N> stories (<points> points)
|
|
154
|
+
- executor:cowork — <N> stories (<points> points)
|
|
155
|
+
|
|
156
|
+
### Branch Structure
|
|
157
|
+
- Release branch: release/<slug> (created)
|
|
158
|
+
- Branch protection: <configured/manual setup needed>
|
|
159
|
+
|
|
160
|
+
### Next Steps
|
|
161
|
+
1. Review the project board: <link>
|
|
162
|
+
2. Adjust priorities and sprint assignments as needed
|
|
163
|
+
3. Run `/sprint-plan` to plan the first sprint iteration
|
|
164
|
+
4. Start work with `/sprint-status` to monitor progress
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
## Error Handling
|
|
168
|
+
|
|
169
|
+
- If `gh` is not authenticated, provide instructions: `gh auth login`
|
|
170
|
+
- If the repo doesn't exist, ask the user to create it or specify the correct repo
|
|
171
|
+
- If label creation fails (label exists), skip silently
|
|
172
|
+
- If project creation fails, check if user has appropriate permissions
|
|
173
|
+
- Always capture and report issue numbers for cross-referencing
|
|
@@ -0,0 +1,170 @@
|
|
|
1
|
+
# Project Management Conventions
|
|
2
|
+
|
|
3
|
+
This document defines the shared standards used across all project management skills.
|
|
4
|
+
All PM skills reference this file — update it here and changes propagate everywhere.
|
|
5
|
+
|
|
6
|
+
## GitHub Project Structure
|
|
7
|
+
|
|
8
|
+
### Project Board Custom Fields
|
|
9
|
+
|
|
10
|
+
Every GitHub Project board MUST include these custom fields:
|
|
11
|
+
|
|
12
|
+
| Field | Type | Values | Purpose |
|
|
13
|
+
|-------|------|--------|---------|
|
|
14
|
+
| Status | Single select | `Backlog`, `Ready`, `In Progress`, `In Review`, `Done` | Kanban workflow state |
|
|
15
|
+
| Sprint | Iteration | 2-week cycles (configurable) | Sprint assignment |
|
|
16
|
+
| Priority | Single select | `P0-Critical`, `P1-High`, `P2-Medium`, `P3-Low` | Triage priority |
|
|
17
|
+
| Executor | Single select | `claude`, `human`, `cowork` | Who works this story |
|
|
18
|
+
| Story Points | Number | 1, 2, 3, 5, 8, 13 | Fibonacci estimation |
|
|
19
|
+
| Phase | Single select | Derived from PRD phases | Maps back to PRD structure |
|
|
20
|
+
|
|
21
|
+
### Project Board Views
|
|
22
|
+
|
|
23
|
+
Create these views on every project board:
|
|
24
|
+
|
|
25
|
+
1. **Current Sprint** — Board layout, filtered by Milestone to the active sprint, columns by Status
|
|
26
|
+
2. **Claude Queue** — Table layout, filtered to `Executor = claude` AND `Status = Ready`, sorted by Priority
|
|
27
|
+
3. **My Tasks** — Table layout, filtered to `Executor = human`, grouped by Sprint
|
|
28
|
+
4. **By Sprint** — Board layout, grouped by Sprint (creates swimlanes per sprint)
|
|
29
|
+
5. **Phase Overview** — Table layout, grouped by Phase, with field sums on Story Points
|
|
30
|
+
6. **Backlog** — Table layout, filtered to `Status = Backlog`, sorted by Priority
|
|
31
|
+
|
|
32
|
+
## Label Taxonomy
|
|
33
|
+
|
|
34
|
+
### Executor Labels (REQUIRED on every story)
|
|
35
|
+
|
|
36
|
+
- `executor:claude` — Claude Code handles implementation autonomously
|
|
37
|
+
- `executor:human` — Requires human judgment, decision-making, or external action
|
|
38
|
+
- `executor:cowork` — Lighter tasks suitable for Cowork/Chrome agent (research, drafts, web tasks)
|
|
39
|
+
|
|
40
|
+
### Status Signal Labels
|
|
41
|
+
|
|
42
|
+
- `ready-for-work` — Fully specced, unblocked, ready to pick up
|
|
43
|
+
- `needs-context` — Missing information; cannot begin until resolved
|
|
44
|
+
- `blocked` — Dependent on another issue (MUST link blocking issue)
|
|
45
|
+
- `deferred` — Intentionally pushed to a future sprint
|
|
46
|
+
- `rolled-over` — Incomplete from previous sprint, gets priority in next planning
|
|
47
|
+
|
|
48
|
+
### Type Labels
|
|
49
|
+
|
|
50
|
+
- `type:story` — A user-facing feature or capability
|
|
51
|
+
- `type:bug` — Defect in existing functionality
|
|
52
|
+
- `type:spike` — Research/exploration task with defined timebox
|
|
53
|
+
- `type:infra` — Infrastructure, CI/CD, tooling, DevOps
|
|
54
|
+
- `type:chore` — Maintenance, cleanup, refactoring, documentation
|
|
55
|
+
|
|
56
|
+
### Priority Labels
|
|
57
|
+
|
|
58
|
+
- `P0-critical` — Blocking release, security issue, or data loss risk
|
|
59
|
+
- `P1-high` — Core functionality for the current phase
|
|
60
|
+
- `P2-medium` — Important but not blocking
|
|
61
|
+
- `P3-low` — Nice-to-have, polish, optimization
|
|
62
|
+
|
|
63
|
+
## Branch Strategy
|
|
64
|
+
|
|
65
|
+
### Branch Naming
|
|
66
|
+
|
|
67
|
+
- **Release branches:** `release/<milestone-slug>` (e.g., `release/phase-1-core-api`)
|
|
68
|
+
- **Story branches:** `story/<issue-number>-<short-slug>` (e.g., `story/42-user-auth-endpoint`)
|
|
69
|
+
- **Spike branches:** `spike/<issue-number>-<short-slug>`
|
|
70
|
+
- **Bug fix branches:** `fix/<issue-number>-<short-slug>`
|
|
71
|
+
|
|
72
|
+
### Merge Strategy
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
main (protected)
|
|
76
|
+
└── release/phase-1-core-api (sprint release branch)
|
|
77
|
+
├── story/1-init-project-structure
|
|
78
|
+
├── story/2-database-schema
|
|
79
|
+
├── story/3-auth-endpoints
|
|
80
|
+
└── story/4-user-crud
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
- **Story → Release branch:** Auto-merge when CI passes. No human review required.
|
|
84
|
+
- **Release → main:** Human review required. This is the executive approval gate.
|
|
85
|
+
- Story PRs target the release branch, NOT main.
|
|
86
|
+
- Release PR to main includes a sprint summary (auto-generated by sprint-release skill).
|
|
87
|
+
|
|
88
|
+
### Branch Protection Rules
|
|
89
|
+
|
|
90
|
+
For the release branch:
|
|
91
|
+
- Require status checks to pass (CI/tests)
|
|
92
|
+
- Allow auto-merge when checks pass
|
|
93
|
+
- No required reviewers
|
|
94
|
+
|
|
95
|
+
For main:
|
|
96
|
+
- Require status checks to pass
|
|
97
|
+
- Require at least 1 reviewer (the human executive)
|
|
98
|
+
- No force pushes
|
|
99
|
+
- No deletions
|
|
100
|
+
|
|
101
|
+
## Issue Template
|
|
102
|
+
|
|
103
|
+
Use this template for every story/task issue:
|
|
104
|
+
|
|
105
|
+
```markdown
|
|
106
|
+
## Objective
|
|
107
|
+
[What this accomplishes — one clear sentence]
|
|
108
|
+
|
|
109
|
+
## Acceptance Criteria
|
|
110
|
+
- [ ] [Specific, testable criterion]
|
|
111
|
+
- [ ] [Specific, testable criterion]
|
|
112
|
+
- [ ] [Specific, testable criterion]
|
|
113
|
+
|
|
114
|
+
## Technical Context
|
|
115
|
+
[Architecture notes, relevant files, API contracts, approach guidance.
|
|
116
|
+
For executor:claude — be specific about code paths, patterns, and test expectations.
|
|
117
|
+
For executor:human — explain why this needs human judgment and what decisions are needed.]
|
|
118
|
+
|
|
119
|
+
## Dependencies
|
|
120
|
+
- **Blocked by:** [#issue or "none"]
|
|
121
|
+
- **Blocks:** [#issue or "none"]
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
## Milestone Structure
|
|
125
|
+
|
|
126
|
+
- Each PRD **phase** becomes a GitHub **milestone**
|
|
127
|
+
- Milestone title format: `Phase N: <Phase Name>` (e.g., `Phase 1: Core API`)
|
|
128
|
+
- Milestone description: Copy the phase summary from the PRD
|
|
129
|
+
- Milestone due date: Derived from sprint cadence and story point estimates
|
|
130
|
+
- Stories are assigned to milestones based on their phase
|
|
131
|
+
|
|
132
|
+
## Sprint Cadence
|
|
133
|
+
|
|
134
|
+
- Default sprint length: **2 weeks** (configurable per project)
|
|
135
|
+
- Sprint naming: `Sprint <N>` within the project's iteration field
|
|
136
|
+
- A phase may span multiple sprints if the work exceeds one cycle
|
|
137
|
+
- At sprint boundaries, incomplete stories roll to the next sprint with a `rolled-over` label
|
|
138
|
+
|
|
139
|
+
## Story Point Guidelines
|
|
140
|
+
|
|
141
|
+
| Points | Meaning | Example |
|
|
142
|
+
|--------|---------|---------|
|
|
143
|
+
| 1 | Trivial — config change, copy update | Update an env variable |
|
|
144
|
+
| 2 | Small — single file, clear implementation | Add a validation rule |
|
|
145
|
+
| 3 | Medium — multiple files, straightforward | New API endpoint with tests |
|
|
146
|
+
| 5 | Large — cross-cutting, some unknowns | Auth system with middleware |
|
|
147
|
+
| 8 | Very large — significant complexity | Database migration with data transform |
|
|
148
|
+
| 13 | Epic-sized — should probably be split | Full feature module end-to-end |
|
|
149
|
+
|
|
150
|
+
If a story estimates at 13, consider splitting it into smaller stories.
|
|
151
|
+
|
|
152
|
+
## Executor Assignment Guidelines
|
|
153
|
+
|
|
154
|
+
### Assign `executor:claude` when:
|
|
155
|
+
- Implementation path is clear from acceptance criteria
|
|
156
|
+
- Work is primarily code: new features, endpoints, tests, refactoring
|
|
157
|
+
- No external approvals, account access, or human judgment needed
|
|
158
|
+
- Dependencies are resolved (status is `ready-for-work`)
|
|
159
|
+
|
|
160
|
+
### Assign `executor:human` when:
|
|
161
|
+
- Requires external service signup, credentials, or account configuration
|
|
162
|
+
- Involves business decisions, UX judgment calls, or stakeholder input
|
|
163
|
+
- Needs access to systems Claude cannot reach (vendor portals, billing, etc.)
|
|
164
|
+
- Requires physical-world action (hardware, meetings, approvals)
|
|
165
|
+
|
|
166
|
+
### Assign `executor:cowork` when:
|
|
167
|
+
- Research tasks: competitive analysis, documentation review
|
|
168
|
+
- Content drafting: blog posts, documentation, emails
|
|
169
|
+
- Web-based tasks: form submissions, data gathering from websites
|
|
170
|
+
- File organization and cleanup tasks
|
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sprint-plan
|
|
3
|
+
description: Plan the next sprint iteration for a GitHub Project. Pulls stories from the backlog, assigns them to the upcoming sprint based on priority and capacity, and prepares the sprint for execution. Use when starting a new sprint cycle or when re-planning mid-sprint.
|
|
4
|
+
allowed-tools: Bash, Read, Write, Glob, Grep
|
|
5
|
+
argument-hint: [owner/repo] [project-number]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Sprint Plan
|
|
9
|
+
|
|
10
|
+
Plan and populate the next sprint iteration for an existing GitHub Project.
|
|
11
|
+
|
|
12
|
+
## Before You Start
|
|
13
|
+
|
|
14
|
+
1. Read `../project-scaffold/references/CONVENTIONS.md` for all project management standards. Follow these conventions exactly.
|
|
15
|
+
2. Confirm the `gh` CLI is authenticated by running `gh auth status`.
|
|
16
|
+
|
|
17
|
+
## Input
|
|
18
|
+
|
|
19
|
+
`$ARGUMENTS` should be the repo identifier and optionally the project number.
|
|
20
|
+
If not provided, detect from the current git remote or ask the user.
|
|
21
|
+
|
|
22
|
+
## Planning Procedure
|
|
23
|
+
|
|
24
|
+
### Step 1: Assess Current State
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
# Get open milestones
|
|
28
|
+
gh api repos/<owner/repo>/milestones --jq '.[] | select(.state=="open") | {number, title, open_issues, closed_issues}'
|
|
29
|
+
|
|
30
|
+
# Get the project's current sprint iteration
|
|
31
|
+
# Use GraphQL to query the project's iteration field and find the current/next sprint
|
|
32
|
+
|
|
33
|
+
# Get backlog items (issues not assigned to a sprint, sorted by priority)
|
|
34
|
+
gh issue list --repo <owner/repo> --state open --label "type:story" --json number,title,labels,milestone --jq 'sort_by(.labels)'
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
Gather:
|
|
38
|
+
- How many stories are in the current sprint and their status
|
|
39
|
+
- What's in the backlog, grouped by milestone/phase
|
|
40
|
+
- Any `rolled-over` items from the previous sprint (these get priority)
|
|
41
|
+
|
|
42
|
+
### Step 2: Calculate Capacity
|
|
43
|
+
|
|
44
|
+
Ask the user (or use defaults):
|
|
45
|
+
- Sprint length (default: 2 weeks per CONVENTIONS.md)
|
|
46
|
+
- Velocity estimate (story points per sprint — use previous sprint actuals if available)
|
|
47
|
+
- Any known unavailability or constraints
|
|
48
|
+
|
|
49
|
+
Default starting velocity if no history: **20 points** per sprint.
|
|
50
|
+
|
|
51
|
+
### Step 3: Select Stories for Sprint
|
|
52
|
+
|
|
53
|
+
Fill the sprint in this priority order:
|
|
54
|
+
|
|
55
|
+
1. **Rolled-over stories** from previous sprint (label: `rolled-over`)
|
|
56
|
+
2. **Blocked items that are now unblocked** (remove `blocked` label, add `ready-for-work`)
|
|
57
|
+
3. **P0-Critical stories** from the active milestone/phase
|
|
58
|
+
4. **P1-High stories** from the active milestone/phase
|
|
59
|
+
5. **P2-Medium and P3-Low** to fill remaining capacity
|
|
60
|
+
|
|
61
|
+
Stop when the total story points reach the velocity target. Present the proposed sprint to the user for approval before assigning.
|
|
62
|
+
|
|
63
|
+
### Step 4: Assign Sprint
|
|
64
|
+
|
|
65
|
+
After confirmation, update issues:
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
# Add sprint iteration assignment via GraphQL
|
|
69
|
+
# Update status to "Ready" for all sprint stories
|
|
70
|
+
# Ensure "ready-for-work" label is on unblocked items
|
|
71
|
+
# Ensure release branch exists for the target milestone
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
For each story in the sprint:
|
|
75
|
+
- Set the Sprint iteration field to the new sprint
|
|
76
|
+
- Set Status to "Ready" (or "Backlog" if dependencies aren't met yet)
|
|
77
|
+
- Verify labels are correct
|
|
78
|
+
|
|
79
|
+
### Step 5: Ensure Branch Exists
|
|
80
|
+
|
|
81
|
+
```bash
|
|
82
|
+
# Check if release branch exists for the active milestone
|
|
83
|
+
git ls-remote --heads origin release/<milestone-slug>
|
|
84
|
+
|
|
85
|
+
# If not, create it
|
|
86
|
+
git checkout main && git pull
|
|
87
|
+
git checkout -b release/<milestone-slug>
|
|
88
|
+
git push -u origin release/<milestone-slug>
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
### Step 6: Generate Sprint Kickoff Summary
|
|
92
|
+
|
|
93
|
+
```
|
|
94
|
+
## Sprint <N> Planned
|
|
95
|
+
|
|
96
|
+
**Sprint:** <N> | **Dates:** <start> — <end>
|
|
97
|
+
**Target:** <points> points across <count> stories
|
|
98
|
+
**Release Branch:** release/<milestone-slug>
|
|
99
|
+
|
|
100
|
+
### By Executor
|
|
101
|
+
- Claude: <N> stories (<points> pts) — ready for autonomous execution
|
|
102
|
+
- Human: <N> stories (<points> pts) — requires your attention
|
|
103
|
+
- Cowork: <N> stories (<points> pts) — delegatable via Cowork
|
|
104
|
+
|
|
105
|
+
### Sprint Goals
|
|
106
|
+
<2-3 sentence summary of what this sprint accomplishes in the context of the overall project>
|
|
107
|
+
|
|
108
|
+
### Blockers/Risks
|
|
109
|
+
<Any known risks, unresolved dependencies, or open questions>
|
|
110
|
+
|
|
111
|
+
### Next Steps
|
|
112
|
+
- Claude can begin picking up `executor:claude` + `ready-for-work` stories
|
|
113
|
+
- Review `executor:human` stories for your personal task list
|
|
114
|
+
- Run `/sprint-status` anytime to check progress
|
|
115
|
+
- Run `/sprint-release` when the sprint is complete
|
|
116
|
+
```
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sprint-release
|
|
3
|
+
description: Close out the current sprint and prepare a release. Generates a sprint summary, opens a release PR from the release branch into main, and transitions incomplete stories. Use when a sprint is complete or at the sprint boundary.
|
|
4
|
+
allowed-tools: Bash, Read, Write, Glob, Grep
|
|
5
|
+
argument-hint: [owner/repo] [project-number]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Sprint Release
|
|
9
|
+
|
|
10
|
+
Close the current sprint and open a release PR.
|
|
11
|
+
|
|
12
|
+
## Before You Start
|
|
13
|
+
|
|
14
|
+
1. Read `../project-scaffold/references/CONVENTIONS.md` for project management standards.
|
|
15
|
+
2. Confirm the `gh` CLI is authenticated.
|
|
16
|
+
|
|
17
|
+
## Input
|
|
18
|
+
|
|
19
|
+
`$ARGUMENTS` should be the repo identifier and optionally the project number.
|
|
20
|
+
If not provided, detect from the current git remote or ask the user.
|
|
21
|
+
|
|
22
|
+
## Release Procedure
|
|
23
|
+
|
|
24
|
+
### Step 1: Verify Sprint State
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
# Check for any stories still "In Progress" — warn before proceeding
|
|
28
|
+
# Count completed vs incomplete stories
|
|
29
|
+
# Get the release branch name for the current milestone
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
If stories are still in progress, warn the user and ask whether to:
|
|
33
|
+
- Wait for completion
|
|
34
|
+
- Roll incomplete stories to next sprint
|
|
35
|
+
- Proceed anyway (mark as rolled-over)
|
|
36
|
+
|
|
37
|
+
### Step 2: Handle Incomplete Stories
|
|
38
|
+
|
|
39
|
+
For any stories not marked Done:
|
|
40
|
+
- Add the `rolled-over` label
|
|
41
|
+
- Remove from current sprint iteration
|
|
42
|
+
- Note them in the release summary
|
|
43
|
+
|
|
44
|
+
### Step 3: Generate Release Summary
|
|
45
|
+
|
|
46
|
+
Build a comprehensive changelog from the sprint:
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
# Get all merged PRs on the release branch
|
|
50
|
+
gh pr list --repo <owner/repo> --base release/<slug> --state merged --json number,title,labels,mergedAt,body
|
|
51
|
+
|
|
52
|
+
# Get all closed issues from this sprint
|
|
53
|
+
gh issue list --repo <owner/repo> --state closed --label "type:story" --json number,title,labels,closedAt
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
### Step 4: Open Release PR
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
gh pr create \
|
|
60
|
+
--repo <owner/repo> \
|
|
61
|
+
--base main \
|
|
62
|
+
--head release/<milestone-slug> \
|
|
63
|
+
--title "Release: Sprint <N> — <Phase Name>" \
|
|
64
|
+
--body "<Release summary markdown>"
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
The PR body should include:
|
|
68
|
+
- Sprint summary (stories completed, points delivered)
|
|
69
|
+
- Full changelog (each story with brief description)
|
|
70
|
+
- Rolled-over items (if any)
|
|
71
|
+
- Notable technical changes
|
|
72
|
+
- Any known issues or follow-ups
|
|
73
|
+
|
|
74
|
+
### Step 5: Close Sprint Iteration
|
|
75
|
+
|
|
76
|
+
- Mark the sprint iteration as complete (via GraphQL)
|
|
77
|
+
- Update milestone progress
|
|
78
|
+
|
|
79
|
+
### Step 6: Output Release Summary
|
|
80
|
+
|
|
81
|
+
```
|
|
82
|
+
## Sprint <N> Release
|
|
83
|
+
|
|
84
|
+
**Release PR:** #<pr-number> — <link>
|
|
85
|
+
**Branch:** release/<slug> → main
|
|
86
|
+
**Stories Delivered:** <count> (<points> points)
|
|
87
|
+
|
|
88
|
+
### Changelog
|
|
89
|
+
- #12 User auth endpoint (5 pts)
|
|
90
|
+
- #13 Database schema migration (3 pts)
|
|
91
|
+
- #14 API key provisioning (2 pts)
|
|
92
|
+
...
|
|
93
|
+
|
|
94
|
+
### Rolled Over
|
|
95
|
+
- #18 Rate limiting (3 pts) — moved to next sprint
|
|
96
|
+
|
|
97
|
+
### Next Steps
|
|
98
|
+
1. Review and merge the release PR: <link>
|
|
99
|
+
2. Run `/sprint-plan` to start the next sprint
|
|
100
|
+
```
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sprint-status
|
|
3
|
+
description: Generate a status report for the current sprint. Shows progress by story, executor breakdown, burndown, blockers, and items needing attention. Use for daily standups, mid-sprint check-ins, or when asked about project progress.
|
|
4
|
+
allowed-tools: Bash, Read, Grep
|
|
5
|
+
argument-hint: [owner/repo] [project-number]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Sprint Status
|
|
9
|
+
|
|
10
|
+
Generate a comprehensive status report for the active sprint.
|
|
11
|
+
|
|
12
|
+
## Before You Start
|
|
13
|
+
|
|
14
|
+
1. Read `../project-scaffold/references/CONVENTIONS.md` for project management standards.
|
|
15
|
+
2. Confirm the `gh` CLI is authenticated.
|
|
16
|
+
|
|
17
|
+
## Input
|
|
18
|
+
|
|
19
|
+
`$ARGUMENTS` should be the repo identifier and optionally the project number.
|
|
20
|
+
If not provided, detect from the current git remote or ask the user.
|
|
21
|
+
|
|
22
|
+
## Status Report Procedure
|
|
23
|
+
|
|
24
|
+
### Step 1: Gather Data
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
# Get all issues in the current sprint iteration (via GraphQL project query)
|
|
28
|
+
# Get issue states, labels, assignees
|
|
29
|
+
# Get recent PRs targeting the release branch
|
|
30
|
+
# Get CI status on the release branch
|
|
31
|
+
|
|
32
|
+
# Open issues with sprint assignment
|
|
33
|
+
gh issue list --repo <owner/repo> --state open --json number,title,labels,state,createdAt,updatedAt
|
|
34
|
+
|
|
35
|
+
# Closed issues (completed this sprint)
|
|
36
|
+
gh issue list --repo <owner/repo> --state closed --json number,title,labels,closedAt
|
|
37
|
+
|
|
38
|
+
# PRs targeting the release branch
|
|
39
|
+
gh pr list --repo <owner/repo> --base release/<milestone-slug> --json number,title,state,mergedAt,labels
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### Step 2: Categorize Stories
|
|
43
|
+
|
|
44
|
+
Group all sprint stories into:
|
|
45
|
+
|
|
46
|
+
- **Done** — Issue closed, PR merged to release branch
|
|
47
|
+
- **In Progress** — PR open or issue actively being worked
|
|
48
|
+
- **Ready** — Not started but unblocked
|
|
49
|
+
- **Blocked** — Has `blocked` label or unresolved dependency
|
|
50
|
+
- **Needs Context** — Has `needs-context` label
|
|
51
|
+
|
|
52
|
+
### Step 3: Generate Report
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
## Sprint <N> Status — <date>
|
|
56
|
+
|
|
57
|
+
**Progress:** <done>/<total> stories | <done_points>/<total_points> points (<percentage>%)
|
|
58
|
+
**Days Remaining:** <N> of <total> days
|
|
59
|
+
|
|
60
|
+
### Burndown
|
|
61
|
+
<done_points> / <total_points> points completed
|
|
62
|
+
[████████░░░░░░░░] 50%
|
|
63
|
+
|
|
64
|
+
### Completed
|
|
65
|
+
| # | Title | Executor | Points | Closed |
|
|
66
|
+
|---|-------|----------|--------|--------|
|
|
67
|
+
| 12 | User auth endpoint | claude | 5 | 2h ago |
|
|
68
|
+
...
|
|
69
|
+
|
|
70
|
+
### In Progress
|
|
71
|
+
| # | Title | Executor | Points | Status |
|
|
72
|
+
|---|-------|----------|--------|--------|
|
|
73
|
+
| 14 | API key provisioning | human | 2 | PR open |
|
|
74
|
+
...
|
|
75
|
+
|
|
76
|
+
### Ready (Not Started)
|
|
77
|
+
| # | Title | Executor | Points | Priority |
|
|
78
|
+
|---|-------|----------|--------|----------|
|
|
79
|
+
| 18 | Rate limiting | claude | 3 | P2 |
|
|
80
|
+
...
|
|
81
|
+
|
|
82
|
+
### Blocked / Needs Attention
|
|
83
|
+
| # | Title | Blocker | Action Needed |
|
|
84
|
+
|---|-------|---------|---------------|
|
|
85
|
+
| 16 | OAuth integration | Waiting on #15 | Complete #15 first |
|
|
86
|
+
...
|
|
87
|
+
|
|
88
|
+
### Executor Summary
|
|
89
|
+
- Claude: <done>/<total> stories (<points> pts done)
|
|
90
|
+
- Human: <done>/<total> stories (<points> pts done)
|
|
91
|
+
- Cowork: <done>/<total> stories (<points> pts done)
|
|
92
|
+
|
|
93
|
+
### Recommendations
|
|
94
|
+
<Actionable suggestions: unblock items, re-prioritize, adjust scope if behind>
|
|
95
|
+
```
|