@goondocks/myco 0.1.0 → 0.2.5

package/dist/src/capture/prompts/prompts/debugging.md

@@ -1,91 +0,0 @@
----
-name: debugging
-description: For debugging sessions with errors
-activity_filter: Read,Edit,Bash
-min_activities: 2
----
-
-You are analyzing a debugging session to capture the root cause and fix.
-
-## Context
-
-The developer was debugging an issue.
-
-Duration: {{session_duration}} minutes
-Files investigated: {{files_read}}
-Files modified: {{files_modified}}
-Errors: {{errors}}
-
-### Debugging Activity
-
-{{activities}}
-
-## Observation Types
-
-{{observation_types}}
-
-## Importance Levels
-
-Rate each observation's importance based on its value for future sessions:
-
-- **high**: Non-obvious insight that would cause bugs, confusion, or wasted time if forgotten. Cannot be easily rediscovered from code alone.
-- **medium**: Useful context that saves time but could be rediscovered with investigation.
-- **low**: Nice-to-know information that is easily found from code or already documented elsewhere. Skip if already captured in project docs.
-
-Prefer fewer high-quality observations over many low-importance ones.
-
-## Task
-
-Extract the debugging journey: what was the symptom, what was investigated, what was the root cause, and how was it fixed.
-
-Focus on:
-- The initial error or symptom
-- Wrong assumptions or dead ends
-- The actual root cause
-- The fix and why it works
-- How to avoid this in the future
-
-Prefer **bug_fix** and **gotcha** types for debugging sessions.
-
-## Examples
-
-**Good observation** (specific root cause and fix — extract this):
-```json
-{
-  "type": "bug_fix",
-  "observation": "SQLite LIMIT clause was string-interpolated, allowing SQL injection. Fix: use parameterized query with LIMIT ? and push value to params array.",
-  "context": "src/index/sqlite.ts",
-  "importance": "high"
-}
-```
-
-**Bad observation** (too vague — skip this):
-```json
-{
-  "type": "bug_fix",
-  "observation": "Fixed a database error",
-  "context": "src/index",
-  "importance": "medium"
-}
-```
-
-## Output Format
-
-```json
-{
-  "observations": [
-    {
-      "type": "{{type_names}}",
-      "observation": "Root cause and fix description",
-      "context": "File where bug was",
-      "importance": "high|medium|low"
-    }
-  ],
-  "summary": "Brief description of bug and fix"
-}
-```
-
-Guidelines:
-- Extract at most 5 observations per session. Prefer fewer, higher-quality observations over many low-value ones.
-
-Respond ONLY with valid JSON.

package/dist/src/capture/prompts/prompts/exploration.md

@@ -1,88 +0,0 @@
----
-name: exploration
-description: For sessions focused on reading/searching code
-activity_filter: Read,Grep,Glob
-min_activities: 3
----
-
-You are analyzing an exploration/research session to extract useful learnings.
-
-## Context
-
-The developer was exploring the codebase to understand how things work.
-
-Duration: {{session_duration}} minutes
-Files explored: {{files_read}}
-
-### Search and Read Activity
-
-{{activities}}
-
-## Observation Types
-
-{{observation_types}}
-
-## Importance Levels
-
-Rate each observation's importance based on its value for future sessions:
-
-- **high**: Non-obvious insight that would cause bugs, confusion, or wasted time if forgotten. Cannot be easily rediscovered from code alone.
-- **medium**: Useful context that saves time but could be rediscovered with investigation.
-- **low**: Nice-to-know information that is easily found from code or already documented elsewhere. Skip if already captured in project docs.
-
-Prefer fewer high-quality observations over many low-importance ones.
-
-## Task
-
-Extract observations about the codebase structure, patterns, or gotchas discovered during exploration.
-
-Focus on:
-- How specific features are implemented
-- Important patterns or conventions used
-- Non-obvious relationships between components
-- Things that surprised the developer
-
-Prefer **discovery** and **gotcha** types for exploration sessions.
-
-## Examples
-
-**Good observation** (non-obvious behavior — extract this):
-```json
-{
-  "type": "discovery",
-  "observation": "Env vars set in .claude/settings.json don't get shell expansion — tilde (~) paths must be expanded manually in code via os.homedir().",
-  "context": "src/vault/resolve.ts",
-  "importance": "high"
-}
-```
-
-**Bad observation** (obvious from code structure — skip this):
-```json
-{
-  "type": "discovery",
-  "observation": "The project has a src directory with TypeScript files",
-  "context": "src/",
-  "importance": "low"
-}
-```
-
-## Output Format
-
-```json
-{
-  "observations": [
-    {
-      "type": "{{type_names}}",
-      "observation": "What was learned",
-      "context": "File or feature area",
-      "importance": "high|medium|low"
-    }
-  ],
-  "summary": "Brief description of what was explored"
-}
-```
-
-Guidelines:
-- Extract at most 5 observations per session. Prefer fewer, higher-quality observations over many low-value ones.
-
-Respond ONLY with valid JSON.

