Why it matters

Most of what Ora does is think about something — diagnose a failure, weigh a decision, map a terrain. Project Mode is different: it is the mode for when you have stopped wanting an answer and started wanting a thing built. You have named a deliverable — a script, a one-page web app, a CLI tool, a structured document, a working component — and the job is no longer to understand a subject but to produce the artifact and produce it well. Project Mode is how Ora runs that work the way a competent engineer runs it: pin down what “done” means, break the work into ordered steps, do the build, and surface the decisions it made along the way so you can see what you are actually getting.

For example: you ask for “a Python script that watches my Downloads folder and renames invoice PDFs to a clean date — vendor — amount filename using OCR.” That one sentence hides a dozen decisions — which OCR library, what to do with a file that does not match the pattern, whether to move or rename, how to handle a PDF with no readable text. A naive system silently picks all twelve and hands you code that looks right. Project Mode does the opposite: it nails down the spec, makes those choices deliberately, builds the script, and then tells you the choices it made — so the one it got wrong is a line you can change, not a surprise you discover in production three weeks later.

  • What it produces. A finished deliverable — working code, a structured document, a component — built to the conventions of its kind, plus an explicit log of the build decisions and known limitations, so what you receive is auditable rather than a black box.
  • How it changes the read. The question shifts from “what is true about X?” to “what is being built, what does ‘done’ mean, and which commitments is this build making on my behalf?” — execution treated with the same care as analysis.
  • When to foreground it. You have named a concrete deliverable and want it constructed — “build me…”, “write me a script that…”, “make me a one-page app that…” — and the work ahead is production, not orientation, diagnosis, or open-ended exploration.
  • What you’d miss without it. That a one-sentence request always contains hidden engineering decisions; let them be made silently and you get output that looks correct but quietly commits you to choices you never saw and would not have endorsed.
  • Where it misleads. Reach for it when the real work is upstream — a decision still unmade, an analysis still undone, a subject you wanted understood rather than built — and it will dutifully construct the wrong thing, fluently and fast.

How to invoke it in Ora

You have a specific deliverable in mind and you want it built — not researched, not weighed, not surveyed, but produced as a working artifact you can run, read, or ship.

Name the deliverable concretely and ask for it:

“Build me a Python CLI that walks a directory of photos, clusters visually similar shots, and produces an HTML gallery I can browse to delete duplicates.”

The verbs build me, write me a script that, and make me a one-page app that are what route you here, and the phrase execution and project mode names it outright. Bring as much of the specification as you have: what the deliverable does, what “working” looks like to you, and any constraints that matter — the language or framework, whether there can be a backend, what it must not do. “Build me an app” works; “build me a single-file React app, no build step, that reads a public API and shows the result as a sorted list” gets you far closer to the thing in your head on the first pass, because every constraint you supply is one the build no longer has to guess.

Two things to expect. The mode will sometimes ask a clarifying question before it builds — that is signal, not friction: it means the request left open a decision you should make rather than one it should invent. And it draws a boundary at analysis: if your request smuggles in real analytical work — “build me a decision-tree for whether to acquire this company” — the deciding is upstream of the building, and the mode will route that work to the right analytical mode first and then come back to construct the artifact. Project Mode builds the thing; it does not pretend the thinking the thing depends on has already been done.

How it works

The clearest way to see what Project Mode is doing is to watch the difference between two people handed the same one-line request: “build me a tool that renames my invoice PDFs.”

The first person starts typing immediately. They pick an OCR library because it is the one they used last, assume every file in the folder is an invoice, decide a non-matching file should just be skipped silently, and hand back a script that runs. It looks finished. But buried inside are four decisions you never saw — and the day a bank statement lands in that folder and vanishes without a trace, you learn that “skip silently” was a choice someone made for you. The work looked like building. It was really guessing with a keyboard.

The second person works like a project. Before writing anything they pin down what “done” actually means: rename invoices, leave everything else untouched, never lose a file, and flag anything the pattern cannot read rather than dropping it. With the goal fixed, they break the job into ordered pieces — read the folder, OCR the first page, parse out date and vendor and amount, build the new name, handle the file that does not match — and they notice the dependencies, that you cannot build a filename until the OCR step has run and that OCR can fail, so the failure path has to exist before the happy path is trustworthy. Then they build, in that order. And when they hand it back, they hand back the decisions too: “I used this OCR engine because it needs no system install; non-matching files are moved to a review/ folder, not deleted; here are the three cases I could not handle.” Now the one decision they got wrong for your situation is a line you can change, not a landmine you step on later.

That second way of working is Project Mode, and it is worth being precise about what kind of mode it is. Ora’s other modes are analytical — they take a subject and produce understanding. Project Mode is an operating mode: it takes a piece of work and runs it as a managed project. The unit it cares about is not a claim to be examined but a deliverable to be shipped, and the discipline it brings is the project manager’s, compressed into a single pass — clarify the goal and what counts as done, decompose the work into steps and milestones, sequence the steps so dependencies come in the right order, execute, and adapt the plan when the building reveals something the planning could not have known. The whole reason the discipline exists is the lesson every veteran builder has learned the hard way: the expensive failures are almost never bad typing. They are the unstated requirement, the dependency you hit in the wrong order, the decision made silently and discovered late. Project Mode is built to drag those into the light before they cost you — which is exactly why it surfaces its build decisions instead of hiding them in clean-looking code. A choice you can see is a choice you can still change.

Framework & implementation

