Skip to content
Back to skills

Studio Producer

ASecurity

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.

  • 21 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 22, 2026
ai-agentsgit

Works with

  • cli

Security analysis

A100/100

Scanned September 28, 2026

npx -y skills add monoes/monomind --skill studio-producer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Studio Producer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Studio Producer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/monoes-studio-producer/badge)](https://www.skillsdirectory.com/skills/monoes-studio-producer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: studio-producer
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."
tags: ["leadership","operations","game-dev","planning"]
tools: []
license: Apache-2.0
source: https://github.com/monoes/monomind
---
# 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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…