SOP-DEV-feature-request-intake-v1.0¶
1. Purpose¶
Define how feature requests enter the development queue, get prioritized, get assigned, and get tracked through to dispatch. Ensures no feature is worked on without a written brief, a Monday.com item, and an owner.
Scope: Any new capability, improvement, or enhancement requested for platform, integrations, agent tooling, dashboards, or site. Bug fixes use SOP-DEV-bug-triage (when authored). Pure content changes route to CMO.
2. Request Sources and Intake Points¶
| Source | How it arrives | Who routes it |
|---|---|---|
| CEO (Rick) | Direct Slack message, session dispatch, or /Claude/inbox/inbox.md |
chief.staff routes to CDO |
| Executive agents | Session-dir drop to CDO or code.platform dir | CDO reviews at session start |
| Agent workflow gap | Agent files a feature request in their status report | project.manager or CDO picks up at Monday.com audit |
| QA finding (qa.testing, qa.visuals) | Defect report or feature request in QA Report | qa.testing routes to CDO per SOP-DEV-qa-signoff |
| Eva dispatch (via iOS recovery or session relay) | Session-dir drop to CDO or code.platform | CDO reviews at session start |
All requests land in one of two places before being worked: CDO session dir or Monday.com backlog. CDO triages all incoming to Monday.com within 24 hours.
3. Intake Triage (CDO)¶
CDO evaluates each incoming request on:
| Factor | Question |
|---|---|
| Priority | Is this blocking an active workflow or Q2 goal? (P1) / Important but not blocking? (P2) / Nice to have? (P3) |
| Scope | Single session or multi-session? Cross-functional or code.platform only? |
| Mission candidate | Does it pass ≥2 of 5 Section 10A.2 triggers? If yes, classify as Mission and hand to project.manager |
| Agent assignment | Which CDO team agent is responsible? (code.platform, qa.testing, qa.visuals, etc.) |
| Dependencies | Does it need design input (qa.visuals), data (qa.dataquality), or external integration (code.platform)? |
CDO classification output: within 24 hours of intake, every request gets a Monday.com item with Status, Priority, Owner, and a one-line description.
4. Intake Procedure¶
Step 1 — Monday.com item creation¶
CDO or assigned agent creates the Monday.com item:
- Board: Tasks
- Name:
[FEAT] {concise description}(prefix distinguishes from bugs[BUG]and ops tasks) - Owner: assigned CDO team agent
- Priority: P1 / P2 / P3
- Status: Backlog → Working on it when picked up
Step 2 — Task Brief¶
Assigned agent authors a Task Brief (CLAUDE.md Section 6A) before starting work:
TASK BRIEF
──────────────────────────────
Objective: {what this feature will do and why}
Owner: {agent}
Requestor: {CEO / agent / workflow gap}
Dependencies: {APIs, data sources, upstream agents}
Constraints: {time, tooling, approval gates}
Done Criteria: {specific, testable — not "it works"}
Deadline: {or TBD}
Escalation Owner: CDO
For P1 features: Task Brief authored before starting work (mandatory). For P2/P3: Task Brief may be authored at session start alongside implementation.
Step 3 — Clarifying questions (if scope is unclear)¶
Per the "ask before assuming" principle in agent contracts: if the requested feature's scope, acceptance criteria, or technical approach is unclear, the assigned agent asks clarifying questions before starting — not after building the wrong thing.
For features originating from CEO directly: agent asks in the same session or Slack thread where the request arrived. For features arriving via session-dir drop: agent files a question note back to the requestor's session dir + posts to #agent-handoffs.
CDO is the escalation point if the requestor is unavailable and the feature is P1.
Step 4 — Security review gate (for features with external exposure)¶
If the feature involves a new external API, webhook, new data write path, or new agent tool capability: security.ops security review is mandatory per SOP-OPS-security-review-v1.0 before implementation begins.
CDO gates the feature at intake if a security review is required.
Step 5 — Dispatch to agent¶
CDO dispatches to the implementing agent via session-dir drop + #agent-handoffs notification, attaching the completed Task Brief.
For features requiring design input: CDO dispatches to qa.visuals first for design review (3-4 options per the "present options don't assume" principle) before implementation begins.
5. Prioritization Principles¶
| Condition | Priority |
|---|---|
| Blocking a Q2 revenue goal or active Mission | P1 — this week |
| Blocking another agent's active workflow | P1 — this week |
| Improves agent efficiency without blocking anything | P2 — next available sprint |
| Quality-of-life, cosmetic, nice-to-have | P3 — backlog |
| Requested but not tied to any current goal | Backlog — revisit at quarterly review |
CDO holds P3 backlog items for Rick's review at the weekly CDO check-in. Rick may elevate or defer.
6. Feature Close Criteria¶
A feature is closeable when:
- Done Criteria met — every criterion in the Task Brief passes
- QA Report filed per SOP-DEV-qa-signoff-v1.0 — Confidence MEDIUM or HIGH
- Monday.com item closed with completion note
- Relevant documentation updated (agent contract if capability changed, SOP if workflow changed, INDEX.md if a new SOP was produced)
Features cannot close with outstanding QA failures or Confidence = LOW without CDO override.
Change Log¶
| Version | Date | Change |
|---|---|---|
| v1.0 | 2026-04-21 | Initial draft — sop.manager. Establishes feature request intake procedure for CDO team. |
Owner: cdo (Dave) Executive sponsor: cdo Drafted by: sop.manager Status: Draft — pending CDO review + approval Version: v1.0