# Knowledge Base Doc Generation — Per-Subagent Instructions

> **Prompt composition (Slice 2).** This file is the *shared procedure* injected
> into every Phase-2 subagent. Your full prompt is assembled as:
> **shared procedure (this file) + one per-step substance fragment
> (`init/phases/phase-2/<step>.md`) + an `<!-- AGENT PARAMS -->` block**. The
> substance fragment names the single doc you write, which Phase-1 discovery
> input to read, its required output, and the not-applicable stub for an absent
> topic. You never see the other steps' fragments — generate only your own.

You are generating **ONE** knowledge base document. You have been given:

1. A **discovery context** — the raw findings from Phase 1 discovery scans,
   passed inline in your prompt
2. A **doc spec** — which file to write and what it should contain
3. A **project brief** (`.forge/init-context.md`) — for names and paths

Your job is to produce exactly one file and return a one-line status.

---

## Rules

1. **Write EXACTLY ONE file** at the path specified in your doc spec.

2. **Confidence header** — every generated doc must open with:
   ```
   <!-- AUTO-GENERATED by /forge:init — confidence: N% -->
   ```
   Set N% based on how much evidence the discovery context provided:
   - 90–100%: directly observed in code/config
   - 70–89%: inferred from conventions or partial evidence
   - below 70%: limited evidence, many `[?]` markers expected

3. **Uncertainty markers** — any fact not directly observed in the discovery
   context must be marked with `[?]`. Do not invent values.

   **Not-applicable stub (absent topic).** If your assigned topic does not exist
   in this project (your substance fragment names the trigger — e.g. no
   persistence layer, no routing surface, no test suite), the topic is *absent*:
   a **certainty**, not a low-confidence guess. Do NOT lower confidence. Write a
   confident stub — exactly three parts:
   ```
   <!-- AUTO-GENERATED by /forge:init — confidence: 100% — status: not-applicable -->
   # <Doc Heading>
   <the one-sentence absence statement from your fragment>
   ```
   The `status: not-applicable` marker in the header is what the Phase-2 verify
   gate reads to accept the doc without demanding substantive body content; the
   100% confidence records that the *absence* is known with certainty. A header
   with an empty body and no marker is rejected by the gate — always emit the
   heading and the absence sentence.

4. **Entity names** — use entity names exactly as they appear in the brief's
   `## Domain Entities` section. Do not rename or abbreviate.

5. **Scope discipline** — generate only what the doc spec prescribes.
   Do not add sections not listed in the spec. Do not cross-reference
   other KB docs that do not yet exist.

6. **`architecture/INDEX.md` and `business-domain/INDEX.md`** — if your
   assigned doc is an INDEX file, link only to docs that exist on disk at
   the time you write. Do not anticipate files that may not have been written.

---

## Self-check (mandatory last step)

After writing the file, verify before returning:

1. Read back the written file
2. Confirm the confidence header is present on the first line
3. Confirm no `{placeholder}` tokens remain
4. Record in the manifest:
   ```sh
   node "$FORGE_ROOT/tools/generation-manifest.cjs" record "{output_path}"
   ```
   (If generation-manifest.cjs is not yet installed, skip silently.)

5. Return **exactly one line**:
   - `done: <first 80 chars of the written file>` — on success
   - `FAILED: <reason>` — if any step above failed or the file could not be written

Do not output anything else after the status line.