@pilotspace/add 1.13.0 → 1.15.0

package/personas-teacher/examples/workflow-book-chapter.md

@@ -0,0 +1,55 @@
+# Workflow Example: Book Chapter Development
+
+> A focused single-agent workflow for turning rough source material into a strategic first-person chapter draft with explicit revision loops.
+
+## When to Use This
+
+Use this workflow when an author has voice notes, fragments, or strategic notes, but not yet a clean chapter draft. The goal is not generic ghostwriting. The goal is to produce a chapter that strengthens category positioning, preserves the author's voice, and exposes open editorial decisions clearly.
+
+## Agent Used
+
+| Agent | Role |
+|-------|------|
+| Book Co-Author | Converts source material into a versioned chapter draft with editorial notes and next-step questions |
+
+## Example Activation
+
+```text
+Activate Book Co-Author.
+
+Book goal: Build authority around practical AI adoption for Mittelstand companies.
+Target audience: Owners and operational leaders of 20-200 person businesses.
+Chapter topic: Why most AI projects fail before implementation starts.
+Desired draft maturity: First substantial draft.
+
+Raw material:
+- Voice memo: "The real failure happens in expectation setting, not tooling."
+- Notes: Leaders buy software before defining the operational bottleneck.
+- Story fragment: We nearly rolled out the wrong automation in a cabinetmaking workflow because the actual problem was quoting delays, not production throughput.
+- Positioning angle: Practical realism over hype.
+
+Produce:
+1. Chapter objective and strategic role in the book
+2. Any clarification questions you need
+3. Chapter 2 - Version 1 - ready for review
+4. Editorial notes on assumptions and proof gaps
+5. Specific next-step revision requests
+```
+
+## Expected Output Shape
+
+The Book Co-Author should respond in five parts:
+
+1. `Target Outcome`
+2. `Chapter Draft`
+3. `Editorial Notes`
+4. `Feedback Loop`
+5. `Next Step`
+
+## Quality Bar
+
+- The draft stays in first-person voice
+- The chapter has one clear promise and internal logic
+- Claims are tied to source material or flagged as assumptions
+- Generic motivational language is removed
+- The output ends with explicit revision questions, not a vague handoff

package/personas-teacher/examples/workflow-landing-page.md

