SOP
2. Accepting Tasks

2. Accepting Tasks

Product Managers are experts in user needs; Engineers are experts in system constraints. Accepting a task means the engineer takes ownership of translating the business requirement into a strict technical constraint file.

The Process

The PRD Gate

Receive a ticket containing a detailed Product Requirement Document (PRD) from the PM, outlining the User Journey and Acceptance Criteria.

Why: Clear business requirements prevent endless revisions.

State Verification & Pushback

Log into the live product and verify the current state. If the PRD misses an edge case, pause and push back.

Why: The engineer is the last line of defense against bad logic reaching production.

Creating the AI Spec

Once the PRD is approved, translate it into an updated AI-readable Product Spec file and commit it to the main repository.

Why: Agentic development only works if the AI has agreed-upon, strict architectural constraints. Prompting an AI without the updated spec will cause it to hallucinate and break our design patterns.

⚠️

Do not write a single line of implementation code until the AI Spec is reviewed and locked.

Example

💡

Chidi receives a PRD to add a "Hard Mode" to Muzingo. He notices the PRD doesn't explain what happens if two players hit "Muzingo!" at the exact same millisecond. Chidi pushes back to the PM to define the tie-breaker rule. Once defined, he updates the AI spec to instruct the coding agent on how to handle WebSocket state during simultaneous win triggers. He does not write code until the spec is locked.