studio-producer
Use when an org role acts as studio producer and must own scope, schedule and capacity for a creative or game production from pitch to shippable build. Covers trading off scope vs schedule vs capacity, look-ahead risk, just-in-time cuts and milestone tracking. For tooling and vendor ops see studio-operations.
- License 许可
- Apache-2.0
- 所属仓库
- monoes/monomind
- 最近更新
- 2026-11-10
- Stars
- ★ 23
- Forks
- 2
01 前言 Front Matter
- name
- studio-producer
- tags
- [ "leadership", "operations", "game-dev", "planning" ]
- tools
- []
- source
- https://github.com/monoes/monomind
- license
- Apache-2.0
- description
- Use when an org role acts as studio producer and must own scope, schedule and capacity for a creative or game production from pitch to shippable build. Covers trading off scope vs schedule vs capacity, look-ahead risk, just-in-time cuts and milestone tracking. For tooling and vendor ops see studio-operations.
03 SKILL.md 正文
Studio Producer — Best Practices
Focus
Owns scope, schedule, and capacity for a creative/game production — the person who keeps a project moving from pitch to shippable build without burning the team out.
Best practices
- Track three levers, not one: scope, schedule, and capacity. When one slips, decide explicitly which of the other two absorbs it — never let all three silently degrade.
- Look 2-3 sprints ahead for risk, not just at the current sprint. Milestones slip because of problems visible weeks earlier that nobody named out loud.
- Make cut decisions just-in-time, not up front. Lock scope only as late as quality of information allows; protect flexibility for as long as it's cheap.
- Keep a single visible source of truth for milestones and owners (board, doc) — cross-discipline teams (design/eng/art/audio) drift apart without one.
- Timebox risk-heavy unknowns as spikes with a hard decision date, so ambiguity doesn't quietly eat the whole schedule.
- Protect crunch as a last resort, not a plan — a schedule that only works if everyone works overtime is not a schedule.
- Close every milestone with a retro that changes something in the next milestone's plan, not just a status report.
Common pitfalls
- Treating the schedule as fixed and scope as the release valve, when scope cuts are usually cheaper and less risky than schedule slips.
- Reporting "on track" from vibes instead of from a burndown against actual remaining scope.
- Letting a discipline (art, audio, design) work in isolation until integration, discovering conflicts only at milestone review.
- Overloading the schedule with optional polish before core loop / critical path features are proven.
Tools & techniques
- Milestone/sprint boards (Jira, Trello, ClickUp, Shotgrid) with owner + due date on every card, not just epics.
- Risk register reviewed weekly: top 3 risks, likelihood, and the specific mitigation in progress.
- Vertical slice / playable-first milestones to validate the core loop before scaling content.
- Explicit descope list maintained alongside the roadmap — the pre-agreed cuts if time runs short.
04 同仓库更多 Skills
zk-steward
Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.
writing-plans
Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.
write-spec
Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.
write-query
Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.
workflow-automation
Org role guidance for workflow automation: build and maintain CI/CD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.
workflow-architect
Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.