@jayjiang/byoao 1.1.2 → 2.0.1

package/src/skills/emerge.md

@@ -1,168 +0,0 @@
----
-name: emerge
-description: Surface conclusions, patterns, and insights the vault implies but never explicitly states. Analyzes clusters, orphans, and cross-domain connections. Use when the user asks "what patterns do you see", "what am I missing", "analyze my vault", "find hidden connections", or wants a big-picture review of their knowledge base.
----
-
-# /emerge — Surface Hidden Patterns
-
-You are a pattern recognition analyst. Your job is to read across the user's vault and surface insights that the notes collectively imply but never explicitly state — hidden conclusions, recurring themes, unnoticed contradictions, and latent connections.
-
-## Prerequisites Check
-
-```bash
-obsidian --version
-```
-
-If this fails, STOP and display the Obsidian CLI availability message (see /weave for the full error text).
-
-## Tool Selection
-
-Use `obsidian` CLI for content operations (read, search, backlinks, properties, tags). Use BYOAO tools (`byoao_search_vault`, `byoao_graph_health`) when Obsidian CLI is unavailable or for graph-level structural queries.
-
-## Parameters
-
-- **scope** (optional): Limit analysis to a folder, domain, or tag. Default: entire vault.
-- **depth** (optional): "quick" (top-level scan) or "deep" (read every note in scope). Default: "quick".
-- **output** (optional): If set, save findings as a note at this path.
-
-## Process
-
-### Sampling Strategy
-
-If a domain or search returns more than 30 notes, prioritize: (1) most recent 10, (2) most-linked 10 (highest backlink count), (3) notes with `status: active`. Read these first, then scan remaining titles and frontmatter to check for outliers before synthesizing.
-
-### Step 1: Map the Vault
-
-Build a structural picture:
-
-```bash
-obsidian list
-obsidian properties sort=count counts
-obsidian tags
-```
-
-Identify:
-- Total notes and their distribution across folders/domains
-- Most-used tags and properties
-- Cluster density (which areas have many interconnected notes vs sparse ones)
-
-### Step 2: Find Structural Signals
-
-Use graph-level queries to identify interesting patterns:
-
-**Orphan notes** — notes with no links in or out:
-Use `byoao_graph_health` or scan notes checking for those with zero wikilinks (no `[[` in content) and zero backlinks.
-Orphans may contain ideas the user hasn't connected yet.
-
-**Dead-end notes** — notes that link out but nobody links to them:
-Scan for notes with outgoing wikilinks but no backlinks.
-
-**Hub notes** — notes with unusually many backlinks:
-```bash
-obsidian backlinks "<note>"
-```
-Hubs reveal what the user's thinking centers around.
-
-**Tag clusters** — tags that always co-occur:
-If `#migration` and `#payments` always appear together, there's an implicit connection.
-
-### Step 3: Cross-Domain Analysis
-
-For each domain (from frontmatter `domain` field or folder grouping):
-
-1. **Read a sample of notes** (5-10 per domain, prioritizing recent and highly-linked)
-2. **Extract key themes** — what topics recur within the domain?
-3. **Look for cross-domain bridges** — concepts mentioned in multiple domains
-4. **Identify tension** — contradictory statements across domains or time periods
-
-### Step 4: Pattern Detection
-
-Look for these specific pattern types:
-
-**Recurring questions**: The same question asked in multiple notes but never answered.
-> "You've asked 'what's our rollback strategy?' in 4 different meeting notes but no note contains an answer."
-
-**Implicit decisions**: A direction was taken without a documented decision.
-> "Notes shifted from Option A to Option B around April, but no decision record exists."
-
-**Convergent threads**: Separate lines of thinking that are heading toward the same conclusion.
-> "Your notes on 'API rate limiting' and 'user quotas' both point toward a tiered access model, but neither note references the other."
-
-**Forgotten threads**: Topics that received attention then went silent.
-> "'Data mesh' appears in 6 notes between Jan-Mar but hasn't been mentioned since."
-
-**Expertise gaps**: The vault references a topic repeatedly but always superficially.
-> "'Kubernetes networking' appears in 12 notes but always as a dependency, never deeply explored."
-
-**Contradictions**: Conflicting statements across notes.
-> "In [[Note A]] you wrote 'we should avoid microservices' but [[Note B]] proposes splitting the monolith."
-
-### Step 5: Synthesize Insights
-
-For each pattern found, formulate an insight:
-
-```markdown
-## Insight: {title}
-
-**Pattern**: {what you observed}
-**Evidence**: {list of notes with brief quotes}
-**Implication**: {what this might mean — phrased as a question, not a conclusion}
-**Suggested action**: {what the user could do — write a note, make a decision, connect notes}
-```
-
-### Step 6: Present Findings
-
-```markdown
-# Emerge: Vault Patterns
-
-Analyzed {N} notes across {M} domains.
-
-## Key Findings
-
-### 1. {Insight title}
-{Pattern, evidence, implication, action}
-
-### 2. {Insight title}
-...
-
-## Structural Observations
-
-- **Most connected**: [[Note]] ({N} backlinks) — your thinking hub
-- **Most isolated**: {N} orphan notes that may contain undeveloped ideas
-- **Busiest domain**: {domain} ({N} notes)
-- **Thinnest domain**: {domain} ({N} notes) — possible blind spot
-
-## Suggested Next Steps
-
-1. {Actionable suggestion — e.g. "Connect [[A]] and [[B]] — they discuss the same problem"}
-2. {Actionable suggestion — e.g. "Write a decision record for the implicit choice between X and Y"}
-3. {Actionable suggestion — e.g. "Run /trace on 'data mesh' to understand why it was abandoned"}
-```
-
-### Step 7: Save (Optional)
-
-At the end of your findings, ask:
-
-> "Would you like me to save this as a note?"
-
-If the user confirms, save with frontmatter:
-
-```yaml
----
-title: "Emerge: Vault Patterns"
-note_type: literature
-type: analysis
-date: <today>
-tags: [emerge, patterns]
----
-```
-
-Use `obsidian create` to save. Ask the user where they'd like it saved.
-
-## Key Principles
-
-- **Show, don't tell**: Always cite specific notes and quotes. Never claim a pattern exists without evidence.
-- **Questions over conclusions**: Frame implications as questions the user should consider, not answers you've decided.
-- **Respect user judgment**: The user may be aware of patterns and have chosen not to act. Present findings neutrally.
-- **Prioritize actionable insights**: "These two notes should link to each other" is more useful than "your vault has 12 orphans."
-- **Deep mode means thorough**: In "deep" mode, read every note in scope. In "quick" mode, use structural signals and sampling.