@@ -0,0 +1,119 @@
+# Multi-Agent Workflow: Landing Page Sprint
+
+> Ship a conversion-optimized landing page in one day using 4 agents.
+
+## The Scenario
+
+You need a landing page for a new product launch. It needs to look great, convert visitors, and be live by end of day.
+
+## Agent Team
+
+| Agent | Role in this workflow |
+|-------|---------------------|
+| Content Creator | Write the copy |
+| UI Designer | Design the layout and component specs |
+| Frontend Developer | Build it |
+| Growth Hacker | Optimize for conversion |
+
+## The Workflow
+
+### Morning: Copy + Design (parallel)
+
+**Step 1a — Activate Content Creator**
+
+```
+Activate Content Creator.
+
+Write landing page copy for "FlowSync" — an API integration platform
+that connects any two SaaS tools in under 5 minutes.
+
+Target audience: developers and technical PMs at mid-size companies.
+Tone: confident, concise, slightly playful.
+
+Sections needed:
+1. Hero (headline + subheadline + CTA)
+2. Problem statement (3 pain points)
+3. How it works (3 steps)
+4. Social proof (placeholder testimonial format)
+5. Pricing (3 tiers: Free, Pro, Enterprise)
+6. Final CTA
+
+Keep it scannable. No fluff.
+```
+
+**Step 1b — Activate UI Designer (in parallel)**
+
+```
+Activate UI Designer.
+
+Design specs for a SaaS landing page. Product: FlowSync (API integration platform).
+Style: clean, modern, dark mode option. Think Linear or Vercel aesthetic.
+
+Deliver:
+1. Layout wireframe (section order + spacing)
+2. Color palette (primary, secondary, accent, background)
+3. Typography (font pairing, heading sizes, body size)
+4. Component specs: hero section, feature cards, pricing table, CTA buttons
+5. Responsive breakpoints (mobile, tablet, desktop)
+```
+
+### Midday: Build
+
+**Step 2 — Activate Frontend Developer**
+
+```
+Activate Frontend Developer.
+
+Build a landing page from these specs:
+
+Copy: [paste Content Creator output]
+Design: [paste UI Designer output]
+
+Stack: HTML, Tailwind CSS, minimal vanilla JS (no framework needed).
+Requirements:
+- Responsive (mobile-first)
+- Fast (no heavy assets, system fonts OK)
+- Accessible (proper headings, alt text, focus states)
+- Include a working email signup form (action URL: /api/subscribe)
+
+Deliver a single index.html file ready to deploy.
+```
+
+### Afternoon: Optimize
+
+**Step 3 — Activate Growth Hacker**
+
+```
+Activate Growth Hacker.
+
+Review this landing page for conversion optimization:
+
+[paste the HTML or describe the current page]
+
+Evaluate:
+1. Is the CTA above the fold?
+2. Is the value proposition clear in under 5 seconds?
+3. Any friction in the signup flow?
+4. What A/B tests would you run first?
+5. SEO basics: meta tags, OG tags, structured data
+
+Give me specific changes, not general advice.
+```
+
+## Timeline
+
+| Time | Activity | Agent |
+|------|----------|-------|
+| 9:00 | Copy + design kick off (parallel) | Content Creator + UI Designer |
+| 11:00 | Build starts | Frontend Developer |
+| 14:00 | First version ready | — |
+| 14:30 | Conversion review | Growth Hacker |
+| 15:30 | Apply feedback | Frontend Developer |
+| 16:30 | Ship | Deploy to Vercel/Netlify |
+
+## Key Patterns
+
+1. **Parallel kickoff**: Copy and design happen at the same time since they're independent
+2. **Merge point**: Frontend Developer needs both outputs before starting
+3. **Feedback loop**: Growth Hacker reviews, then Frontend Developer applies changes
+4. **Time-boxed**: Each step has a clear timebox to prevent scope creep

package/personas-teacher/examples/workflow-startup-mvp.md

