unity-costing

name	unity-costing
description	Create tshirt costing, detail costing, highlevel costing, feature costing, task breakdown, estimate, effort sizing, or a detailed Unity delivery plan before implementation. Use for small-to-XL Unity work when a costed task tree is the deliverable; investigate the codebase first and fire subagents when scope touches multiple systems or evidence is needed.
metadata	{"author":"kuozg","version":"4.0"}

unity-costing

Produce a self-contained HTML costing report for a Unity feature/refactor. Answer "what will this cost?" — not "please implement this." Supports: tshirt costing, detail costing, and highlevel costing.

Pre-requisite: Read references/output-template.html. Replace all [PLACEHOLDER] tokens exactly. Use predefined CSS badge classes. Maintain Vercel dark theme.

Workflow

1. Clarify Requirements

Understand clearly the requirement. Do not assume. Ask user if: target platform, boundaries, quality bar, unknown SDKs, or estimate unit are unclear.

2. Investigate Context

Understand the code base and document context.

• Spawn explore or librarian subagents to gather evidence on:
  • Entry points, public APIs, module boundaries.
  • Cross-system dependencies (calls, shared state, events).
  • Existing patterns, test coverage, and performance-critical paths. Record file:line evidence. Collect all results before scoping.

3. Analyze Scope & Sizing

• Size Scale: XS (1-2h, 1 file), S (2-4h, 1-3 files), M (4-16h, 3-10 files), L (16-40h, 10-25 files), XL (40+h, 25+ files).
• Modifiers: Bump +1 size if crossing assemblies, requiring data migration, or touching Editor+Runtime.
• Confidence: High (knowns), Med (some unknowns), Low (ambiguous territory).
• BLOCKING: If scope is ambiguous or confidence is Low, print a "🔍 SCOPE DETECTION" summary and stop for user confirmation before planning.

4. Architect & Technical Approach

• Spawn a subagent to define the architecture and technical approach (Current vs Proposed).
• Ensure numbered steps with <code> references are formulated.

5. Create Epics

• Group work into logical Epics: Foundation, Runtime Logic, UI/Scene, Data/Persistence, Assets, Tests/Release.

6. Create Tasks

• Granularity: 1-4h per task. Split >4h, merge <30m. One clear deliverable per task.
• Format: Subject starts with imperative verb. Description must have {What}\n{Why}\n{How}\n→ skill:{name}.
• Dependencies: Minimize chains. Use blockedBy=[ID] only for true data dependencies.
• Tasks Data: T-N ID, epic, title, 2-5 action steps, type, cost, affected files.
• Types/Costs: Logic/UI/Data/API/Asset/Test/Config. S/M/L/XL/Spike. Use predefined template badges.

7. Review Costing & Risks

• Risk Levels: Low (Accept), Medium (Monitor), High (Mitigate), Critical (Block/Spike).
• Categories: Technical, Integration, Performance, Data Migration, UX.
• Mitigation: Use spikes, feature flags, or rollback plans for High/Critical risks.
• Detail risks with severity (badge-sev-high), impact, and mitigations. Ensure backward compatibility is analyzed.

8. Generate Plan

Create directory: mkdir -p Docs/Plans Generate Docs/Plans/{Name}.html using the template from references/output-template.html. Report to user: Output location, total effort range, confidence level, top 2-3 risks, critical path. BLOCKING: After generating the plan, print "❓ Next steps? 1. Create tasks 2. Adjust scope" and wait. Do not execute or auto-create tasks.