Source: plans/2026-04-06-linear-agent-pm-system.md

Goal

Design a project management system for Had, Winston, other agents, and collaborators that borrows the good parts of Taskplane's agent-first workflow but runs on Linear as the source of truth.

Initial framing

Top-level domains

• Personal
• Applied Realities

Personal examples

• hadsed.com
• other personal projects / ops

Applied Realities functions

• Product
• GTM
• Engineering

Applied Realities engineering streams

• assemble-anything
• additional repos to be added

What seems valuable from Taskplane

• Agent-first task ownership
• Structured task packets instead of vague tickets
• Clear task states and handoffs
• Review / approval gates
• Visibility into what each worker is doing
• Hierarchy between goals, projects, and tasks

What we likely want to keep in Linear

• Teams / initiatives / projects / issues as canonical objects
• Human-collaborator visibility
• Roadmaps and prioritization
• Simple assignment and status views
• API/webhook automation layer for agents

Proposed architecture direction

Linear as source of truth

• Humans and agents both read/write Linear
• Every actionable unit maps to a Linear issue
• Projects / initiatives capture longer arcs

Winston layer on top

• Winston acts as executive + personal routing layer
• Start with a single-agent system (Winston only)
• Add specialist Winstons later only if the structure proves useful
• Agents can triage, decompose, claim, execute, review, and escalate

Likely objects

• Domains: Personal, Applied Realities
• Project boards instead of teams
• Functional boards / projects under Applied Realities: Product, GTM, Engineering
• Streams / repos under Engineering: assemble-anything, others
• Issues for work items
• Labels / custom fields to encode agent workflow

Questions to resolve

• Whether to model Personal and Applied Realities as top-level project boards, initiatives, or parent projects
• Whether agent ownership should live in assignee, labels, or a custom field
• What the lifecycle should be from intake → triage → execution → review → done
• How much Taskplane-style structured task memory to store inside Linear vs repo files
• How much hierarchy Linear should carry directly vs how much should be encoded in labels and naming

Recommended next steps

1. Reverse-engineer the best parts of Taskplane into a small design doc
2. Design a Linear information architecture around project boards
3. Define statuses, labels, and custom fields for a single-agent trial run
4. Create the first Linear workspace schema
5. Test the workflow with Winston alone before adding specialist agents
6. Build a lightweight sync/ops layer for agents

Draft Linear schema v0

Board structure

• Personal
  • hadsed.com
  • Other personal projects / ops
• Applied Realities
  • Product
  • GTM
  • Engineering
    • assemble-anything
    • other repos / streams later

Recommended issue lifecycle

• Inbox
  • Newly captured work
  • Not yet clarified
• Triaged
  • Clarified and categorized
  • Missing execution detail or priority decision
• Ready
  • Can be picked up immediately
  • Has enough context for a human or Winston to act
• In Progress
  • Active execution
• In Review
  • Waiting on Had or collaborator review
• Blocked
  • Cannot proceed due to dependency, missing decision, or external wait
• Done
  • Finished and closed

Label taxonomy

• Domain
  • domain:personal
  • domain:applied-realities
• Function
  • function:product
  • function:gtm
  • function:engineering
• Stream / repo
  • stream:hadsed-com
  • stream:assemble-anything
• Work type
  • type:project
  • type:task
  • type:bug
  • type:research
  • type:ops
  • type:decision
• Execution mode
  • actor:human
  • actor:agent
  • actor:either
• State markers
  • needs-spec
  • needs-review
  • blocked:external
  • blocked:decision

Custom fields

• Area
  • Personal
  • Applied Realities / Product
  • Applied Realities / GTM
  • Applied Realities / Engineering
• Stream
  • hadsed.com
  • assemble-anything
  • none / other
• Owner mode
  • human
  • agent
  • either
• Agent owner
  • winston
  • none
• Review required
  • yes
  • no
• Spec / brief link
  • URL or doc reference
• Repo link
  • URL

Operating rules for v0

• Every new item starts in Inbox
• Triage adds domain, function, work type, owner mode, and stream if relevant
• Only items in Ready are eligible for active work
• Winston can move items from Inbox to Triaged to Ready when scope is clear
• Winston can take actor:agent or actor:either work
• Any item needing Had input moves to In Review or Blocked depending on whether work is complete
• Longer efforts should be represented as a parent project plus child execution issues

Suggested templates

Agent-executable task

• Outcome
• Why it matters
• Context
• Constraints
• Definition of done
• Links / artifacts

Decision ticket

• Decision to make
• Options
• Recommendation
• Open questions
• Decision owner

Project ticket

• Goal
• Success metric
• Milestones
• Dependencies
• Current risks

Execution Log

2026-04-06 — Initial project capture

• Captured Had's intended hierarchy and direction
• Framed this as a Linear-native system inspired by Taskplane's agent-first workflow
• Next: produce the concrete Linear schema + agent operating model

2026-04-06 — Refined Linear direction

• Updated the plan toward project boards rather than teams
• Simplified rollout to a Winston-only pilot before adding specialist agents
• Next: define the exact board structure, statuses, labels, and custom fields for the first test run

2026-04-06 — Drafted schema v0

• Added a concrete board structure for Personal and Applied Realities
• Defined a first-pass issue lifecycle, label taxonomy, and custom fields
• Added operating rules and starter templates for agent tasks, decisions, and projects
• Next: tighten this into a setup checklist and then map it onto actual Linear objects