Your idea.
A step-by-step path.

Follow the arrows.

Each box links to instructions below. You approve installations and every build. A person, never AI, runs tests and accepts results.

1. 01 Get Pi + context toolsPi → RTK → Billion Context
2. 02 Set boundariesBackups · permissions · approvals
3. 03 Choose a gameExact version · one feature
4. 04 Research in GhidraEvidence, not guesses
5. 05 Define featuresPlain-language rows
6. 06 Spreadsheet → SQLite3One writable authority
7. 07 PreflightFix record blockers
8. 08 Export + approve + compileOne reviewed engine build
9. 09 Decoded assets + menuAfter the first successful compile
10. 10 Human testYou play · you judge
11. 11 In-game feedbackExpected versus actual
12. 12 Improve the tablesPreflight → approve → recompile
13. 13 Human acceptancePackage · document · share

Open your first conversation.

node --version
npm --version
npm install -g --ignore-scripts @earendil-works/pi-coding-agent
pi --version

Add RTK and Billion Context.

Use both before starting the project research loop. They solve different problems. Neither replaces the authoritative spreadsheet/SQLite database, your approval rules or human testing.

1. A RTKShorter shell output
2. B Billion ContextManage long conversations
3. C Confirm bothInspect activity, not promises

rtk --version
rtk init -g --agent pi

npm install -g billion-context
bili plugin install pi

C. Confirm the setup yourself

1. After saving your work, close and reopen Pi in your project folder. Do not restart someone else's active session. Read startup warnings. If a managed configuration blocks extensions, ask its maintainer to allow the specific extensions rather than disabling the safety policy.
2. RTK: in a separate terminal, run rtk rewrite "git status". It should suggest rtk git status. This only confirms the binary knows the rewrite, not that Pi loaded the adapter. In an existing Git project, ask Pi to show repository status without editing files or running tests, then inspect rtk gain --history yourself. Look for a new matching entry. No entry or a missing-binary warning means activation is not confirmed. Do not initialize an unrelated folder just for this check.
3. Billion Context: inside Pi, type /acp. After one ordinary model request, such as “Explain our project rules without running tools,” inspect its session status and /acp-cache. A fresh session can be idle and have no savings yet. Unknown commands, proxy errors or direct/uncompressed warnings mean stop and review setup. The model request has normal provider cost.
4. Record installed versions and what you actually observed. These are human setup checks, not permission for AI to test the game or run a software test suite. A loaded extension alone does not prove long-session compression or savings.

Ready when: you have observed both integrations, know how to view their status, and can recover original evidence. If either is blocked, disclose that and resolve setup before calling this workflow ready. Next: set the project boundaries.

You stay in control.

Keep a backup or version-controlled copy of your project. Start with original sample data, not your only game save or an untrusted download. Give Pi this prompt:

Create an AGENTS.md in this new project with these rules:
AI never runs tests or claims tests passed. Humans own all testing and acceptance.
Ask before installing tools, compiling, recompiling, publishing or deleting anything.
Keep one authoritative spreadsheet/database. Never patch generated game output.
After an approved SQLite cutover, edit tables and treat spreadsheets/search indexes as derived views.
Complete the detailed preflight and obtain explicit approval for each individual compile.
After the first successful compile, integrate authorized decoded assets and an in-game feedback menu in an agreed follow-up batch.
Label facts, hypotheses and unknowns. Preserve originals, saves and credentials.
Use RTK and Billion Context, but never treat filtered output or summaries as authoritative evidence.
Recover original records and full error details when needed. Never stack duplicate context plugins.
Explain each step in plain language. Stop if a required integration is unavailable.
First inspect available tools read-only and list what is present and missing.
Do not install, build, test or deploy now.

Ready when: you can open AGENTS.md, read the rules and see a list of missing tools. Pi security guidance · Project instructions

Start with one small behavior.

Choose an original example or a game/input you are authorized to analyze. Record the title, exact version, platform, permitted scope and where the untouched original is stored. A person observes the reference and writes down what happens.

Ask Pi: “Turn my observation into a one-feature research checklist. Mark missing evidence. Do not invent answers or run the game.”

