Skip to content
d3 Wiki
01.01

Project intake and scoping

Turn "can we build a thing that…" into a scoped piece of work with a clear yes/no.

Updated
Oct 3, 2026
On this page

Purpose

Turn "can we build a thing that…" into a scoped piece of work with a clear yes/no.

The standard

  • Every tool request gets an intake issue in [TEAM: intake repo/board] using the template below. No intake issue, no work.

  • Scoping answers five questions: who uses it, what they do today, what changes, what "done" looks like, and what it must integrate with.

  • Requests are triaged weekly. Outcomes: build, prototype first, existing tool covers it, or no.

  • Anything estimated over [TEAM: e.g. 2 weeks] gets a written ADR (01.06) before code.

Procedure

  1. Requester opens an intake issue: problem, current workaround, users, deadline, related tools.

  2. Owner assigns a scoper within 2 working days.

  3. Scoper writes a one-page scope: goal, non-goals, users, inputs/outputs, dependencies, rough size (S/M/L), risks.

  4. Triage meeting decides the outcome and priority; decision recorded on the issue.

  5. If build: create the repo from a template (02.02), link it back to the intake issue.

Anti-patterns

Building a tool for one person's one-time task; scoping by feature list instead of by user outcome.

Owner: [TEAM] · Last reviewed: 2026-09