t1k:cocos:playable:estimate

Field	Value
Module	`playable`
Version	`0.15.0`
Effort	`medium`
Tools	—

Keywords: breakdown, cost, dev-days, effort, estimate, estimation, how long, module architecture, playable, quote, scope, system design, timeline, work package

How to invoke

/t1k:cocos:playable:estimate
<spec-file-or-brief> [--3d]

Cocos Playable — Dev-Effort Estimate

Turn a playable-ad spec into a reuse-grounded, risk-weighted, module-first effort estimate: a ready-to-build system design (module tree, communication flow, signal contracts, class reference, level-data schema) with each module estimated directly, plus a two-point Base / Worst-case total — one markdown report. Optimize for a base that matches an experienced estimator’s gut number, and for a design so complete that /t1k:cook can build straight off it with no separate planning pass.

Module-first, not WP-first. The internal effort taxonomy is still the WP catalog (work-packages.md) — but it is a sizing tool, not the output shape. The report is sliced by actual system-design module (the scripts/classes/signals a dev will write, per the system-design-template.md in the project’s docs/), so every estimate line traces to a class. Gameplay code → estimated per module; cross-cutting art/optimization/polish/QA → production packages. Reconcile: the module + production totals must equal the WP totals (same work, re-sliced).

Grill before you cost. This skill runs a mandatory clarification gate (step 2, <HARD-GATE-CLARIFY-FIRST>) that interrogates every material assumption via AskUserQuestion before any estimate is produced — see rules/workflow-gates.md for the universal HARD-GATE contract. Never emit an estimate that rests on unconfirmed assumptions.

Decision Tree

Intent	Path
”Estimate this playable spec” (2D or 3D)	Full workflow below
3D game (models/camera/optimization/env-polish)	Full workflow + `work-packages.md` §3D block, pass `--3d`
”Just the reuse discount — what’s already built?”	`reuse-sweep.md` only
”Why is X not billed?” / defaults question	`estimation-rules.md` § Default deliverables
”Re-price after a scope change”	Re-clarify any new unknowns (step 2), then re-run steps 4–8 on the changed WPs only
”Just give me a number, skip the questions”	Only on explicit “proceed on stated defaults” — record each default in the report; otherwise the gate stands

Workflow