Ready when: the reference version and a repeatable human observation are recorded. Stop if: authorization, inputs or the version are unclear. Do not upload proprietary binaries to the site or an AI provider.

Research what the program does.

1. Get the official Ghidra release distribution, not GitHub's source-code ZIP. Read the requirements bundled with that release and install its required JDK from Temurin. Requirements vary by release.
2. Extract into a new folder. Launch ghidraRun.bat on Windows or ghidraRun on macOS/Linux. Follow the official guide for platform-specific native components if needed.
3. In Ghidra, choose File → New Project → Non-Shared Project, select a project folder and name, then finish. Choose File → Import File and select an authorized input copy.
4. Open the imported program in CodeBrowser and review its analysis prompt. Keep defaults only when appropriate for the detected format. If the format is not supported or the output is confusing, stop and ask an experienced researcher.
5. Record the relevant function/location, your interpretation, reference version and confidence. Ghidra's decompiled view is not the original source code. Do not label an AI interpretation as proven behavior.

Ask Pi: “Explain these research notes in plain language. Separate observed facts from hypotheses and propose feature rows. Do not execute the game or claim behavior is verified.”

Ready when: each proposed behavior has an evidence reference or an explicit unknown. A beginner may need a researcher here. Official getting-started guide · Official training

Turn research into editable records.

Capture decompiler findings and human observations in a spreadsheet first. Describe how the game works: systems, inputs, states, transitions, rules, timing, units, limits and asset references. Keep facts, interpretations and unknowns separate. These example columns are a planning model, not a ready-made import schema.

Ask Pi: “Organize my research into these records without inventing missing mechanics. Show evidence and unresolved questions. Do not run tests.”

Ready when: you can explain each rule yourself and every row has evidence or a visible unknown. Preserve the original binaries and researcher notes outside generated output.

One database. Clear, editable tables.

Use the spreadsheet to capture the research, then map the approved records into a project-specific SQLite3 database. Review the import and choose one writable authority. After an approved SQLite cutover, edit through the database's table view and keep spreadsheet exports as dated, read-only views. Existing workbook-driven projects keep their current pipeline until that migration is explicitly approved.

A practical table map

Keep large binaries and decoded assets in controlled storage with hash-based references. Preserve originals. Do not duplicate an entire game inside cells, upload private research to a provider without permission, or share proprietary material through public listings.

Search quickly without changing the source of truth.

1. Exact lookup: use ordinary SQLite indexes for stable IDs, relationships and common filters.
2. Text lookup: use SQLite FTS5, where available, for names, notes and evidence text. This is full-text search, not semantic vector search.
3. Semantic / vector search: a reviewed extension such as sqlite-vec can store and query embeddings. Record the embedding model/version, dimensions and source-row hash. Review installation, provider privacy and any cost first. The author's documentation currently labels sqlite-vec pre-v1 with possible breaking changes.
4. Treat text/vector indexes as derived, rebuildable search data. An embedding is not proof of a mechanic and must not overwrite an authored rule. Return results with their real row IDs and evidence.
5. A human measures retrieval quality and latency on the actual dataset. Vector search is not automatically faster than an indexed exact lookup, and this guide makes no “ultra-fast” benchmark claim.

Ask Pi: “Identify our authority and existing editor. Propose a reviewed spreadsheet-to-SQLite mapping, table views and derived search indexes. Identify missing integration. Do not install, migrate, compile or test.”

Ready when: the authority, backups, editing path and exporter are named and the human has reviewed the cutover. Stock Pi does not automatically include a Ghidra connector, DBViewer or this database workflow.

Resolve blockers before compiling.

Prepare this checklist once for the complete proposed feature batch, then refresh it for every recompile. Preflight is specification and release preparation, not gameplay testing, a disguised test suite or proof of parity. AI can inspect source and records and draft findings. Humans run all tests, including automated software suites.

