I didn't invent AppMaker. I curated it.

There's a file in the AppMaker repo called REFERENCES.md that I maintain as carefully as the code. It lists every project that shaped the design — what I took, what I considered, what I explicitly rejected. I keep it because the honest answer to "how did you design this?" is: I didn't, mostly. I curated.

Good systems are rarely inventions. They're syntheses with taste. Here's mine, with full attribution.

What I took, and from whom

From Matt Pocock's skills: the form factor and the voice. Single-purpose markdown files, no framework, no runtime. His "caveman" compression style became the mandatory style guide for every AppMaker skill. The deepest lesson was one line in my notes: inspiration beats runtime dependency — copy the markdown, modify it, own it. Several of his skills (grill, TDD, to-prd) survive in AppMaker as recognisable descendants. Even his deprecated ubiquitous-language skill made it in — I adopted the format he abandoned, but changed the process that probably killed it (the glossary now maintains itself as a byproduct of other skills, instead of demanding its own ceremony).

From OpenSpec: the folder and the philosophy. Per-change artifact folders with an archive flow, and a phrase I think about a lot: convention without coercion. No phase gates doesn't mean no structure.

From Spec Kit: the constitution. Project-level principles as a first-class, user-owned file — plus the pattern of opt-in deepening commands instead of a mandatory pipeline.

From GSD: the paranoia. Plan-check before execution, dependency legitimacy checks (is this package real or a typosquat?), context-budget awareness, surfacing gray areas instead of letting them silently become assumptions.

From gstack: the evidence. UI changes ship with browser screenshots, QA is diff-aware, diagnosis starts from root cause. "Looks fine to me" is not a verification.

From ECC: two cherry-picks from 249 skills. The four-voice decision council (fresh subagents argue Skeptic, Pragmatist and Critic with zero access to the conversation — they can't be anchored by what I already believe) and the security gate. I deliberately did not adopt the other 247. A capability library that broad is the opposite bet to a discipline spine, and bundling it would have been context-bloat with name collisions.

From outside the repo ecosystem entirely: tracer bullets from The Pragmatic Programmer (every slice cuts through all layers and is demoable alone), ubiquitous language from Eric Evans' DDD, and Karpathy's memory-as-compilation framing — raw notes in, compiled wiki out, with a test suite for broken links.

The field, compared

Checking the numbers while writing this (June 2026), every source is alive and enormous. The comparison is the clearest way to show what AppMaker is — and isn't:

| Tool | ★ | What it is | What I took | Where AppMaker differs | |---|---|---|---|---| | Pocock skills | 119k | single-purpose markdown skills | form factor, caveman style, grill/TDD/PRD patterns | adds a lifecycle across skills, not just within them | | Spec Kit | 109k | GitHub's 5-phase spec-driven workflow | constitution, opt-in deepening | no mandatory pipeline — gates are scripts, not phases | | gstack | 108k | 23 opinionated tools (Garry Tan's setup) | browser evidence, diff-aware QA | evidence lands in durable per-slice records | | GSD | 64k | meta-prompting & context engineering | plan-check, package legitimacy, context budget | checks become PASS/FAIL gates wired to artifacts | | Graphify | 60k | codebase knowledge graph | optional read-only context layer | consumed, never bundled — small versioned packets | | OpenSpec | 53k | spec-driven change folders | per-feature folders, archive flow | adds criterion→test traceability links on top | | ECC | new | 249-skill operator system | council + security gate, nothing else | opposite bet: a spine, not a library | | AppMaker | 0 | spec + governance layer | all of the above | the synthesis itself |

Yes, zero stars — I'm publishing this before promoting the repo. Every tool I borrowed from has tens of thousands. That gap doesn't embarrass me; it's the whole thesis of this post. The parts are proven at scale. The synthesis is new.

What taught me more: the failures

REFERENCES.md has a section most reference lists don't: negative references.

The first is a project of mine called AppsMaker-2025. It implemented a clever voting algorithm from a research paper, reached 75% completion in November 2025, and has not moved since. Over-scoped, never integrated, ambitious without a minimal first cut. It never shipped anything.

The second is AppMaker's own first iteration, now sitting in a history/ folder: 5 ADRs, 18 constitutional rules, 3 JSON Schemas, propagation chains. Roughly 80% of those artifacts served the system's own self-consistency rather than any user. What stopped it was not a metric but a human instinct mid-session: we have to stop here and define what this is for.

Both failures bought the same lesson, which became AppMaker's architecture: every layer opt-in, ship the minimal cut first, and let stop-points come from a human asking "does this concretely help anyone today?" The five-layer design isn't elegance. It's scar tissue.

Why I publish the provenance

Partly fairness — these people did the hard thinking and their repos deserve the traffic. But mostly because curation is the actual skill being demonstrated. Anyone can collect 249 capabilities. Choosing the one council pattern worth keeping, noticing that a deprecated skill had a salvageable format, recognising your own stalled project as a design input — that's the work. The synthesis is the invention.

If you're building your own system on top of AI agents, steal this process before you steal any of the parts: keep a references file, write down what you rejected and why, and give your failures equal billing. Future-you, staring at a design decision six months later, will thank present-you for the paper trail.