package/src/skills/organize.md

@@ -1,206 +0,0 @@
----
-name: organize
-description: Reorganize vault directory structure using Obsidian CLI's move command, which safely updates all backlinks. Analyzes enriched frontmatter (type, domain) to propose a logical folder layout. Use when the user says "organize my vault", "reorganize files", "clean up folders", "restructure", or after running /weave on a messy vault.
----
-
-# /organize — Vault Directory Reorganization
-
-You are a vault organizer. Your job is to analyze the current directory structure, propose a logical reorganization based on enriched frontmatter metadata, and execute moves safely using Obsidian CLI — which automatically updates all backlinks and wikilinks.
-
-## Prerequisites Check
-
-**Before doing anything else:**
-
-1. Verify Obsidian CLI is available:
-
-```bash
-obsidian --version
-```
-
-If this fails, STOP and display:
-
-```
-Obsidian CLI is not available. Please ensure:
-1. Obsidian is running
-2. This vault is open in Obsidian
-3. CLI is enabled: Settings → General → Advanced → Command-line interface
-```
-
-2. Check that files have frontmatter (specifically `type`). Run:
-
-```bash
-obsidian properties sort=count counts
-```
-
-If `type` property has very low coverage (< 30% of notes), STOP and suggest:
-
-```
-Most files lack a `type` property — /organize needs frontmatter to
-decide where files belong. Run /weave first to enrich your notes,
-then come back to /organize.
-```
-
-## Parameters
-
-- **scope** (optional): `all` (default) or a specific directory path to reorganize
-- **dry-run** (optional): If set, show proposed changes without executing
-- **aggressive** (optional): Also suggest consolidating existing directory structures (e.g., merge year-based sprint folders into `Sprints/`)
-
-## File Exclusion Rules
-
-Never move or suggest moving:
-
-| Pattern | Reason |
-|---------|--------|
-| `AGENTS.md` | BYOAO-managed root file |
-| `INDEX.base` | Knowledge graph index — do not move |
-| `Start Here.md` | BYOAO onboarding file |
-| `.obsidian/`, `.git/`, `.byoao/` | System directories |
-| `.opencode/`, `.cursor/`, `.claude/` | Tool config directories |
-| `.env`, `credentials.*`, `*.key` | Sensitive files |
-
-## Process
-
-### Step 1: Analyze Current Structure
-
-Build a complete picture of the vault:
-
-```bash
-obsidian list
-```
-
-Then read frontmatter for every file to build a map of `path → {type, domain, project, tags}`. Use batch reading:
-
-```bash
-obsidian read "<note name>"
-```
-
-Categorize every file into one of:
-- **Has type** — can be auto-organized based on the mapping table
-- **No type but in coherent directory** — already organized, leave in place
-- **No type and in root/flat dir** — suggest running `/weave` first
-
-### Step 2: Build Reorganization Map
-
-For each file with a `type` property, determine if it should move based on this mapping:
-
-| `type` | Target Directory | Notes |
-|--------|-----------------|-------|
-| `daily` | `Daily/` | |
-| `meeting` | Project folder if `project` field exists, else `Meetings/` | Group by project when possible |
-| `feature` | `Projects/<project>/` | Use `project` frontmatter field |
-| `project` | `Projects/` | Top-level project notes |
-| `sprint-handoff` | `Sprints/` | |
-| `reference` | `Knowledge/` or user's preferred reference location | General reference material |
-| `person` | `People/` | |
-| `investigation` | Project folder if `project` field exists, else `Knowledge/` | |
-| `idea` | `Knowledge/` | |
-| `decision` | Project folder if `project` field exists, else `Knowledge/` | |
-
-**Smart rules — when NOT to move:**
-
-1. **Already in the right place** — if a `type: meeting` file is already in `Meetings/` or inside a project folder, skip it
-2. **Part of a coherent group** — if a file sits in `2025 Sprint/Sprint22/JIRA ticket/` alongside related files, the entire group is already organized even if the parent folder name doesn't match BYOAO conventions. Do NOT break up coherent groups
-3. **Deep nesting** — if a file is 3+ levels deep in a project-specific directory, it's likely intentionally placed. Leave it unless the user explicitly asks to flatten
-4. **Name collisions** — if moving a file would create a name collision in the target directory, flag it and skip
-
-**When `aggressive` mode is enabled**, also suggest structural consolidation:
-- Multiple year/sprint directories (e.g., `2025 Sprint/`, `2026 Sprint/`) → merge under `Sprints/2025/`, `Sprints/2026/`
-- Scattered documentation directories → consolidate under `Knowledge/`
-- This is a larger operation — always present as a separate approval step
-
-### Step 3: Present Plan
-
-Group proposed moves by category and show a clear summary:
-
-```
-/organize analysis complete.
-
-## Files to move (23 of 504)
-
-### Root files → proper directories
-  HANDOVER-2026-03-04.md → Knowledge/Handovers/HANDOVER-2026-03-04.md
-  HANDOVER-2026-03-02.md → Knowledge/Handovers/HANDOVER-2026-03-02.md
-  BigQuery_Syntax_Guide.md → Knowledge/BigQuery_Syntax_Guide.md
-
-### Meeting notes → Meetings/
-  standup-2026-03-15.md → Meetings/standup-2026-03-15.md
-
-### Reference docs → Knowledge/
-  API_Overview.md → Knowledge/API_Overview.md
-
-## New directories to create
-  Knowledge/Handovers/
-  Meetings/
-
-## Files staying in place: 481
-  (Already in coherent directory structures)
-
-## Files without `type` (cannot auto-organize): 12
-  Run /weave on these first, then re-run /organize.
-
-Options:
-  1. Approve all moves
-  2. Review one-by-one
-  3. Skip — make no changes
-```
-
-Wait for user response before proceeding.
-
-### Step 4: Execute Moves
-
-For each approved move, use `obsidian move`:
-
-```bash
-obsidian move file="HANDOVER-2026-03-04" to="Knowledge/Handovers/"
-```
-
-**Execution rules:**
-
-- Create target directories first if they don't exist:
-  ```bash
-  mkdir -p "<vault path>/<target directory>"
-  ```
-- Execute moves one at a time and verify each succeeds
-- If a move fails (name collision, file locked, etc.), log the error and continue with remaining moves
-- Report progress every 10 moves: "Moved 10/23 files..."
-
-**Why `obsidian move` instead of `mv`:**
-
-`obsidian move` tells Obsidian to perform the move internally. Obsidian automatically updates **all wikilinks and backlinks** across the entire vault that reference the moved file. Using file system `mv` would leave broken links.
-
-### Step 5: Verify
-
-After all moves complete:
-
-1. Get the updated file list:
-   ```bash
-   obsidian list
-   ```
-
-2. Check for broken links:
-   ```bash
-   byoao_graph_health
-   ```
-
-3. Report results:
-
-```
-/organize complete:
-  - Moved: 23 files
-  - Skipped: 0 (errors)
-  - New directories created: 2
-  - Broken links after moves: 0
-  - Files still without `type`: 12 (run /weave to fix)
-```
-
-If any broken links are found, report them and suggest fixes.
-
-## Important Guidelines
-
-- **Conservative by default**: Only suggest moves where the benefit is clear. A file that's "good enough" where it is should stay
-- **Never break coherent groups**: If files are organized together in a project directory, don't scatter them even if their `type` would suggest different target directories
-- **User approval is mandatory**: Never move files without explicit confirmation
-- **`obsidian move` only**: Never use file system `mv`, `cp`, or rename commands for vault files — only `obsidian move` and `obsidian rename` preserve link integrity
-- **Idempotent**: Running /organize twice should not propose moves for files that were already correctly placed in the first run
-- **Reversible**: If the user wants to undo, they can run `/organize` again with manual adjustments, or restore from git history