package/dist/src/capture/prompts/prompts/extraction.md

@@ -1,93 +0,0 @@
----
-name: extraction
-description: General observation extraction from session activities
-min_activities: 1
----
-
-You are analyzing a coding session to extract important observations for future reference.
-
-## Session Activity
-
-Duration: {{session_duration}} minutes
-Files read: {{files_read}}
-Files modified: {{files_modified}}
-Files created: {{files_created}}
-Errors encountered: {{errors}}
-
-### Tool Executions
-
-{{activities}}
-
-## Observation Types
-
-Extract observations using these types:
-
-{{observation_types}}
-
-## Importance Levels
-
-Rate each observation's importance based on its value for future sessions:
-
-- **high**: Non-obvious insight that would cause bugs, confusion, or wasted time if forgotten. Cannot be easily rediscovered from code alone.
-- **medium**: Useful context that saves time but could be rediscovered with investigation.
-- **low**: Nice-to-know information that is easily found from code or already documented elsewhere. Skip if already captured in project docs.
-
-Prefer fewer high-quality observations over many low-importance ones.
-
-## Session Context Awareness
-
-Consider the session's activity pattern when rating observation importance:
-
-- **Planning/investigation sessions** (many reads, few edits): Prefer lower importance ratings for observations that describe current problems or temporary state rather than permanent learnings.
-- **Implementation sessions** (significant edits): Observations about decisions made, patterns established, or gotchas encountered are more likely to be permanent learnings and may warrant higher importance.
-
-When in doubt, prefer a conservative (lower) importance rating.
-
-## Examples
-
-**Good observation** (specific, actionable):
-```json
-{
-  "type": "gotcha",
-  "observation": "SQLite WAL mode must be enabled before concurrent reads work. Without WAL, readers block writers and vice versa.",
-  "context": "src/index/sqlite.ts",
-  "importance": "high"
-}
-```
-
-**Bad observation** (too generic — skip this):
-```json
-{
-  "type": "discovery",
-  "observation": "The project uses SQLite for storage",
-  "context": "src/index",
-  "importance": "low"
-}
-```
-
-## Output Format
-
-Respond with a JSON object:
-
-```json
-{
-  "observations": [
-    {
-      "type": "{{type_names}}",
-      "observation": "Concise description of what was learned",
-      "context": "Relevant file or feature name",
-      "importance": "high|medium|low"
-    }
-  ],
-  "summary": "One sentence describing what the session accomplished"
-}
-```
-
-Guidelines:
-- Extract at most 5 observations per session. Prefer fewer, higher-quality observations over many low-value ones.
-- Only include genuinely useful observations that would help in future sessions
-- Be specific - mention file names, function names, actual values
-- If the session was just exploration without meaningful learnings, return empty observations
-- Focus on things that aren't obvious from the code itself
-
-Respond ONLY with valid JSON.

package/dist/src/capture/prompts/prompts/implementation.md

