PRD/PRD.md
Personal Assistant Platform — PRD
The Personal Assistant Platform is Arijit's agent-based personal operating system. It eliminates the operational overhead of scheduling, context-switching, and information retrieval so that high-judgment work gets more time and attention.
The platform is built as a series of independent Claude Code skills — each one an autonomous agent that can be invoked by name in any Claude Code session. A future Mission Control layer will allow agents to be chained and orchestrated.
1. Why This Exists
Arijit operates across multiple time zones (US East, Australia, Europe), manages a distributed team, and runs complex parallel workstreams. The operational overhead — finding meeting times, preparing for calls, tracking decisions, surfacing context — consumes meaningful time that should be spent on strategy and execution.
The hypothesis: a personal assistant that knows your calendar, your contacts, your preferences, and your work context can handle 80% of the operational overhead autonomously, leaving Arijit to confirm rather than orchestrate.
2. Modules
Module 1 — Meeting Scheduler
Status: ✅ MVP v1 shipped 2026-04-15
Skill: ~/.claude/skills/scheduler.md
Code: /Users/arijitchowdhury/AI-Development/Scheduler/
Finds mutual availability across time zones, presents ranked options with visual timelines, and books the meeting with the correct conferencing link and attendee list.
Module 2 — Morning Briefing Agent
Status: 🔲 Planned
Each morning: what's on the calendar, what needs prep, what decisions are pending, what happened yesterday that matters.
Module 3 — Memory Agent
Status: 🔲 Planned
Captures decisions, action items, and context from meetings and conversations. Makes them retrievable. Feeds downstream modules.
Module 4 — Mission Control Dashboard
Status: 🔲 Planned
A single view that ties all agents together — status, pending actions, recent decisions, upcoming meetings.
3. Design Principles
- Skills are the interface — every agent is a Claude Code skill, invokable by name in any session
- Calendar is the source of truth —
gwsCLI is the only gateway to Google Workspace; no raw API calls - Config drives behavior —
preferences.jsonandteam.jsonencode defaults so the agent doesn't ask the same question twice - No accept-your-own-meeting — the scheduler creates events as organizer; only invitees receive action-required notifications
- Conferencing is a first-class choice — Google Meet, Zoom, and Gong Engage are all valid; default is configurable
4. Open Requirements (v2)
| ID | Requirement | Priority | Status |
|---|---|---|---|
| REQ-01 | Conference provider selection at booking time (Zoom / Meet / Gong) | High | Phase 1 — next task |
| REQ-02 | Zoom personal meeting URL stored in preferences.json |
High | Phase 1 — next task |
| REQ-03 | Zoom API OAuth integration for one-time meeting links | Medium | Phase 2 — later |
| REQ-04 | gws people contacts scope re-auth for name→email resolution |
Medium | Backlog |
| REQ-05 | Preferred conferencing default in preferences.json |
High | Phase 1 — next task |
| REQ-06 | Gong Engage link (outbound/prospect only — not internal) | Low | Phase 1 — next task |
| REQ-07 | Multi-turn booking re-negotiation ("can we push to 4pm?") | Medium | Phase 2 |
| REQ-08 | Inbound scheduling — self-service booking link for others | Low | Phase 3 |
Decision log:
- 2026-04-15: nspady/google-calendar-mcp evaluated and deferred. gws CLI stays as-is. Gaps are in UX not plumbing.
- 2026-04-15: Gong clarified — it is Gong Engage (external meetings), not a conferencing provider for internal calls.
- 2026-04-15: Phase 1 = personal URL approach (no new APIs). Phase 2 = Zoom API OAuth for unique links.
5. Success Criteria
- Scheduler invocation to confirmed booking in under 2 minutes
- Zero "accept your own meeting" prompts for the organizer
- Correct conferencing link on every event (no fallback to Meet when Zoom is default)
- Time zone math is always correct — no missed calls due to TZ errors