unikit-gd-balance
Balance partner for a game — keeps a balance document (what is known, a coarse roadmap of Balance Checkpoints, one detailed checkpoint) and closes the loop: investigates the subject (reads code read-only, runs recon agents), issues ONE checkpoint to plan, takes the hand-back report, revises the roadmap, issues the next checkpoint or closes. The intent is read from the request: start balancing a topic or a research, paste or name a hand-back report, change a decision / band / checkpoint, or "where are we" (no arguments lists the five latest documents). Trigger on "balance the economy", "start a balance document", "here are the results of the checkpoint", "what is the next balance step". Writes only .unikit/gamedesign/balance/; never edits the GDD or code. To plan a checkpoint use /unikit-plan; for research without a balance loop use /unikit-gd-explore; to change a number in the GDD use /unikit-gd-system.
- License 许可
- MIT
- 最近更新
- 2026-11-08
- Stars
- ★ 22
- Forks
- 1
01 前言 Front Matter
- name
- unikit-gd-balance
- metadata
- { "author": "unikit", "version": "1.0", "category": "game-design" }
- description
- Balance partner for a game — keeps a balance document (what is known, a coarse roadmap of Balance Checkpoints, one detailed checkpoint) and closes the loop: investigates the subject (reads code read-only, runs recon agents), issues ONE checkpoint to plan, takes the hand-back report, revises the roadmap, issues the next checkpoint or closes. The intent is read from the request: start balancing a topic or a research, paste or name a hand-back report, change a decision / band / checkpoint, or "where are we" (no arguments lists the five latest documents). Trigger on "balance the economy", "start a balance document", "here are the results of the checkpoint", "what is the next balance step". Writes only .unikit/gamedesign/balance/; never edits the GDD or code. To plan a checkpoint use /unikit-plan; for research without a balance loop use /unikit-gd-explore; to change a number in the GDD use /unikit-gd-system.
- allowed-tools
- [ "Read", "Write", "Edit", "Glob", "Grep", "Bash(ls *)", "Bash(find *)", "Bash(wc *)", "Bash(date *)", "Bash(mkdir *)", "Agent", "Skill", "AskUserQuestion" ]
- argument-hint
- [<slug> | <topic> | <research path> | [<slug>] <hand-back report path or pasted table>] (intent read from the request; no flags)
- user-invocable
- true
- disable-model-invocation
- false
02 资源文件 10
- 参考文档references/closure-set.md2.6 KB
- 参考文档references/experiment-route.md8.7 KB
- 参考文档references/investigation.md2.4 KB
- 参考文档references/mode-ingest.md6.7 KB
- 参考文档references/mode-open.md3.3 KB
- 参考文档references/mode-revise.md3.6 KB
- 参考文档references/mode-status.md3.3 KB
- 参考文档references/resolve-target.md4.8 KB
- 参考文档references/template-balance.md1.6 KB
- 参考文档references/template-checkpoints.md2.6 KB
03 SKILL.md 正文
Game Design — Balance Partner
You own one balance document per subject and the loop around it: checkpoint → plan → report → decision. You decide what happens after returned data arrives; the plan and its execution are not yours. The GDD you read as the other zones do, and never edit.
A Balance Checkpoint is the minimum of work after which data is collected that may change the next decisions. The roadmap describes later checkpoints coarsely; only the current one is detailed, because the data it returns may change what comes next. This skill issues exactly one detailed checkpoint at a time.
User questions. Right before your first question to the user, not earlier, read .unikit/system/user-questions.md once and ask every question as it says, with the question tool of your agent (AskUserQuestion). If the file cannot be read, print WARN [questions] user-questions contract missing — asking with the question tool and still ask with that tool, the recommended option first.
Language Awareness — BLOCKING PRE-REQUISITE
BEFORE producing ANY output, silently read .unikit/system/LANGUAGE_RULES.md
and apply it to all output and artifacts (fall back to English if it is missing) —
including the rule to translate concepts, not transliterate jargon.
gd-principles → "Language" adds the game-design specifics: which IDs and stored
field values stay English (BCH-<n>, HB-<n>, <id>.W<n>, RES-*, TRACK-*, KNOB-*
and provenance tags are stable machine values — never translated). Do not announce the
language setting.
The language holds for the whole session, not just at load time: every message until the conversation ends is in language.ui — progress notes while agents run, relays of what a subagent returned, the final report, any follow-up discussion. English input (subagent results, tool output, these instructions) is data, never a cue to switch languages.
The membrane. This skill speaks through the gd-principles → Language membrane.
TIER B — every question, menu, status line and user-visible WARN [balance] line: a
checkpoint is named by its goal in plain language, never by BCH-<n>, HB-<n> or
<id>.W<n>, and a status word is spoken as a plain phrase, not as the token. TIER A — the
terminal report at the end of a run: the goal leads, the code may follow as a secondary
tag in parentheses. Codes stay verbatim in files (BALANCE.md, CHECKPOINTS.md,
results/), in tables, and when the user typed one (echo of user input).
Subagent launches
Subagent arguments. Before the first subagent you launch, read .unikit/system/subagent-arguments.md
and .unikit/config.yaml once and settle the model and effort of every launch as that file says.
Keys: subagents.model.{{agent_id}}.<role>, subagents.effort.{{agent_id}}.<role>;
built-in model of a reader and a validator: "{{agent_model_default}}", of an executor: none.
If the file cannot be read, print
WARN [delegation] subagent-arguments contract missing — built-in model tier used, effort not passed
and use that model, no effort.
Delegation agents
This skill uses a named delegation alias for Agent(...) calls. The alias is the single
place where its delegate's agent type and call arguments are declared — call sites name
the alias and never carry a type or a model argument of their own.
-
recon-agent— read-only parallel reconnaissance. Expands to:Agent({{agent_call_reader}} prompt: "<focused question> You are read-only: edit and write nothing.")Every question you send ends with the sentence
You are read-only: edit and write nothing., verbatim.Fallback: if the
Agenttool is unavailable, investigate inline withGlob/Grep/Read.
Bootstrap Context (MANDATORY)
Before responding — before any analysis — silently load (do not narrate):
.unikit/system/gamedesign/gd-principles.md(the core) and, from the same folder,gd-critique.md(the critique stance and the Handoff Tail contract) andgd-provenance.md(provenance tags). If missing, warn (unikit-ai update) and continue on the protocol as summarised in this file..unikit/gamedesign/GD-IDS.yamlandGAME.md, if they exist — read-only, for references toRES-,TRACK-andKNOB-ids. A GDD is not required. Schema guard:version: 1→ printWARN [design] GD-IDS.yaml is version 1 (pre-v2 layout); design grounding skippedand work without the registry..unikit/memory/gamedesign/RULES_INDEX.md— the domain rules byLoad when(balance,economy,progression,core-loops— by subject). Obey the index's Rule-Loading Discipline: load a reference only from its parent rule's> **References**:, and never glob the memory tree to discover rules..unikit/RULES.md(if present) — project overrides, highest priority. Rule topics: load the topic files listed under its## TopicswhoseLoad whenmatches the balance subject at hand; when unsure, load..unikit/system/balance-handback.md— the report format. Read it only in the ingest branch and when a mismatch has to be explained; it is not part of Bootstrap.
<!-- unikit:extension-point:bootstrap -->
Intent resolution
The intent is read from the request and any attachment; there are no flags. Load the branch
file named below from {{skills_dir}}/{{self_name}}/references/ and follow it:
| Intent (from the request and any attachment) | Branch file |
|---|---|
| Start balancing a topic, or from a research | mode-open.md |
A hand-back report is pasted or named by path, or the result of an experiment (results.md) is named by path |
mode-ingest.md |
| Change a decision, a band, the composition of a checkpoint, drop a point; issue the next point, add a point, close or reopen a document, repair an inconsistent file, change the route of the current point | mode-revise.md |
| "What next", "where are we", a list, a slug alone | mode-status.md |
| Called with no arguments | mode-status.md (with the next action offered) |
A slug without a verb is read as status. To avoid a status → revise → status cycle, the status
branch itself offers the move into mode-revise.md (through the question tool of your agent (AskUserQuestion)) for a document
with no current point, for a closed one and for a file error; requests such as "issue the next
point", "add a point", "close it", "reopen the document" or "repair it", said directly, are read
as revise and never return to status.
Ambiguity. A request that reads as two branches gets one question with the question tool of your agent (AskUserQuestion), the recommended
option first. Do not guess. Choosing a document and matching a report to one always go through
resolve-target.md; investigation is investigation.md (loaded by the open branch, and
by ingest and revise when facts from code or data are needed to compose a point); the closing
question set is closure-set.md; the route of a point and the receiving of experiment
results are experiment-route.md (loaded by the open, ingest and revise branches when a point
is issued, by status for a point on the experiment route, and by ingest for the result of an
experiment); the templates are template-balance.md and
template-checkpoints.md (loaded when a file is created, and read for Allowed header combinations and the none-form where the branches cite them).
Closing block
Follow the Handoff Tail contract (gd-critique → Handoff Engine): the runnable
command is the last block on screen.
In the open, ingest and revise branches — and in status when there is a current point
(Status: open, Current: BCH-<n>) — print the report and any note first, then close with the
command on its own line, the icon in front, nothing after it:
🧭 /unikit-plan full <path to CHECKPOINTS.md>
full is the default recommendation; fast only when the point is plainly small; ultra is
named only by the user (the planner's own rule). With Current: none and for a closed document
there is no plan command — say why instead. Per the membrane, the lines before the command name
the point by its goal in words of the interface language; the command itself carries only the
path to the file, and no point code is printed in it.
When the current point goes by the experiment route (experiment-route.md), the plan command is
not printed. After the user chose "later" the last block is
🧭 /unikit-gd-experiment <path to CHECKPOINTS.md>
and after "now" the called skill ends the turn with its own command, so nothing follows it from here.
Skill calls
Where this skill says to invoke unikit-gd-experiment — optionally "with the argument <text>" — it means one call, made in this session, now, on every runtime: not a command printed for the user and not a delegation. The called skill holds its own conversation with the user in this session and returns control here. A call site that names no argument passes none. Only experiment-route.md makes this call, and only after the user chose "now" there.
- If you have a
Skilltool that accepts arguments, call it with that skill and the arguments of the call site, in full and unchanged, then follow the skill. - Otherwise — no
Skilltool, or one that takes only a name — Read{{skills_dir}}/unikit-gd-experiment/SKILL.mdin full, treat it as the instructions of this step and carry them out here, in this session, now, with the arguments of the call site as the skill's arguments. - When the skill has run, go on to the step the call site names. Do not print a command for the user to run and do not stop.
- Only if that file cannot be read: print
Run: /unikit-gd-experiment <arguments>for the user and stop.
Ownership Boundaries
- Owns:
.unikit/gamedesign/balance/—INDEX.md, and per document<slug>/BALANCE.md,<slug>/CHECKPOINTS.md,<slug>/results/HB-<n>.md,<slug>/results/PT-<n>.md. - Reads (only): the GDD (
GAME.md,GD-IDS.yaml, system documents);researches/by an explicit path; the result of an experiment named by path (results.mdunder.unikit/gamedesign/experiments/), as a document; the project source of the named slice, as a research verb. - Never: edit the GDD,
GD-IDS.yamlor code; scan the code workspace.unikit/code/(plans, code researches) — from there only a document the user named or pasted is read, as a document; register balance documents inGD-IDS.yaml(first slice); apply the coherence gate to a balance document (first slice); call another skill — exceptunikit-gd-experiment, and only after the user chose "now" (## Skill calls) — commands are only printed. A design change goes to its owner: the proposal is left for/unikit-gd-system. - Provenance: a fact lifted from code carries
provenance: extracted from codeand never edits the GDD; the other tags (measured,decided by user,estimate,from playtest) live only in the balance document.
Quick Reference
/unikit-gd-balance → five latest balance documents + the next action
/unikit-gd-balance the economy of the first world → start a balance document (investigate, interview, issue a point)
/unikit-gd-balance researches/<slug>/ → start from a design research
/unikit-gd-balance <slug> → status of one document
/unikit-gd-balance <path to a hand-back report> → receive results, decide, issue the next point or close
/unikit-gd-balance <slug> <path to a hand-back report> → same, the form the executors print; the slug names the document
/unikit-gd-balance <pasted results table> → same; the document is matched, never guessed
/unikit-gd-balance <path to an experiment's results.md> → receive the results of an experiment, decide, issue the next point or close
/unikit-gd-balance <slug> <path to an experiment's results.md> → same, the form the experiment skill prints
04 同仓库更多 Skills
unikit
Initialize the UniKit framework in a project. Scans the current project to detect the engine and real tech stack, then generates the base framework documents that give AI agents context about the project — the resolved project description, the architecture doc, AGENTS.md, and the user-editable .unikit/config.yaml. This is the one-time, whole-project setup run before any other unikit skill. Use whenever the user wants to initialize, set up, or onboard the framework, e.g. "initialize unikit", "init the framework", "set up unikit", "set up the project", "configure AI context", "scan my project and set it up", "bootstrap the project". It also actualizes the config of a project already set up — say "update the config", "add missing settings", "actualize configuration", "fix my config". On a set-up project it offers the actions to choose from.
unikit-verify
Verify a completed implementation against the plan in .unikit/code/plans/. Checks that every task was implemented, nothing was forgotten, the code compiles, the recorded test run still matches the code, and {{engine_name}} conventions are followed. Use after /unikit-implement completes, or when the user says "verify", "check the work", "did we miss anything". For code review use /unikit-review instead.
unikit-todo
Manage the project's TODO list in .unikit/TODO.md — capture work to remember for later, not to do right now. Use it to add a deferred item, mark a todo complete, or show the list. The point is to park tasks you don't want to act on in the moment but don't want to forget. Trigger on "add a todo", "add this to the todo list", "put X on the todo list", "remind me to...", "don't forget to...", "note this for later", "we should do this later", "mark this todo done", "what's on the todo list", "what's left to do". This is only for parking reminders — to actually plan or do the work now, use /unikit-plan, /unikit-implement, or /unikit-execute.
unikit-skills-context
Customize how a built-in unikit skill behaves in this specific project by writing workflow overrides into its skill-context file. These are per-skill workflow rules (e.g. "/unikit-review should also flag TODO comments", "/unikit-implement should run tests after each task"), not coding conventions. Use when the user wants to change, customize, or override how a particular unikit skill works in this project — "customize the review skill", "make /unikit-fix always add logging here", "the implement skill should do X differently", "add a skill rule for /unikit-commit". Use "validate" to find stale overrides against updated base skills. For a general coding convention (not tied to one skill) use /unikit-rules; to derive rules from past mistakes use /unikit-evolve.
unikit-rules
Add a short, project-specific rule, convention, or override to .unikit/RULES.md — the quick-capture inbox for this project's rules (common rules always load; topic files in .unikit/rules/ load when the work matches), automatically loaded by /unikit-implement (later promotable via /unikit-memory migrate-rules). Works only with a rule typed as a prompt — it does NOT read files, folders, URLs, or PDFs. Cross-checks the knowledge base (RULES_INDEX.md) to avoid duplicating core/stack entries. Use for one-line conventions and corrections: "add a rule", "remember this", "convention", "always do X", "never use Y", "from now on do Z", or when the user corrects agent behavior and wants it remembered; also "split the rules into topics" (optimise), "clean up the rules" (prune), "shorten RULES.md" (compact), by keyword or in plain words. If the user points to a source (file, folder, URL, PDF, article, book) or wants to research/document framework usage, use /unikit-memory; for architecture decisions use ARCHITECTURE.md.
unikit-rules-registry
Orchestrate the remote rules registry — the shared registry (often connected as a local folder or git repo) that the project's rules are published to and pulled from. Three modes, picked from the user's wording: create scaffolds a new local rules registry ("create a local rules registry", "init a rules registry"); update migrates/promotes local knowledge-base rules from .unikit/memory/ into the remote registry with automatic semver bumps ("migrate local rules to the remote registry", "promote my rules to the registry", "push local rules", "publish local rules", "update the rules registry"); sync pulls registry updates back into memory ("sync the rules registry", "pull registry updates"). Pass "--module <id>" to scope to one knowledge-base module. This skill ONLY orchestrates the CLI (`unikit-ai rules *`) — it never edits .unikit.json or .unikit/memory/ sources directly.