@@ -1,90 +0,0 @@
----
-name: implementation
-description: For implementation sessions with writes/edits
-activity_filter: Write,Edit
-min_activities: 2
----
-
-You are analyzing an implementation session to capture design decisions.
-
-## Context
-
-The developer was implementing a new feature or making significant changes.
-
-Duration: {{session_duration}} minutes
-Files created: {{files_created}}
-Files modified: {{files_modified}}
-
-### Implementation Activity
-
-{{activities}}
-
-## Observation Types
-
-{{observation_types}}
-
-## Importance Levels
-
-Rate each observation's importance based on its value for future sessions:
-
-- **high**: Non-obvious insight that would cause bugs, confusion, or wasted time if forgotten. Cannot be easily rediscovered from code alone.
-- **medium**: Useful context that saves time but could be rediscovered with investigation.
-- **low**: Nice-to-know information that is easily found from code or already documented elsewhere. Skip if already captured in project docs.
-
-Prefer fewer high-quality observations over many low-importance ones.
-
-## Task
-
-Extract design decisions, architectural choices, and implementation gotchas.
-
-Focus on:
-- Why specific approaches were chosen
-- Trade-offs considered
-- Patterns followed or established
-- Edge cases handled
-- Integration points with existing code
-
-Prefer **decision**, **trade_off**, and **gotcha** types for implementation sessions.
-
-## Examples
-
-**Good observation** (clear rationale — extract this):
-```json
-{
-  "type": "decision",
-  "observation": "Chose plain tsc over tsup for build because native deps (better-sqlite3) can't be bundled. tsc preserves directory structure so relative imports work without path rewriting.",
-  "context": "package.json build config",
-  "importance": "medium"
-}
-```
-
-**Bad observation** (no rationale — skip this):
-```json
-{
-  "type": "decision",
-  "observation": "Used TypeScript for the project",
-  "context": "src/",
-  "importance": "low"
-}
-```
-
-## Output Format
-
-```json
-{
-  "observations": [
-    {
-      "type": "{{type_names}}",
-      "observation": "Design choice and rationale",
-      "context": "Feature or component name",
-      "importance": "high|medium|low"
-    }
-  ],
-  "summary": "Brief description of what was implemented"
-}
-```
-
-Guidelines:
-- Extract at most 5 observations per session. Prefer fewer, higher-quality observations over many low-value ones.
-
-Respond ONLY with valid JSON.

package/dist/src/capture/prompts/prompts/schema.yaml

@@ -1,97 +0,0 @@
-# Myco Observation Schema
-#
-# Defines the observation types that the LLM uses for classification.
-# Ported from open-agent-kit's battle-tested schema.
-#
-# Each type has:
-#   - description: What this type captures (shown to LLM)
-#   - examples: Example observations of this type (help LLM understand)
-
-version: "1.0"
-
-observation_types:
-  gotcha:
-    description: "Non-obvious behaviors, edge cases, or tricky parts that could trip someone up"
-    examples:
-      - "The API returns 200 even for validation errors, check the response body for success field"
-      - "File paths must be absolute, relative paths silently fail"
-      - "The cache TTL is in seconds, not milliseconds despite the variable name"
-
-  bug_fix:
-    description: "Bugs that were identified and fixed, including root cause and solution"
-    examples:
-      - "Race condition in async handler - added mutex lock around shared state"
-      - "Off-by-one error in pagination - fixed boundary check in slice operation"
-      - "Memory leak from unclosed connections - added try/finally cleanup"
-
-  decision:
-    description: "Architecture choices, design decisions, or approach selections with rationale"
-    examples:
-      - "Chose SQLite over PostgreSQL for activity storage - simpler deployment, sufficient for single-user"
-      - "Using background thread instead of async for file watcher - better isolation from event loop"
-      - "Storing tags as comma-separated string - avoids metadata array limitations"
-
-  discovery:
-    description: "Important facts learned about the codebase, APIs, patterns, or conventions"
-    examples:
-      - "The config is loaded lazily on first access via __getattr__"
-      - "All API routes use dependency injection for state"
-      - "Test fixtures are shared across modules via conftest.py"
-
-  trade_off:
-    description: "Trade-offs that were considered, alternatives evaluated, and why current approach was chosen"
-    examples:
-      - "Chose simplicity over performance - O(n) scan acceptable for expected data size"
-      - "Sacrificed type safety for flexibility - using dict instead of typed model for config"
-      - "Accepted eventual consistency for better throughput in background processing"
-
-activity_classifications:
-  exploration:
-    description: "Reading code, searching, understanding the codebase"
-    indicators:
-      - "Mostly Read, Grep, Glob tools"
-      - "Few or no file modifications"
-      - "Questions about how things work"
-
-  debugging:
-    description: "Investigating errors, fixing bugs, troubleshooting"
-    indicators:
-      - "Error messages in output"
-      - "Test failures"
-      - "Iterative fixes to same files"
-
-  implementation:
-    description: "Writing new code, adding features, creating new files"
-    indicators:
-      - "New files created"
-      - "Significant Write/Edit operations"
-      - "Feature-related file names"
-
-  refactoring:
-    description: "Modifying existing code structure without adding new functionality"
-    indicators:
-      - "Edits without new files"
-      - "Moving/renaming operations"
-      - "No new test files"
-
-session_origin_types:
-  planning:
-    description: "Planning-phase session"
-    indicators:
-      - "High read:edit ratio"
-      - "Few file modifications"
-  investigation:
-    description: "Exploration/debugging session"
-    indicators:
-      - "Many file reads"
-      - "Minimal edits"
-  implementation:
-    description: "Active coding session"
-    indicators:
-      - "Significant file modifications"
-      - "Low read:edit ratio"
-  mixed:
-    description: "Combined activity types"
-    indicators:
-      - "Both reads and edits"
-      - "Does not fit other categories"