1. Scope and permission: exact reference version, authorized inputs, intended feature batch and material you may use or distribute are recorded.
2. Recovery: original binaries, saves, authoritative database/workbook, schema, source and required asset files are backed up. Name the recovery destination, prior build and rollback procedure.
3. One authority: name its path and revision/hash. Confirm no competing editable workbook/database and no unreviewed migration.
4. Schema and records: review required values, unique stable IDs, types, units, ranges, foreign-key references and change history. Have a human run any required integrity/validator tests and attach their actual results.
5. Evidence: each scoped mechanic has linked research or an explicitly reviewed uncertainty. Missing or contradictory evidence is a blocker unless the owner explicitly narrows the scope.
6. Assets: record original/decoded hashes, supported formats, paths, IDs, budgets and permissions. For the first engine build, explicitly identify any approved placeholders and deferred asset integration.
7. Implementation: identify the real generator, exporter and engine/runtime that consume the tables. Review schema compatibility and missing rendering, physics, input, AI or audio code. Tables do not supply that implementation automatically.
8. Search: derived indexes correspond to the current row revisions and embedding configuration. Search ranking must not alter deterministic exported mechanics.
9. Toolchain and storage: identify installed versions, dependency locks, target platform, output directory and available disk/memory. No surprise installations, provider switches or full-app copies.
10. Build command: show the exact non-test command, changed files, manifest contents and expected artifact. Separate any command that launches tests so a human can run it.
11. Human plan: name who will boot the artifact, compare features, check boundary cases and exercise the feedback menu. Prepare disposable saves and report fields. Untested behavior stays untested.
12. Decision: present blocker IDs and proposed fixes, not just a green badge. A human reviews the findings, resolves blockers and explicitly approves this one compile. Failure does not authorize another compile.

Preflight record
Batch / reference version:
Authority path + revision/hash:
Source / schema / exporter / toolchain versions:
Original + decoded asset manifest:
Backup + rollback locations:
Unresolved blockers + reviewed uncertainties:
Exact non-test build command + output target:
Human-only test plan + tester:
Owner approval + date:
Build ID + artifact hash after compilation:

Ready when: the human has reviewed the checklist, blockers are resolved and the exact build is approved. A completed checklist is not a human acceptance result.

Build from the reviewed tables.

The exporter turns the approved SQLite records into deterministic engine data and an asset manifest. A project-specific generator/runtime consumes that data and its reviewed source code to produce your game. Decompiled pseudocode and tables alone are not an automatic recompilation pipeline.

1. Freeze the approved database revision and source revision. Record schema/exporter versions, feature IDs and asset hashes in a build manifest. Keep generated output reproducible and separate from authored records.
2. Identify the actual engine/runtime and the code implementing the rules. The public workbook starter does not supply a playable runtime. Stop if integration is missing rather than pretending JSON is a game.
3. Present the complete preflight, exact build command, feature batch, tools, output folder and storage needs. The first approved build may be a narrow engine slice with explicitly recorded placeholders.
4. Obtain explicit approval for this one non-test compile. AI may run that approved build, but the AI/harness must not run tests. A command that also runs tests must be separated or run by a human.
5. Record the build ID, database/source revisions, artifact path and hash. A successful compile is not a passed test. A person performs the first boot observation.
6. After the first successful compile, continue to decoded assets and the in-game feedback menu before the full human gameplay cycle. Every later compile needs fresh approval.

Ready when: there is an identified artifact, manifest and human handoff. Install Rust only if the selected runtime requires it. No universal compile command works for every game.

Add decoded assets and a feedback menu.

Once the initial engine build compiles successfully, integrate the authorized decoded assets so a person can begin meaningful gameplay comparison. Preserve the original asset files and the decoding research. Decoding an asset does not create permission to redistribute it.

1. For each texture, model, animation, audio clip or map, record its stable ID, original/decoded hashes, decoder version/options, format, units/scale and permission status.
2. Map those IDs through the database asset table and manifest into the runtime's supported import pipeline. Keep unknown formats and missing dependencies visible. Do not overwrite original assets or saves.
3. Add an in-game feedback menu in this post-first-build batch. The menu should let the human report the current feature, build, database revision, reproduction steps, expected/actual behavior and permitted local evidence without leaving the game.
4. If code or asset integration requires another compile, combine assets and menu into one reviewed follow-up batch, refresh preflight and request fresh build approval. Data-only refresh is allowed only if the runtime already supports it. Do not promise that all asset changes avoid recompilation.
5. Keep reports in a local feedback queue or an owner-approved destination. Reports propose changes, not automatic edits to authoritative mechanics. Never expose secrets, private saves or proprietary attachments.

