playbooks

home / skills / velcrafting / codex-skills / intake-interview

intake-interview skill

/skills/meta/intake-interview

This skill helps you elicit, structure, and document a clear Intake Brief from high-level goals without proposing solutions.

npx playbooks add skill velcrafting/codex-skills --skill intake-interview

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.5 KB
---
name: intake-interview
description: Interview to extract intent, constraints, assumptions, and success criteria for a new system or major feature. Produces an Intake Brief (not a plan, not code).
metadata:
  short-description: Interview → intake brief
  mode: interview
  read-only: true
  idempotent: true
---

# Intake Interview

## Goal
Turn a messy, high-level goal into a crisp **Intake Brief** that surfaces assumptions and prevents silent drift.

This skill produces clarity, not implementation.

---

## Non-negotiables
- Operate in read-only mode. Do not modify files.
- Ask questions to eliminate high-impact ambiguity.
- Do not “smooth over” unknowns. Record them.
- Do not output a plan or propose an architecture. Output only the Intake Brief.

---

## Workflow

### 1) Minimal context scan (if in a repo)
- Skim: README, docs, AGENTS/ARCHITECTURE/ROADMAP/CALIBRATION if present.
- Check for `REPO_PROFILE.json`:
  - If present, treat it as authoritative for stack/tooling and do not re-ask those questions.
- Identify: constraints, current architecture shape, and any non-negotiables.

### 2) Interview (bounded)
Ask up to 10 questions maximum. Prefer multiple-choice. Ask only what materially affects design.

Question groups:
- Objective: what outcome, who uses it, what does success look like?
- Constraints: timeline, tech constraints, security/risk constraints, performance/reliability.
- Interfaces: inputs/outputs, integrations, APIs, data stores.
- Invariants: “must always hold true”, “must never happen”.
- Scope boundaries: what is explicitly out of scope.

Avoid tooling questions already answered by `REPO_PROFILE.json`.

### 3) Output Intake Brief (follow template exactly)

# Intake Brief

## Objective
<1–3 sentences>

## Users
- Primary:
- Secondary:
- Non-users:

## Success metrics
- <Metric 1>
- <Metric 2>

## Constraints
- Technical:
- Operational:
- Risk/safety:

## Functional requirements (v1)
- <Req 1>
- <Req 2>
- <Req 3>

## Non-functional requirements
- Performance:
- Reliability:
- Observability:

## Assumptions register
- A1: <assumption> | confidence: (low/med/high) | impact: (low/med/high)
- A2: <assumption> | confidence: (low/med/high) | impact: (low/med/high)

## Open questions
- Q1 (blocking/non-blocking):
- Q2 (blocking/non-blocking):

## Out of scope (v1)
- <Item 1>
- <Item 2>

## Recommended next step
- If repo scaffolding is missing: `$bootstrap-repo`
- If repo exists but profile/governance needs tailoring: `$personalize-repo`
- If requirements are crisp and execution is next: `$create-plan`

Overview

This skill conducts a focused intake interview to turn a vague goal into a concise Intake Brief that captures intent, constraints, assumptions, and success criteria. It produces clarity and a single-source brief—not a plan, not code—so teams avoid silent scope drift.

How this skill works

It performs a minimal context scan of available repo artifacts and a profile file (if present) to avoid redundant questions, then runs a bounded interview of up to 10 targeted questions. The interview prefers multiple-choice where possible, records unknowns without smoothing them over, and outputs a standardized Intake Brief using a fixed template.

When to use it

  • At project kickoff when requirements are still high-level.
  • Before drafting an implementation plan or architecture.
  • When stakeholders disagree about scope or success criteria.
  • When onboarding a new team to an existing initiative.
  • To capture constraints and invariants before procurement or vendor work.

Best practices

  • Run a minimal read-only scan of docs and a repo profile to avoid repeated tooling questions.
  • Limit the interview to questions that materially affect design; max 10 questions.
  • Prefer multiple-choice or constrained answers to reduce ambiguity and speed responses.
  • Explicitly capture assumptions and mark confidence and impact for each.
  • Flag any blocking open questions and label them clearly in the brief.

Example use cases

  • Converting a stakeholder mission statement into a concise intake for product managers.
  • Clarifying success metrics and non-functional constraints before hiring contractors.
  • Recording invariants and out-of-scope items prior to an architecture trade-off session.
  • Standardizing intake for multiple feature requests to prioritize backlog items.
  • Rapidly aligning cross-functional teams on acceptance criteria for a major feature.

FAQ

Will the skill modify repository files?

No. It operates strictly in read-only mode and will not change any files.

Does it produce an implementation plan or architecture?

No. The output is an Intake Brief only; it intentionally avoids plans or solution proposals.