zakariaf
UserOne prompt in. A researched, designed, planned, implemented app out — you make exactly one decision: which design. A hyperresearch-style multi-agent pipeline for Claude Code.
Categories
Indexed Skills (23)
hyperbuild-1-intake
Step 1 of the hyperbuild pipeline — persists the verbatim app idea as gospel (runs/<run_tag>/idea.md), mints the run_tag (slug + random 6-hex suffix), resolves the target platform (stated > inferred, with category defaults) into decisions/platform.md, detects the scale gear (standard | premier), initializes manifest.json and scaffold.md, and seeds TodoWrite with every pipeline step. Spawns no subagents. Every later step and every subagent re-reads what this step writes. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-10-skill-forge
Step 10 of the hyperbuild pipeline — generates the five PROJECT-SPECIFIC Claude Code skills into .claude/skills/ (app-code-style, app-architecture, app-testing, app-components, app-review-checklist) in the rich four-part anatomy (SKILL.md + references/ + examples/ + scripts/ PASS-FAIL gates) by spawning 5 hb-skill-smith subagents in parallel, each grounded in research/02-engineering/author/stack-guide.md + research/product-spec.md, bound by step 9's research/04-claude-skills/author/skill-authoring-guide.md, and adapting harvested skills from step 9's shortlist where they fit. These skills steer every step 14 implementer and arm the step 15 critics; app-components gets its concrete design-token references wired later by step 13. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-11-epics
Step 11 of the hyperbuild pipeline — turns the PRD and feature specs into the full backlog: epics/00-overview.md with the PRD coverage matrix, one epics/NN-<slug>/ dir per epic, one task file per task with the frontmatter contract step 14 keys off. Spawns 1 hb-epic-planner (orchestrator approves the breakdown), then parallel hb-task-author subagents (one per epic), then an hb-spec-critic coverage audit — every must/should PRD feature maps to ≥1 task. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-12-design-gate
Step 12 of the hyperbuild pipeline — the Stage-A hard gate and THE ONE permitted stop. Spawns 1 hb-gate-verifier to mechanically run the full Stage-A checklist (research vault, PRD, feature specs, stack guide, 3 complete design systems with every full/partial screen mocked + screenshotted and art-direction cards for none screens, step 8.5's visual-QA findings with zero unresolved criticals, generated skills, full backlog with PRD↔epics coverage, and the research archive's shape: the four FIXED-name areas, a non-empty verify/ in each, provenance blocks everywhere), writes runs/<run_tag>/gates/design-gate-report.md and — on pass — research/README.md (the areas index + REUSABILITY GUIDE, docs/RESEARCH-ARCHIVE.md §8), then stops the pipeline with a user-facing summary ending in "run /hyperbuild-choose a|b|c", setting manifest blocked_on: "design-choice". On fail: fix artifacts, re-run the gate, max 3 rounds, then blocked + honest report. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-13-scaffold
Step 13 of the hyperbuild pipeline — the first step of Stage B (BUILD). Initializes the real project in app/ per the committed decisions in research/02-engineering/author/stack-guide.md and runs/<run_tag>/decisions/platform.md, git-inits app/ with a platform .gitignore (step 14's per-epic reviews need diffs), spawns ONE hb-implementer to wire lint + formatter + test harness + CI and translate the CHOSEN design's tokens.css into the target framework's theme file(s), updates the generated app-components skill with concrete theme file references, and verifies the empty app builds and its smoke test passes before making the repo's initial commit and exiting. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-14-implement
Step 14 of the hyperbuild pipeline — THE WAVE LOOP, the longest step in Stage B. Schedules the task DAG across ALL epics in waves: each wave is a set of ready tasks with PAIRWISE-DISJOINT files: lists (3–5 standard / 6–10 premier); all of a wave's hb-implementers spawn in ONE parallel batch (idea, PRD section, task file, all generated app-* skills, the chosen design's mockup HTML + screenshots for its screens), each followed by its hb-test-engineer (writes/extends tests — incl. visual/golden-snapshot tests for UI tasks — runs the suite, fixes until green). SYNC POINT between waves: full suite + every generated skill's script gates green — NEVER starts a wave on red — then ONE git commit per wave. When a wave completes an epic's last task: hb-code-critic on the epic's REAL git diff, findings applied by the TOOL-LOCKED (Read+Edit) hb-patcher, structural findings escalate as NEW task files, then an epic commit. Wave plans go to temp/wave-log.md for crash resume; per-epic progress notes live in manifest.json. Inv
hyperbuild-15-adversarial-review
Step 15 of the hyperbuild pipeline — whole-app adversarial review. Spawns 3 critics in parallel (hb-code-critic, hb-spec-critic, hb-ux-critic), each emitting an independent findings JSON to runs/<run_tag>/gates/. The orchestrator ranks and dedupes findings, spawns hb-patcher (TOOL-LOCKED to Read + Edit) to apply surgical fixes, and commits the patch pass in app/. Structural findings become new task files and trigger AT MOST ONE loop back through step 14. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-16-ship-gate
Step 16 of the hyperbuild pipeline — THE ship gate (FINAL STEP). Spawns hb-gate-verifier to run the ship checklist mechanically: full test suite green, lint/analyzer clean, every task status done, every epic acceptance criterion checked, PRD coverage matrix complete, platform-appropriate build succeeds, every generated-skill scripts/*.sh gate passes, the feature→task→file→test TRACEABILITY CHAIN holds for every must/should feature, and app/ is a clean git repo with scaffold/wave/epic history. Produces runs/<run_tag>/gates/ship-report.md. The gate's verdict is final — failures are fixed by changing the app, never by re-interpreting checks; max 3 fix rounds, then blocked with an honest report. On pass, delivers the final user message. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-2-market-recon
Step 2 of the hyperbuild pipeline — competitor recon. Spawns ONE hb-competitor-scout to discover and rank the competitor set, then a parallel wave of hb-competitor-analyst subagents (one per curated competitor: 6–8 standard, 12–15 premier) that each write a dossier to research/01-product-and-market/research/competitors/<slug>.md in the docs/RESEARCH-ARCHIVE.md research-file format (H3 claims written as complete assertions) covering latest version, feature set, changelog cadence, pricing, and store ratings. The orchestrator then registers those claims in runs/<run_tag>/temp/claims-01.json and merges the dossiers into research/01-product-and-market/author/competitor-landscape.md with a feature matrix. Runs concurrently with step 3 as the 2 ∥ 3 pair; step 3.5 audits these artifacts before step 4 builds the PRD on them. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-3-5-research-audit
Step 3.5 of the hyperbuild pipeline — the VERIFY + CRITIQUE + INDEX phases of research area 01-product-and-market, and the home of the REUSABLE VERIFICATION ENGINE that steps 5, 6 and 9 re-run over their own areas. Runs after steps 2 AND 3 (the 2 ∥ 3 pair) both complete. Reads the area claim registry runs/<run_tag>/temp/claims-01.json, spawns ONE hb-claim-verifier PER CLAIM in parallel batches — each told to REFUTE its single claim against primary sources and to write research/01-product-and-market/verify/<dimension>--<claim-slug>.md with a closed-vocabulary verdict (CONFIRMED | PARTIALLY_TRUE | REFUTED | UNVERIFIABLE) — then runs the CRITIQUE PANEL (2 standard / 3 premier, distinct lenses) over the whole area corpus. The orchestrator then PATCHES the area's author/ syntheses per verdict: REFUTED claims leave the argument and are recorded under "## Refuted by verification", PARTIALLY_TRUE claims carry their correction inline, nothing is ever silently deleted — and closes the area with _INDEX.md. Invoked by th
hyperbuild-3-social-mining
Step 3 of the hyperbuild pipeline — social sentiment mining. Spawns 4 hb-sentiment-miner subagents in parallel, one per platform group (reddit / HN+forums / app-store reviews / LinkedIn+X), each mining 25–40 posts (standard) or 60–100 (premier) into research/01-product-and-market/research/sentiment/<platform>.md in the docs/RESEARCH-ARCHIVE.md research-file format (H3 claims written as complete assertions) with verbatim quotes + URLs. The orchestrator registers those claims in runs/<run_tag>/temp/claims-01.json and merges the files into research/01-product-and-market/author/sentiment-synthesis.md — pain points and wish lists ranked by frequency × intensity. Runs concurrently with step 2 as the 2 ∥ 3 pair; step 3.5 audits the synthesis before step 4 traces PRD features to these quotes. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-4-5-feature-specs
Step 4.5 of the hyperbuild pipeline — expands every must/should PRD feature into its own deep spec file at the repo root: features/NN-<slug>.md (frontmatter id, name, moscow, status: specced, screens; eight required body sections) plus the features/00-index.md roster. Cap 15 files (standard) / 25 (premier). Spawns 3–5 hb-feature-author subagents in parallel, features split into batches, every claim evidenced from the research vault. Steps 6–8 draw real flows and content from these specs, step 11 tasks cite feature ids, and the step 12 and 16 gates check feature coverage and status flips. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-4-product-spec
Step 4 of the hyperbuild pipeline — merges the competitor landscape (step 2) and sentiment synthesis (step 3), as audited by step 3.5, into the PRD at research/product-spec.md: personas, a MoSCoW feature list where every must/should traces to competitor evidence or user-demand quotes, differentiators, and THE CANONICAL SCREEN INVENTORY (each screen classified mockup_feasibility: full | partial | none) that steps 8, 11, and 14 all key off. Spawns 1 hb-spec-critic to attack the draft PRD; the orchestrator patches the findings itself via surgical Edits. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-5-stack-research
Step 5 of the hyperbuild pipeline — builds the engineering research area `research/02-engineering/` to the docs/RESEARCH-ARCHIVE.md contract. The orchestrator probes the real toolchain, runs a bounded harvest DISCOVER sweep, then DERIVES 6–8 (standard) / 10–14 (premier) engineering dimensions for the platform chosen in step 1 from a documented base set; spawns ONE hb-stack-researcher per dimension (harvest-first) → research/; extracts every load-bearing claim into temp/claims-02.json; runs the verification engine (one hb-claim-verifier per claim, each told to REFUTE it) → verify/; runs the hb-corpus-critic panel → critique/; writes _INDEX.md; and only THEN authors `research/02-engineering/author/stack-guide.md` on the claims that survived. Steps 10, 13, 14 build by that guide and the step-15 code critic enforces it. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-6-design-research
Step 6 of the hyperbuild pipeline — research area 03-design-system. The orchestrator names EXACTLY 3 design directions that are three genuinely DIFFERENT VISUAL WORLDS (each committing to its own answer on type personality, depth model, shape language, color strategy, density, and data/status form), then spawns ONE wave: 3 hb-design-researcher subagents (one per direction) plus 2 (standard) / 3 (premier) hb-stack-researcher subagents on the SHARED dimensions the platform forces on all three directions — what the target framework can actually render, font availability and licensing, platform design-language conventions, accessibility/contrast constraints. All six-ish docs land in research/03-design-system/research/ in the docs/RESEARCH-ARCHIVE.md format (claims as H3 assertions + Sources + provenance block). The orchestrator registers the area's claims in runs/<run_tag>/temp/claims-03.json, drafts author/design-directions.md, then RUNS THE VERIFICATION ENGINE (step 3.5, phases V1-V6: one hb-claim-verifier per
hyperbuild-7-design-systems
Step 7 of the hyperbuild pipeline — spawns 3 hb-design-system-author subagents in parallel (one per design direction from step 6). Each author reads its direction's research doc and writes a complete design system: runs/<run_tag>/designs/<a|b|c>/design-system.md + tokens.css — a named signature element, a display+body type pairing, light+dark color palettes, spacing, a shape language, a named depth model, motion, illustration/empty-state art direction, data personality, and component specs (buttons, cards, inputs, nav, lists, empty states). docs/DESIGN-CRAFT.md is BINDING on this step. tokens.css follows the three-layer token structure (primitive → semantic → component) unless the direction's research argues otherwise, and must carry real layered elevation, a radius rhythm, both type faces, and motion tokens. Step 8's mockup smiths inline these tokens verbatim; /hyperbuild-choose copies the winning tokens.css to app/design/ and step 13 implements it in the target framework. Invoked by the hyperbuild router vi
hyperbuild-8-5-visual-qa
Step 8.5 of the hyperbuild pipeline — VISUAL QA of the rendered mockups, the first and only point where anything LOOKS at the pixels the user will judge. Spawns 3 hb-design-critic agents in parallel (one per design direction); each VIEWS every rendered screenshot for its direction (the Read tool renders PNGs) against docs/DESIGN-CRAFT.md §4 (layout integrity) and that direction's own design-system.md (craft), and files runs/<run_tag>/gates/visual-qa-<letter>.json — findings carrying screen, severity, category, what_is_wrong, fix_instruction. The orchestrator ranks the findings, re-spawns the responsible hb-mockup-smith in PATCH MODE (edit the existing mockup HTML, never rewrite), re-renders the patched screenshots, and re-runs the critic ONCE over the affected screens. MAX 2 rounds — remaining criticals are recorded as known issues, never looped on. Step 12 checks these files and prints unresolved criticals to the user. Invoked by the hyperbuild router via Skill(); not run directly by users.
hyperbuild-8-mockups
Step 8 of the hyperbuild pipeline — reads the PRD's canonical screen inventory, freezes the mockup screen list (every full/partial screen per its mockup_feasibility, cap 12 standard / 20 premier), and spawns 3-6 hb-mockup-smith subagents in parallel, grouped by design, so EVERY full/partial screen exists as a self-contained HTML mockup in all 3 design systems (tokens inlined, REAL PRD content — never lorem ipsum, phone-frame wrapper for mobile; partial screens get real chrome over a clearly-marked placeholder viewport; none screens get an art-direction card per design instead of a mockup). The orchestrator then renders screenshots/<screen>.png for every mockup via headless Chrome and writes runs/<run_tag>/designs/index.html — a side-by-side iframe gallery grouped by screen with design names and jump nav — the page the user opens to pick a design at the step 12 gate. Every smith is bound by docs/DESIGN-CRAFT.md — the craft contract (signature element, depth model, shape language, type pairing, CSS-drawn art) p
hyperbuild-9-skill-research
Step 9 of the hyperbuild pipeline — research area 04-claude-skills: deep research on Claude Code skill authoring. Spawns 4 hb-stack-researcher subagents in ONE parallel wave, one per dimension (skill format and frontmatter; progressive disclosure and file splitting; check-script gates; harvested-collection survey), each writing research/04-claude-skills/research/<dimension>.md in the docs/RESEARCH-ARCHIVE.md format (claims as H3 assertions + Sources + provenance block). Claude Code mechanics are EXACTLY where invented frontmatter fields, invented size limits and invented triggering behaviour appear, so the orchestrator registers every claim in runs/<run_tag>/temp/claims-04.json, drafts research/04-claude-skills/author/skill-authoring-guide.md, and RUNS THE VERIFICATION ENGINE (step 3.5, phases V1-V6: one hb-claim-verifier per claim hunting invented names first, a 2/3-seat hb-corpus-critic panel, the author patch, and _INDEX.md). The guide ends in a binding "Rules for our generated skills" section that step 10
hyperbuild-choose
Human checkpoint of the hyperbuild pipeline — the user's ONE decision. Invoked directly by the user as /hyperbuild-choose <a|b|c> [platform] after the Stage-A design gate (step 12) parks the run with blocked_on: "design-choice". Validates the run is actually at the gate, writes decisions/design-choice.md, copies the chosen design's tokens.css and design-system.md to app/design/, flips the manifest to stage: "BUILD" (an optional second argument overrides the platform, which marks steps 5, 10, and 11 for re-run), then invokes Skill(skill: "hyperbuild") so the router's resume logic drives Stage B. This skill does NO build work.
hyperbuild-redesign
Generate a NEW set of design directions for a run parked at the Stage-A design gate. Invoked directly by the user as /hyperbuild-redesign [notes], where notes are free-form ("bolder, more playful", "keep c, replace a and b", "nothing beige", "more like Duolingo's energy"). Parses KEEP/REPLACE instructions — kept directions survive untouched with their letters, only the replaced slots regenerate — archives everything it replaces under runs/<run_tag>/designs/archive/round-<N>/, then re-runs step 6 (design research) for the new slots with the user's notes appended to the direction brief as binding constraints, followed by step 7 (design systems), step 8 (mockups + screenshots) and the step-8.5 visual QA for those slots only, rebuilds directions.md + designs/index.html, re-runs the step-12 gate and parks the run again. Repeatable — round 2, 3, … each archive their predecessors. Records every round in runs/<run_tag>/decisions/revisions.md. Does NO build work and never touches app/.
hyperbuild-revise
Change something BEFORE the build starts. Invoked directly by the user as /hyperbuild-revise <plain-English change> on a run parked at the Stage-A design gate (step 12, blocked_on: "design-choice"). Classifies the request into a revision scope — idea | feature | design | epics — states the resolved plan and blast radius, then applies it: idea → a dated "## Revisions" entry appended to runs/<run_tag>/idea.md (the verbatim idea is never rewritten) plus re-runs of steps 4/4.5 and everything downstream that depends on them; feature → surgical edits to features/*.md + 00-index.md then scoped re-runs of 8/11; design → a scoped re-run of one direction's system author + mockup smiths + screenshots + 8.5 visual QA (new DIRECTIONS go to /hyperbuild-redesign instead); epics → a re-run of step 11 under the stated constraint. Always ends by re-running the step-12 gate so the run parks cleanly again, and records every revision in runs/<run_tag>/decisions/revisions.md. Does NO build work and never touches app/.
hyperbuild
Turns ONE app idea into a fully researched, designed, planned, and implemented application via the hyperbuild 19-step, two-stage pipeline: Stage A — PLAN (steps 1–12, autonomous: market recon, social mining, adversarial research audit — every load-bearing claim fact-checked by its own agent into a four-phase research archive — PRD, feature specs, stack research, 3 complete design systems with HTML mockups of every screen, adversarial VISUAL QA of every rendered screen, project-specific generated skills, epics/tasks) → ONE human checkpoint (`/hyperbuild-choose <a|b|c>`) → Stage B — BUILD (steps 13–16, autonomous: scaffold, implement, adversarial review, ship gate). This entry skill is a ROUTER. It contains no step procedures — it tells you which Skill to invoke for each step, in order, and how to recover a crashed run. Each step's instructions live in its own skill file (hyperbuild-1-intake through hyperbuild-16-ship-gate) and are loaded fresh into context when invoked.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.