Personalized Dashboard PRD
Project: Personalized Dashboard (My Work)
Client: Internal — Brainforge Platform
Version: 1.0
Date: 2026-02-23
Author: Brainforge Product Team
Status: Draft
TL;DR
A personalized dashboard inside the Brainforge platform that aggregates each person’s Linear issues, standup-derived todos, and (optionally) client weekly goals into a single “my work today” view. It does not replace Linear or Slack; it supplements them so anyone can answer “what do I need to do today?” in one place and reduce context switching.
1. Summary
This PRD defines the requirements for a personalized dashboard (also referred to as “My Work”) within the Brainforge platform. The dashboard consolidates work items from multiple sources—Linear (assigned issues), standup summaries (todos and completions derived from Zoom and Slack), and optionally client weekly goals and deliverables—into one person-centric, day-oriented view.
Today, work is scattered: Linear holds tickets (team- and project-centric), Slack holds ad-hoc commitments, standups capture verbal commitments, and client goals live in client-summary and standup notes. No single view answers “What do I need to do today?” The dashboard is the supplement: a daily task list and context hub that links back to Linear and Slack for creation and collaboration.
2. Background and Context
Current State
- Linear is the system of record for issues: creation, triage, cycles, and project views. It is organized by team, project, and cycle. “My work” requires filtering by assignee and mentally aggregating across teams.
- Standup Assistant already synthesizes completed work and todos from “any source” (Zoom discussions, Slack, Linear) and persists standup summaries (e.g.
standup_summaries, weekly goals) in the platform. - Client context (weekly goals, deliverables) lives in client-summary flows and standup data; it is not surfaced in a single place next to an individual’s tickets.
- Slack is where many ad-hoc tasks are agreed; they often never become Linear issues. The Standup Assistant can extract these; the dashboard can surface them.
Why a Dashboard Instead of “Just Linear”
- Linear is project-centric; the dashboard is person- and day-centric.
- The “real” task list for a person is the union of Linear issues, standup-derived todos, and client goals—not just the Linear slice.
- A single pane reduces context switching (Linear + client summary + Standup Assistant) and supports a clear “today” or “this week” focus.
Platform Context
The platform already has:
- Linear API integration (
linearApiServer.ts): teams, users, cycles, issues by cycle; create ticket, attachments, states. - Standup summaries and APIs: latest standup by client, history, draft updates, weekly goals.
- Auth and user identity (Supabase); main app layout and navigation (e.g. Dashboard, Sidebar).
The dashboard is a new read-only aggregation view and API that consumes these existing capabilities.
3. Problem and Value
The Problem
| Pain Point | Current Impact |
|---|---|
| Context switching | Users open Linear, then client summary, then Standup Assistant to understand their day; no single starting point. |
| Incomplete picture | Work agreed in Slack or standups may not be in Linear; users miss commitments or duplicate effort. |
| No clear “today” list | Linear provides due date and priority but no native “focus for today” or daily checklist without custom views. |
| Deliverables vs. tickets | Client deliverables and weekly goals live outside Linear; they are not visible alongside assigned issues. |
| Mental aggregation | Individuals on multiple teams or clients must mentally merge backlogs; no one-place “my work” view. |
Cost of Inaction
- Time lost every day switching between tools to answer “what do I do next?”
- Dropped or delayed commitments that never became tickets.
- Misalignment between what was said in standups/Slack and what appears in Linear.
Value Delivered
| Stakeholder | Value |
|---|---|
| Individual contributors | One place to see “my work today”: Linear issues + standup todos + client goals; less context switching. |
| Leads / multi-team members | Single view across teams and clients without opening multiple Linear views. |
| Client-facing staff | Visibility of client weekly goals and deliverables next to their tickets. |
| Team (indirect) | Fewer missed follow-ups from standups/Slack because they appear on the dashboard until ticketed or done. |
4. Goals and Non-Goals
4.1 Goals
- Aggregate “my” work — Show Linear issues assigned to the current user in one view, with optional filters (e.g. state, cycle, team).
- Surface standup-derived work — Show todos (and optionally completions) from standup summaries for the current user, alongside Linear items.
- Support “today” and “this week” — Provide simple time-based grouping (e.g. Today / This week / Backlog) so the dashboard functions as a daily task list.
- Optional client context — For users tied to clients, show relevant weekly goals or deliverables so they are visible next to tickets.
- Supplement, not replace — Deep links to Linear (and Slack where relevant); all creation and collaboration stay in Linear and Slack.
4.2 Non-Goals
- Replacing Linear — No creating, editing, or triaging issues in the dashboard; that stays in Linear.
- Replacing Slack — No conversation or approval flows in the dashboard; Slack remains the place for communication.
- Full project/team views — No team backlogs or project roadmaps; those stay in Linear.
- Real-time sync as a hard requirement — Near-real-time or periodic refresh is acceptable for V1; no requirement for sub-second updates.
- “View as teammate” or manager views — V1 is strictly “my work” for the logged-in user only.
5. Staged Milestones
POC (Proof of Concept)
Goal: Validate that we can reliably show “my” Linear issues and that the UX is useful as a single pane.
Scope:
- Single page: “My Linear issues” — issues assigned to the current user (all teams), with link to Linear.
- Resolve current user → Linear user (e.g. by email or existing mapping).
- Basic UI: list of issues with title, state, team, link to Linear; optional simple filters (e.g. state).
Success Criteria:
- Logged-in user sees only their assigned issues.
- Each item links to the correct Linear issue.
- At least one internal user can use it as their “what do I have in Linear?” check without opening Linear first.
Timeline: [TBD, needs technical review] — Estimated 1–2 weeks
MVP (Minimum Viable Product)
Goal: Deliver a usable “my work today” view that combines Linear and standup-derived work.
Scope:
- “My Linear issues” with optional grouping (e.g. Today / This week / Backlog) based on due date and state.
- “My standup todos” — items from the latest standup (or by selected client/date) that reference the current user, from existing standup summary data.
- Optional: “This week’s goals” for the user’s clients (from existing weekly goals / client-summary data).
- Single dashboard route (e.g.
/my-workor/dashboard/personal) with clear sections and links to Linear and standup/client context. - Refresh on load (no real-time required).
Not in MVP:
- Manual “focus for today” (pin/reorder).
- Deliverables from SOWs or external docs.
- Slack-derived tasks beyond what Standup Assistant already captures.
- User preferences (e.g. default client, which sections to show).
Success Criteria:
- 50%+ of pilot users open the dashboard at least once per week.
- Users can name at least one standup or Slack item they saw on the dashboard that they would have missed in Linear alone.
- No regression in Linear or Standup Assistant usage (dashboard is additive).
Timeline: [TBD, needs technical review] — Estimated 3–4 weeks post-POC
V1 (Production Release)
Goal: Full-featured personal dashboard with optional prioritization and preferences.
Scope (additions to MVP):
- Optional “focus for today” — allow user to pin or reorder a short list for the day.
- Optional: deliverables or milestones from client/SOW layer when that data is available.
- Optional: surface Slack-derived tasks if exposed via API or standup pipeline.
- User preferences: default client, which sections to show, optional filters.
- Basic analytics: dashboard visits, click-through to Linear (to measure “dashboard as starting point”).
Success Criteria:
- 60%+ of active platform users open the dashboard at least once per week.
- Optional survey: “Did this view help you prioritize today?” — target ≥4/5.
- Documented support for “dashboard as daily starting point” without replacing Linear.
Timeline: [TBD, needs technical review] — Estimated 4–6 weeks post-MVP
6. Users and Use Cases
6.1 Primary Users
- Individual contributors — People with assigned Linear issues and standup commitments who want one place to see their day.
- Leads / multi-team members — People on multiple Linear teams or clients who need a single “my work” view.
- Client-facing staff — People who need to see client weekly goals and deliverables alongside their tickets.
6.2 User Flow
Primary User: An individual contributor or lead who works across multiple teams/clients.
Journey:
- User logs into the Brainforge platform.
- Navigates to “My Work” (or equivalent) from the main nav.
- Sees sections: e.g. “Today,” “This week,” “Standup todos,” “Client goals” (if applicable).
- Reviews Linear issues and standup-derived items in one place.
- Clicks through to Linear (or standup/client context) to take action; all creation and updates happen there.
- Optionally refreshes the page to get updated data.
6.3 Key Use Cases
- UC-1: Start of day — “I open the dashboard with my coffee and see my Linear tickets and standup todos for today without opening Linear or the Standup Assistant.”
- UC-2: Client context — “I’m on a client engagement; I see my Linear work plus this client’s weekly goals so I don’t forget deliverables.”
- UC-3: Ad-hoc work — “Something was assigned in Slack or standup and isn’t in Linear yet; I still see it on my dashboard until it’s ticketed or done.”
7. Functional Requirements
7.1 Inputs
| ID | Requirement | Priority |
|---|---|---|
| FR-1.1 | System SHALL use the authenticated platform user as the “current user.” | P0 |
| FR-1.2 | System SHALL resolve current user to a Linear user (e.g. by email or explicit mapping). | P0 |
| FR-1.3 | System SHALL consume standup summary data (e.g. latest by client, or by date) from existing APIs/tables. | P0 |
| FR-1.4 | System MAY consume client weekly goals from existing client-summary / standup data. | P1 |
7.2 Processing
| ID | Requirement | Priority |
|---|---|---|
| FR-2.1 | System SHALL fetch Linear issues where assignee = current user (across teams). | P0 |
| FR-2.2 | System SHALL filter or group issues by state, due date, or cycle as needed for Today / This week / Backlog. | P0 |
| FR-2.3 | System SHALL derive “my” standup todos from standup summary content (e.g. by assignee name or user id). | P0 |
| FR-2.4 | System MAY combine weekly goals for clients associated with the current user. | P1 |
7.3 Outputs
| ID | Requirement | Priority |
|---|---|---|
| FR-3.1 | Dashboard SHALL display a list of Linear issues assigned to the current user with at least: title, state, team, link to Linear. | P0 |
| FR-3.2 | Dashboard SHALL display standup-derived todos with source (e.g. standup date, client) and link to standup/client context. | P0 |
| FR-3.3 | Dashboard MAY display client weekly goals when the user has client context. | P1 |
| FR-3.4 | Each Linear item SHALL link to the canonical Linear issue URL. | P0 |
7.4 Workflow or Interaction Logic
| ID | Requirement | Priority |
|---|---|---|
| FR-4.1 | Data SHALL be loaded on page load (or on route entry); no real-time subscription required for MVP. | P0 |
| FR-4.2 | Dashboard SHALL be read-only; no create/update/delete of Linear issues or standup data from the dashboard. | P0 |
| FR-4.3 | If Linear or standup data is unavailable, dashboard SHALL degrade gracefully (e.g. show available sections, message for unavailable). | P0 |
8. Technical Approach
Architecture Overview
┌─────────────────────────────────────────────────────────────────┐
│ Brainforge Platform (Next.js) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ My Work / Personalized Dashboard │ │
│ │ Route: e.g. /my-work or /dashboard/personal │ │
│ └────────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Dashboard API (e.g. GET /api/.../my-work) │ │
│ │ - Resolves current user → Linear user │ │
│ │ - Aggregates: Linear issues + standup todos + goals │ │
│ └───┬─────────────────────┬─────────────────────┬──────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Linear API │ │ Standup APIs │ │ Client / Goals │ │
│ │ (existing │ │ (existing │ │ (existing │ │
│ │ server) │ │ routes/DB) │ │ data) │ │
│ └─────────────┘ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
Linear GraphQL Supabase Supabase
(issues by standup_summaries, weekly_goals,
assignee) etc. client context)
Key Components
| Component | Technology | Notes |
|---|---|---|
| Frontend | Next.js App Router, React | New route under (main); reuse existing layout, auth, sidebar. |
| Dashboard API | Next.js API route(s) | One or more routes that return { linearIssues, standupTodos, weeklyGoals? } for current user. |
| Linear | Existing linearApiServer.ts | Add or use function to fetch issues by assignee (e.g. getIssuesAssignedToUser(userId)). Linear GraphQL supports filter by assignee. |
| Standup data | Existing standup APIs, Supabase | Latest standup, by-date; parse or store structured todos/completions for current user. |
| Client goals | Existing weekly goals / client-summary | Optional; join with user’s clients if association exists. |
| Auth | Supabase Auth | Current user from session; map to Linear user (email or stored mapping). |
Data Model
No new primary data stores required for MVP. The dashboard is read-only aggregation.
Existing data used:
- Linear: Issues (via API) filtered by
assignee.idorassignee.emailmatching current user. - Supabase:
standup_summaries(and related tables for weekly goals, client context) — existing schema. - Optional (V1): User preferences for dashboard (e.g. default client, sections to show):
-- Optional, V1
CREATE TABLE dashboard_user_preferences (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES auth.users(id) UNIQUE,
default_client_id UUID,
sections_enabled JSONB DEFAULT '{"linear": true, "standup": true, "goals": true}',
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);API Endpoints
| Method | Endpoint | Purpose |
|---|---|---|
| GET | /api/brainforge/my-work or similar | Return aggregated work for current user: { linearIssues, standupTodos, weeklyGoals? }. |
| GET | /api/brainforge/linear/issues/assigned-to-me (or inline in above) | Return Linear issues where assignee = current user. [Implementation: add to linearApiServer.ts or call from dashboard API.] |
9. Assumptions
| # | Assumption | Risk if Wrong |
|---|---|---|
| A1 | Platform user can be mapped to a Linear user (email or existing integration). | Dashboard cannot show “my” Linear issues; need explicit mapping or onboarding step. |
| A2 | Standup summary structure includes assignee or name so we can filter “my” todos. | Cannot show standup-derived todos per user; may need schema or extraction change. |
| A3 | One dashboard per user (no “view as” or manager view) is sufficient for V1. | May need follow-up for manager or team views. |
| A4 | Refresh on load is acceptable; no real-time sync required for MVP. | If users expect live updates, we add polling or subscriptions later. |
| A5 | Existing Linear API key and Supabase access are sufficient for server-side aggregation. | May need per-user OAuth for Linear if we move to user-scoped tokens. |
10. Open Questions
| # | Question | Owner | Needed By | Status |
|---|---|---|---|---|
| Q1 | How is platform user mapped to Linear user (email match, table, or SSO)? | Engineering | POC start | Open |
| Q2 | Which standup summary fields identify “assignee” for todos (name, email, user id)? | Engineering | POC / MVP | Open |
| Q3 | Should “My Work” show multiple clients’ goals or only one “active” client? | Product | MVP | Open |
| Q4 | Preferred route name: /my-work, /dashboard/personal, or other? | Product | POC | Open |
| Q5 | Refresh strategy: on load only, or add a manual refresh button, or polling? | Product | MVP | Open |
11. Tradeoffs
T1: Read-only dashboard vs. inline actions
| Option | Pros | Cons | Effort |
|---|---|---|---|
| Read-only with links (chosen) | Clear scope, no duplication of Linear/Slack; single source of truth stays in Linear. | User must open Linear (or Slack) to act. | Low |
| Inline create/update | Fewer context switches. | Duplicates logic, sync issues, and blurs “one place to work.” | High |
Decision: Read-only dashboard with deep links. Keeps scope bounded and avoids replacing Linear.
T2: All teams vs. team filter
| Option | Pros | Cons | Effort |
|---|---|---|---|
| All teams (chosen for MVP) | Simple; one view for “everything assigned to me.” | Noisier for users on many teams. | Low |
| Default team or filter | Cleaner for multi-team users. | Requires preference and possibly team membership data. | Medium |
Decision: MVP shows all assigned issues; V1 can add optional team filter or default team preference.
T3: Standup “my todos” from latest only vs. date picker
| Option | Pros | Cons | Effort |
|---|---|---|---|
| Latest standup per context (chosen for MVP) | Simple; “what’s my latest standup saying I do?” | If user has multiple clients, may need client selector. | Low |
| Date picker / history | Full control over which standup. | More UI and API surface. | Medium |
Decision: MVP uses latest standup (or one selected client); V1 can add date or history.
12. Success Metrics
| Metric | Target | How Measured |
|---|---|---|
| Adoption | 50% of pilot users open dashboard ≥1×/week (MVP); 60% for V1 | Platform analytics: unique users hitting dashboard route per week. |
| Usefulness | ≥4/5 on “Did this view help you prioritize today?” (V1, optional survey) | Short in-app or email survey. |
| Additive behavior | No drop in Linear or Standup Assistant usage | Compare usage before/after dashboard launch (optional). |
| Click-through | Dashboard as starting point before Linear | Optional: track “session contains dashboard visit then Linear visit.” |
13. Dependencies
Technical
- Linear API — Existing
linearApiServer; may need new helper to fetch issues by assignee (GraphQL filter byassignee.idor equivalent). - Standup APIs and data — Existing routes and
standup_summaries(and related) tables; may require structured todos/assignee in payload or DB. - Auth — Supabase Auth; current user available in session.
External
- Linear availability — Dashboard degrades if Linear API is down; show cached or standup-only view with message.
Team
- Product — Prioritization of sections (Linear vs. standup vs. goals) and route naming.
- Engineering — User → Linear user mapping and standup “my todos” extraction logic.
14. Risks and Mitigations
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| User → Linear mapping unclear or missing | Medium | High — no “my” Linear issues | Resolve in POC: document email match or add mapping table; fallback to standup-only. |
| Standup data has no assignee | Medium | High — no “my” standup todos | Inspect standup schema/output; add assignee/name to extraction or storage if needed. |
| Low adoption | Medium | Medium | Place “My Work” prominently in nav; short internal rollout and feedback. |
| Linear rate limits | Low | Medium | Cache responses briefly; respect Linear rate limits. |
| Scope creep (dashboard becomes “mini-Linear”) | Medium | High | Enforce non-goals; keep dashboard read-only and link out for all actions. |
15. Timeline Summary
| Phase | Scope | Duration | Status |
|---|---|---|---|
| POC | My Linear issues only; user mapping; basic UI | 1–2 weeks | Not started |
| MVP | + Standup todos, optional goals; Today/This week; single route | 3–4 weeks | Not started |
| V1 | + Focus for today; preferences; optional deliverables/Slack; analytics | 4–6 weeks | Not started |
Notes: Timeline estimates require technical review and resource allocation.
16. References
- Brainforge Platform AGENTS.md — Platform technical overview
- PRD Template — PRD structure
- PRD Prompts — PRD quality standards
- PRD Checklist — Pre-finalization checklist
- Linear API usage:
apps/platform/src/lib/linearApiServer.ts - Standup Assistant and summaries:
apps/platform/src/mastra/agents/standup-assistant.ts, standup API routes
17. PRD Checklist Review
Run against standards/02-writing/PRDs/prd-checklist.md to lock the draft.
Structure & Format
- Follows the official PRD template — Sections 1–16 + Changelog match template order and content types.
- All sections are present and complete — No gaps; each section has substantive content.
- Headings and formatting are consistent — Numbered sections, subsections, tables, and lists used consistently.
- Uses lists where appropriate — Bullets for goals/non-goals, tables for requirements, value, risks, etc.
- No placeholder text left behind — No
[PROJECT NAME]-style placeholders; timelines use[TBD, needs technical review]by design.
Clarity
- The summary clearly states the purpose — Section 1 states what the dashboard is and why it exists (consolidate work, one place, supplement to Linear/Slack).
- Goals are concise and measurable — Five goals with clear outcomes (aggregate, surface, support today/this week, optional client context, supplement).
- Non-goals are explicit — Five non-goals (no replacing Linear/Slack, no project views, no real-time requirement, no “view as” in V1).
- Use cases are described simply and logically — UC-1, UC-2, UC-3 with clear user scenarios and outcomes.
- Requirements are testable and unambiguous — FRs use SHALL/MAY, have IDs and priorities; each can be verified done/not done.
Accuracy
- All details align with meeting notes and discovery sessions — Based on stakeholder discussion and codebase (Linear, standup, platform); internal PRD with no formal transcript.
- Requirements reflect real client needs — Requirements reflect internal platform users’ need for a single “my work” view.
- No invented features or assumptions — Features and scope come from problem statement; assumptions are listed with “risk if wrong.”
- Technical approach matches actual Brainforge capabilities — References existing
linearApiServer.ts, standup APIs, Supabase, auth. - Terminology is consistent throughout — “Dashboard,” “My Work,” “standup,” “Linear” used consistently.
Completeness
- Includes goals and non-goals — Section 4.
- Lists all use cases — Section 6.3 (three key use cases).
- Defines functional requirements clearly — Section 7 (Inputs, Processing, Outputs, Workflow) with IDs and priorities.
- Includes data requirements or constraints — Section 8 (Data Model: existing data + optional V1 preferences table).
- Outlines risks and assumptions — Section 9 (Assumptions), Section 14 (Risks and Mitigations).
- Clearly defines acceptance criteria — Success criteria per milestone (POC, MVP, V1) act as acceptance criteria; FRs are testable.
- Open questions are documented — Section 10 with owner, needed-by, status.
Tone & Professionalism
- Neutral and factual tone — No hype; problem and value stated factually.
- No casual phrasing — Use cases are professional; “with my coffee” (UC-1) is a light user quote and acceptable for internal PRD.
- Clear, concise, and client-facing — Readable by product, engineering, and stakeholders.
- Avoids technical jargon unless needed and defined — Technical terms (e.g. GraphQL,
standup_summaries) appear in Technical Approach where appropriate.
Final Review
- Passed AI clarity check — Summary, goals, requirements, and use cases are clear.
- Passed AI completeness check — All checklist areas above satisfied.
- Passed AI accuracy check — Aligned with codebase and stated scope; no invented details.
- Reviewed manually for correctness — For author/reviewer to complete before approval.
- Ready for internal review or client delivery — Pending manual review; structure and content are ready for internal review.
Checklist result: All items pass except manual review, which is left for the author. Draft is ready to lock for internal review once manual sign-off is done.
Changelog
| Date | Author | Change |
|---|---|---|
| 2026-02-23 | Brainforge Product Team | Initial draft |
| 2026-02-23 | Brainforge Product Team | Added PRD Checklist Review (Section 17) per playbook checklist |