write-readmelisted

# Write README Produce a `README.md` in `TARGET_DIR` that an engineer arriving at the repository would actually find useful. The README serves humans landing on the repo page; it is not a duplicate of `PROJECT_BRIEF.md` (the machine contract) or of any internal documentation. ## Preconditions - `TARGET_DIR` must contain a `PROJECT_BRIEF.md`. If not, stop and ask the user to run `project-builder` first. - Never write inside `SESSION_DIR`. - Never generate a README for the `project-builder` workspace itself; that workspace's README is maintained by hand. ## Step 1 — Read the brief 1. Read `PROJECT_BRIEF.md`. 2. Parse the YAML frontmatter — structured facts: `project.name`, `stack.languages`, `stack.versions`, `build.tool`, `build.commands`, `profiles`, `deployment.provider`. 3. Read the `## Overview` section for the problem, users, and value proposition. 4. Read `## Architecture` and `## Deployment` for the shape of a realistic quick-start. ## Step 2 — Ask about audience, visibility, and license Via `AskUserQuestion`: - **Audience**: contributors (developers modifying the code) / users (consuming the output) / both. - **Visibility**: public or private repo. Private repos can skip license and contributing boilerplate. - **License**: open-source license name (`MIT`, `Apache-2.0`, etc.), `Proprietary`, or `Not yet licensed`. ## Step 3 — Draft against the fixed skeleton Use this skeleton verbatim. No additional top-level sections without a concrete reason. ```markdown #