package/dist/src/capture/prompts/prompts/session-summary.md

@@ -1,65 +0,0 @@
----
-name: session-summary
-description: Generate a high-level summary of what was accomplished in the session
----
-
-You are summarizing a coding session to help future sessions understand what was done.
-
-The developer working in this session is **{{developer_name}}**. Refer to them by name instead of "the user" or "the developer".
-
-## Session Statistics
-
-- Duration: {{session_duration}} minutes
-- Prompt batches: {{prompt_batch_count}}
-- Files read: {{files_read_count}}
-- Files modified: {{files_modified_count}}
-- Files created: {{files_created_count}}
-- Total tool calls: {{tool_calls}}
-- **Session Origin Type:** {{session_origin_type}}
-
-## Prompt Batches
-
-{{prompt_batches}}
-
-## Session Origin Type
-
-The session origin type indicates the dominant activity pattern:
-- **planning**: Primarily reading and planning, few file modifications
-- **investigation**: Exploration and debugging, many reads with minimal edits
-- **implementation**: Active coding with significant file modifications
-- **mixed**: Combined activity patterns
-
-When summarizing, note whether observations are planning-phase findings (may become
-stale once work is implemented) versus implementation learnings (more likely to remain
-relevant long-term).
-
-## Task
-
-Write a concise summary of this session. You have access to both the user's prompts and the agent's actions, so capture the full picture:
-
-- **Developer intent**: What was {{developer_name}} trying to accomplish? What was their approach or priority?
-- **Key actions**: What did the agent do? Which files were modified and why?
-- **Outcomes**: What was achieved? Any decisions made or problems solved?
-- **Context**: Any constraints, trade-offs, or discoveries worth noting?
-
-Be specific - include file names, feature names, and technical details when relevant.
-
-## Output Format
-
-Respond with ONLY the summary text. No JSON, no code blocks, just plain text. A bulleted list is acceptable if it improves clarity.
-
-## Examples
-
-Good (captures intent + actions + outcome):
-- "Chris wanted to add dark mode support. Implemented theme toggle in settings/ThemeProvider.tsx using CSS variables, added useTheme hook, and updated 12 components to use theme tokens instead of hardcoded colors. Chose CSS variables over styled-components for better performance."
-
-Good (captures debugging journey):
-- "Alex reported intermittent test failures in CI. Investigated flaky tests in tests/api/, discovered race condition in database cleanup. Fixed by adding proper test isolation with transaction rollbacks. Also identified that TestClient was sharing state across tests."
-
-Good (captures exploration with learnings):
-- "Sam needed to understand the payment processing flow before adding refund support. Traced code from PaymentController through StripeService to webhook handlers. Key finding: payments use idempotency keys stored in Redis, refunds will need similar pattern."
-
-Bad (too vague):
-- "Fixed some bugs and added a feature"
-- "Worked on authentication"
-- "Made improvements to the codebase"

package/dist/src/capture/prompts/prompts/session-title.md