This section uses Ora’s own terms for the parts of an operating mode, so that if you open the actual mode file they line up. Each is glossed in plain language on first use.

Pipeline execution

Project Mode is the original-execution mode in the execution-project-mode territory — the mode Ora invokes when the user has named a specific deliverable and wants it built, rather than wanting orientation, analysis, or exploration. It is an operating mode, not an analytical one: it runs a piece of work as a managed project rather than producing understanding about a subject. Its closest sibling is Structured Output, the rendering-only counterpart — the division is simple: Project Mode thinks (the deliverable needs original work, design decisions, and content the system has to produce), while Structured Output renders (the content already exists and the task is faithful formatting).

The pass does four things in order. It locks the deliverable specification — what is being built, what the success criteria are, what the scope constraints are — so “done” has a fixed definition before any work starts. It clarifies the requirements when the user has named a deliverable without explicit acceptance criteria, asking rather than guessing when the ambiguity is large enough that the build would otherwise commit to decisions the user should make. It produces the deliverable — code, document, component, artifact — honoring the conventions of the artifact type: idiomatic code in the relevant language, the formatting conventions of the document kind, sane naming, deliberate dependency management. And it surfaces the build decisions when they are non-trivial — the architectural choices, the library selections, the tradeoffs another engineer might have made differently — so the user evaluates and revises rather than inheriting a black box.

The load-bearing discipline is that execution deserves the same epistemic care as analysis. The characteristic failure of a careless build is to treat the deliverable as a one-shot rendering of the request, producing output that looks correct but contains commitments the user never endorsed; the mode’s corrective is to make those commitments visible.

Output contract

The deliverable comes in a consistent shape so the work is reviewable rather than opaque: the artifact itself (the working code, document, or component, built to its type’s conventions), a decisions log (each non-trivial build choice with the alternatives weighed and the reason for the one taken), and a limitations acknowledged section (the known gaps, risks, and boundary conditions the build does not cover). The contract’s whole purpose is to convert silent commitments into stated ones — every decision the build made on the user’s behalf appears where the user can see it, challenge it, and change it.

Origin and evidence

Project Mode is the software-era distillation of project-management discipline, not a single author’s invention. Its backbone — clarify the goal, decompose into tasks, sequence dependencies, track and adapt — is the institutional core codified in the Project Management Institute’s A Guide to the Project Management Body of Knowledge (first edition 1996), the standard reference for scope, scheduling, and execution. Its sharpest lessons about building come from Frederick Brooks’s The Mythical Man-Month (1975), the classic on why software projects fail: not for want of effort but through unstated requirements, mis-sequenced work, and the myth that thrown bodies substitute for clear specification — the precise failures this mode front-loads against. Scott Berkun’s Making Things Happen (2008) carries the same discipline into the modern practice of running a build as a project, where surfacing decisions and tradeoffs is the everyday work rather than a ceremony. The mode adapts that lineage to a single execution pass: it is the project manager’s checklist compressed to the point of action.

Applications and common uses

  • One-file web apps and components. A self-contained app or UI component built from a named spec — read an API, render the result, honor an explicit framework constraint with no build tooling.
  • Automation and CLI tools. A script or command-line utility that does a concrete job — watch a folder and rename files, walk a directory and cluster its contents, pull a data feed and chart it.
  • Structured documents with original content. A document whose content the system must produce, not merely format — a spec, a runbook, a templated report where the writing is the work.
  • Code components from a clear contract. A function, module, or integration built to a stated interface and acceptance criteria, with the design choices surfaced for review.
  • Data-pulling and visualization artifacts. A small app or script that fetches a public source and presents it — a sparkline of a weekly change, a sorted feed, a browsable gallery.

Failure modes and when not to use it

  • The black-box build. Producing a deliverable that runs but hides the decisions it made — the failure the mode exists to prevent. The decisions log and limitations section are the guard: silent commitments become stated ones.
  • Guessing through ambiguity. When requirements are genuinely under-specified, building anyway commits the user to invented choices. The mode’s corrective is to ask the clarifying question rather than manufacture the missing criteria.
  • Building past the spec. Adding scope the user did not request — gold-plating — produces an artifact heavier and more fragile than the one asked for. The locked specification is the boundary that keeps the build honest to “done.”

When not to reach for it. When the real work is analysis that has not been done — a decision still open, a subject to be understood rather than built — route to the analytical mode first; Project Mode is downstream of analysis, not a substitute for it. When the deliverable is content that already exists and only needs formatting, that is rendering, and Structured Output is the right operation. When the request is exploratory with no named deliverable — a question to wander into rather than a thing to construct — an exploration or orientation mode fits. And when the build depends on domain expertise the user has not supplied and the system cannot reasonably infer, the honest output is to name what input is needed before construction can responsibly begin, not to build on a guess.

  • Structured Output — the rendering-only sibling and the boundary this mode hands across: when the content already exists and the task is faithful formatting rather than original construction, that is the right operation, not this one.
  • Decision Architecture — the upstream partner for when the build depends on a choice that has not been made: settle the decision there, then return to Project Mode to construct what the decision warrants.
  • Constraint Mapping — the mode for surfacing the real boundaries — budget, dependencies, non-negotiables — that a deliverable must live inside, before the spec is locked and the build begins.
  • Pre-Mortem Fragility — the review to pair with a deliverable headed for deployment: stress the built artifact for how it could fail before you rely on it, rather than discovering the failure surface in production.