shipshitdev/feature-intake

Feature Intake

Turn a rough client, sales, founder, or stakeholder requirement into a durable tracker artifact that agents can plan and implement without re-eliciting the same context. Prefer one parent PRD issue plus focused sub-issues over a single vague ticket.

Contract

Inputs:

• Feature idea, client requirement, sales request, or stakeholder note
• Target repository and optional GitHub Project owner/number
• Optional priority, labels, assignee, parent epic, or scope constraints

Outputs:

• Draft parent PRD issue body
• Draft sub-issue bodies for the implementation slices
• Duplicate/nearby-work findings
• Created issue URLs and project-board placement after approval

Creates/Modifies:

• Creates GitHub issues and sub-issues only after draft approval
• Adds approved issues to a GitHub Projects board when a board is configured
• Does not create sidecar PRD files unless the user explicitly asks

External Side Effects:

• Reads GitHub repository, issue, and project-board state
• Writes GitHub issues, sub-issue links, project items, and project fields only after approval

Confirmation Required:

• Before creating or editing GitHub issues
• Before adding items to a project board or changing project fields
• Before updating an existing duplicate instead of creating a new epic

Delegates To:

• writing-prds for PRD structure and quality gates
• task-prd-creator for issue and sub-issue creation mechanics
• gh-project-board when the target board needs inspection or normalization
• prd-quality-gate before marking the intake ready for planning

Core Behavior

Create a small issue tree:

1. Parent epic issue: the PRD, written for product and planning readers.
2. Sub-issues: one issue per meaningful implementation slice.
3. Project-board placement: parent and sub-issues added to the target kanban with native status/priority fields instead of body metadata.

Use sub-issues to prevent dropped work. A full-stack feature normally needs at least:

• [backend] for API, data model, business logic, jobs, integrations, auth, or persistence.
• [frontend] for screens, state, routing, copy, forms, or user-visible flows.
• [e2e] for cross-layer wiring, contracts, and the test that proves the flow works end to end.

Allow a layer to be N/A only with a one-line reason in the parent PRD's Layer Coverage section. If both backend and frontend are in scope, include an e2e sub-issue.

Intake Workflow

1. Confirm Repository And Board

Verify the target repository and GitHub auth before drafting:

gh auth status
gh repo view --json nameWithOwner,defaultBranchRef --jq '{repo:.nameWithOwner, default:.defaultBranchRef.name}'
git status --short --branch

If a GitHub Project target is known, inspect live project fields before assuming status or priority option names:

gh project view <project-number> --owner <owner> --format json
gh project field-list <project-number> --owner <owner> --format json
gh project item-list <project-number> --owner <owner> --limit 100 --format json

Use the repository's native board vocabulary. If the board is missing expected Status or Priority fields, run gh-project-board before writing items.

2. Check Current Work State

Read the branch and dirty state so intake does not trample active work:

git status --short --branch
git branch --show-current

For read-only intake, dirty state is acceptable if reported. For workflows that require switching or pulling a branch, require a clean tree first. Never stash, reset, merge, rebase, or switch branches just to write intake unless the user explicitly asked for that repository workflow.

3. Search For Duplicates And Nearby Work

Search issues and the project board before drafting:

gh issue list --state all --limit 50 --search "<keywords>" --json number,title,state,labels,url,projectItems

Also search local planning and memory docs when available:

rg -n "<keywords>" .agents README.md docs 2>/dev/null

If a strong duplicate exists, recommend updating that issue. If nearby work exists but the request is distinct, reference it in Dependencies or Risks & Open Questions.

4. Gather Context

Prefer existing context over stakeholder interrogation:

• Read relevant .agents/memory/, product docs, roadmap docs, and recent issues.
• Search code for three related examples when the request implies a concrete product surface or integration.
• Translate technical context into business language for non-technical stakeholders.

Ask questions only when the PRD would otherwise invent important facts. Ask no more than three focused questions at a time, and avoid implementation questions.

Cover these details:

• Primary user, buyer, or operator
• Workflow or moment where the problem appears
• Business outcome or customer promise
• Required version-one behavior
• Explicit non-goals and out-of-scope boundaries
• Priority and urgency
• Dependencies or related architecture
• Success signal and verification path

If context is clear enough, draft with an explicit inference note:

I have enough context to draft this. I inferred the user, outcome, and initial
priority from existing repo context. I will keep uncertain assumptions in
Risks & Open Questions for confirmation.

5. Classify Layers

Decide which slices are in scope before writing sub-issues:

