Module Build Plan
Objective
Complete a public, source-backed reverse engineering map of Garry's AI software factory. Each module should be useful on its own, but together they should read like a product spec, GTM teardown, JTBD map, and contribution strategy for the whole system.
Definition of Done
Each module is complete when it has:
- A clear product lens: what part of the system it explains.
- Source evidence: repo files, README language, schema details, skills, issues, PRs, benchmarks, or public pages.
- Jobs-to-be-done: what the user is hiring this layer to do.
- Personas and use cases where relevant.
- Product requirements: what the system must provide to make the job work.
- Implications for Ren/OpenClaw: what we should copy, avoid, contribute to, or compete with.
- Open questions and next evidence to gather.
Module Inventory
| Module | Status | Core Question | Primary Evidence |
|---|---|---|---|
| 01 gstack teardown | Complete v1 | What product does the 52-skill workflow actually define? | gstack README, SKILL.md files, docs |
| 02 gbrain runtime map | Complete v1 | How does persistent memory work as a product and data system? | schema.sql, core types, README, MCP docs |
| 03 gbrain skillpack JTBD | Complete v1 | What work does the 43-skill brain workflow automate? | gbrain/skills SKILL.md files, README |
| 04 funnel and CTA teardown | Complete v1 | How does OSS attention turn into YC hiring and founder demand? | gstack README, YC software/apply pages |
| 05 competitive map | Complete v1 | Where does this system sit vs coding agents, memory tools, and eval repos? | README claims, repo capabilities, market categories |
| 06 contribution map | Complete v1 | Where can Ren create credible, mergeable value? | open issue/PR themes, repo health, duplicate-risk scan |
| 07 gbrain-evals proof layer | Complete v1 | How does the system make memory claims falsifiable? | gbrain-evals README, benchmark reports, comparison docs, runner layout |
Build Order
- Build the internal source-backed docs first.
- Mirror each module onto the public Pages site.
- Keep the home page as the executive map, and make /modules/ the working index.
- Add deeper module revisions as new evidence comes in.
Completion Standard
This should not stop at "interesting analysis." The final system should let us answer:
- What is each repo for?
- What does each skill do?
- What user job does each layer serve?
- What is the user acquisition path?
- What are the product specs implied by the public artifacts?
- What are the strongest contribution opportunities?
- What should Ren/OpenClaw learn from it?