Inbox Agent — Charter Project Planning Prompt
I am ready to begin implementation planning for the PlatypusMail project.
I have completed the product requirements and architecture documentation. Treat the complete Inbox Agent documentation set provided to you as the authoritative source of truth for project scope, requirements, architecture, data model, implementation constraints, and acceptance criteria.
Your job is now to turn that documentation into a complete, dependency-aware implementation plan in Jira.
Your Role
Act as the project planning and delivery architect for Inbox Agent.
You are responsible for:
- analyzing the complete documentation set;
- identifying implementation work;
- determining dependencies and sequencing;
- decomposing the work into appropriate Jira hierarchy;
- creating clear, implementation-ready Jira items;
- defining acceptance criteria;
- identifying technical prerequisites and cross-cutting work;
- ensuring every requirement is accounted for;
- maintaining traceability between Jira work and the source documentation.
Do not redesign the application unless you discover a genuine contradiction or missing decision that prevents implementation.
Do not invent functionality simply to make the plan more comprehensive.
1. Read the Documentation Before Planning
Before creating Jira work, read the entire Inbox Agent documentation set.
Do not begin ticket creation after reading only one or two documents.
Build an internal understanding of:
- product objectives;
- functional requirements;
- user workflows;
- architecture;
- integrations;
- security/privacy requirements;
- canonical data model;
- synchronization model;
- AI processing architecture;
- non-functional requirements;
- MVP boundaries;
- future product direction.
Use the README as the guide for interpreting the documentation set.
2. Critical Data Model Rule
The following correction is authoritative and supersedes any older conflicting language:
MailMessage and MessageInstance are separate entities.
MailMessage
Represents the logical/content-level email message.
Examples of MailMessage-owned information include:
- subject;
- body/content;
- core headers;
- participants;
- logical attachments;
- content-level AI classification and extraction.
MessageInstance
Represents a provider/account/mailbox-specific occurrence of a MailMessage.
Examples of MessageInstance-owned information include:
- connected account;
- provider message ID;
- provider thread/conversation ID;
- read/unread state;
- flagged/starred state;
- folder/label membership;
- trash/spam/archive state;
- provider version/change metadata;
- synchronization state.
The relationship is:
MailMessage 1:N MessageInstance
If an older document or assumption conflicts with this model, the updated Canonical Data Model wins.
Make sure the Jira implementation plan consistently reflects this distinction.
3. MVP Boundary
Plan the project toward the documented Inbox Agent MVP.
Do not expand the MVP into a full custom email client.
The MVP should prove that Inbox Agent can:
- connect to supported mail;
- reliably synchronize mail into the canonical model;
- reconcile provider and canonical state;
- intelligently classify and extract information from mail;
- surface actionable inbox intelligence;
- allow appropriate human review/correction;
- perform explicitly supported safe mailbox-state write-back;
- operate reliably, securely, and observably.
Future ideas such as a custom mail client, native iOS application, full contact consolidation, or calendar functionality must remain outside the MVP unless specifically required by the documentation.
4. Planning Structure
Create a coherent Jira project hierarchy rather than a flat backlog.
Use the Jira hierarchy available in the project and organize work into logical implementation areas.
At minimum, the plan should account for:
- Project/application foundation
- Canonical domain model and database
- Authentication and connected mail accounts
- Provider adapter architecture
- Initial synchronization
- Incremental synchronization and provider events
- Durable event processing and background jobs
- Retry, failure handling, and dead-letter processing
- Reconciliation and synchronization recovery
- Thread/message canonicalization
- Attachment handling
- AI classification
- AI structured extraction
- AI inference persistence and provenance
- AI evaluation/golden-set framework
- Inbox intelligence/triage experience
- Human correction/override workflows
- Safe provider write-back
- Security and privacy controls
- Observability and operational health
- Testing and regression infrastructure
- Backup/recovery
- MVP integration and hardening
- MVP release readiness
These are planning domains, not mandatory Jira epic names. Organize them in the way that produces the clearest implementation plan.
5. Dependency-Aware Sequencing
The plan must reflect actual technical dependencies.
The expected high-level dependency flow is approximately:
Canonical domain/schema
→ provider authentication/adapter
→ initial and incremental synchronization
→ event processing/retry/reconciliation
→ AI enrichment/evaluation
→ triage experience and safe write-back
→ integration/hardening
→ MVP release
Cross-cutting work such as:
- security;
- privacy;
- observability;
- automated testing;
- database migrations;
- CI/CD;
- documentation;
must be incorporated throughout the implementation rather than deferred until the end.
Identify blocking relationships explicitly in Jira where supported.
6. Jira Item Quality
Each implementation item should contain enough information that a development agent can execute it without needing to reinterpret the entire product.
Include, where applicable:
- objective;
- implementation context;
- functional requirements;
- technical requirements;
- affected canonical entities;
- relevant APIs/contracts;
- synchronization implications;
- AI implications;
- security/privacy considerations;
- failure/retry behavior;
- observability requirements;
- acceptance criteria;
- testing expectations;
- dependencies;
- source-document references.
Avoid vague tickets such as:
Implement synchronization.
Break substantial work into independently understandable and testable units.
At the same time, do not create hundreds of microscopic tickets for trivial implementation details.
Tickets should represent meaningful units of engineering work.
7. Traceability
Every significant documented requirement must be represented somewhere in the implementation plan.
Maintain traceability from Jira back to the governing documentation.
Where practical, include a section such as:
Source Specifications
with references to the relevant document and section.
This is particularly important for:
- canonical data ownership;
- synchronization behavior;
- reconciliation;
- AI inference behavior;
- security/privacy;
- non-functional requirements;
- MVP boundaries.
8. Architecture Guardrails
Do not violate the documented architecture for implementation convenience.
In particular:
- provider SDK objects stop at the provider-adapter boundary;
- provider IDs are not canonical primary keys;
- synchronization must be idempotent and replay-safe;
- provider notifications are hints, not the authoritative event log;
- synchronization must tolerate duplicate and out-of-order events;
- reconciliation is a required correctness mechanism;
- AI processing failure must not prevent mail synchronization;
- AI output must be schema validated and versioned;
- AI output does not directly authorize external side effects;
- email content must be treated as untrusted input;
- provider mutations must converge through synchronization;
- core business concepts should be modeled explicitly rather than hidden in JSON;
- historical/provenance information must be preserved where specified.
9. Testing Must Be Planned With the Work
Do not create a single generic QA phase that assumes testing happens after development.
Implementation tickets should contain their own testing expectations.
The overall plan must explicitly cover:
- unit testing;
- database integration testing;
- provider adapter testing;
- synchronization replay/idempotency testing;
- duplicate event testing;
- out-of-order event testing;
- cursor recovery;
- reconciliation testing;
- provider write-back convergence;
- AI structured-output validation;
- AI golden-set regression testing;
- privacy/logging validation;
- end-to-end MVP testing.
A final regression/release-validation stage should still exist.
10. Do Not Implement Yet
For this step, your responsibility is project planning and Jira construction.
Do not begin writing application code.
First:
- analyze the documentation;
- construct the project structure;
- build the implementation backlog;
- establish dependencies;
- establish sequencing;
- verify requirements coverage;
- identify unresolved blocking decisions.
If you discover a decision that genuinely prevents planning, flag it clearly rather than silently choosing an architecture.
Non-blocking implementation details may be captured as decisions to resolve during the appropriate engineering item.
11. Final Planning Validation
After constructing the Jira plan, perform a second pass against the documentation.
Verify:
- all MVP capabilities are represented;
- no major documented requirement has been omitted;
- no future feature has accidentally entered MVP;
- MailMessage vs MessageInstance is modeled correctly throughout;
- dependencies are logical;
- reconciliation is planned;
- AI evaluation is planned;
- security/privacy are incorporated;
- NFRs have implementation/testing coverage;
- MVP release criteria map to actual work;
- tickets are sufficiently detailed for Cursor/engineering agents.
Correct gaps you find during this review.
12. Deliverable
The result should be a complete Jira implementation plan for Inbox Agent that Cursor and development agents can execute against.
The documentation remains the requirements and architecture source of truth.
Jira becomes the source of truth for planned and active implementation work.
Do not replace the documentation with ticket descriptions, and do not allow implementation assumptions in Jira to silently override documented architecture or requirements.