Skip to content
← PARAM BAHIA

SYSTEM — THE ENGINE ROOM

The Framework.

Every project this month shipped absurdly fast. None of them are the interesting part. This is.
← PARAM BAHIA

SYSTEM — THE ENGINE ROOM

The Framework.

Every project this month shipped absurdly fast. None of them are the interesting part. This is.

Look at the timeline and the pattern is hard to miss: a game in five days, a rental-intelligence product in one, a commercialisation run in three. The projects didn’t get easier — the system underneath them got real. The framework is that system: a spec-driven, orchestrated way of building where every project starts from the same scaffold — a briefing for any fresh session, a prioritised backlog, atomic numbered specs, an architecture map, decision records, runbooks — so no session ever starts from zero and nothing durable lives only in a chat window. Sessions are disposable; the framework is the memory.

It grew the way tools should: out of necessity, one project at a time. It started here, on this site, as a discipline for not losing decisions between sessions. Then it learned parallelism — an orchestrator terminal that writes the specs, makes the calls, and merges; worker terminals that each take one spec into an isolated worktree, build it, and hand back a completion brief; me as the relay between them. Work moves in waves: a batch of specs fans out, lands, gets adversarially reviewed, merges, and the next wave goes. The game ran twelve waves and fifty specs in five days. The day-job cockpit took over three hundred commits in ten. Every one of those commits traces back to a written spec with acceptance criteria.

The unreasonable effectiveness comes from what the structure does to speed. Specs make work parallelisable — five terminals can build five things at once without colliding. Decision records make it resumable — any session can pick up exactly where the last one stopped. Reviews make it trustworthy — nothing merges on vibes. The result is that the gap between an idea and a working thing collapsed to an afternoon, and the constraint moved from “can I build it?” to “what’s worth building?” That question turned out to have its own answer: once building stopped being the bottleneck, turning the builds into businesses became it — so the framework’s first descendant is a platform for exactly that.

→ github.com/parambahia/agents-folder

The public version. MIT, no code — fourteen templates and an overview. Copy what you need into .agents/.

AMENDED 20 OCT 2026 — HOW IT GREW

28 June. It began as a decision record on this site. New sessions kept losing the thread — which task came next, what had been decided, and why — because the plan lived in a conversation. The first decision record put execution in a folder of its own beside the design vault: a backlog, numbered specs with acceptance criteria, a system map, runbooks. The vault kept the taste. The folder took the work.

July. On the 6th a spec on this site went to a second agent for the first time, as a written handoff with the brief as the contract. By the 26th the pattern had outgrown one repo, and I cut it into a master of its own: the templates, and the orchestration model the intro describes. The next day it gained provenance. Projects had started moving between Claude Code and Codex, and a session log that does not record which agent, which model and which role did the work cannot be trusted on resume.

13 August. The completion notice stopped going through me. A finished worker tells the orchestrator directly, and the brief on disk stays the record — nothing true lives only in a message.

21 August. The day before, I found the FlatSignal board three weeks stale. Nothing had said so: the watchdog checked that the job ran, the job ran, and it republished frozen data with a clean exit. The framework gained three templates in answer. Ops and liveness: a deployed surface ships with a check that asserts the data is fresh, never that a job fired, and a run that cannot produce fresh output fails loudly instead of publishing stale state. A cross-session protocol, proven the same day in the build of Watchtower: one orchestrator routed two workers through five specs across three machines without my pasting a single handoff. And a portfolio board, where every parked project carries a wake condition or becomes a candidate for the kill. Two days later came the rules for runs nobody watches.

6 October. The system map had gained a living flow diagram on 1 September, redrawn in the same session as the change it describes. The Hold opened on 23 September, and a review of what it had collected produced a proposal against the framework itself. I approved it on 6 October and ported back everything the projects had learned through September and October. That release carries the rules I lean on most: rejections are logged, never deleted, and the ledger of what was ruled out is read before any change; a status claim comes from the running system, not a document; the reviewer gets the artifact and the contract, never the author’s account of it. It also added a protocol for paid work inside someone else’s business: build in the tools they already pay for, freeze a dated baseline before building anything, write the exit plan in week one.

12 October. It went public as agents-folder, scrubbed of every project name, path and machine. Two days later the scrub became mechanical: a check script that fails on any leak, and it caught one the day it landed. Since then: a debugging method for code nobody in the session has read (13 October); a measured optimisation loop — one number, one script, keep or revert (14 October); comments that carry the why or the quirk and nothing else (15 October); and on 19 October, the distilled lessons of twenty-nine works on software design — design it twice, deep modules, structure commits kept apart from behaviour commits. The public copy moves with the master.

THE SKILLS

