跳到正文
cccskills
免费在 GitHub 公开

hybrid-prototype

Fast-lane prototype skill for the hybrid workflow. Builds a playable prototype in 2-3 days with minimal process overhead. Designed for discovery phase.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md5.0 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Overview

This skill implements the Discovery Phase fast lane as described in docs/framework/hybrid-workflow.md. It is intentionally lightweight: no formal GDD, no architecture, no epic breakdown. Just build it, play it, decide.

Time budget: 1-3 days. Agents involved: creative-director, game-designer, prototyper, godot-specialist (or engine equivalent).


Phase 1: Concept & Question (5 minutes)

Read the concept description from the argument. State the one core question this prototype must answer. If the concept is vague, ask the user to clarify before proceeding.

Examples of good questions:

  • "Does the combat feel responsive with 200ms input lag?"
  • "Is resource scarcity actually fun, or just frustrating?"
  • "Does the movement mechanic support the intended platforming challenges?"

Bad question: "Is this game fun?" (Too broad. Narrow it down.)

Ask the user: "The core question for this prototype is: [question]. Proceed?"


Phase 2: Plan (15 minutes)

Define the minimum viable prototype in 3-5 bullet points:

  • What is the absolute minimum code to answer the question?
  • What can be hardcoded / placeholder / skipped?
  • What is the success criteria? (e.g., "Player can complete 3 jumps in a row without dying")

Present the plan to the user and ask for confirmation.


Phase 3: Build (1-2 days)

Ask: "May I create the prototype directory at prototypes/[concept-name]/ and begin implementation?"

If yes, create the directory. Every file must begin with:

// PROTOTYPE - NOT FOR PRODUCTION
// Question: [Core question being tested]
// Date: [Current date]

Rules for prototype code:

  • Hardcode values freely
  • Use placeholder assets (colored squares, simple shapes)
  • Skip error handling
  • Use the simplest approach that works
  • Copy code rather than importing from production
  • NEVER import from src/ — prototypes are isolated

Run the prototype as you build. Test continuously. Fix blockers, but don't polish.


Phase 4: Playtest (2-4 hours)

Play the prototype yourself. Then ask the user to play it. Collect observations:

  • What worked?
  • What felt bad?
  • Did it answer the core question?
  • Any surprising discoveries?

Document findings informally — a bulleted list is fine.


Phase 5: Decide (30 minutes)

Collaborate with creative-director and game-designer (via Task or conversation) to make a decision:

VerdictMeaningNext Step
ITERATECore is promising, but needs adjustmentRun /hybrid-prototype [revised-concept]
PIVOTThe concept doesn't work, but a related one mightRun /concept-brainstorm or /hybrid-prototype [new-direction]
PRODUCTIONIZEIt's fun and proven — move to productionBegin GDD in /design-system, architecture in /create-architecture
KILLIt's not fun and no clear fixStop. The prototype report is the deliverable.

Update prototypes/[concept-name]/DECISION.md with:

# Prototype Decision: [Concept Name]

## Question
[Core question]

## Result
[What happened]

## Verdict
[ITERATE / PIVOT / PRODUCTIONIZE / KILL]

## Reasoning
[Why]

## Next Steps
[What to do next]

Ask: "May I write the decision to prototypes/[concept-name]/DECISION.md?"


Phase 6: Done

Output a summary to the user: the core question, the verdict, and the next step.

If PRODUCTIONIZE: remind them to switch to the Production phase workflow (/design-system, /create-architecture, etc.)

If ITERATE / PIVOT / KILL: no further action needed.


Constraints

  • Prototype code must NEVER import from production source files
  • Production code must NEVER import from prototype directories
  • If productionizing, rewrite from scratch — do not refactor prototype code
  • Timebox strictly: if it's not working after 3 days, kill or pivot
  • Keep the question narrow — one prototype, one question
  • Workflow isolation: This skill explicitly bypasses production/review-mode.txt. Any stale review-mode state from a previous full OCGS session is ignored — the hybrid fast lane always runs without formal gates.

Differences from Full /prototype Skill

Aspect/prototype (Full OCGS)/hybrid-prototype (Fast Lane)
Review mode gatesSolo / Lean / FullNone (always fast)
Creative Director reviewFormal gate spawnInformal chat/Task
Report formatFormal REPORT.mdLightweight DECISION.md
Agents involvedAll tiers4 core roles only
Time to verdict1-3 days + review overhead1-3 days total
Next step on PROCEEDFormal GDD + ADRStart GDD when ready

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

adopt

免费

Brownfield onboarding — audits existing project artifacts for template format compliance (not just existence), classifies gaps by impact, and produces a numbered migration plan. Run this when joining an in-progress project or upgrading from an older template version. Distinct from /project-stage-detect (which checks what exists) — this checks whether what exists will actually work with the template's skills.

中文简介正在准备中。当前显示原文说明。

striderZA/OpenCodeGameStudios992026年10月7日 更新

Creates an Architecture Decision Record (ADR) documenting a significant technical decision, its context, alternatives considered, and consequences. Every major technical choice should have an ADR.

中文简介正在准备中。当前显示原文说明。

striderZA/OpenCodeGameStudios992026年10月7日 更新

Validates completeness and consistency of the project architecture against all GDDs. Builds a traceability matrix mapping every GDD technical requirement to ADRs, identifies coverage gaps, detects cross-ADR conflicts, verifies engine compatibility consistency across all decisions, and produces a PASS/CONCERNS/FAIL verdict. The architecture equivalent of /design-review.

中文简介正在准备中。当前显示原文说明。

striderZA/OpenCodeGameStudios992026年10月7日 更新

art-bible

免费

Guided, section-by-section Art Bible authoring. Creates the visual identity specification that gates all asset production. Run after /concept-brainstorm is approved and before /map-systems or any GDD authoring begins.

中文简介正在准备中。当前显示原文说明。

striderZA/OpenCodeGameStudios992026年10月7日 更新

Generates placeholder .aseprite files from asset specs using the Aseprite MCP. Reads asset specs and art bible, creates sprites with correct dimensions/palette/layers, exports PNGs. Run after /asset-spec has produced specs and /art-bible exists.

中文简介正在准备中。当前显示原文说明。

striderZA/OpenCodeGameStudios992026年10月7日 更新

Audits game assets for compliance with naming conventions, file size budgets, format standards, and pipeline requirements. Identifies orphaned assets, missing references, and standard violations.

中文简介正在准备中。当前显示原文说明。

striderZA/OpenCodeGameStudios992026年10月7日 更新

查看 striderZA 的全部技能

报告此技能的问题