# Request Intake

> Captures a new request as a registered Work Packet with a unique, never-reused Work ID, so it is never tracked informally (docs/PROCESS_CONTRACT.md, stage REQUIREMENT_INTAKE).

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

---


# Request Intake

This Skill covers Stage 1 of the workflow, `REQUIREMENT_INTAKE`
(docs/PROCESS_CONTRACT.md §5). It is deliberately the smallest possible
step: get the request into the system as a real, traceable Work Packet
before anything else can happen to it.

## Why this exists

Per `docs/WORK_PACKET_MODEL.md` §3, a change with no discoverable Work ID
is not traceable. This Skill is what makes a Work ID exist in the first
place, and it is the only Skill in this pack with no MCP capability at
all — there is nothing to read or write yet beyond the intake record
itself.

## Rejection path

An incomplete submission is returned to the Requester
(`status=incomplete`); a duplicate is merged into the existing Work
Packet rather than creating a new one (docs/PROCESS_CONTRACT.md, stage
`REQUIREMENT_INTAKE`, "Rejection path").

## Relationship to the `triage` Skill

Classifying the request (type, rough size, initial risk) is handled by
the companion `triage` Skill, which also triggers at this same stage —
the current fourteen-stage workflow does not have a separate Triage
stage of its own (see `triage`'s own SKILL.md for the full explanation of
that mapping).

