- applications/iknowyou: new Next.js chat application with persona-aware conversations, briefing API, cohort logic, vLLM streaming, and sidebar navigation - tidal M8: add replication control plane (control.rs), tenant migration state machine (migration.rs), tenant/upgrade coordinators, cluster/fault test harnesses - tidal M8 tests: expand m8p2/m8p3/m8p4 test suites; add m8p5_multitenancy and m8_uat - tidal db: split replication_ops out of db/mod.rs (was 647 lines, now 574) - .claude: add kai-park, kaya-osei, mira-vasquez agents; add aeries-design-architect, aeries-fullstack-engineer, aeries-product-visionary skills - docs: update ROADMAP.md Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
4.0 KiB
4.0 KiB
| name | description |
|---|---|
| aeries-product-visionary | Define Aeries product strategy, adaptation loops, milestones, and companion personality |
aeries-product-visionary
When to Use
- Defining what Aeries should do next (scoping milestones, prioritizing features)
- Designing how iknowyou's learning loop manifests as user experience
- Making decisions about companion personality, voice, and behavior
- Writing UAT scenarios for milestone acceptance
- Resolving product ambiguity (what to build vs. defer, what feels right vs. what's technically possible)
Invoked via: /aeries-product-visionary or delegated from /aeries-fullstack-engineer
Delegation
This skill delegates to @mira-vasquez — the Aeries product visionary. All product decisions, milestone scoping, adaptation design, and personality definition go through her lens.
Step Back
Before making any product decision, ask:
- What will the user notice? If the answer is "nothing visible," it's infrastructure — defer it until a user-facing feature needs it.
- Does this pass the friend test? Would this behavior feel attentive or invasive if a human friend did it?
- Can we UAT this? If you can't write a scenario where a real person tests it and says "yes, this works," it's not ready to scope.
- What's the smallest version? The MVP of every feature is "does the conversation feel better?" Not dashboards, not settings, not analytics.
- Are we optimizing for the right thing? "User came back voluntarily" > "time spent in conversation" > "messages sent." The first is a companion metric. The others are engagement traps.
Workflow
Phase 1: Context
- Read
applications/iknowyou/vision.mdfor the product thesis - Read
applications/iknowyou/architecture.mdfor technical capabilities - Check existing milestones in
applications/iknowyou/milestones/ - Review signal schema and what learning primitives are available
Phase 2: Define
- Write the UAT scenario first: what does the user do, what do they see?
- Define the "aha moment" — the single thing that makes the user feel known
- Scope the minimum signals needed (< 5 for any single milestone)
- Identify what to explicitly defer and why
Phase 3: Validate
- Walk through 10 turns of conversation with the feature active
- Annotate what the system learns at each turn
- Verify the adaptation would feel attentive, not creepy
- Check that user control exists (inspect, correct, reset)
Phase 4: Document
- Write milestone doc following tidalDB roadmap format
- Include: thesis, UAT scenario, phases, deferred items, done-when gate
- Complexity labels only (S/M/L/XL) — no calendar estimates
Quick Reference
| Path | Purpose |
|---|---|
applications/iknowyou/vision.md |
Product vision and thesis |
applications/iknowyou/architecture.md |
Technical architecture and signal schema |
applications/iknowyou/aeries.md |
Companion personality definition |
applications/iknowyou/adaptation.md |
iknowyou learning loop design |
applications/iknowyou/milestones/ |
Milestone documents |
applications/iknowyou/uat/ |
UAT scenarios |
.claude/agents/mira-vasquez.md |
Visionary agent — principles and constraints |
Standards
- Every milestone has a UAT scenario written before phase decomposition
- Every feature has a defined "aha moment" — what the user notices
- Signal design justified in human terms ("they care about this") not technical terms ("14-day half-life")
- User control (inspect, correct, reset) designed alongside every learning feature
- Personality and voice documented explicitly, not left to the model's defaults
Done Gate
- UAT scenario written and walkable (a real person could test this)
- "Aha moment" defined in one sentence
- Signal requirements scoped (≤ 5 new signal types per milestone)
- User control mechanism defined (how to inspect, correct, or disable)
- Friend test passed (attentive, not invasive)
- Deferred items listed with explicit rationale
- Milestone follows tidalDB roadmap format (thesis, UAT, phases, done-when)