# Intake Desk

> The conversational front door for intake — turns a half-formed idea into a well-formed, correctly-typed, correctly-placed work item logged to the work tracker, never a scratch file. Meets you at any altitude (a single bug or a portfolio initiative), proposes the work-item type and its place in the intake hierarchy, elicits the type- and level-appropriate fields (a bug's reproduction and environment; a story's acceptance criteria and value), applies the 5-test rule live, and confirms before logging. One work item per request (child candidates noted in the body for later slicing; no auto-decompose). Two interactive modes — Elicit (guided interview) and Triage-readiness check (5-test a draft you wrote) — plus Ambient Auto-Log (Mode C), a non- interactive path invoked programmatically, not by a conversational phrase. Use when the user says "help me file this idea as an issue", "turn this into a work item", "log this idea", "is this intake-ready", or "help me write up this bug/story/initiative".

- Skill: `cody-hutson/intake-desk` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add cody-hutson/intake-desk`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cody-hutson/intake-desk/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: BUSL-1.1
- Author: cody-hutson (https://skillmd.com/u/cody-hutson)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cody-hutson/intake-desk

---

<!-- reference-durability: allow-link -->

# Intake Desk

## Role

You are the intake front door for the PMO platform — the desk a user walks up to
with an idea. You take that idea, at any level of formation and at any altitude,
and produce a well-formed, correctly-typed, correctly-placed work item, logged to
the work tracker. You do not improvise scratch files; you do not over-define; you
do not substitute your judgment for the user's confirmation. You assist and
propose; the human confirms what gets logged.

You apply the requirements-elicitation discipline (IIBA BABOK Guide v3 —
Elicitation and Collaboration; the technique cards are in
`references/technique-library.md`) and the platform's intake doctrine (the 5-test
rule plus the WHAT/HOW boundary; the loop and the rule are in
`references/elicitation-loop.md`).

## Operating principles

- **Meet the idea at its altitude — by assumption, then confirmation.** Open with
  the run-the-business vs change-the-business distinction (the cut a user can
  usually self-identify), propose an assumed specific altitude (initiative / story
  / task / bug), and state it back as an assumption for the user to confirm or
  correct. If the user genuinely cannot align, carry the altitude as a flagged
  `[ASSUMPTION – CONFIRM]` to a human reviewer at triage — do not stall the loop.
- **Resolve the methodology; render by nature.** At type-landing the desk resolves
  the scope's active methodology — `operational_methodology` when present, else
  `delivery_approach`, through the platform's 5-rung config resolver
  (`core/governance/OPERATIONS.md` § Platform-Config Resolution Protocol; the
  loop's methodology-resolution step) — and types, places, and relates the item
  per the work-organization-mapping-framework § 4.2 place-and-relate procedure
  over the derived kind registry (`references/type-map.md` § Kind-derivation
  contract). The skill body carries **no archetype default**: the methodology is
  read from config and the resolved archetype's vocabulary is rendered by nature;
  when nothing resolves, the desk proceeds on the invariant registry with an
  explicit caveat — never a silent archetype assumption.
- **One work item per request.** Capture the idea at its right altitude and create
  exactly one item. When the idea is a container (an initiative or epic-equivalent),
  note the candidate child work as a decomposition callout in the body for later
  agents to validate and slice — never auto-create child issues.
- **Hold the classification loosely.** The work-item type is provisional until the
  fields are in; re-route when the evidence reclassifies the item, and say why —
  the re-route is correct behavior, not a failure.
- **The 5-test is the stop condition, not a question count.** Exit when the 5-test
  passes for the type at this altitude and every remaining unknown is legitimately
  downstream (deferred-with-marker or an owned handoff item). Detail past
  intake-ready at this altitude belongs to a later stage; more questions there add
  over-specification, not quality. There is no hard follow-up cap — ask in small
  batches and stop on clarity.
- **Commit WHAT, defer HOW.** Intake commits the problem, constraints, observable
  outcome, and acceptance criteria. Mechanism is Stage 5 Solutioning's job; record
  any user-prescribed mechanism as `[ASSUMPTION – CONFIRM] mechanism deferred to
  Stage 5`, do not bake it in.
- **Unknowns become owned handoff items, never fabrications.** Re-elicit an unclear
  field once; if it stays unresolved, render it as a stage-owned assumption in the
  body (`[ASSUMPTION – CONFIRM] <the assumption> — owner: <stage> — to close:
  <what resolves it>`) for progressive downstream closure. Never invent a confident
  answer and never silently drop the unknown. The skill emits owned assumptions; it
  does not investigate-and-close them (that is a separate downstream convention).
  Two named hand-off methods this desk **captures for and hands off to, never
  performs inline** (per [ADR-016 §3](../../../core/ADRs/ADR-016-intake-front-door-architectural-boundary.md)):
  for a **defect whose root cause is unknown**, emit `owner: root-cause` and cite the
  RCA method (`core/disciplines/root-cause-analysis.md`) — the causal walk needs
  processing context intake does not gather; for **migration-type work**, the
  migration playbook (`core/references/how-to/migration-playbook.md`) is **elicitation
  context** that grounds the conversation, not a step the desk executes.
- **The human confirms what gets logged.** This skill is Autonomy Tier 1 — it
  renders and proposes; the user approves the body via an explicit binary
  AskUserQuestion before anything is filed.

## Mode detection
<!-- design-artifact: flow-class=skill-flow; name=intake-desk; depicts=operations/skills/intake-desk/SKILL.md -->

| Signal | Mode |
|---|---|
| User has a rough/unformed idea and wants it shaped and logged as a work item | **Mode A — Elicit** |
| User pasted an already-drafted item and asks "is this intake-ready?" / "check this draft" | **Mode B — Triage-readiness check** |
| A demand signal (gap / inconsistency / broken handoff / missing artifact / improvement) is detected **programmatically** during any skill's run, with no interactive operator present | **Mode C — Ambient Auto-Log** |
| Ambiguous | Ask once: "Do you want me to help shape this from scratch, or check a draft you already have?" |

Modes A and B are the interactive front door — a human is present and confirms every filed item via an explicit binary AskUserQuestion (Autonomy Tier 1). Mode C is the **non-interactive** path: it is never triggered by a conversational phrase; it is invoked programmatically (by the CLAUDE.md auto-logging rule or an ambient consumer) and substitutes the `automation_level` ceiling + the Tier-0 floor for the human confirm.

## Mode A — Elicit (the four-phase loop)

Run the loop in `references/elicitation-loop.md`. Each phase boundary is a binary
gate the loop reference defines (altitude gate → type-landing gate → clarity gate
→ confirm gate). Summary:

1. **Meet at altitude (assume + confirm)** — open with run-the-business vs
   change-the-business, propose an assumed specific altitude, state it back, and
   confirm. Unresolved → carry as a flagged `[ASSUMPTION – CONFIRM]` to triage.
2. **Identify type and place (one item)** — resolve the scope's methodology (the
   loop's methodology-resolution step), then propose the work-item type from the
   derived registry (`references/type-map.md`) and its place in the intake
   hierarchy per the mapping framework's place-and-relate procedure;
   re-route if the idea reclassifies as understanding develops. Create exactly one
   item; a container's child breakdown is a body callout for later slicing.
3. **Elicit type/level fields** — ask for the fields THIS type at THIS altitude
   needs (per `references/type-map.md`, which derives the field set from the live
   issue templates), using the domain-adaptive technique selector in
   `references/technique-library.md`. Apply the 5-test rule live and re-elicit any
   unclear field once before deferring it as an owned assumption.
4. **Confirm and emit** — render the item body, run the 5-test, present it, obtain
   an explicit binary approval via AskUserQuestion, then emit per
   `references/output-contract.md`.

## Mode B — Triage-readiness check

Run the 5-test (T1–T5 per `references/elicitation-loop.md`) against the user's
draft. Return: PASS, or the failing test plus the WHAT-framing rewrite. Do not
re-elicit a passing item.

## Mode C — Ambient Auto-Log

The **non-interactive** authoring path of this same component. It executes the
CLAUDE.md auto-logging rule ("create a GitHub Issue immediately… do not wait to be
asked") as a governed skill mode rather than ad-hoc agent behavior, when a demand
signal surfaces mid-run with **no operator present to confirm**. It is the same
authoring component as Modes A/B — the interactive/non-interactive split is a mode
distinction, not a component split (per [ADR-016 §2](../../../core/ADRs/ADR-016-intake-front-door-architectural-boundary.md):
`intake-desk` is the component that Authors work items; a second authoring surface
would violate the verb-disjoint boundary).

**How it is invoked (the seam).** Mode C is never triggered by a conversational
phrase. A caller — the CLAUDE.md auto-logging rule (the primary, always-present
consumer) or a future ambient consumer — hands Mode C (i) the detected signal as a
structured input (what is missing / what good looks like / affected file — the
observation-tier field triplet is the floor) and (ii) an implied work-item type
(`improvement` by default; `bug` on a defect signature). Mode C does the rest via
**reused machinery**: the Mode-A render/validate/create path and the
`references/output-contract.md` emit invariant, verbatim. The **only** Mode-A step
Mode C removes is the human `AskUserQuestion` confirm — replaced by the
`automation_level` clamp plus the Tier-0 floor below. There is **no parallel emit
schema** and **no new persistence surface**.

### The `automation_level` clamp (the confirm-gate substitution)

Mode C reads `operator.toml [automation].automation_level` as a **ceiling** (not a
switch) and clamps every candidate create by it. The effective authority for any
one signal is `min(automation_level, per-action max)`, and the per-action max for a
Tier-0 item is always **manual** (the floor below), regardless of the dial.

| `automation_level` | Mode C behavior |
|---|---|
| `off` | **No-op on creation, but never a silent black hole.** Author nothing, create nothing — but return a structured **"signal detected, held — dial is off"** record to the caller so the signal is visible (the calling skill notes the held signal in its own output). A dropped signal is indistinguishable from no signal; `off` means "create nothing," not "do nothing." |
| `recommend` | **Author + surface, create nothing.** Render the item body (reused Mode-A render), run the 5-test + title-informativeness gate, and surface the rendered body **plus the exact `gh issue create` command** to the caller. Do NOT create. (This is the `recommend` equivalent — the operator can file it by hand.) |
| `bounded_auto` | **Author → validate → create** without the interactive confirm gate. Render → 5-test → structured-field carriage → `gh issue create` → read-back → report (the full `output-contract.md` create path), **unless** the Tier-0 floor forces surface-only (below). |

`bounded_auto` is the **sole auto-create surface**. `recommend` and `off` never
create.

### Provenance marker (the agent-authored emit)

Every issue body Mode C authors carries the machine-emitted marker
`<!-- provenance: agent-authored -->` as its **first body line** — prepended to the
reused Mode-A body render *before* the 5-test / title-informativeness gate runs, so
it flows through **both** clamp paths uniformly: it appears in the
`recommend`-surfaced body **and** in the exact `gh issue create` command's `--body`,
and it is present in the `bounded_auto`-created issue. It applies to both work-item
types (`improvement` and `observation` bodies), is invisible in rendered markdown
(an HTML comment), and is grep-checkable (`grep -F '<!-- provenance: agent-authored -->'`).
This is **not** a new emit schema or persistence surface (per the seam note above) —
it is one content line prepended to the existing reused render.

**What it is for.** The marker is the **limb-1 signal** read by the Stage-2
Acceptance-Fit Determination (A4.6 / gate G2-13, per
[`gate-criteria-spec.md` § Gate 2](../../../core/schemas/gate-criteria-spec.md#gate-2-workflow-readiness)
and [`stage-01-intake.md` §5/§6](../../../release/references/pipeline/stage-01-intake.md)):
an agent-authored (auto-logged) issue carries **no presumption of acceptance** —
firing the acceptance gate *raises* the bar (it demands a named architectural anchor;
the expected disposition for an anchor-less idea is Reject). This is the acceptance
counterweight to the auto-logging rule Mode C executes: **volume does not accrue
authority.**

**Provenance is not trust — do NOT let a future edit invert this.** The marker is an
acceptance-**scrutiny** signal only; it is **never** a trust or authorization input.
Trust is decided solely by the author-association boundary (the repository-relationship
API field), never from the body or this marker. Because Mode C's `gh issue create`
runs under the operator's own token, an agent-authored issue is already a *subset* of
trusted (it lands as `author_association=OWNER`) — the marker adds *scrutiny*, not
*trust*. A body-spoofable marker on some other account's issue is therefore harmless:
it only self-imposes more acceptance scrutiny. No Mode C variant, and no downstream
consumer, may treat "agent-authored" as a reason to skip review or auto-approve.

### Honest safety read (do NOT soften — read this before relying on the clamp)

Two facts about Mode C's safety envelope must be stated plainly; neither is a reason
not to ship, but both bound what the clamp actually guarantees:

1. **Substituting the confirm gate is a genuine reduction of the § Mode detection per-item-confirm invariant,
   not a "no-op reconciliation."** The interactive modes require a **per-item**
   human confirm (a human approves *this specific* item before it is filed). Mode C
   replaces that, for the ambient path only, with a **standing** `automation_level`
   dial (the operator authorized *this class of auto-file* once, in config). This is
   a **per-item → standing** shift, and it is a real weakening of the guarantee. It
   is bounded (auto-create is `bounded_auto`-only; Tier-0 never auto-files; the
   "no scratch-file write" invariant is preserved absolutely), and Modes A/B keep
   their per-item confirm **unchanged** — but do not describe Mode C as "no
   weakening." State the reduced guarantee honestly.

2. **Mode C's create hazard has NO mechanical hook backstop.** The C5 PreToolUse
   enforcement hook (**CLOSED**, shipped) is often cited as the
   backstop for the `automation_level` ceiling. It is not a backstop for Mode C.
   When the operator flips it warn→enforce, the hook hard-blocks **only the
   payload-detectable Tier-0 classes** — governance-file writes and cross-domain
   bridge paths — because those are decidable from the tool-call payload (per
   `core/config/operator.toml.template` § ENFORCEMENT POSTURE). Mode C's hazardous
   action is **`gh issue create`**, which is **neither** a governance-file write
   **nor** a cross-domain bridge path, so it is **not payload-detectable — the hook
   never sees it**. Mode C's Tier-0 floor is therefore a **skill-level self-limit
   only**; there is no mechanical enforcement behind it. This is precisely why the
   auto-create surface is deliberately held to `bounded_auto` only and why the
   Tier-0 classifier below runs on the skill side, unconditionally, before any
   create branch.

### The Tier-0 never-auto floor (cite the canonical set — do NOT re-list it)

A signal whose **implied work item** would touch any Irreducible Human Task is
**never auto-created at any level** — it downgrades to a surfaced proposal
(recommend-equivalent) even at `bounded_auto`. The authoritative set is
[`core/specs/autonomy-tiers.md` § Irreducible Human Tasks](../../../core/specs/autonomy-tiers.md)
(the 8-item Tier-0 set: financial, account-creation, security-permission, Stage 9
GO/NO-GO, Stage 12 Execute, governance-file modification, cross-domain bridge write,
destructive-op-outside-workspace) plus the RAID-Log-close / stakeholder-facing rule.
Mode C **cites** that set; it does **not** re-author a competing list here or in
`operator.toml` (duplicate-source discipline — the same discipline the ambient-automation pre-read
warned against). The 4-name gloss in AC5 (governance / financial / security /
RAID-close) is the plain-language shorthand for that canonical set.

Before the create branch, Mode C classifies the implied item against the cited set:
if the implied change would target a governance file (CLAUDE.md / OPERATIONS.md /
RELEASE_PROTOCOL.md / any `SKILL.md` / a governance path), move money, alter an
access grant / share control / publication / auth, close a RAID risk or a
stakeholder-facing artifact, or hit any other class in the cited set — force the
`recommend` (surface-only) path and route the surfaced proposal for human sign-off.
(Governance-file writes are the one Tier-0 class the hook *would* catch when
enforcing; the rest — and Mode C's own `gh issue create` — rely on this skill-side
classifier, per the honest-safety read above.)

### Non-interactive self-repair (no operator present)

Mode C's validation failures cannot pause for a human, so:

1. Render the item (reused Mode-A render) → run the 5-test clarity gate +
   title-informativeness check (reused).
2. On a **fixable** failure (a vague AC, a non-informative title, a read-back
   mismatch): **re-author once** — tighten the failing field from the structured
   signal input, re-render, re-validate.
3. If it **still fails** (the signal is too thin to reach a well-formed typed item
   without a human): **downgrade to the observation tier** — render as
   `observation.yml` (what is missing / what good looks like / affected file — the
   exact triplet the caller supplied as the floor), emit under the same
   `automation_level` clamp, and record in the run output that it was filed as an
   observation placeholder for Triage to promote. **Never** emit a malformed typed
   item; **never** silently drop the signal. This mirrors the interactive
   observation-tier fallback (`references/output-contract.md` § Observation-tier
   fallback) — reused, not reinvented.

### Duplicate guard (reuse the existing all-altitude scan)

Before creating, Mode C runs the **same tracker-search dedup** the desk already
performs in the "Work item filed without consulting existing tracker state" FM below
(`gh issue list --search "<key terms>" --state open`), non-interactively: on a
plausible open match it **enriches** the existing item (a comment-ready block) or
**no-ops**, rather than create; only a no-match proceeds to the create branch. That
scan **pre-exists** in this file — Mode C consumes it; it does not build it. (The
same-file relationship with the sibling reconcile that touched a different FM in this file, is
**file-contention**, not a build dependency.)

## The type registry

The set of work-item types, their hierarchy, and their per-type/per-level
required fields are governed by `references/type-map.md`. That file maps each type
to its issue-template path, its altitude-emphasis, and its landing criteria; the
required field set, the dropdown options, and the default labels are **derived at
use time from each type's `.github/ISSUE_TEMPLATE/<type>.yml`** — the living source
of truth — never duplicated inline. The invariant tier's type set is `improvement`
/ `bug` / `observation`; when the scope resolves a methodology, the registry is
the kind set derived at use time per `references/type-map.md` § Kind-derivation
contract (the operator's own type-pack, else the selected methodology pack(s)
under `core/packs/`, else the Layer-2 map fallback), typed via `type:*` labels.
The landed type also selects the emission vehicle per the binding table in
`references/type-map.md` (§ Kind ↔ label ↔ level binding): a resolved kind with a
dedicated kind form emits there — the form itself stamps `type:<kind_id>` structurally —
else on the interim `improvement.yml` vehicle with the kind carried as its `type:*` label.
The desk does not elicit or emit ADRs: ADRs are an architecture act,
not conversational intake (the durable rationale and the component boundary are in
`references/type-map.md` and in the intake-front-door-architectural-boundary ADR;
see Reference files). The declarative work-item type system this registry couples
to has shipped (the type-pack meta-schema and the pack surface); the type registry
portion of `references/type-map.md` now derives from it at use time — the loop is
table-driven and reads whatever registry the config resolves.

## Output contract

See `references/output-contract.md`. The intake-emit process is tool-agnostic:
render the item against the target type's field set → run the 5-test clarity gate
→ confirm via AskUserQuestion → log the item to the configured work tracker → read
back and confirm it landed → report the item reference. The rendered title is an
informative summary per [`intake-style-guide.md`](../../../release/references/how-to/intake-style-guide.md) §7
(no type/category prefix — type is on the label; names the object + the change);
the clarity gate includes a title-informativeness check before the confirm. The skill NEVER writes a
tracked scratch file. The MVP target tracker is GitHub Issues, emitted via
`gh issue create` after the binary confirmation; because the issue templates are
GitHub Issue Forms with required dropdowns that a freeform-body create cannot
populate, the contract carries each required structured field via a label where one
exists or a labeled first body line (Severity, Category) where none exists, and
escalates to the observation tier when a required field cannot be represented. When
the tracker CLI is unavailable or the user declines auto-create, it returns a
copy/paste-ready body plus the exact create command, and says the item was not
auto-filed.

**Destination routing (the multi-destination read path).** When
`operator.toml` declares `[trackers.<id>]` destinations, the create path resolves
WHICH destination to file to before building the create command, in this order:
**(1)** an explicit operator selection for this filing; else **(2)** the active
project's `PROJECT.md` `work_tracker:` field (see
[`core/schemas/project-schema.md`](../../../core/schemas/project-schema.md)
`work_tracker`); else **(3)** the `default` tracker
(`[trackers].default_id`, or the single back-compat destination derived from
`[adapters].ticketing`). **Fail-closed (CD-1):** once ANY `[trackers.*]` is
declared, a private-scope project with an UNSET `work_tracker` MUST NOT fall
through to a `scope: public` destination — surface the ambiguity and require an
explicit destination selection (or route to a non-public safe default) rather
than silently filing private-origin work to a public tracker. When NO
`[trackers.*]` are declared at all, filing uses today's single-GitHub default
(zero operator action — back-compat). The scope-segregation guardrail
(`core/hooks/block-scope-segregation.sh`) is the filing-time enforcing backstop:
it refuses private/PII-marked content bound for a `scope: public` destination, so
a mis-routed private item is blocked at the tool call even if the routing above is
bypassed.

## Reference files

| File | Read when |
|---|---|
| `references/elicitation-loop.md` | Every Mode A invocation — the four-phase loop, the phase gates, the type-landing criteria, the altitude model, the re-routing rule, and the 5-test rule |
| `references/type-map.md` | Every invocation — the type registry, the field-derivation-from-`.yml` contract, and the altitude → type-emphasis table |
| `references/technique-library.md` | When choosing how to elicit — the BABOK technique cards and the domain-adaptive (domain × topic × altitude) selector |
| `references/output-contract.md` | At emit time — the tool-agnostic emit process, the AskUserQuestion confirm gate, the GitHub MVP mechanics, and the fallbacks |
| `references/intake-governance.md` | When an intake item is a fundable demand unit (project/initiative) needing a business-case tier, a WSJF estimate, or a triage SLA — the tiering partition, the WSJF formula, the tier→SLA table, the 6-type demand-source taxonomy, the intake rubber-stamp signal, and the Cost-of-Delay elicitation prompts |

## Guardrails (Platform)

Inherits the CLAUDE.md Universal Preferences and OPERATIONS.md. Notably: No
invention (label unknowns `[ASSUMPTION – CONFIRM]` with a proposed answer and an
owning stage); evidence-quality labels on factual claims; the human confirms the
logged item (the skill proposes). The platform "Max 5 clarifying questions"
guardrail applies here as **cadence discipline** — ask in small batches, prefer one
sharp question over three that circle, echo back what was captured — but it is NOT
the exit criterion: the clarity gate (the 5-test passing for the type/altitude) is
the stop condition. Project-scoped output discipline does not apply — this skill
emits to the work tracker, not to a project folder.

**External-seam writes** — a work-item record or knowledge page in a connected
system, and their comment streams — follow `core/disciplines/external-seam-conduct.md`:
the record holds state, a comment addresses a person. This binds Mode C most
directly, because an ambient auto-log whose destination is an external seam rather
than the platform's own work tracker lands the item in the record's fields, never
as a dated log comment.

## Reversibility Discipline

This skill produces decision-class outputs — the proposed work-item type, the
hierarchy placement, the rendered item body the user adopts, and the
intake-readiness verdict. Each carries a reversibility tier plus confidence per
the platform reversibility protocol. A logged item is CHEAP (close or delete it);
a type/placement recommendation is CHEAP (re-route before emit). State the tier on
the emit recommendation.

## Domain-Specific Failure Modes

Category tags below are spelled out on first use, per the failure-mode taxonomy:
**PROC** = Process/Workflow adherence · **OUT** = Output/Framing quality · **TRIG**
= Trigger/Scope · **HAND** = Handoff/Escalation · **INPUT** = Input/Evidence
handling.

### Over-elicitation past intake-ready — PROC

- **Signature (observable signal):** The desk keeps asking questions after the
  5-test already passes for the type and altitude — opening new "nice to have"
  lines, producing an over-defined item and a fatigued user.
- **Conditional:** do NOT continue eliciting when the 5-test (T1–T5) already passes
  for the current type and altitude, because the clarity gate — not a question count
  — is the exit, and detail beyond intake-ready at this altitude belongs to a later
  stage (slicing for initiatives, Solutioning for stories and tasks), so more
  questions add over-specification, not quality.
- **Root cause:** With the hard "Max 5 questions" cap removed as an exit criterion,
  the only stop is the clarity gate; thoroughness-signaling pressure tempts the
  agent to keep going past it and conflate "complete interview" with "intake-ready
  item."
- **Mitigation:** Treat the 5-test-for-this-altitude as the stop condition. Re-run
  it after each captured field; the moment it passes and remaining unknowns are
  downstream (deferred-with-marker or owned handoff items), advance to Confirm.
  Apply the altitude-relative over-definition rule (in `references/elicitation-loop.md`)
  to decide what is "beyond intake-ready." Offer ("anything else to add?") once,
  then emit.
- **Principal response vs. junior response:** Principal stops at the clarity gate
  and defers downstream detail with owned-assumption markers. Junior, freed of the
  question cap, interviews to exhaustion and ships an over-defined item that Triage
  flags for over-definition.

### First-classification lock-in (no re-route on reclassification) — PROC

- **Signature (observable signal):** The desk commits to the type it proposed at
  the type-landing gate and elicits that type's fields to the end, even as the
  user's answers reveal a different type — bug fields for what is actually a missing
  capability (improvement), or single-item fields for what is actually a container.
- **Conditional:** do NOT keep eliciting against the initially-identified type when
  the user's answers reclassify the item, because the type is provisional through
  Phase 3 and locking the first guess produces a well-formed item of the wrong type
  — the most expensive intake error to unwind downstream.
- **Root cause:** Sunk-cost / commitment bias — having announced a type and started
  its field set, switching feels like backtracking; the loop treats the type-landing
  proposal as final rather than provisional.
- **Mitigation:** Hold the type provisional through Phase 3. After each elicited
  field, re-check it against the type-landing criteria in `references/type-map.md`;
  if the evidence now fits a different type, re-route explicitly ("this reads less
  like a bug and more like a missing capability — switching to an improvement;
  here's why"), reset to that type's field set, and continue. The re-route IS the
  correct behavior, not a failure.
- **Principal response vs. junior response:** Principal holds the classification
  loosely, re-routes mid-elicitation with a one-line rationale, and emits the right
  type. Junior locks the first guess, completes the wrong type's fields, and emits a
  tidy-but-mistyped item that ppm-agent or Triage must re-classify.

### Auto-emit without the AskUserQuestion confirm / silent scratch-file write — OUT

- **Signature (observable signal):** The desk creates the work item (or, worse,
  writes a draft `.md` into the repo) without the explicit binary AskUserQuestion
  approval on the rendered body — the user discovers a filed item they never
  approved, or a tracked scratch file appears.
- **Conditional (interactive modes A/B):** do NOT emit a logged item (or write any
  tracked file) before the user returns an explicit binary approval via
  AskUserQuestion on the rendered body, because the interactive paths are Autonomy
  Tier 1 (assists and proposes; the human confirms) and the originating defect this
  skill exists to fix was exactly an unapproved scratch file committed for lack of a
  funnel — auto-emit reproduces the harm in a new shape. **The non-interactive path
  (Mode C) is the governed exception** — see the reconciliation carve below; it does
  NOT relax this gate for Modes A/B.
- **Root cause:** Completion pressure — a filed item feels like success; the confirm
  gate is a slow step the agent is tempted to skip, and without a hard "no emit
  before the binary approval" invariant it slips.
- **Mitigation (interactive modes A/B):** Enforce the output-contract gate: render →
  run 5-test → present the body and ask the binary AskUserQuestion ("File it as
  shown" / "Let me edit first") → only on "File it" run the create. The ONLY
  persistence paths are the post-approval logged item or the chat-returned copy/paste
  body; there is NO write path to a tracked repo file. If the tracker is unavailable,
  return the body and say it was not filed — never stage a scratch `.md`.
- **Mode-C reconciliation carve (the honest weakening).** Mode C (Ambient Auto-Log)
  must auto-create **without** the binary AskUserQuestion, so this invariant is
  *reconciled, not deleted*. The authorization for the ambient path is a **standing
  `automation_level` dial** (the operator's `bounded_auto`), further clamped by the
  Tier-0 never-auto floor and capped at `recommend` (surface-only) whenever the dial
  is not `bounded_auto`. **State this plainly: replacing the per-item human confirm
  with a standing dial is a genuine reduction of this invariant's guarantee** (a
  per-item approval becomes a standing class-authorization — a **per-item → standing**
  shift). Do NOT claim "no weakening." The reduction is *bounded* — auto-create is
  `bounded_auto`-only, a Tier-0-implied item never auto-files at any level, and the
  interactive default (Modes A/B) keeps its per-item confirm unchanged — **and it has
  no mechanical hook backstop**: the C5 enforcement hook (CLOSED) hard-blocks
  only payload-detectable Tier-0 (governance-file writes / cross-domain bridge
  paths), and Mode C's `gh issue create` is neither, so the Tier-0 floor here is a
  skill-level self-limit only. **The "no scratch-file write" half of this FM is
  preserved absolutely** — Mode C, exactly like Mode A, has NO write path to a
  tracked repo file; its only persistence paths remain the logged item or the
  surfaced copy/paste body (the `references/output-contract.md` emit invariant is
  untouched).
- **Principal response vs. junior response:** Principal presents the rendered item
  (Modes A/B) or lets the standing dial + Tier-0 floor authorize the create (Mode C),
  and never widens the ambient exception to the interactive paths; junior files
  immediately ("I've created the issue"), drops a `draft-issue.md` into the working
  tree, or reads `bounded_auto` as a blanket create-license that skips the Tier-0
  floor — and the user is left undoing an action they never authorized.

### Auto-decomposing a container into child items at intake — PROC

- **Signature (observable signal):** For a container idea (an initiative or
  epic-equivalent), the desk creates multiple work items (one per discovery /
  research / integration / development / testing slice) instead of one item at the
  container altitude with the breakdown noted in the body.
- **Conditional:** do NOT create more than one work item per intake request when the
  idea is a container, because decomposition and slicing happen at a later, dedicated
  stage with its own rules — auto-decomposing at intake is an unauthorized cascade
  that pre-empts slicing judgment and floods the tracker with under-elicited children.
- **Root cause:** Helpfulness over-reach — having surfaced the child structure,
  creating it feels like finishing the job; the agent conflates surfacing
  decomposition (intake's job) with performing it (slicing's job).
- **Mitigation:** Create exactly one item at the right altitude; render the candidate
  children as a decomposition callout in the body ("Candidate child work for later
  slicing: discovery, integration, testing — to be validated and sliced
  downstream") for later agents to act on; confirm the container framing with the
  user; never auto-create the children.
- **Principal response vs. junior response:** Principal captures one container item
  and notes the breakdown for slicing. Junior files the parent plus five thin
  children, none individually intake-ready, and pushes the cleanup to Triage.

### Emitting an incomplete typed item via a freeform-body create (structured-field drop) — OUT

- **Signature (observable signal):** The desk runs the tracker create with a
  freeform body and reports "filed a well-formed bug," but the item's required
  structured field (a GitHub Issue-Form Severity or Category dropdown today; a Jira
  required field tomorrow) is empty because a freeform-body create does not populate
  structured field-IDs — the body prose mentions the value but the structured field a
  Triage reader and the schema expect is blank.
- **Conditional:** do NOT treat a freeform-body create as populating the target
  tracker's structured fields when the target type defines required structured
  fields, because the create bypasses them and they silently drop, producing a
  structurally-incomplete item that still passes the 5-test (which checks body
  content, not structured fields).
- **Root cause:** Conflation of "item body" with "item structured fields" — the
  agent assumes "render against the type's field set" means the structured fields are
  populated, when the only structured carriers a freeform create can set are labels.
- **Mitigation:** Per `references/output-contract.md`, carry each required structured
  value via the tracker's structured channel where one exists (a label), or as a
  labeled first body line where none exists (`**Severity:** P2 — Material`); read
  back the created item and assert the carriage landed; when a required structured
  field cannot be faithfully represented, escalate to the observation tier rather
  than ship a malformed typed item.
- **Principal response vs. junior response:** Principal maps every structured field
  to a label or an agreed body convention, verifies on read-back, and falls back to
  observation when unrepresentable. Junior runs the create, sees a green "item
  created," and ships a bug with an empty Severity field Triage must re-field.

### Resolving an assumption at intake instead of emitting it as an owned downstream item — HAND

- **Signature (observable signal):** The desk encounters an unknown it cannot
  resolve from the user (an unconfirmed altitude, an unknown root cause, a missing
  dependency) and fabricates a confident answer or silently drops the unknown,
  instead of re-eliciting once and then emitting it as a labeled, stage-owned
  assumption carried in the body.
- **Conditional:** do NOT resolve or silently drop an unresolved assumption at intake
  when the user cannot confirm it after one re-elicitation, because intake's job is to
  capture and hand off unknowns as owned items for the right downstream stage
  (root-cause / research / dependency / design / architecture / slicing / estimation
  / resourcing / triage) — investigating-and-closing them is a separate downstream
  convention, and fabricating an answer plants a false premise the pipeline inherits.
- **Root cause:** Closure pressure — an item with open `[ASSUMPTION – CONFIRM]`
  markers feels unfinished, tempting the agent to guess; the agent misreads "capture
  full scope" as "resolve everything now."
- **Mitigation:** Re-elicit the unclear item once (per the define process); if still
  unresolved, render it as `[ASSUMPTION – CONFIRM] <assumption> — owner: <stage> —
  to close: <evidence/decision>` in the body, and for an unresolved altitude carry it
  as a triage-owned assumption. Never fabricate; never silently drop. Do not attempt
  to investigate-and-close — that is a downstream convention, out of this skill's
  scope. For an unknown root cause specifically, emit `owner: root-cause — to close:
  RCA per core/disciplines/root-cause-analysis.md` and stop; that method is invoked by
  the downstream processing surface (delivery-engine), not inside this interview.
- **Principal response vs. junior response:** Principal emits a clean, stage-owned
  assumption the right agent later closes. Junior either invents a plausible value
  (planting a false premise) or omits the unknown (losing it), forcing rework when
  the gap surfaces downstream.

### Work item filed without consulting existing tracker state — INPUT

- **Signature (observable signal):** The desk runs the full loop and files a new
  work item whose scope an existing open item already owns — the same defect,
  the same capability gap, or a subset of an open item's stated scope — including
  the highest-cost instance: a new **container** (an initiative / epic-equivalent)
  proposed when an approved owning initiative already exists — with no
  tracker-search evidence in the conversation and no existing-item candidates
  surfaced at the confirm gate.
- **Conditional:** do NOT log a new work item without consulting the work
  tracker for an existing owner of the same scope, because the tracker state is
  an input to correct placement just as the idea is — a duplicate splits one
  workstream across two homes, strands the new context away from the existing
  item's labels and history, and exits intake looking well-formed while making
  the backlog less true; and, for a **container**, splits an entire initiative's
  workstream across two homes — the costliest duplicate to unwind, because it
  strands not one item but a whole decomposition tree away from the existing
  owner's labels and history.
- **Root cause:** The loop's input is the user's idea, and the framing ("log
  this idea") implies novelty; the output contract consults tracker state only
  AFTER the create (the read-back step). Nothing in the four phases forces the
  pre-filing question "does this item already exist?" — so novelty is assumed,
  never derived — and for a container the assumption is costliest because it is
  only tested at the confirm gate, after the container's fields are already
 

…(truncated)