intake
Intake
The mandatory entry point for all work. No downstream execution without an approved intake decision.
Context
Intake is the control plane for all engineering work in Prodcraft. Every piece of work — feature, bug fix, refactoring, migration, or research — enters the lifecycle through intake. Its job is to classify the work type, route to the correct lifecycle phase and methodology, and produce the intake-brief that anchors every downstream skill. It is triage, not a design session.
Inputs
- user-request -- the raw description of the work to be done
- existing-context -- project documentation, recent commits, open issues (read silently before asking questions)
Outputs
- intake-brief -- structured routing record: request summary,
source_language,artifact_record_language,user_presentation_locale, intake mode, work type, entry phase, workflow metadata (workflow_primarywhen governance is explicit,workflow_overlayswhen an overlay is active), next skill, routing rationale, key risks - phase-recommendation -- the lifecycle phase where work should begin
- workflow-recommendation -- the methodology best suited to the work
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6ci-cd
Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6requirements-engineering
Use when the work is still at the \u201Cwhat should we build\u201D stage and approved discovery inputs or entry-stack outputs must become prioritized requirements and scope boundaries before specification, architecture, planning, or coding. Not for acceptance criteria, spec review, or implementation.
6