@@ -0,0 +1,155 @@
+# Multi-Agent Workflow: Startup MVP
+
+> A step-by-step example of how to coordinate multiple agents to go from idea to shipped MVP.
+
+## The Scenario
+
+You're building a SaaS MVP — a team retrospective tool for remote teams. You have 4 weeks to ship a working product with user signups, a core feature, and a landing page.
+
+## Agent Team
+
+| Agent | Role in this workflow |
+|-------|---------------------|
+| Sprint Prioritizer | Break the project into weekly sprints |
+| UX Researcher | Validate the idea with quick user interviews |
+| Backend Architect | Design the API and data model |
+| Frontend Developer | Build the React app |
+| Rapid Prototyper | Get the first version running fast |
+| Growth Hacker | Plan launch strategy while building |
+| Reality Checker | Gate each milestone before moving on |
+
+## The Workflow
+
+### Week 1: Discovery + Architecture
+
+**Step 1 — Activate Sprint Prioritizer**
+
+```
+Activate Sprint Prioritizer.
+
+Project: RetroBoard — a real-time team retrospective tool for remote teams.
+Timeline: 4 weeks to MVP launch.
+Core features: user auth, create retro boards, add cards, vote, action items.
+Constraints: solo developer, React + Node.js stack, deploy to Vercel + Railway.
+
+Break this into 4 weekly sprints with clear deliverables and acceptance criteria.
+```
+
+**Step 2 — Activate UX Researcher (in parallel)**
+
+```
+Activate UX Researcher.
+
+I'm building a team retrospective tool for remote teams (5-20 people).
+Competitors: EasyRetro, Retrium, Parabol.
+
+Run a quick competitive analysis and identify:
+1. What features are table stakes
+2. Where competitors fall short
+3. One differentiator we could own
+
+Output a 1-page research brief.
+```
+
+**Step 3 — Hand off to Backend Architect**
+
+```
+Activate Backend Architect.
+
+Here's our sprint plan: [paste Sprint Prioritizer output]
+Here's our research brief: [paste UX Researcher output]
+
+Design the API and database schema for RetroBoard.
+Stack: Node.js, Express, PostgreSQL, Socket.io for real-time.
+
+Deliver:
+1. Database schema (SQL)
+2. REST API endpoints list
+3. WebSocket events for real-time board updates
+4. Auth strategy recommendation
+```
+
+### Week 2: Build Core Features
+
+**Step 4 — Activate Frontend Developer + Rapid Prototyper**
+
+```
+Activate Frontend Developer.
+
+Here's the API spec: [paste Backend Architect output]
+
+Build the RetroBoard React app:
+- Stack: React, TypeScript, Tailwind, Socket.io-client
+- Pages: Login, Dashboard, Board view
+- Components: RetroCard, VoteButton, ActionItem, BoardColumn
+
+Start with the Board view — it's the core experience.
+Focus on real-time: when one user adds a card, everyone sees it.
+```
+
+**Step 5 — Reality Check at midpoint**
+
+```
+Activate Reality Checker.
+
+We're at week 2 of a 4-week MVP build for RetroBoard.
+
+Here's what we have so far:
+- Database schema: [paste]
+- API endpoints: [paste]
+- Frontend components: [paste]
+
+Evaluate:
+1. Can we realistically ship in 2 more weeks?
+2. What should we cut to make the deadline?
+3. Any technical debt that will bite us at launch?
+```
+
+### Week 3: Polish + Landing Page
+
+**Step 6 — Frontend Developer continues, Growth Hacker starts**
+
+```
+Activate Growth Hacker.
+
+Product: RetroBoard — team retrospective tool, launching in 1 week.
+Target: Engineering managers and scrum masters at remote-first companies.
+Budget: $0 (organic launch only).
+
+Create a launch plan:
+1. Landing page copy (hero, features, CTA)
+2. Launch channels (Product Hunt, Reddit, Hacker News, Twitter)
+3. Day-by-day launch sequence
+4. Metrics to track in week 1
+```
+
+### Week 4: Launch
+
+**Step 7 — Final Reality Check**
+
+```
+Activate Reality Checker.
+
+RetroBoard is ready to launch. Evaluate production readiness:
+
+- Live URL: [url]
+- Test accounts created: yes
+- Error monitoring: Sentry configured
+- Database backups: daily automated
+
+Run through the launch checklist and give a GO / NO-GO decision.
+Require evidence for each criterion.
+```
+
+## Key Patterns
+
+1. **Sequential handoffs**: Each agent's output becomes the next agent's input
+2. **Parallel work**: UX Researcher and Sprint Prioritizer can run simultaneously in Week 1
+3. **Quality gates**: Reality Checker at midpoint and before launch prevents shipping broken code
+4. **Context passing**: Always paste previous agent outputs into the next prompt — agents don't share memory
+
+## Tips
+
+- Copy-paste agent outputs between steps — don't summarize, use the full output
+- If a Reality Checker flags an issue, loop back to the relevant specialist to fix it
+- Keep the Orchestrator agent in mind for automating this flow once you're comfortable with the manual version

package/personas-teacher/examples/workflow-with-memory.md

