ordo-build-intake

Captures complete requirements records through clarifying questions before Ordo app builds begin.

Updated Aug 10, 2026
One-click install
npx skills add https://github.com/Rekonquest/ordo-pro --skill ordo-build-intake-rekonquest
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ordo-build-intake
Source: https://github.com/Rekonquest/ordo-pro/tree/main/default-user-files/skills/ordo-build-intake
Command: npx skills add https://github.com/Rekonquest/ordo-pro --skill ordo-build-intake-rekonquest

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Ordo app builds fail when they start from vague requests, because unasked questions become wrong assumptions baked into the architecture. This Skill enforces a structured intake step that pins down exactly what is being built before any blueprint, crate, or code exists. ## Core Features & Use Cases - Structured Questioning: Walks the user through seven requirement areas — purpose, UI, persistence, external systems, local/cloud siting, out-of-scope items, and definition of done — in small focused batches. - Requirements Record: Produces a complete written record stored to the ledger, which the planner gates on before releasing the blueprint step. - Scope Guardrails: Explicitly forbids crate design, scaffolding, and unconfirmed assumptions during intake. - Use Case: A user says "build me an Ordo app that monitors my cameras." Instead of scaffolding immediately, the Skill asks what the UI shows, whether state persists across restarts, and what done looks like, then writes the record. ## Quick Start Ask me the intake questions needed to define my Ordo app before any building starts.

Frequently Asked Questions about ordo-build-intake

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I start an Ordo app build the right way?▼

Start with the intake step: answer focused questions about purpose, UI, persistence, external systems, and definition of done. The answers are written to a requirements record in the ledger, and no blueprint or code is produced until that record is complete.

What questions should be answered before designing software architecture?▼

Pin down what the app does, whether it has a UI, what state persists across restarts, which external systems it touches, what runs locally versus in the cloud, what is explicitly out of scope, and the observable condition that means the build is finished.

When does the intake step decide an Ordo app needs persistent storage?▼

Persistence is decided by asking whether any state must survive a restart. If the answer is yes, the requirements record notes it, and the later blueprint step includes the claw-store crate; intake itself never names crates.

Why should I not skip requirements gathering for a clear-seeming request?▼

Requests that seem clear still hide assumptions about UI shape, persistence, and integrations. Wrong assumptions compound through later build steps and become expensive to fix at launch-proof, while a question at intake costs almost nothing.

Can the intake step design crates or scaffold code?▼

No. Intake is forbidden from naming crates, writing code, or scaffolding anything. Its only output is the requirements record; crate design belongs to the blueprint step, which the planner releases after the record passes the completeness gate.