Scout the spec. Read the brief/spec fully. List every feature, screen, transition, interaction, FX, and asset. Note engine (2D/3D), whether models arrive pre-rigged + pre-animated, and whether note/tile/level data is dynamic (runtime colors, JSON-driven). As you scout, keep a running list of every point where the spec is silent, ambiguous, or you’d otherwise fill a gap with a guess — that list feeds step 2.
Clarification gate — grill BEFORE costing. <HARD-GATE-CLARIFY-FIRST> Enumerate every material unknown (anything that moves the number) and batch it into AskUserQuestion (max 4 per call) until each is answered. Walk the grill checklist in clarification-gate.md: engine 2D/3D · exact gameplay mechanic + full element inventory · reference authority (A exact / B original-GOAT / C mixed) · level-data ingestibility/format · art & model readiness (rigged? animated? final?) · dynamic-color · orientation set · target ad networks + size budget · reference-build/asset access · in/out-of-scope boundary. Do NOT run the reuse sweep or emit any estimate until this passes. </HARD-GATE-CLARIFY-FIRST> Override: if the user explicitly says “proceed on stated defaults” (or equivalent), record each still-unanswered item with its documented default (the checklist’s Default column) in the report’s Scoping-assumptions table, then continue. A stated default under explicit override is legitimate; a silent assumption is a gate violation.
Reuse sweep (grounds every discount). Search the Knowledge MCP by capability keyword across the whole corpus — not one project — to find reusable framework code (game-flow, signals, params, CTA, audio, end-cards, juice/motion, pooling, timers, screen-adapt). Follow reuse-sweep.md. Fallback: skill catalog + code grep when MCP is unavailable. Tag each need ● inherited · ◐ framework-assisted · ○ custom.
Map to work packages (sizing pass). Slot every feature into WP0–WP9 (work-packages.md) to size the effort. Exclude studio default deliverables (do NOT bill): parameter dashboard, draw-call/batching, size-budget compliance, low-end perf profiling. Bill a param ONLY if it needs logic beyond gameplay or is a level-editor tool (e.g., JSON level generator). This pass produces the numbers; step 6 re-slices them into modules.
Apply the estimation rules (estimation-rules.md) — the studio heuristics: pre-rigged import ~10 min/model; lighting default-first, look-dev → env polish (~2h per distinct model, 4–10h band); dynamic-color surcharge; animated/skinned meshes cost more to optimize; VFX ~1h base each; pure gameplay carries no juice (juice authored once in the polish package); no double-counting.
Design the modules, then estimate each directly. <HARD-GATE-DESIGN-EMBEDDED> Produce the system design following the project’s docs/system-design-template.md (fall back to ../PlayableAdsTemplate/docs/system-design-template.md): the module tree under assets/scripts/[Name-Project]/ ([Name-Project] = placeholder, rename before build), a module-responsibility table, the communication flow (STARTUP / INPUT / LOOP / WIN / LOSE trace), the signal contracts table, a class summary, the level-data schema decoded from the real samples, and a class reference for the bespoke modules. Then re-slice the step-4 WP hours into (a) gameplay code modules (each row = a module + its classes, estimated directly) and (b) production packages (art / optimization / VFX / polish / QA / buffer — cross-cutting, not single classes). Study the worked example: ../PlayableAdsTemplate/docs/system-design-example.md. Do NOT emit an estimate whose lines are generic WPs instead of named modules. </HARD-GATE-DESIGN-EMBEDDED>
Set Base per module/package, then risk-weight the worst-case. Base = O = L — the lean, realistic plan number (no rosy floor below it). Worst-case P = Base + risk premium, applied ONLY to high-uncertainty items (bespoke gameplay module, camera framing, skinned-mesh optimization, feedback-juice authoring, dynamic-color polish → P ≈ Base×1.4–1.6). Inherited/mechanical items: P ≈ Base (near-flat). Add the iteration buffer = 0.1 × total implementation (all other items’ base); its worst = 0.1 × implementation-P.
Assemble + gut-check. Emit the report per report-template.md: project understanding + gameplay, scoping table, reuse-basis table, module architecture + communication flow + signal contracts + class summary + level-data schema + class reference (the embedded design), then the per-module + production-package estimate tables, Base/Worst totals (8h=dev-day, 5d=week), headline, risk hotspots. Reconcile: module + production totals MUST equal the step-4 WP totals — if they don’t, a slice is missing or double-counted. Gut-check: the base should land near an experienced estimator’s number for the genre; if it drifts well above, per-task optimistic values are inflated — the base is the lean figure, risk lives only in the worst-case.

Non-negotiables

Module-first output — the design ships with the estimate. The report embeds a build-ready system design (module tree, communication flow, signals, class reference, level-data schema per system-design-template.md) and estimates each module directly. The goal is that /t1k:cook runs off it with no separate planning pass. An estimate whose line items are generic WPs (WP0/WP4/…) instead of named modules is a regression — WPs are the internal sizing tool, modules are the output.
Scripts folder = assets/scripts/[Name-Project]/. The gameplay module tree lives under a project-named folder — [Name-Project] is a placeholder to rename before implementing (never ship the literal [Name-Project], and never use the template’s literal gameplay/ as the root). Matches the Cocos code-convention assets/scripts/{ProjectName}/.
Reconcile module + production totals to the WP totals. Re-slicing WP hours into modules must not change the number — same work, different cut. A mismatch means a missing or double-counted slice.
Reuse-first, evidence-grounded. Every discount cites the reusable code found in step 3. Never assume greenfield when a framework exists.
Base = O = L. One plan number; risk is on the downside only. Do not carry an optimistic floor below the base.
Default deliverables are never billed. Param dashboard, draw-call/batching, size-budget compliance, low-end profiling — always excluded; state so explicitly.
No juice in gameplay tasks. Gameplay WPs = mechanic/logic only; feedback juice is authored once in WP8.1; VFX assets in WP9. Never double-count.
Clarify before costing (HARD-GATE). Grill on every material assumption via AskUserQuestion before the reuse sweep or any output (step 2). Zero silent assumptions. The only way past an unanswered item is an explicit user “proceed on stated defaults”, which records the checklist’s documented default in the report — never a value you invented. If you catch yourself drafting an “Assumptions” list the user never confirmed, STOP and ask.

Gotchas

