Exploration
Technical deep dives within existing projects. Think through problems, evaluate options, investigate approaches. Captures insights to explorations/ for future iterations.
Available Environment Variables
These env vars are available in bash commands (use ${VAR} syntax):
${PROJECT_NAME}- Current project name${PROJECT_ROOT}- Current project code directory (e.g.,~/development/projects/argus)${WORKFLOW_PROJECTS}- Obsidian projects root (e.g.,~/obsidian/projects)
Output location:
- Explorations save to:
~/obsidian/reference/technical/explorations/{PROJECT_NAME}/ - TODO: Replace hardcoded path with
{OBSIDIAN_ROOT}variable when available
Mindset
Explore WITH them — not interviews, real collaborative thinking. Follow their energy, challenge assumptions, stay concrete.
Read actual code — Use Read and Grep to examine how things work. Evidence over speculation.
Find hidden gems:
- The constraint that isn't real
- The simple solution they dismissed
- The pattern from another domain
Process
- Engage immediately — No meta-commentary, just start thinking together
- Investigate real code — Use Read/Grep, reference file:line locations, build on what exists
- Track patterns mentally — Problems crystallizing, approaches forming, decisions being made
- Challenge constructively — "What about edge case X?", "What happens at scale?"
- Build on energy — Dig deeper into excitement, connect across domains
Examples
Example 1: Architecture decision
User: "How should we structure the plugin system?"
→ Read existing code to understand current patterns
→ Discuss options, trade-offs
→ On "save this exploration" → create architecture-decision.md
Example 2: Technical investigation
User: "The auth flow feels slow, let's explore why"
→ Use Grep/Read to trace the flow
→ Identify bottlenecks together
→ On "document these insights" → create auth-performance.md
Example 3: Options evaluation
User: "Should we use SQLite or Postgres for this?"
→ Discuss constraints, scale requirements
→ On "capture this" → create database-selection.md
When to Save
User signals with: "save this exploration", "capture this", "document these insights", "write this down"
Do NOT ask if they want to save — wait for the trigger.
Saving Explorations
Location: ~/obsidian/reference/technical/explorations/{PROJECT_NAME}/{slug}.md
Slug: Descriptive, lowercase-hyphen (skills-vs-routing.md), not timestamps (exploration-20251017.md)
Template: Reference assets/EXPLORATION_TEMPLATE.md, adapt as needed
Required: Title, date, context, key insights, decisions (if any)
Critical: Capture the JOURNEY, not just destination. Show how thinking evolved.
Write concretely:
- Good: "Discovered routing can't scale beyond 20 skills due to token costs"
- Bad: "We discussed various approaches"
Include file references if code was examined: src/hooks/hook.ts:45
Registering in Global Index
After saving an exploration, append entry to ~/obsidian/reference/technical/explorations/index.md:
Entry format:
- [[{PROJECT_NAME}/{slug}|{Title}]] - {YYYY-MM-DD} - {one-line summary}
Rules:
- Group entries by project
- Create project section (
### [[{PROJECT_NAME}]]) if first exploration for that project - Add new entries at top of project section (most recent first)
- Update the
updated:frontmatter field to current date
Resources
assets/
Contains EXPLORATION_TEMPLATE.md - the template structure for saving explorations. Adapt sections as needed for each exploration.
references/
Contains example explorations demonstrating different styles:
lore-mvp-event-system.md- Clean architectural explorationskills-vs-routing-architecture.md- Complex decision-making with trade-offs2025-10-07-jarvis-audio-briefings.md- Feature design exploration
These examples show different approaches to capturing explorations. Use them for inspiration, not strict templates.