AgentX Sprint Protocol

Use this skill when the user wants to turn a product or engineering goal into a controlled sprint delivery process. The user may arrive with a raw brain dump, or they may already have a Research.md, Plan.md, Spec.md, System-Design.md, Requirements.md, PRD, architecture packet, or prior chat summary. The protocol must handle both paths.

The goal is not to create busywork. The goal is to decide what should be built, whether it fits in one sprint, how to divide it if it does not, how to write executable stories, how to run multiple workers safely, when to run a dedicated verification pass, and how to preserve traceability through sprint artifacts and commits.

Core Invariants

1. Founder intent is the source of truth. The protocol starts by understanding what the founder wants shipped and why. Existing research or design docs must be reviewed for gaps, inconsistencies, missing decisions, and scope risk before sprint folders are created.
2. Plan before execution. Every phase starts with a task list. The lead keeps an explicit queue, dependency map, blocker list, and approval status.
3. One canonical memory surface. Sprint state lives in files under the sprint folder, not in chat memory. Long-running work must be resumable from artifacts alone.
4. Lead orchestrates, workers implement. The lead does not absorb the whole codebase. The lead reads sprint artifacts, high-level diffs, reports, and status. Codebase research, implementation, code review, and verification are delegated to teammates.
5. Feature-driven sprinting. A sprint must deliver one or more concrete features, fixes, or quality checkpoints. Sprints are ordered so each one creates usable foundation for the next.
6. Story count is earned, not fixed. Do not force a sprint into an artificial number of stories. Create as many stories as the feature requires, then challenge the set for over-splitting, missing work, dependency problems, and testability.
7. Every story declares required skills and tests. Each story must tell the worker which domain skills/tools to load and which feature-specific tests prove completion.
8. Execution concurrency is configurable. Before Phase 4 execution, ask the user how many stories to run at once: 1, 2, 3, or 4. Respect dependency and conflict risk even if the user chooses a higher number.
9. One sprint, one delivery commit. Workers normally do not create final commits per story. The lead verifies, reviews, stages intentionally, and creates one clean sprint commit unless the user asks for a different commit strategy.
10. Verification is an explicit QA mode. Every executed sprint produces progress.md, verification-checklist.md, and sprint-completion.md. verification-report.md and browser/video evidence are created when the user runs Phase 5 verification or when a checkpoint sprint explicitly performs QA work.