mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +00:00
Skills refinement: improve formatting, phase structure, and trigger descriptions across 9 skills
- balance-check: rewrote as explicit phases with domain routing table; expanded trigger hints - scope-check: restructured into numbered phases for clarity - adopt, review-all-gdds, help, project-stage-detect: add argument mode headers or trigger hints - gate-check, sprint-status, story-readiness: minor wording and structure improvements Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Donchitos
@@ -1,73 +1,126 @@
|
||||
---
|
||||
name: scope-check
|
||||
description: "Analyze a feature or sprint for scope creep by comparing current scope against the original plan. Flags additions, quantifies bloat, and recommends cuts."
|
||||
description: "Analyze a feature or sprint for scope creep by comparing current scope against the original plan. Flags additions, quantifies bloat, and recommends cuts. Use when user says 'any scope creep', 'scope review', 'are we staying in scope'."
|
||||
argument-hint: "[feature-name or sprint-N]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep
|
||||
context: |
|
||||
!git diff --stat HEAD~20 2>/dev/null
|
||||
allowed-tools: Read, Glob, Grep, Bash
|
||||
context: fork
|
||||
---
|
||||
When this skill is invoked:
|
||||
|
||||
1. **Read the original plan** — Find the relevant document:
|
||||
- If a feature name: read the design doc from `design/gdd/`
|
||||
- If a sprint number: read the sprint plan from `production/sprints/`
|
||||
- If a milestone: read the milestone definition from `production/milestones/`
|
||||
# Scope Check
|
||||
|
||||
2. **Read the current state** — Check what has actually been implemented or is in progress:
|
||||
- Scan the codebase for files related to the feature/sprint
|
||||
- Read git log for commits related to this work
|
||||
- Check for TODO comments that indicate unfinished scope additions
|
||||
Compares original planned scope against current state to detect, quantify, and triage
|
||||
scope creep. Read-only — never edits files without approval.
|
||||
|
||||
3. **Compare original vs current scope**:
|
||||
**Argument:** `$ARGUMENTS[0]` — feature name, sprint number, or milestone name.
|
||||
|
||||
```markdown
|
||||
## Scope Check: [Feature/Sprint Name]
|
||||
Generated: [Date]
|
||||
---
|
||||
|
||||
### Original Scope
|
||||
[List of items from the original plan]
|
||||
## Phase 1: Find the Original Plan
|
||||
|
||||
### Current Scope
|
||||
[List of items currently implemented or in progress]
|
||||
Locate the baseline scope document for the given argument:
|
||||
|
||||
### Scope Additions (not in original plan)
|
||||
| Addition | Who Added | When | Justified? | Effort |
|
||||
|----------|-----------|------|------------|--------|
|
||||
| [item] | [commit/person] | [date] | [Yes/No/Unclear] | [S/M/L] |
|
||||
- **Feature name** → read `design/gdd/[feature].md` or matching file in `design/`
|
||||
- **Sprint number** (e.g., `sprint-3`) → read `production/sprints/sprint-03.md` or similar
|
||||
- **Milestone** → read `production/milestones/[name].md`
|
||||
|
||||
### Scope Removals (in original but dropped)
|
||||
| Removed Item | Reason | Impact |
|
||||
|-------------|--------|--------|
|
||||
| [item] | [why removed] | [what's affected] |
|
||||
If the document is not found, report the missing file and stop. Do not proceed without
|
||||
a baseline to compare against.
|
||||
|
||||
### Bloat Score
|
||||
- Original items: [N]
|
||||
- Current items: [N]
|
||||
- Items added: [N] (+[X]%)
|
||||
- Items removed: [N]
|
||||
- Net scope change: [+/-N] ([X]%)
|
||||
---
|
||||
|
||||
### Risk Assessment
|
||||
- **Schedule Risk**: [Low/Medium/High] — [explanation]
|
||||
- **Quality Risk**: [Low/Medium/High] — [explanation]
|
||||
- **Integration Risk**: [Low/Medium/High] — [explanation]
|
||||
## Phase 2: Read the Current State
|
||||
|
||||
### Recommendations
|
||||
1. **Cut**: [Items that should be removed to stay on schedule]
|
||||
2. **Defer**: [Items that can move to a future sprint/version]
|
||||
3. **Keep**: [Additions that are genuinely necessary]
|
||||
4. **Flag**: [Items that need a decision from producer/creative-director]
|
||||
```
|
||||
Check what has actually been implemented or is in progress:
|
||||
|
||||
4. **Output the scope check** with a clear verdict:
|
||||
- **On Track**: Scope within 10% of original
|
||||
- **Minor Creep**: 10-25% scope increase — manageable with adjustments
|
||||
- **Significant Creep**: 25-50% scope increase — need to cut or extend timeline
|
||||
- **Out of Control**: >50% scope increase — stop and re-plan
|
||||
- Scan the codebase for files related to the feature/sprint
|
||||
- Read git log for commits related to this work (`git log --oneline --since=[start-date]`)
|
||||
- Check for TODO/FIXME comments that indicate unfinished scope additions
|
||||
- Check active sprint plan if the feature is mid-sprint
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Compare Original vs Current Scope
|
||||
|
||||
Produce the comparison report:
|
||||
|
||||
```markdown
|
||||
## Scope Check: [Feature/Sprint Name]
|
||||
Generated: [Date]
|
||||
|
||||
### Original Scope
|
||||
[List of items from the original plan]
|
||||
|
||||
### Current Scope
|
||||
[List of items currently implemented or in progress]
|
||||
|
||||
### Scope Additions (not in original plan)
|
||||
| Addition | Source | When | Justified? | Effort |
|
||||
|----------|--------|------|------------|--------|
|
||||
| [item] | [commit/person] | [date] | [Yes/No/Unclear] | [S/M/L] |
|
||||
|
||||
### Scope Removals (in original but dropped)
|
||||
| Removed Item | Reason | Impact |
|
||||
|-------------|--------|--------|
|
||||
| [item] | [why removed] | [what's affected] |
|
||||
|
||||
### Bloat Score
|
||||
- Original items: [N]
|
||||
- Current items: [N]
|
||||
- Items added: [N] (+[X]%)
|
||||
- Items removed: [N]
|
||||
- Net scope change: [+/-N] ([X]%)
|
||||
|
||||
### Risk Assessment
|
||||
- **Schedule Risk**: [Low/Medium/High] — [explanation]
|
||||
- **Quality Risk**: [Low/Medium/High] — [explanation]
|
||||
- **Integration Risk**: [Low/Medium/High] — [explanation]
|
||||
|
||||
### Recommendations
|
||||
1. **Cut**: [Items that should be removed to stay on schedule]
|
||||
2. **Defer**: [Items that can move to a future sprint/version]
|
||||
3. **Keep**: [Additions that are genuinely necessary]
|
||||
4. **Flag**: [Items that need a decision from producer/creative-director]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Verdict
|
||||
|
||||
Assign a canonical verdict based on net scope change:
|
||||
|
||||
| Net Change | Verdict | Meaning |
|
||||
|-----------|---------|---------|
|
||||
| ≤10% | **PASS** | On Track — within acceptable variance |
|
||||
| 10–25% | **CONCERNS** | Minor Creep — manageable with targeted cuts |
|
||||
| 25–50% | **FAIL** | Significant Creep — must cut or formally extend timeline |
|
||||
| >50% | **FAIL** | Out of Control — stop, re-plan, escalate to producer |
|
||||
|
||||
Output the verdict prominently:
|
||||
|
||||
```
|
||||
**Scope Verdict: [PASS / CONCERNS / FAIL]**
|
||||
Net change: [+X%] — [On Track / Minor Creep / Significant Creep / Out of Control]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Next Steps
|
||||
|
||||
After presenting the report, offer concrete follow-up:
|
||||
|
||||
- **PASS** → no action required. Suggest re-running before next milestone.
|
||||
- **CONCERNS** → offer to identify the 2–3 additions with best cut ratio. Reference `/sprint-plan update` to formally re-scope.
|
||||
- **FAIL** → recommend escalating to producer. Reference `/sprint-plan update` for re-planning or `/estimate` to re-baseline timeline.
|
||||
|
||||
Always end with:
|
||||
> "Run `/scope-check [name]` again after cuts are made to verify the verdict improves."
|
||||
|
||||
---
|
||||
|
||||
### Rules
|
||||
|
||||
- Scope creep is additions without corresponding cuts or timeline extensions
|
||||
- Not all additions are bad — some are discovered requirements. But they must be acknowledged and accounted for.
|
||||
- Not all additions are bad — some are discovered requirements. But they must be acknowledged and accounted for
|
||||
- When recommending cuts, prioritize preserving the core player experience over nice-to-haves
|
||||
- Always quantify scope changes — "it feels bigger" is not actionable, "+35% items" is
|
||||
|
||||
Reference in New Issue
Block a user