The templates are the memory. These are the instruments I built or adapted to run on top of them — they live in my Claude Code setup, not in the repo.

  • god — Distils a spoken brain dump into a sharp prompt: the intent under the words, the parts, the cuts, and a depth pass that asks for the goal beyond the goal and a proof from outside the conversation.
  • scaffold — Attacks a distilled idea before planning it, makes two or three architectures compete against the requirements, and returns a build brief with a milestone ladder and the kickoff prompt.
  • forge — Runs the whole loop in one flow: dump, distil, one pause for my follow-up, scaffold, and the brief written into the new repo.
  • software-decompiler — Reverse-engineers what a product does from public evidence — docs, demos, talks, reviews — into a capability map, a data contract and a bolt-on spec in my repo’s own format. Behaviour only: never binaries, never code, never anything behind a login.
  • animation-review — Reviews motion by its frames, not its code: the twelve principles of animation as a pass/fail table, a frame cited for every row, one revision pass, a re-render. Web, iOS and video alike.
  • accessibility-audit — A WCAG 2.1 AA pass: axe-core in a real browser, plus static analysis of the components.
  • ui-ux-pro-max — A searchable library of styles, palettes, type pairings and UX rules, with a section I added for cutting interface copy that says nothing.
  • codex — Cross-model review: a different model family reads the change, read-only, before a milestone merges.
  • portfolio — The board across every project: liveness first, then what is blocked on me, then which parked projects have reached their wake date.

BUILT ON

Mine is an amalgamation. These are the public repos I have taken from, or am about to, and what each gives.

  • → addyosmani/agent-skills · MIT

    Process skills for coding agents, with reviewer personas and evals for the skills themselves.

    Not the pack. Its red-flag and rationalisation tables — the excuses an agent makes before it skips a step — are next to fold into my review policy; the forge skill already carries a red-flags section of its own.

  • → nextlevelbuilder/ui-ux-pro-max-skill · MIT

    Design intelligence for interface work: styles, palettes, type pairings, UX rules.

    Installed as a skill, with my own section on interface copy added.

  • → juliobsz/skills · MIT

    One skill, /awwwards, for building award-style marketing sites.

    Its stack is not mine. Two process rules for this site: every invented placeholder listed before a page ships, and a screenshot loop that scores the page until it clears eight out of ten.

  • → ai-evals-course/evals-skills · Apache-2.0

    Skills for evaluating model output: error discovery, judge prompts, judge validation.

    Error discovery as the step before any golden set: find how the system actually fails before writing the tests that grade it.

  • → LottieFiles/motion-design-skill · MIT

    Motion rules for before you build: archetypes, durations, stagger budgets.

    Queued: its archetype and stagger tables go on the pre-build side of my motion review. Its rule that every scene carries three layers of motion I rejected. One thing moves at a time.

  • → howseen-ai/claude-motion-design · MIT

    One studio’s pipeline for rendering film from HTML with Playwright and ffmpeg.

    Queued, the method only and never the install: deterministic frames driven by a single time value, and a critique loop that scores a contact sheet and fixes the three worst frames.

  • → madebymustafa/design-taste · MIT

    Plain-text design skills against generic machine-made output, with packs by genre.

    Text only, no installer. Its editorial and dark packs sit closest to this site’s register; I read them for bans my own rules lack.

  • → browser-use/video-use · MIT

    An agent skill that rough-cuts recorded footage over ffmpeg.

    On trial, for recorded footage only, with a kill rule: more than three correction rounds and it goes.

And the rule that keeps it from becoming ceremony: standalone is the default. One terminal, a briefing file, a resume point. Specs arrive when the work spans files or deserves an audit trail; orchestration when the work genuinely splits; governance when someone other than me owns the decisions. A thirty-line fix does not get a spec. Every piece earns its place in a project, or it stays out.

→ APCP — the platform built on it

→ The timeline — the burst it produced

No screenshots — the framework is markdown, terminals, and discipline. The projects it shipped are the gallery.

The decomposition — 20 Oct 2026

07 / 20 · The Framework — Sessions are disposable; the folder is the memory

Project / The Framework · Design decomposition

  1. 01The folder

    Every project starts from the same folder beside its code, so no session starts from zero and nothing durable lives only in a chat window.

  2. 02State

    A briefing for any fresh session, a prioritised backlog, a system map and the decision records hold the state, so any session resumes where the last one stopped.

  3. 03Specs

    Every task is an atomic numbered spec with acceptance criteria, and that is what lets five terminals build five things without colliding.

  4. 04The orchestrator

    One terminal writes the specs, makes the calls and merges, and a finished worker reports to it directly.

  5. 05Workers

    Each worker takes one spec into an isolated worktree, builds it, and hands back a completion brief that stays on disk as the record.

  6. 06Review

    Every wave is reviewed adversarially, a different model family reads the large changes, and the reviewer gets the artifact and the contract, never the author’s account.

  7. 07Provenance

    Every session log records which agent, which model and which role did the work, because a log that cannot say so cannot be trusted on resume.

  8. 08Liveness

    A deployed surface ships with a check that its data is fresh, never only that a job fired, and every parked project carries a wake condition.

  9. 09agents-folder

    The public copy is agents-folder on GitHub: fourteen templates, MIT, no code, scrubbed by a check script that fails on any leak.

Schematic — structure only · markdown and terminals

Dwg framework · Scale 1:1 · Rev 09

The public templates: github.com/parambahia/agents-folder.