Task Creation Standards (CQ)¶
Owner: Vi | Updated: 2026-02-05
Purpose¶
Every task must have a deadline. No exceptions. This SOP defines what information is required before a task can be assigned to a developer.
The problem this solves: - Tasks without deadlines drift forever - No urgency = no accountability - Devs don't know what "done" means
Required Fields¶
Every ClickUp task MUST have these fields before assignment:
| Field | Required | Description |
|---|---|---|
| Title | Yes | Clear, action-oriented (e.g., "Build email sequence editor") |
| Deadline | Yes | Specific date. No "ASAP" or "when possible" |
| Phase | Yes | Alpha / Beta / Final (or Bug / Hotfix) |
| Assignee | Yes | Single owner (one dev) |
| Priority | Yes | Critical / High / Medium / Low |
| Description | Yes | What problem this solves, acceptance criteria |
| Reference | Recommended | Link to Figma, competitor, or example |
The Deadline Rule¶
Every task gets a deadline. Period.
| Phase | Default Deadline |
|---|---|
| Alpha | 3 days from assignment |
| Beta | Scope-dependent, as short as possible (challenge the dev) |
| Final | Discussed at Beta review |
| Bug (Critical) | Same day |
| Bug (High) | 24 hours |
| Bug (Medium) | This week |
| Bug (Low) | This sprint |
Beta deadlines: Don't default to "2 weeks." Beta should be as short as the scope allows. Push devs to commit to aggressive but achievable timelines.
If you can't estimate: - Break the task down smaller - Ask for clarification - Default to 3 days for Alpha work
Deadline is not optional. A task without a deadline is not a real task.
Task Title Format¶
Format: [Phase] Action + Object
Good titles:
- [Alpha] Build task management system
- [Beta] Add email tracking to outreach feature
- [Bug] Fix login redirect on mobile
- [Hotfix] Database connection timeout
Bad titles:
- Work on feature (what feature?)
- Fix stuff (what stuff?)
- As discussed (no context)
- Updates (meaningless)
Description Template¶
## Problem
[What problem does this solve? Why does the user need this?]
## Solution
[What are we building? High-level approach]
## Acceptance Criteria
- [ ] User can do X
- [ ] System handles Y
- [ ] Works on mobile/desktop
## References
- Figma: [link]
- Competitor example: [link]
- Related task: [link]
## Notes
[Any constraints, dependencies, or context]
Priority Definitions¶
| Priority | Meaning | Response |
|---|---|---|
| Critical | Production down, users blocked | Drop everything |
| High | Major functionality broken or key deadline | Today |
| Medium | Important but not urgent | This week |
| Low | Nice to have, backlog | This sprint |
Who sets priority: - Critical/High: Vi, Ryan, or Erik - Medium/Low: Vi or Dev
Who Creates Tasks¶
| Source | Who Creates Task | Who Sets Deadline |
|---|---|---|
| Erik/Ryan request | Vi | Vi (confirm with requester if unclear) |
| Bug report | QA or Dev who found it | Vi |
| Dev identifies improvement | Dev | Vi reviews and confirms |
| Client feedback | Vi | Vi |
Rule: Vi owns the backlog. All tasks flow through Vi for prioritization.
Before Assigning to Dev¶
Vi's checklist before assignment:
- Task has clear title
- Task has deadline
- Task has phase (Alpha/Beta/Final/Bug)
- Task has priority
- Task has description with problem statement
- Task has acceptance criteria
- Reference links added (if applicable)
- Dependencies identified
- Assigned to single dev
If any checkbox is missing: Don't assign. Complete the task first.
Dev's Response to Assignment¶
When assigned a task, dev should acknowledge immediately (or within 2 hours of next workday if assigned after hours):
- Read the full task (description, criteria, references)
- Confirm deadline is achievable - If not, reply immediately
- Ask clarifying questions - Don't start work with assumptions
- Acknowledge - Comment "Got it, starting on this"
If deadline is not achievable:
@Vi This deadline won't work because [reason].
I can deliver by [alternative date] instead.
OR we can reduce scope to [smaller version] for the original date.
Red Flags (Don't Accept)¶
Devs should push back on tasks that:
| Red Flag | Response |
|---|---|
| No deadline | "What's the deadline for this?" |
| Unclear scope | "Can you clarify what 'done' looks like?" |
| No acceptance criteria | "What should I test against?" |
| Multiple owners | "Who is the single owner?" |
| "ASAP" as deadline | "What's the actual date?" |
It's OK to ask questions. It's NOT OK to start work without clarity.
Task Lifecycle¶
Created → Assigned → In Progress → Review → Done
↓ ↓ ↓ ↓
[Vi] [Dev] [Dev] [QA/Vi]
Status updates: - Dev moves task to "In Progress" when starting - Dev moves task to "Review" when ready for QA - QA/Vi moves task to "Done" when accepted
Integration with Other SOPs¶
| SOP | Connection |
|---|---|
| Alpha-Beta-Final | Phase field determines workflow |
| Daily Dev Update | Report progress on assigned tasks |
| Blocked Protocol | Use when task is blocked |
| Missed Deadline | What happens if deadline slips |
FAQ¶
Q: What if Erik asks for something verbally? A: Vi creates the task in ClickUp. Nothing starts without a task.
Q: Can I work on something not in ClickUp? A: No. If it's worth doing, it's worth tracking.
Q: What if the deadline is unrealistic? A: Speak up immediately. Propose alternative. Don't silently miss it.
Q: Can tasks have multiple assignees? A: No. One owner. Others can be collaborators, but one person is accountable.
Q: What's the difference between deadline and estimate? A: Deadline = when it's due. Estimate = how long you think it takes. We track deadlines.
Summary¶
| Rule | Why |
|---|---|
| Every task has a deadline | No deadline = no urgency |
| Every task has one owner | Shared ownership = no ownership |
| Every task has clear criteria | Unclear scope = endless rework |
| Devs confirm within 4 hours | Silent acceptance = silent failure |
| Push back on unclear tasks | Better to ask than build wrong |
No task without a deadline. No exceptions.