gstack-sprint

Solid

3-Phase Sprint workflow — design → execute → review with user interaction at decision points

AI & Automation 22 stars 1 forks Updated 1 months ago MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
45
Recency 20%
75
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

<Purpose> gstack-sprint wraps the 3-Phase Sprint workflow (design→execute→review) as a structured skill to guarantee deterministic execution. Without this skill, the 3-Phase workflow exists only as prompt instructions in boss.md and may be forgotten during long sessions. This skill is the single entry point for end-to-end feature implementation — it coordinates design, execution, and review with user confirmation at each phase boundary. </Purpose> <Use_When> - End-to-end feature implementation ("build this feature", "design it and implement it") - Build or Mid-sized intent type with implementation phase included - User says "sprint", "end-to-end", "e2e implementation" </Use_When> <Do_Not_Use_When> - Pure design/planning/idea review without implementation → use /office-hours or /plan-ceo-review directly - Architecture intent type (design only, no build) - "just design it", "just plan it", "review my idea" — these route to /office-hours or /plan-ceo-review - Single-purpose requests: code review → /review, QA → /qa, deploy → /ship - Trivial fixes, research, documentation </Do_Not_Use_When> <Why_This_Exists> End-to-end feature work fails silently in three predictable ways: 1. Implementation starts before design is aligned — wrong thing built 2. Execution proceeds without structured iteration — partial implementations declared done 3. Review skips comparison against the design doc — drift goes unnoticed gstack-sprint enforces the three-phase contract: user-confirmed design → a...

Details

Author
sehoon787
Repository
sehoon787/my-codex
Created
5 months ago
Last Updated
1 months ago
Language
Shell
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

gstack-sprint

3-Phase Sprint workflow — design → execute → review with user interaction at decision points

14 Updated 1 months ago
sehoon787
Testing & QA Solid

sprint-testing

Orchestrates in-sprint manual QA per ticket across Stages 1 (Planning), 2 (Execution) and 3 (Reporting). Use for user-story testing, bug retesting, and batch-sprint QA loops. Creates the PBI folder, drives session-start, runs the triage + veto + risk-score decision tree on bugs, produces the ATP + ATR + TC artifacts in the TMS, executes smoke and trifuerza (UI/API/DB) exploration, and files the final QA comment + bug reports. Triggers on: test this ticket, QA this user story, retest this bug, verify bug fix, run exploratory testing, smoke test a feature, process the sprint, next ticket in sprint, generate the SPRINT-N-TESTING framework, resume sprint testing, continue-from a ticket. Do NOT use for Stage 4 TMS documentation + ROI (test-documentation), Stage 5 automation coding (test-automation), Stage 6 regression suite execution (regression-testing), or onboarding a new repo (project-discovery).

21 Updated 6 days ago
upex-galaxy
AI & Automation Listed

sprint-execution

Use to orchestrate the five-dispatch sprint loop end-to-end — Architect → QA-Red → Developer → QA-Verify → Reporter — across one ClearGate sprint. Activates from sprint kickoff (preflight + cut sprint branch + state init) through per-story execution (worktree → dev → QA → flashcard gate → merge) into walkthrough and Gate-4 close. Triggers: SessionStart banner mentioning an active sprint; explicit user phrases "start the sprint", "run the sprint", "execute the sprint", "begin sprint execution", "kick off SPRINT-NN", "run STORY-NNN-NN"; CLI directives ending with `→ Load skill: sprint-execution`. The skill does not draft work items, run triage, or manage planning — those stay in always-on CLAUDE.md surface.

3 Updated 1 weeks ago
sandrinio