---
name: aeries-product-visionary
description: 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)