@@ -1,46 +0,0 @@
----
-name: session-title
-description: Generate a short title from a session summary
----
-
-Generate a short, descriptive title (6-12 words) for this coding session based on its summary.
-
-## Session Summary
-
-{{session_summary}}
-
-## Task
-
-Create a brief title that captures the main accomplishment or focus of this session. The title should:
-- Be 6-12 words maximum
-- Start with an action verb when appropriate (Add, Fix, Implement, Refactor, Debug, Update, Configure, etc.)
-- Capture the primary task or feature worked on
-- Be specific enough to distinguish from other sessions
-- If this is a continuation session, emphasize what THIS session specifically did, not the overall goal
-
-## Output Format
-
-Respond with ONLY the title text as plain text.
-- No JSON
-- No quotes
-- No markdown
-- No punctuation at the end
-- No explanation or preamble
-
-Just the title itself, nothing else.
-
-## Examples
-
-Good titles:
-- Add dark mode theme support
-- Fix authentication token refresh bug
-- Implement user profile settings page
-- Refactor payment processing service
-- Debug CI pipeline test failures
-- Port OAK prompt templates to Myco
-
-Bad titles (too vague):
-- Working on code
-- Bug fix
-- Feature implementation
-- Updates

package/dist/src/capture/prompts/schema.yaml

@@ -1,97 +0,0 @@
-# Myco Observation Schema
-#
-# Defines the observation types that the LLM uses for classification.
-# Ported from open-agent-kit's battle-tested schema.
-#
-# Each type has:
-#   - description: What this type captures (shown to LLM)
-#   - examples: Example observations of this type (help LLM understand)
-
-version: "1.0"
-
-observation_types:
-  gotcha:
-    description: "Non-obvious behaviors, edge cases, or tricky parts that could trip someone up"
-    examples:
-      - "The API returns 200 even for validation errors, check the response body for success field"
-      - "File paths must be absolute, relative paths silently fail"
-      - "The cache TTL is in seconds, not milliseconds despite the variable name"
-
-  bug_fix:
-    description: "Bugs that were identified and fixed, including root cause and solution"
-    examples:
-      - "Race condition in async handler - added mutex lock around shared state"
-      - "Off-by-one error in pagination - fixed boundary check in slice operation"
-      - "Memory leak from unclosed connections - added try/finally cleanup"
-
-  decision:
-    description: "Architecture choices, design decisions, or approach selections with rationale"
-    examples:
-      - "Chose SQLite over PostgreSQL for activity storage - simpler deployment, sufficient for single-user"
-      - "Using background thread instead of async for file watcher - better isolation from event loop"
-      - "Storing tags as comma-separated string - avoids metadata array limitations"
-
-  discovery:
-    description: "Important facts learned about the codebase, APIs, patterns, or conventions"
-    examples:
-      - "The config is loaded lazily on first access via __getattr__"
-      - "All API routes use dependency injection for state"
-      - "Test fixtures are shared across modules via conftest.py"
-
-  trade_off:
-    description: "Trade-offs that were considered, alternatives evaluated, and why current approach was chosen"
-    examples:
-      - "Chose simplicity over performance - O(n) scan acceptable for expected data size"
-      - "Sacrificed type safety for flexibility - using dict instead of typed model for config"
-      - "Accepted eventual consistency for better throughput in background processing"
-
-activity_classifications:
-  exploration:
-    description: "Reading code, searching, understanding the codebase"
-    indicators:
-      - "Mostly Read, Grep, Glob tools"
-      - "Few or no file modifications"
-      - "Questions about how things work"
-
-  debugging:
-    description: "Investigating errors, fixing bugs, troubleshooting"
-    indicators:
-      - "Error messages in output"
-      - "Test failures"
-      - "Iterative fixes to same files"
-
-  implementation:
-    description: "Writing new code, adding features, creating new files"
-    indicators:
-      - "New files created"
-      - "Significant Write/Edit operations"
-      - "Feature-related file names"
-
-  refactoring:
-    description: "Modifying existing code structure without adding new functionality"
-    indicators:
-      - "Edits without new files"
-      - "Moving/renaming operations"
-      - "No new test files"
-
-session_origin_types:
-  planning:
-    description: "Planning-phase session"
-    indicators:
-      - "High read:edit ratio"
-      - "Few file modifications"
-  investigation:
-    description: "Exploration/debugging session"
-    indicators:
-      - "Many file reads"
-      - "Minimal edits"
-  implementation:
-    description: "Active coding session"
-    indicators:
-      - "Significant file modifications"
-      - "Low read:edit ratio"
-  mixed:
-    description: "Combined activity types"
-    indicators:
-      - "Both reads and edits"
-      - "Does not fit other categories"