capture

If vault_path is not in context, read ~/.myna/config.yaml first. If the file does not exist, tell the user to run /myna:setup and stop.

capture

Routes user-entered data to the right vault destinations. One capture can produce multiple entries — one per destination. Nothing is silently dropped.

📋 Before You Start

Read at session start:

• _system/config/workspace.yaml — user identity, role, and timezone
• _system/config/projects.yaml — project names, aliases
• _system/config/people.yaml — person names, aliases, relationship tiers

---

🔀 Routing Logic

When the user says "capture: [text]", decompose the input into its components and route each one:

Content type	Destination
Recognition or praise about a person	People/{person-slug}.md → Recognition section
Observation about a person (strength, growth area)	People/{person-slug}.md → Observations section
Project update, decision, blocker, risk	Projects/{project-slug}.md → Timeline section
Task or action item	Projects/{project-slug}.md or daily note (if no project)
Your own contribution	Journal/contributions-{YYYY-MM-DD}.md (Monday date)
Personal note unrelated to projects/people	Daily note or user specifies
Ambiguous destination	Review queue (ReviewQueue/review-work.md or review-people.md)

Every relevant destination gets its own entry. If the same capture maps to three destinations, write three entries. Report each one.

Provenance markers on captures:

• Destination (project or person) is clear from what the user wrote → [User]
• Destination was guessed by Claude (ambiguous project or person name) → [Inferred]
• Genuinely ambiguous (can't determine destination at all) → review queue

---

📝 Quick Capture

Trigger: "capture: [text]" — catch-all for anything

How:

1. Read the capture text. Identify all components: recognitions, observations, project updates, tasks, contributions.
2. For each component: a. Resolve the entity (person or project) via fuzzy name resolution against people.yaml and projects.yaml. b. Assign a provenance marker. c. Write to the destination file — append-only.
3. If entity resolution fails (ambiguous match or no match), apply the two-phase approach — ask the user inline first, and simultaneously add a review queue item as a safety net:
   • Ambiguous match: Ask inline: "I found multiple matches for '[name]': [list candidates]. Which one?" Present candidates and wait for the user to pick. Once the user responds, resolve the entity, write the entry to the correct destination, and remove the queue item. The queue item persists only if no response arrives (batch run, no interaction).
   • No match: Ask inline: "I don't recognize '[name]' — want to create it? (yes / no, just write a plain note)". Add a review queue item simultaneously (person → ReviewQueue/review-people.md, project → ReviewQueue/review-work.md). Once the user responds — either way — remove the queue item and proceed. The queue item persists only if no response arrives.
4. Report all destinations written.

Entry formats by destination:

Project timeline (prepend to ## Timeline — newest-first):

- {content} [User] (capture, {user.name}, {YYYY-MM-DD})

Person Recognition (prepend to ## Recognition — newest-first):

- {what they did} — {context} [User] (capture, {user.name}, {YYYY-MM-DD})

Person Observation (prepend to ## Observations — newest-first):

- **{strength|growth-area|contribution}:** {observation} [User] (capture, {user.name}, {YYYY-MM-DD})

Contributions log (prepend to ## Contributions — Week of {YYYY-MM-DD} in Journal/contributions-{YYYY-MM-DD}.md — Monday date, newest-first):

- **{category}:** {description} [User] (capture, {user.name}, {YYYY-MM-DD})

Worked example:

User: "capture: Sarah did a great job handling the auth incident, and the auth migration is now unblocked"

Decompose:

• Recognition for Sarah (explicit) → People/sarah-chen.md Recognition section → [User]
• Auth migration unblocked (explicit project update) → Projects/auth-migration.md Timeline → [User]
• No first-person language → no user contribution inferred

Writes:

1. People/sarah-chen.md — Recognition (prepend): - Great handling of auth incident — resolved within SLA [User] (capture, {user.name}, 2026-04-05)
2. Projects/auth-migration.md — Timeline (prepend): - Blocker resolved — migration unblocked [User] (capture, {user.name}, 2026-04-05)

Output: "Wrote 2 entries: recognition for Sarah, timeline update for auth migration."

---

👀 Observations

Trigger: "observation about Sarah: [text]", "feedback note for Alex: [text]"

How:

1. Resolve person via fuzzy name resolution.
2. Determine observation type: strength, growth-area, or contribution.
   • Explicit praise → strength
   • Explicit concern or development feedback → growth-area
   • Contribution noted → contribution
   • Unclear → ask the user which type applies
3. Check if this should also go to Pending Feedback (if it's a coaching point worth delivering).
4. Append to People/{person-slug}.md → Observations section.
5. If it's a growth area with coaching potential, also append to Pending Feedback section.

Observation entry (prepend to ## Observations — newest-first):

- **{type}:** {observation} [User] (capture, {user.name}, {YYYY-MM-DD})

Pending Feedback entry (when observation has coaching value; append to ## Pending Feedback):

- {observation} — Coaching note: {framing} [User] (capture, {YYYY-MM-DD})

---

🏆 Recognition Tracking

Trigger: "recognition for Sarah: [text]", "log that Sarah [accomplishment]"

Different from the observation capture above: this is a recognition entry specifically (for compiling into recognition drafts later via /myna:draft).

How:

1. Resolve person.
2. Prepend to People/{person-slug}.md → ## Recognition section (newest-first).
3. Entry format: - {what they did} — {context} [User] (capture, {user.name}, {YYYY-MM-DD})

---

✅ Task Management

Add Task

Trigger: "add task: [description]", "create task: [description]", "TODO: [description]"

How:

1. Parse the task from natural language. Extract:
   • Title (short, scannable)
   • Project (from context or explicit mention — fuzzy match against projects.yaml)
   • Due date (resolve relative dates to absolute: "by Friday" → 2026-04-11)
   • Priority (explicit or inferred from language — "urgent", "ASAP" → high)
   • Effort estimate (if mentioned)
   • Type: task (default), reply-needed (if "need a reply from...")
   • Person (for tasks with an owner or tasks assigned to others)
2. Mark each field as explicit or (inferred).
3. Write directly if all fields are explicit. If any field is inferred: add the task with [review-status:: pending] to the destination AND add a review queue item to ReviewQueue/review-work.md immediately, then ask the user inline to clarify the inferred fields. If the user resolves it, update the task, remove [review-status:: pending], and remove the queue item. If no response, the queue item persists as the safety net.

Task format:

- [ ] {title} 📅 {YYYY-MM-DD} ⏫ [project:: {name}] [type:: {task|reply-needed}] [person:: {name}] [effort:: {estimate}] [review-status:: pending] [User] (capture, {date})

Include only fields that have values.

Type rules:

• task — default for all action items, regardless of who owns them; use [person::] to indicate the owner
• reply-needed — "need a reply from X"

When the user specifies a project AND a person for a task (e.g., "Add task 'review PR' to Project Alpha for Sarah"), create [type:: task] with [person:: [[Sarah Chen]]] as the owner.

Person field rules:

• Self-assigned tasks ([type:: task] with no explicit owner): always include [person:: [[{user.name}]]] using user.name from workspace.yaml
• Project tasks with an explicit owner ([type:: task] with a named person): [person:: [[{their-name}]]]
• Tasks assigned to others or reply-needed: [person:: [[{their-name}]]] using the name as it appears in people.yaml

Destination: Project file at Projects/{project-slug}.md — prepend to ## Tasks section (newest-first raw task storage). If no project is specified, ask the user which project before writing.

Worked examples:

User: "add task: review Sarah's design doc by Friday, high priority"

Parse:

• Title: Review Sarah's design doc
• Due: Friday → 2026-04-11 (explicit)
• Priority: high (explicit)
• Project: not mentioned → inferred from context or ask
• Person: not specified (user is the owner — self-assigned)

If project can't be inferred: Ask: "Which project is this for? Or would you like to create a personal project for standalone tasks like this?"

If user says "auth migration":

- [ ] Review Sarah's design doc 📅 2026-04-11 ⏫ [project:: [[Auth Migration]]] [type:: task] [person:: [[Sam Bennett]]] [User] (capture)

All fields explicit → write directly, no review queue.

User: "Add task 'review PR' to Project Alpha for Sarah"

Parse:

• Title: Review PR
• Project: Project Alpha (explicit)
• Person: Sarah (explicit owner)
• Type: task

- [ ] Review PR [project:: [[Project Alpha]]] [type:: task] [person:: [[Sarah Chen]]] [User] (capture)

User: "hand the onboarding doc review to Sarah"

Parse:

• Title: Onboarding doc review
• Person: Sarah (explicit owner)
• Type: task (person field carries ownership)

- [ ] Onboarding doc review [project:: [[{project}]]] [type:: task] [person:: [[Sarah Chen]]] [User] (capture)

---

Add Recurring Task

Trigger: "create recurring task: [description]", "set up weekly task: [description]"

How:

1. Parse title and recurrence interval from the request.
2. Recurrence field uses Tasks plugin syntax: 🔁 every {interval}
   • "weekly" → 🔁 every week
   • "daily" → 🔁 every day
   • "biweekly" → 🔁 every 2 weeks
   • "monthly" → 🔁 every month
   • "quarterly" → 🔁 every 3 months
3. Write to appropriate project file or daily note.

Recurring task format:

- [ ] {title} 🔁 every {interval} [project:: [[{name}]]] [type:: task] [person:: [[{user.name}]]] [User] (capture, {date})

---

📁 Project / Person File Management

Update Project Status

Trigger: "update status of auth migration to paused", "mark platform api as complete"

How:

1. Resolve project via fuzzy match.
2. Edit frontmatter: status: {active|paused|complete}
3. Prepend timeline entry (newest-first): - Status changed to {status} [User] (capture, {user.name}, {YYYY-MM-DD})

Create Project File

Trigger: "create project file for [project]", "add project [name]"

How:

1. Confirm project name and basic info (description, key people). Ask if not provided.
2. Create Projects/{slug}.md from template. If template exists at _system/templates/project.md, use it. Otherwise create minimal structure:

Minimal project file structure (sections in order):

• Frontmatter: aliases: ["{Project Display Name}"] — enables wiki-link resolution from [[Project Display Name]]
• Tags line: #project #{project-tag}
• ## Overview — Description, Status (active), Key People as wiki-links using readable alias form ([[Sarah Chen]])
• ## Timeline — newest-first chronological log; new entries prepended
• ## Tasks — raw task storage; all skills write here; new tasks prepended (newest-first)
• ## Open Tasks — Dataview live-view block; skills do NOT write here
• ## Links
• ## Notes

3. Show file path.

Create Person File

Trigger: "create person file for [name]", "add [name] to people"

How:

1. Look up in people.yaml — if found, use those fields. If not, ask for relationship tier (required).
2. Create People/{slug}.md:

---
created: {YYYY-MM-DD}
aliases: ["{full name}"]
---

#person #{relationship-tier}

## Overview

**Name:** {full name}
**Role:** {role or unknown}
**Team:** {team or unknown}
**Relationship:** {tier}

## Communication Preferences

## Observations

## Pending Feedback

## Recognition

## Personal Notes

## Meeting History

- [[{Full Name} 1:1]] — 1:1 meetings

3. Show file path.

---

⚠️ Edge Cases

Entity not found (person): Ask inline: "I don't recognize '[name]' — want to add them to people.yaml and create a person file? (yes / no, just write a plain note)". At the same time, add a review queue item to ReviewQueue/review-people.md: - [ ] Unknown person '[name]' mentioned in capture — create person file or update people.yaml (capture, {date}). Once the user responds — either way — remove the queue item and proceed accordingly (create person file, or write entry to daily note as plain note). The queue item persists only if no inline response arrives (batch run, no interaction).

Entity not found (project): Ask inline: "I don't recognize '[name]' — is this a new project? (yes to create, no to just write a note)". At the same time, add a review queue item to ReviewQueue/review-work.md: - [ ] Unknown project '[name]' mentioned in capture — create project file or update projects.yaml (capture, {date}). Once the user responds — either way — remove the queue item and proceed accordingly (create project file, or write entry to daily note as plain note). The queue item persists only if no inline response arrives.

Multiple matches (person): Ask inline: "I found multiple matches for '[name]': [list candidates]. Which one?" At the same time, add a review queue item to ReviewQueue/review-people.md: - [ ] Ambiguous person '[name]' in capture — candidates: [list] (capture, {date}). Once the user picks, resolve the entity, write the entry to the correct destination, and remove the queue item. The queue item persists only if no inline response arrives (batch run, no interaction).

Deduplication: Before writing, check the target section for near-duplicate entries (same action + same entity from the same source). Skip duplicates: "This looks like it may already be logged in auth-migration.md — skipping to avoid duplicate."

Missing target file: If a project or person file doesn't exist, create it (minimal structure) before writing the entry. Mention: "Created new file for {entity}."

No identifiable entity: If capture text has no recognizable person, project, or task ("the meeting went well"), ask: "Where should I log this? (project name, person name, or personal notes)"