Design AT estimate time, not after. The whole point of this skill’s output is that the module architecture, signals, and class reference are settled while costing — so estimation confidence is per-class and the build needs no re-plan. If you find yourself emitting an estimate and deferring “the modules will be defined in planning,” STOP — that IS the planning, do it now (step 6). Ground the module tree in the real level-data samples + the reuse sweep, not in a generic genre template.
[Name-Project] is a placeholder — flag the rename. In the module tree, use assets/scripts/[Name-Project]/ and state once that it must be renamed to the actual project folder before implementing. Do not silently invent a final name, and do not copy the template’s literal gameplay/ as the root folder.
Pre-rigged models cut two ways: import/rig ≈ 0 (WP1 cheap) BUT skinned-mesh decimation must preserve rig + weights (WP2 more expensive). Apply both signs.
Dynamic-color games (runtime note/tile recolor) lengthen env/shading polish — the look must read across the whole palette, not one fixed set.
The level generator is the classic estimable-param trap: a JSON that just swaps values = default (0h); a JSON that spawns/positions/recolors notes at runtime = billable custom work (it’s a level tool). Placement-only ≈ 6h L; +runtime per-note color ≈ 8h L.
The standalone visual level editor is near-universal — never forget it. Most level-based playables ship a separate HTML tool to author the level JSON from scratch (grid/board canvas, entity placement, per-entity props, JSON export). This is its own bespoke package (WP10, ~8–16h base ○), distinct from runtime JSON ingestion (WP4.3) and from the param dashboard (WP6 default). The clarification gate (row 12) MUST confirm it; bill it by default unless the client explicitly wants no authoring tool. Omitting it silently under-bills a whole deliverable.
Scan EVERY provided level-data sample, not just the first — the entity vocabulary grows across levels. A later level’s JSON can introduce a whole new mechanic absent from level 1 (e.g. a pedestrian layer: PS/C/PE waypoints that a character walks, car-collision = lose). Before finalizing, diff all samples for new type codes / layers / id fields; each new entity type = a new bespoke gameplay sub-item, and any animated character (pedestrian, NPC) reintroduces the two-sided skinned-mesh penalty (cheap pre-rigged import BUT dearer skinned optimization + character shading) even when the rest of the art is rigid. Assuming the first sample shows the full vocabulary is the trap.
When the spec cites a reference (game / video / image / GIF), FIRST decide which source is authoritative — then reconcile against it. A reference is not one thing: (A) reference-exact — “do exactly like the ref clip, ignore the original game” → reconcile against the ref only (and confirm the clip shows the full loop incl. the lose case; clips are usually partial); (B) original-authoritative — “the original game is the source of truth (GOAT), the ref is just clearer visuals” → reconcile against the ORIGINAL’s full cast (a separate character/avatar the brief’s prose skipped lives here); (C) mixed → per-element source × scope table, nothing assumed. The brief’s prose always UNDER-lists whichever source is authoritative — it names the headline loop and forgets secondary actors, NPCs, hazard layers, meta-timers. Each confirmed-IN secondary element is its OWN §5 module row. See clarification-gate.md row 1 + the “Reference reconciliation” section (Step 0 = pick A/B/C). This is the reference-driven twin of the “scan every level-data sample” gotcha.
Env/shading polish scales per distinct model to shade (~2h each), not per scene. Count the models.
Don’t inflate the base to “tighten the spread.” Close the Base↔Worst gap by keeping the base lean and only widening P on genuinely risky tasks — never by raising the base.
MCP reuse sweep is keyword-across-corpus, not a single-project lookup — the index holds many codebases; search by capability and use whatever surfaces.
Never output on first pass with buried assumptions. The #1 failure mode is emitting a polished report whose “Assumptions” section quietly guessed the gameplay mechanic, the level-data format, or art readiness. Those are exactly the items that swing the number most — they belong in step 2’s AskUserQuestion, not in a fait-accompli report. A stated default is legitimate ONLY after an explicit “proceed on defaults” override.
Batch the grill, don’t drip it. Group unknowns into as few AskUserQuestion calls as possible (max 4 questions/call) so the user answers in one or two passes — don’t ask one question, cost a little, ask another. Resolve the assumption set, then cost once.

Security & scope: this skill estimates Cocos playable effort only; it does not implement. Full rules in estimation-rules.md.