@@ -0,0 +1,238 @@
+# Multi-Agent Workflow: Startup MVP with Persistent Memory
+
+> The same startup MVP workflow from [workflow-startup-mvp.md](workflow-startup-mvp.md), but with an MCP memory server handling state between agents. No more copy-paste handoffs.
+
+## The Problem with Manual Handoffs
+
+In the standard workflow, every agent-to-agent transition looks like this:
+
+```
+Activate Backend Architect.
+
+Here's our sprint plan: [paste Sprint Prioritizer output]
+Here's our research brief: [paste UX Researcher output]
+
+Design the API and database schema for RetroBoard.
+...
+```
+
+You are the glue. You copy-paste outputs between agents, keep track of what's been done, and hope you don't lose context along the way. It works for small projects, but it falls apart when:
+
+- Sessions time out and you lose the output
+- Multiple agents need the same context
+- QA fails and you need to rewind to a previous state
+- The project spans days or weeks across many sessions
+
+## The Fix
+
+With an MCP memory server installed, agents store their deliverables in memory and retrieve what they need automatically. Handoffs become:
+
+```
+Activate Backend Architect.
+
+Project: RetroBoard. Recall previous context for this project
+and design the API and database schema.
+```
+
+The agent searches memory for RetroBoard context, finds the sprint plan and research brief stored by previous agents, and picks up from there.
+
+## Setup
+
+Install any MCP-compatible memory server that supports `remember`, `recall`, and `rollback` operations. See [integrations/mcp-memory/README.md](../integrations/mcp-memory/README.md) for setup.
+
+## The Scenario
+
+Same as the standard workflow: a SaaS team retrospective tool (RetroBoard), 4 weeks to MVP, solo developer.
+
+## Agent Team
+
+| Agent | Role in this workflow |
+|-------|---------------------|
+| Sprint Prioritizer | Break the project into weekly sprints |
+| UX Researcher | Validate the idea with quick user interviews |
+| Backend Architect | Design the API and data model |
+| Frontend Developer | Build the React app |
+| Rapid Prototyper | Get the first version running fast |
+| Growth Hacker | Plan launch strategy while building |
+| Reality Checker | Gate each milestone before moving on |
+
+Each agent has a Memory Integration section in their prompt (see [integrations/mcp-memory/README.md](../integrations/mcp-memory/README.md) for how to add it).
+
+## The Workflow
+
+### Week 1: Discovery + Architecture
+
+**Step 1 — Activate Sprint Prioritizer**
+
+```
+Activate Sprint Prioritizer.
+
+Project: RetroBoard — a real-time team retrospective tool for remote teams.
+Timeline: 4 weeks to MVP launch.
+Core features: user auth, create retro boards, add cards, vote, action items.
+Constraints: solo developer, React + Node.js stack, deploy to Vercel + Railway.
+
+Break this into 4 weekly sprints with clear deliverables and acceptance criteria.
+Remember your sprint plan tagged for this project when done.
+```
+
+The Sprint Prioritizer produces the sprint plan and stores it in memory tagged with `sprint-prioritizer`, `retroboard`, and `sprint-plan`.
+
+**Step 2 — Activate UX Researcher (in parallel)**
+
+```
+Activate UX Researcher.
+
+I'm building a team retrospective tool for remote teams (5-20 people).
+Competitors: EasyRetro, Retrium, Parabol.
+
+Run a quick competitive analysis and identify:
+1. What features are table stakes
+2. Where competitors fall short
+3. One differentiator we could own
+
+Output a 1-page research brief. Remember it tagged for this project when done.
+```
+
+The UX Researcher stores the research brief tagged with `ux-researcher`, `retroboard`, and `research-brief`.
+
+**Step 3 — Hand off to Backend Architect**
+
+```
+Activate Backend Architect.
+
+Project: RetroBoard. Recall the sprint plan and research brief from previous agents.
+Stack: Node.js, Express, PostgreSQL, Socket.io for real-time.
+
+Design:
+1. Database schema (SQL)
+2. REST API endpoints list
+3. WebSocket events for real-time board updates
+4. Auth strategy recommendation
+
+Remember each deliverable tagged for this project and for the frontend-developer.
+```
+
+The Backend Architect recalls the sprint plan and research brief from memory automatically. No copy-paste. It stores its schema and API spec tagged with `backend-architect`, `retroboard`, `api-spec`, and `frontend-developer`.
+
+### Week 2: Build Core Features
+
+**Step 4 — Activate Frontend Developer + Rapid Prototyper**
+
+```
+Activate Frontend Developer.
+
+Project: RetroBoard. Recall the API spec and schema from the Backend Architect.
+
+Build the RetroBoard React app:
+- Stack: React, TypeScript, Tailwind, Socket.io-client
+- Pages: Login, Dashboard, Board view
+- Components: RetroCard, VoteButton, ActionItem, BoardColumn
+
+Start with the Board view — it's the core experience.
+Focus on real-time: when one user adds a card, everyone sees it.
+Remember your progress tagged for this project.
+```
+
+The Frontend Developer pulls the API spec from memory and builds against it.
+
+**Step 5 — Reality Check at midpoint**
+
+```
+Activate Reality Checker.
+
+Project: RetroBoard. We're at week 2 of a 4-week MVP build.
+
+Recall all deliverables from previous agents for this project.
+
+Evaluate:
+1. Can we realistically ship in 2 more weeks?
+2. What should we cut to make the deadline?
+3. Any technical debt that will bite us at launch?
+
+Remember your verdict tagged for this project.
+```
+
+The Reality Checker has full visibility into everything produced so far — the sprint plan, research brief, schema, API spec, and frontend progress — without you having to collect and paste it all.
+
+### Week 3: Polish + Landing Page
+
+**Step 6 — Frontend Developer continues, Growth Hacker starts**
+
+```
+Activate Growth Hacker.
+
+Product: RetroBoard — team retrospective tool, launching in 1 week.
+Target: Engineering managers and scrum masters at remote-first companies.
+Budget: $0 (organic launch only).
+
+Recall the project context and Reality Checker's verdict.
+
+Create a launch plan:
+1. Landing page copy (hero, features, CTA)
+2. Launch channels (Product Hunt, Reddit, Hacker News, Twitter)
+3. Day-by-day launch sequence
+4. Metrics to track in week 1
+
+Remember the launch plan tagged for this project.
+```
+
+### Week 4: Launch
+
+**Step 7 — Final Reality Check**
+
+```
+Activate Reality Checker.
+
+Project: RetroBoard, ready to launch.
+
+Recall all project context, previous verdicts, and the launch plan.
+
+Evaluate production readiness:
+- Live URL: [url]
+- Test accounts created: yes
+- Error monitoring: Sentry configured
+- Database backups: daily automated
+
+Run through the launch checklist and give a GO / NO-GO decision.
+Require evidence for each criterion.
+```
+
+### When QA Fails: Rollback
+
+In the standard workflow, when the Reality Checker rejects a deliverable, you go back to the responsible agent and try to explain what went wrong. With memory, the recovery loop is tighter:
+
+```
+Activate Backend Architect.
+
+Project: RetroBoard. The Reality Checker flagged issues with the API design.
+Recall the Reality Checker's feedback and your previous API spec.
+Roll back to your last known-good schema and address the specific issues raised.
+Remember the updated deliverables when done.
+```
+
+The Backend Architect can see exactly what the Reality Checker flagged, recall its own previous work, roll back to a checkpoint, and produce a fix — all without you manually tracking versions.
+
+## Before and After
+
+| Aspect | Standard Workflow | With Memory |
+|--------|------------------|-------------|
+| **Handoffs** | Copy-paste full output between agents | Agents recall what they need automatically |
+| **Context loss** | Session timeouts lose everything | Memories persist across sessions |
+| **Multi-agent context** | Manually compile context from N agents | Agent searches memory for project tag |
+| **QA failure recovery** | Manually describe what went wrong | Agent recalls feedback + rolls back |
+| **Multi-day projects** | Re-establish context every session | Agent picks up where it left off |
+| **Setup required** | None | Install an MCP memory server |
+
+## Key Patterns
+
+1. **Tag everything with the project name**: This is what makes recall work. Every memory gets tagged with `retroboard` (or whatever your project is).
+2. **Tag deliverables for the receiving agent**: When the Backend Architect finishes an API spec, it tags the memory with `frontend-developer` so the Frontend Developer finds it on recall.
+3. **Reality Checker gets full visibility**: Because all agents store their work in memory, the Reality Checker can recall everything for the project without you compiling it.
+4. **Rollback replaces manual undo**: When something fails, roll back to the last checkpoint instead of trying to figure out what changed.
+
+## Tips
+
+- You don't need to modify every agent at once. Start by adding Memory Integration to the agents you use most and expand from there.
+- The memory instructions are prompts, not code. The LLM interprets them and calls the MCP tools as needed. You can adjust the wording to match your style.
+- Any MCP-compatible memory server that supports `remember`, `recall`, `rollback`, and `search` tools will work with this workflow.