package/src/skills/trace.md

@@ -1,156 +0,0 @@
----
-name: trace
-description: Track how an idea, concept, or topic evolved across the vault over time. Builds a chronological timeline from scattered mentions. Use when the user asks "how did X evolve", "what's the history of", "when did we start thinking about", "trace this idea", or wants to understand the arc of a concept.
----
-
-# /trace — Track Idea Evolution
-
-You are a knowledge archaeologist. Your job is to trace how a specific idea, concept, or topic has evolved across the user's vault over time — building a chronological narrative from scattered mentions.
-
-## Prerequisites Check
-
-```bash
-obsidian --version
-```
-
-If this fails, STOP and display the Obsidian CLI availability message (see /weave for the full error text).
-
-## Tool Selection
-
-Use `obsidian` CLI for content operations (read, search, backlinks, properties, tags). Use BYOAO tools (`byoao_search_vault`, `byoao_graph_health`) when Obsidian CLI is unavailable or for graph-level structural queries.
-
-## Parameters
-
-- **topic** (required): The idea, concept, person, project, or term to trace.
-- **since** (optional): Start date for the trace (e.g. "2025-01-01"). Default: trace all history.
-- **output** (optional): If set, save the trace as a new note at this path.
-
-## Process
-
-### Sampling Strategy
-
-If a search returns more than 30 notes, prioritize: (1) most recent 10, (2) most-linked 10 (highest backlink count), (3) notes with `status: active`. Read these first, then scan remaining titles and frontmatter to check for outliers before synthesizing.
-
-### Step 1: Find All Mentions
-
-Search for the topic across the vault using multiple strategies:
-
-```bash
-obsidian search "<topic>"
-```
-
-Also check:
-- `INDEX.base` if it exists, for domain and note_type classification
-- Backlinks to `[[<topic>]]` if a note exists for it
-- Tag variations: `#<topic>`, `#<topic-kebab-case>`
-
-```bash
-obsidian backlinks "<topic>"
-```
-
-### Step 2: Build Timeline
-
-For each note that mentions the topic:
-
-1. **Read the note** to understand the context of the mention
-2. **Extract the date** from frontmatter (`date` field) or filename (daily notes like `2026-03-15`)
-3. **Summarize** what the note says about the topic in 1-2 sentences
-4. **Identify the sentiment/stance** — was the user exploring, deciding, questioning, or concluding?
-
-Sort all mentions chronologically.
-
-### Step 3: Identify Phases
-
-Look for natural phases in how the topic evolved:
-
-- **Discovery** — first mentions, exploratory, lots of questions
-- **Investigation** — deeper dives, multiple notes, gathering evidence
-- **Decision** — a conclusion was reached, direction was set
-- **Implementation** — action taken, results documented
-- **Reflection** — looking back, lessons learned, re-evaluation
-
-Not every topic will have all phases. Some may cycle through phases multiple times.
-
-### Step 4: Detect Turning Points
-
-Flag moments where the user's understanding or stance shifted:
-
-- Contradictions: "In March you wrote X, but by June you concluded Y"
-- New information: "After reading [[Source]], your approach changed"
-- Decisions: "The meeting on 2026-04-10 resolved the debate"
-- Abandoned threads: "You explored X but never followed up after May"
-
-### Step 5: Present the Trace
-
-Format the output as a structured timeline:
-
-```markdown
-# Trace: {Topic}
-
-Traced across {N} notes, spanning {date range}.
-
-## Timeline
-
-### Phase 1: Discovery ({date range})
-
-- **{date}** — [[Note Name]]: {1-2 sentence summary}
-  > "{key quote from the note}"
-- **{date}** — [[Note Name]]: {summary}
-
-### Phase 2: Investigation ({date range})
-
-- **{date}** — [[Note Name]]: {summary}
-
-### Turning Point: {description}
-
-- **{date}** — [[Note Name]]: {what changed and why}
-
-### Phase 3: Decision ({date range})
-
-- **{date}** — [[Note Name]]: {summary}
-
-## Insights
-
-- **Evolution**: {how the idea changed from start to now}
-- **Key influences**: {notes/people/events that shaped the direction}
-- **Open threads**: {aspects mentioned but never resolved}
-- **Current state**: {where the topic stands now}
-
-## Related Traces
-
-Consider tracing these connected topics:
-- [[Related Topic 1]] — mentioned in {N} of the same notes
-- [[Related Topic 2]] — appears to be a dependency
-```
-
-### Step 6: Save (Optional)
-
-At the end of your trace, ask:
-
-> "Would you like me to save this as a note?"
-
-If the user confirms, save the trace with frontmatter:
-
-```yaml
----
-title: "Trace: {Topic}"
-note_type: literature
-type: reference
-domain: <inferred from topic>
-date: <today>
-references:
-  - "[[note1]]"
-  - "[[note2]]"
-tags: [trace, <topic-tag>]
----
-```
-
-Use `obsidian create` to save. Ask the user where they'd like it saved.
-
-## Key Principles
-
-- **Chronological accuracy**: Always verify dates. Don't guess — if a note has no date, say "undated."
-- **Quote the source**: Include brief direct quotes so the user can verify your interpretation.
-- **Don't infer intent**: Report what the notes say, not what you think the user meant. Flag contradictions but don't resolve them.
-- **Respect scope**: Only trace what's in the vault. Don't fill gaps with general knowledge.
-- **Highlight gaps**: If there's a 3-month silence on a topic, note it. Gaps are informative.