Ready when: the artifact identifies the assets it uses, the feedback menu exists in the agreed runtime scope and a human is ready to exercise it. AI does not launch gameplay or test the menu.

You play. You record. You decide.

1. Use a backup or disposable save. Note the exact build ID and environment.
2. A person runs the feature scenario with the recorded inputs and compares actual behavior to the reference.
3. The person checks documented boundary cases and performs any required software tests. AI does not launch tests, click through gameplay or supply invented results.
4. Record pass, fail or not tested. Include the tester and evidence. An untested feature stays untested.

Example: you start at 20 health, use the potion and see 25 instead of 30. That is a mismatch to report, not a reason to edit the executable.

Ready when: human observations are recorded against feature IDs. Even when all checks pass, proceed to documented acceptance rather than letting AI sign off.

Report the difference while playing.

The post-first-build runtime should provide a pause/settings-accessible feedback menu. Automatically attach the build ID, database revision and selected feature where possible, but let the human describe what actually happened. The starter does not include this menu. A temporary local report form can preserve observations while a developer implements it, but is not a claim that an in-game menu exists.

Feature ID: potion.small.use
Build ID: [the build you personally tested]
Database revision / asset manifest: [revision]
Reference version: [version]
Tester / date / platform: [fill in]
Scene / save / seed: [permitted reproduction context]
Steps: Start with 20 health and one small potion. Use it once.
Expected: Health 30, potion count 0.
Actual: [what you actually saw, not a guess]
Evidence: [permitted local screenshot or notes]
Severity / result: [severity] / pass / fail / not tested
Proposed table/row: [if known, not an automatic edit]
Status: open, awaiting human review

1. Store each report under a stable feedback ID, linked to its build, feature and database revision.
2. A human reviews the observation and proposed change. AI may organize the report, locate related rows and draft an old/new-value diff, but cannot invent results or accept its own correction.
3. Approved corrections enter the authoritative tables through the supported editor with evidence and revision history. Rejected or unresolved reports remain traceable.
4. Do not let the menu silently patch rules, execute code, recompile the game or publish attachments. Never include credentials, private saves or proprietary assets without permission.

Ready when: another person can understand the observation, identify the affected row and follow the recorded steps. Human approval, not an AI confidence score, controls the correction.

Fix the rule at its source.

Ask Pi: “Compare this human feedback with the authoritative rows and evidence. Propose a minimal correction, explain why, and show the old and new values. Do not patch game output, compile or test.”

1. A human reviews whether the observation justifies a specification correction.
2. Update the authoritative rows through the supported editor, preserving evidence and revision history.
3. If the rows were already correct, do not falsify them to compensate. Record a generator/runtime defect for a developer to fix generically. Do not add a one-off patch to generated game output.
4. Return to preflight, request fresh build approval, regenerate and recompile, then return to human testing.

Ready when: the human retests the new build and closes the feedback record, or records the remaining mismatch for another cycle.

Finish with evidence, not a promise.

• A human accepts the agreed feature scope on the named build.
• Every scoped feature has a human result. Remaining issues and untested environments are disclosed.
• The authoritative data, source revision, build instructions and feedback history are preserved.
• Package only material you may distribute, with licenses, requirements and plain-language run instructions.
• A human separately approves publication. Keep rollback and original saves.

Ask Pi to draft the release notes from recorded evidence. Review them yourself. For sharing, use your own source/release hosting and follow the creator hosting guide and site terms. Modport resources explain the workflow. Listings do not grant permission to redistribute someone else's game or assets; server-hosted downloads remain subject to their separately configured access and publication policy.

Your outcome: either a completed learning matrix or, when a project-specific runtime exists, a human-accepted project. State which one you actually achieved.

Every resource, in one place.

Setup sources reviewed October 4, 2026; SQLite/search and game-method update reviewed October 5, 2026. Use the official instructions for the release you install. This page is an instructional diagram, not screenshots of an integrated product or proof of end-to-end acceptance.