| Layer | Mark IN when | Mark N/A when | | --- | --- | --- | | backend | APIs, data, jobs, auth, integrations, persistence, business rules change | Pure copy/static UI change | | frontend | Any user-visible screen, form, state, route, or interaction changes | Internal job or backend-only operation | | e2e | Frontend and backend must work together, or a critical workflow needs proof | Single-layer change with no integration path | | docs/ops | Runbooks, migration notes, launch steps, support workflow, or monitoring are required | No operational handoff needed |

Default product features to backend + frontend + e2e unless the requirement is clearly narrower. Keep sub-issues small enough for one focused PR.

6. Draft The Parent PRD

Use the issue body as the PRD. Do not add YAML frontmatter to issue bodies.

# PRD: <kebab-case-name>

## Executive Summary
<2-4 sentences: what this is, why now, and who benefits.>

## Problem Statement
<Concrete pain, missing capability, or customer promise. Name the user/workflow.>

## Goals
- <Measurable or verifiable goal>

## Non-Goals
- <Explicitly excluded scope>

## User Stories
- As a <role>, I want <capability> so that <outcome>.
  **Acceptance:**
  - <Concrete check>

## Functional Requirements
1. <Verifiable behavior, not implementation detail>

## Non-Functional Requirements
- <Only performance, accessibility, security, observability, or reliability requirements that matter>

## Success Criteria
- <Pass/fail assertion>

## Acceptance Criteria
- [ ] <Human-checkable completion condition>
- [ ] <Edge case or failure state is handled>

## Out of Scope
- <Boundary agents must not cross>

## Dependencies
- <Issue numbers, docs, services, packages, feature flags, or `None`>

## Layer Coverage
- **backend:** IN - sub-issue #<filled after creation> | or `N/A - <reason>`
- **frontend:** IN - sub-issue #<filled after creation> | or `N/A - <reason>`
- **e2e:** IN - sub-issue #<filled after creation> | or `N/A - <reason>`
- **docs/ops:** IN - sub-issue #<filled after creation> | or `N/A - <reason>`

## Sub-Issues
- [ ] `[backend]` <title> - #<n>
- [ ] `[frontend]` <title> - #<n>
- [ ] `[e2e]` <title> - #<n>

## Verification Plan
- tests: <test suites or files that must exist/pass>
- manual: <manual QA steps or stakeholder demo checks>

## Risks & Open Questions
- <Unresolved assumption or risk>

7. Draft Sub-Issues

Each sub-issue should include:

• Parent epic link
• Scope for that slice only
• Acceptance criteria
• Tests or verification for that slice
• Out-of-scope notes to prevent overlap with sibling issues

Use titles like:

• [backend] Add saved search automation API
• [frontend] Add saved search controls
• [e2e] Verify saved search workflow

8. Quality Gate Before Creation

Do not create issues until the draft passes these checks:

• Primary user and workflow are named.
• Business outcome is explicit.
• Version-one behavior is clear.
• Out-of-scope boundaries exist.
• Priority is selected or defaulted with a reason.
• Dependencies are named or set to None.
• Success criteria and acceptance criteria are pass/fail.
• Every IN layer has a sub-issue.
• Every N/A layer has a reason.
• Open questions are visible in Risks & Open Questions.
• Duplicate search results have been considered.

Show the parent and sub-issue draft. Wait for approval before writing to GitHub.

9. Create And Place Issues

After approval, create the parent first, then sub-issues:

gh issue create --title "<short imperative title>" --body-file /tmp/parent-prd.md --label "feature"
gh issue create --title "[backend] <title>" --body-file /tmp/backend.md --label "feature"

Link sub-issues using the repository's supported GitHub sub-issue API or tracker convention. If native sub-issues are unavailable, link children in the parent body and each child body.

Add approved items to the configured project board and set native fields:

gh project item-add <project-number> --owner <owner> --url <issue-url>

Use live field IDs from gh project field-list and item IDs from gh project item-list; do not hard-code project field IDs.

10. Report Outcome

Return:

• Parent epic URL
• Sub-issue URLs grouped by layer
• Project board and status/priority set
• Any skipped layer reasons
• Any open questions still needing stakeholder confirmation

Rules

• Preserve the stakeholder's language where it captures customer pain, but convert vague asks into verifiable product requirements.
• Keep issue bodies readable by sales, product, engineering, and agents.
• Do not write implementation plans into the PRD. Put implementation constraints only where they are true product or system requirements.
• Do not create GitHub issues, project items, or project field edits without approval.
• Prefer updating a true duplicate over creating parallel epics.
• Keep the tracker issue as the source of truth; avoid sidecar PRD files unless the repo explicitly uses them.