Skip to main content
Engineering Docs’ Greenfield Mode (Mode A) takes a raw project idea — a sentence, a messy paragraph, a half-formed concept — and produces a complete, cross-consistent set of pre-development documents. The orchestrator skill (using-engineering-docs) handles all routing decisions: you answer questions about your project, it decides which of the 22 specialist skills to invoke, in what order, and assembles the results into a navigable master index. You never need to name a skill or choose a document type.

​
What you’ll end up with

After a full Mode A run, your project root will contain a .engineering-docs/ folder organized like this:

​
Step-by-step walkthrough

1

Invoke the orchestrator with your idea

Give the orchestrator your project idea in plain language — a polished brief is not required. One sentence is enough to start.
Example prompt
The orchestrator detects Mode A (Greenfield) because there is no existing .engineering-docs/ folder and no language indicating an existing codebase.
You don’t need to say “use engineering-docs” or name any skill. The orchestrator activates automatically when your agent has the plugin installed.
2

Business concept interview — Phase 0

Before any technical document is produced, the orchestrator runs a business concept interview. This is mandatory: every downstream document is built on the answers gathered here. Without it, the orchestrator would be guessing.Questions arrive one at a time via tool calls — not as a bulleted list in chat. This keeps conversation clean and produces better answers.What to expect — the six business concept questions:
  1. Core idea — What is being built, and what’s the single most important thing it needs to do well?
  2. Who it’s for — Who are the users, and what problem are they solving today without this product?
  3. Value proposition — Why would someone choose this over alternatives, including doing nothing?
  4. Monetization — How does this make money? (subscription, one-time, freemium, ads, internal cost savings)
  5. Must-have vs. nice-to-have — What’s the minimum that’s useful? What can wait for v2?
  6. Timeline and budget — When does this need to exist, and what’s the rough budget?
Each question is presented with multiple-choice options and an “I don’t know, you decide” escape hatch. When you take that path, the orchestrator picks the most reasonable option, tags it as [agent-decided] in the document, and continues without blocking.
If your initial prompt already contains some of these details (team size, budget, timeline), the orchestrator will not re-ask. It reads your prompt first and only asks for what’s genuinely missing.
Output of Phase 0: 1-business-plan.md — the foundational document every later skill reads before asking its own questions.
3

Standing constraint questions — asked once, early

Alongside the business concept questions, the orchestrator asks a set of standing constraint questions that every downstream skill depends on. These are asked once, early in Phase 0, and never repeated.

Team size & skill level

Affects framework and stack recommendations throughout all technical documents.

Hosting / infra preference

Self-hosted, cloud, existing vendor lock-in — shapes the architecture and deployment plan.

Budget sensitivity

Determines managed-service vs. self-hosted trade-offs in every operational document.

Timeline urgency

MVP-speed constraints versus enterprise rigor — affects scope and right-sizing decisions.

Regulatory / compliance needs

Data residency, PCI, GDPR — triggers or skips the security threat model and access control spec.

Existing integrations

Systems this must connect to or avoid conflicting with — informs the API design and architecture.
4

Sequencing plan preview

After the business concept is complete, the orchestrator uses the project profile to determine which of the 22 skills apply. It then previews the document plan before generating anything:
Example sequencing plan
This is your opportunity to redirect — “skip the design system, we’re using a component library” or “add an admin access control spec, we’ll have staff accounts.” The orchestrator proceeds once there’s no objection, and it initializes index.md as a durable progress tracker at this point.
The sequencing plan is a proposal, not a contract. If a later interview reveals an unexpected complexity (e.g., a feature that needs an ADR), the plan is updated in real time.
5

Sequential document generation with confirmation gates

The orchestrator generates documents one at a time, in order. For each document:
  1. Reads the skill’s SKILL.md to understand what that document needs.
  2. Reads all prior documents in .engineering-docs/ to extract already-known information — team size, budget, stack, constraints.
  3. Asks only what’s genuinely missing — maximum 2–3 questions per skill, one at a time via tool calls.
  4. Generates the document using the skill’s template.
  5. Writes it to .engineering-docs/<N>-<slug>.md with a YAML frontmatter block.
  6. Confirms with you before moving to the next — no silent chaining.
Every generated document opens with this metadata header:
Document metadata frontmatter
After each document completes, you’ll see a progress report:
Progress update example
6

Consistency pass

After each document is produced, the orchestrator runs an incremental consistency check — verifying entity names, role names, and terminology match across the documents written so far.What it checks:
  • Does the architecture doc’s chosen approach match what the database and API docs assume?
  • Does every endpoint in the API doc have a corresponding entity in the database doc?
  • Does the security threat model cover every external-facing API surface listed in the API doc?
  • Does the test strategy reference every feature blueprint that exists?
  • Do entity names match across all documents (e.g., Order vs order vs Purchase)?
Mismatches are surfaced to you with a plain-language explanation and a recommended resolution — not silently fixed.
Consistency checks happen after each document, not just at the end. Catching a naming mismatch between the business plan and the database design while only 3 documents exist is far cheaper than finding it in document 12.
7

Master index — the final deliverable

After all documents are generated and the final consistency pass is complete, the orchestrator produces index.md — the single document that ties everything together.The master index contains:
  • Every document produced, its status, and the order to read them
  • A “if you only read three documents” shortcut pointer for any agent or engineer starting cold
  • All [agent-decided] items flagged for human review
  • The complete reading order that matches the dependency order
index.md excerpt
The index.md file is the anchor for session persistence. If you need to stop mid-pipeline and return in a new session, the orchestrator reads index.md first and resumes exactly where it left off — no re-asking, no restarting.

​
Right-sizing: not every project needs every document

The orchestrator decides which conditional skills to run based on your project’s actual profile. You will never receive a disaster recovery plan for a solo-developer MVP, or an SLO error budget document for an internal prototype.
These eight documents are generated for every project, regardless of size:
These are only produced when the project actually warrants them:

​
Session persistence across long runs

A full Mode A pipeline for a non-trivial project can span multiple sessions. Engineering Docs is designed for this:
  • After every phase, index.md records which phases are done, which is in progress, and what the next unanswered question is.
  • On a new invocation in a project that already has a partial .engineering-docs/ folder, the orchestrator reads index.md first and resumes exactly where it left off.
  • For projects requiring 10+ documents, the orchestrator may suggest starting a fresh agent session between major phases to keep quality high — each skill reads prior documents from files, not from conversation memory.
If your agent starts re-asking questions that were already answered, or loses track of entity names established in earlier documents, context is too full. Start a fresh session — the orchestrator will pick up from index.md without missing a beat.