tidaldb/.claude/skills/aeries-product-visionary/SKILL.md
jordan 98bdc18a49 feat: add iknowyou app + complete M8 replication extensions + Aeries agents/skills
- 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>
2026-02-24 21:09:11 -07:00

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:

  1. What will the user notice? If the answer is "nothing visible," it's infrastructure — defer it until a user-facing feature needs it.
  2. Does this pass the friend test? Would this behavior feel attentive or invasive if a human friend did it?
  3. 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.
  4. What's the smallest version? The MVP of every feature is "does the conversation feel better?" Not dashboards, not settings, not analytics.
  5. 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.md for the product thesis
  • Read applications/iknowyou/architecture.md for 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)