القائمة
Create, update, or summarize a sprint plan from current milestones, prior velocity, ready work, risks, and available capacity, with an optional feasibility review.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | studio-sprint-plan |
| description | Create, update, or summarize a sprint plan from current milestones, prior velocity, ready work, risks, and available capacity, with an optional feasibility review. |
| category | studio |
| source | chronos-adapted |
| source_path | .claude/skills/sprint-plan/SKILL.md |
Use this skill to generate a new sprint plan, update an existing one, or summarize sprint status.
Supported modes:
newupdatestatusIf no mode is supplied, infer the simplest sensible default from context and state the choice.
Read the minimum planning evidence needed:
Build a short planning picture of:
newGenerate a sprint plan with these sections:
Use estimates, dependencies, and acceptance criteria for each task. Prefer a compact table when the content fits.
updateRead the existing sprint plan and current status, then:
statusGenerate a short sprint status report containing:
If the repository already uses a machine-readable sprint tracker, update or propose updating it after the markdown plan is ready.
If no such file exists, do not invent one unless the user explicitly asks. You may still suggest a simple YAML or JSON tracker as an optional improvement.
Before asking to write the final sprint plan, challenge the plan for realism.
Optionally spawn a Task-based production or planning reviewer with:
Use the review to detect:
If the review returns concerns, revise the plan before asking for final write approval.
Check whether the sprint has explicit QA expectations.
If a QA plan, test checklist, or acceptance-test artifact already exists, reference it.
If none exists, call it out explicitly:
Use AskUserQuestion to let the user choose whether to create the QA plan now or knowingly continue without it.
Present the draft first.
Then ask for approval before writing or updating files. If the user declines, keep the generated plan in the conversation and mark the workflow as blocked on approval.
If the user approves, write the sprint plan to the repository's sprint-planning location or the most obvious equivalent already present in the project.
# Sprint [N] — [Start] to [End]
## Sprint Goal
## Capacity
## Must Have
## Should Have
## Nice to Have
## Carryover
## Risks
## External Dependencies
## Definition of Done
After the sprint plan is written or approved, recommend the next most logical actions, such as:
Verdict: COMPLETE when the sprint plan or status report is produced and the next action is clear.
Lazy-load for LUX Unity bridge and MCP game-development operations: status, compile, tests, logs, launch, screenshots, hierarchy, dynamic code, record/replay, and one-loop MCP workflows.
Lazy-load only when this workflow is explicitly needed. Use for durable technical choices. Output a short ADR: Context, Decision, Alternatives, Consequences, Verification, Owner. Prefer existing LUX boundaries: gateway owns CLI/server, bridge owns Unity protocol, Skills owns passive workflows. Reject duplicate state, hidden fallback, and broad rewrites without evidence.
Lazy-load only when this workflow is explicitly needed. Use to review an existing design or implementation for boundary drift. Check SSoT, responsibility split, protocol consistency, atomicity, idempotency, and observable failures. Return ranked findings with file references, risk level, and the smallest corrective action.
Lazy-load only when this workflow is explicitly needed. Use when a change risks architectural drift. Enforce: .lux is SSoT; clear subsystem ownership; consistent schemas; atomic operations; idempotent retries; no silent fallback. Report violations and concrete repair steps.
Lazy-load only when this workflow is explicitly needed. Use for high-risk product, automation, or ethical decisions. Run: clarify intent; quantify evidence; check user/data/IP/fairness risks; define stop and rollback conditions; record approval. Verdicts: PASS, REVIEW, or REJECT.
Lazy-load only when this workflow is explicitly needed. Use to turn observed failures into actionable reports. Capture summary, environment, exact steps, expected result, actual result, logs, suspected subsystem, severity, reproducibility, and minimal next diagnostic. Do not invent fallback data.