@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 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
+ ```