@funnycode/myclaude 0.1.70 → 0.1.72

package/seed/marketplaces/ecc/commands/learn-eval.md

@@ -1,116 +1,116 @@
----
-description: "Extract reusable patterns from the session, self-evaluate quality before saving, and determine the right save location (Global vs Project)."
----
-
-# /learn-eval - Extract, Evaluate, then Save
-
-Extends `/learn` with a quality gate, save-location decision, and knowledge-placement awareness before writing any skill file.
-
-## What to Extract
-
-Look for:
-
-1. **Error Resolution Patterns** — root cause + fix + reusability
-2. **Debugging Techniques** — non-obvious steps, tool combinations
-3. **Workarounds** — library quirks, API limitations, version-specific fixes
-4. **Project-Specific Patterns** — conventions, architecture decisions, integration patterns
-
-## Process
-
-1. Review the session for extractable patterns
-2. Identify the most valuable/reusable insight
-
-3. **Determine save location:**
-   - Ask: "Would this pattern be useful in a different project?"
-   - **Global** (`~/.claude/skills/learned/`): Generic patterns usable across 2+ projects (bash compatibility, LLM API behavior, debugging techniques, etc.)
-   - **Project** (`.claude/skills/learned/` in current project): Project-specific knowledge (quirks of a particular config file, project-specific architecture decisions, etc.)
-   - When in doubt, choose Global (moving Global → Project is easier than the reverse)
-
-4. Draft the skill file using this format:
-
-```markdown
----
-name: pattern-name
-description: "Under 130 characters"
-user-invocable: false
-origin: auto-extracted
----
-
-# [Descriptive Pattern Name]
-
-**Extracted:** [Date]
-**Context:** [Brief description of when this applies]
-
-## Problem
-[What problem this solves - be specific]
-
-## Solution
-[The pattern/technique/workaround - with code examples]
-
-## When to Use
-[Trigger conditions]
-```
-
-5. **Quality gate — Checklist + Holistic verdict**
-
-   ### 5a. Required checklist (verify by actually reading files)
-
-   Execute **all** of the following before evaluating the draft:
-
-   - [ ] Grep `~/.claude/skills/` and relevant project `.claude/skills/` files by keyword to check for content overlap
-   - [ ] Check MEMORY.md (both project and global) for overlap
-   - [ ] Consider whether appending to an existing skill would suffice
-   - [ ] Confirm this is a reusable pattern, not a one-off fix
-
-   ### 5b. Holistic verdict
-
-   Synthesize the checklist results and draft quality, then choose **one** of the following:
-
-   | Verdict | Meaning | Next Action |
-   |---------|---------|-------------|
-   | **Save** | Unique, specific, well-scoped | Proceed to Step 6 |
-   | **Improve then Save** | Valuable but needs refinement | List improvements → revise → re-evaluate (once) |
-   | **Absorb into [X]** | Should be appended to an existing skill | Show target skill and additions → Step 6 |
-   | **Drop** | Trivial, redundant, or too abstract | Explain reasoning and stop |
-
-**Guideline dimensions** (informing the verdict, not scored):
-
-- **Specificity & Actionability**: Contains code examples or commands that are immediately usable
-- **Scope Fit**: Name, trigger conditions, and content are aligned and focused on a single pattern
-- **Uniqueness**: Provides value not covered by existing skills (informed by checklist results)
-- **Reusability**: Realistic trigger scenarios exist in future sessions
-
-6. **Verdict-specific confirmation flow**
-
-- **Improve then Save**: Present the required improvements + revised draft + updated checklist/verdict after one re-evaluation; if the revised verdict is **Save**, save after user confirmation, otherwise follow the new verdict
-- **Save**: Present save path + checklist results + 1-line verdict rationale + full draft → save after user confirmation
-- **Absorb into [X]**: Present target path + additions (diff format) + checklist results + verdict rationale → append after user confirmation
-- **Drop**: Show checklist results + reasoning only (no confirmation needed)
-
-7. Save / Absorb to the determined location
-
-## Output Format for Step 5
-
-```
-### Checklist
-- [x] skills/ grep: no overlap (or: overlap found → details)
-- [x] MEMORY.md: no overlap (or: overlap found → details)
-- [x] Existing skill append: new file appropriate (or: should append to [X])
-- [x] Reusability: confirmed (or: one-off → Drop)
-
-### Verdict: Save / Improve then Save / Absorb into [X] / Drop
-
-**Rationale:** (1-2 sentences explaining the verdict)
-```
-
-## Design Rationale
-
-This version replaces the previous 5-dimension numeric scoring rubric (Specificity, Actionability, Scope Fit, Non-redundancy, Coverage scored 1-5) with a checklist-based holistic verdict system. Modern frontier models (Opus 4.6+) have strong contextual judgment — forcing rich qualitative signals into numeric scores loses nuance and can produce misleading totals. The holistic approach lets the model weigh all factors naturally, producing more accurate save/drop decisions while the explicit checklist ensures no critical check is skipped.
-
-## Notes
-
-- Don't extract trivial fixes (typos, simple syntax errors)
-- Don't extract one-time issues (specific API outages, etc.)
-- Focus on patterns that will save time in future sessions
-- Keep skills focused — one pattern per skill
-- When the verdict is Absorb, append to the existing skill rather than creating a new file
+---
+description: "Extract reusable patterns from the session, self-evaluate quality before saving, and determine the right save location (Global vs Project)."
+---
+
+# /learn-eval - Extract, Evaluate, then Save
+
+Extends `/learn` with a quality gate, save-location decision, and knowledge-placement awareness before writing any skill file.
+
+## What to Extract
+
+Look for:
+
+1. **Error Resolution Patterns** — root cause + fix + reusability
+2. **Debugging Techniques** — non-obvious steps, tool combinations
+3. **Workarounds** — library quirks, API limitations, version-specific fixes
+4. **Project-Specific Patterns** — conventions, architecture decisions, integration patterns
+
+## Process
+
+1. Review the session for extractable patterns
+2. Identify the most valuable/reusable insight
+
+3. **Determine save location:**
+   - Ask: "Would this pattern be useful in a different project?"
+   - **Global** (`~/.claude/skills/learned/`): Generic patterns usable across 2+ projects (bash compatibility, LLM API behavior, debugging techniques, etc.)
+   - **Project** (`.claude/skills/learned/` in current project): Project-specific knowledge (quirks of a particular config file, project-specific architecture decisions, etc.)
+   - When in doubt, choose Global (moving Global → Project is easier than the reverse)
+
+4. Draft the skill file using this format:
+
+```markdown
+---
+name: pattern-name
+description: "Under 130 characters"
+user-invocable: false
+origin: auto-extracted
+---
+
+# [Descriptive Pattern Name]
+
+**Extracted:** [Date]
+**Context:** [Brief description of when this applies]
+
+## Problem
+[What problem this solves - be specific]
+
+## Solution
+[The pattern/technique/workaround - with code examples]
+
+## When to Use
+[Trigger conditions]
+```
+
+5. **Quality gate — Checklist + Holistic verdict**
+
+   ### 5a. Required checklist (verify by actually reading files)
+
+   Execute **all** of the following before evaluating the draft:
+
+   - [ ] Grep `~/.claude/skills/` and relevant project `.claude/skills/` files by keyword to check for content overlap
+   - [ ] Check MEMORY.md (both project and global) for overlap
+   - [ ] Consider whether appending to an existing skill would suffice
+   - [ ] Confirm this is a reusable pattern, not a one-off fix
+
+   ### 5b. Holistic verdict
+
+   Synthesize the checklist results and draft quality, then choose **one** of the following:
+
+   | Verdict | Meaning | Next Action |
+   |---------|---------|-------------|
+   | **Save** | Unique, specific, well-scoped | Proceed to Step 6 |
+   | **Improve then Save** | Valuable but needs refinement | List improvements → revise → re-evaluate (once) |
+   | **Absorb into [X]** | Should be appended to an existing skill | Show target skill and additions → Step 6 |
+   | **Drop** | Trivial, redundant, or too abstract | Explain reasoning and stop |
+
+**Guideline dimensions** (informing the verdict, not scored):
+
+- **Specificity & Actionability**: Contains code examples or commands that are immediately usable
+- **Scope Fit**: Name, trigger conditions, and content are aligned and focused on a single pattern
+- **Uniqueness**: Provides value not covered by existing skills (informed by checklist results)
+- **Reusability**: Realistic trigger scenarios exist in future sessions
+
+6. **Verdict-specific confirmation flow**
+
+- **Improve then Save**: Present the required improvements + revised draft + updated checklist/verdict after one re-evaluation; if the revised verdict is **Save**, save after user confirmation, otherwise follow the new verdict
+- **Save**: Present save path + checklist results + 1-line verdict rationale + full draft → save after user confirmation
+- **Absorb into [X]**: Present target path + additions (diff format) + checklist results + verdict rationale → append after user confirmation
+- **Drop**: Show checklist results + reasoning only (no confirmation needed)
+
+7. Save / Absorb to the determined location
+
+## Output Format for Step 5
+
+```
+### Checklist
+- [x] skills/ grep: no overlap (or: overlap found → details)
+- [x] MEMORY.md: no overlap (or: overlap found → details)
+- [x] Existing skill append: new file appropriate (or: should append to [X])
+- [x] Reusability: confirmed (or: one-off → Drop)
+
+### Verdict: Save / Improve then Save / Absorb into [X] / Drop
+
+**Rationale:** (1-2 sentences explaining the verdict)
+```
+
+## Design Rationale
+
+This version replaces the previous 5-dimension numeric scoring rubric (Specificity, Actionability, Scope Fit, Non-redundancy, Coverage scored 1-5) with a checklist-based holistic verdict system. Modern frontier models (Opus 4.6+) have strong contextual judgment — forcing rich qualitative signals into numeric scores loses nuance and can produce misleading totals. The holistic approach lets the model weigh all factors naturally, producing more accurate save/drop decisions while the explicit checklist ensures no critical check is skipped.
+
+## Notes
+
+- Don't extract trivial fixes (typos, simple syntax errors)
+- Don't extract one-time issues (specific API outages, etc.)
+- Focus on patterns that will save time in future sessions
+- Keep skills focused — one pattern per skill
+- When the verdict is Absorb, append to the existing skill rather than creating a new file

package/seed/marketplaces/ecc/commands/learn.md

@@ -1,74 +1,74 @@
----
-description: Extract reusable patterns from the current session and save them as candidate skills or guidance.
----
-
-# /learn - Extract Reusable Patterns
-
-Analyze the current session and extract any patterns worth saving as skills.
-
-## Trigger
-
-Run `/learn` at any point during a session when you've solved a non-trivial problem.
-
-## What to Extract
-
-Look for:
-
-1. **Error Resolution Patterns**
-   - What error occurred?
-   - What was the root cause?
-   - What fixed it?
-   - Is this reusable for similar errors?
-
-2. **Debugging Techniques**
-   - Non-obvious debugging steps
-   - Tool combinations that worked
-   - Diagnostic patterns
-
-3. **Workarounds**
-   - Library quirks
-   - API limitations
-   - Version-specific fixes
-
-4. **Project-Specific Patterns**
-   - Codebase conventions discovered
-   - Architecture decisions made
-   - Integration patterns
-
-## Output Format
-
-Create a skill file at `~/.claude/skills/learned/[pattern-name].md`:
-
-```markdown
-# [Descriptive Pattern Name]
-
-**Extracted:** [Date]
-**Context:** [Brief description of when this applies]
-
-## Problem
-[What problem this solves - be specific]
-
-## Solution
-[The pattern/technique/workaround]
-
-## Example
-[Code example if applicable]
-
-## When to Use
-[Trigger conditions - what should activate this skill]
-```
-
-## Process
-
-1. Review the session for extractable patterns
-2. Identify the most valuable/reusable insight
-3. Draft the skill file
-4. Ask user to confirm before saving
-5. Save to `~/.claude/skills/learned/`
-
-## Notes
-
-- Don't extract trivial fixes (typos, simple syntax errors)
-- Don't extract one-time issues (specific API outages, etc.)
-- Focus on patterns that will save time in future sessions
-- Keep skills focused - one pattern per skill
+---
+description: Extract reusable patterns from the current session and save them as candidate skills or guidance.
+---
+
+# /learn - Extract Reusable Patterns
+
+Analyze the current session and extract any patterns worth saving as skills.
+
+## Trigger
+
+Run `/learn` at any point during a session when you've solved a non-trivial problem.
+
+## What to Extract
+
+Look for:
+
+1. **Error Resolution Patterns**
+   - What error occurred?
+   - What was the root cause?
+   - What fixed it?
+   - Is this reusable for similar errors?
+
+2. **Debugging Techniques**
+   - Non-obvious debugging steps
+   - Tool combinations that worked
+   - Diagnostic patterns
+
+3. **Workarounds**
+   - Library quirks
+   - API limitations
+   - Version-specific fixes
+
+4. **Project-Specific Patterns**
+   - Codebase conventions discovered
+   - Architecture decisions made
+   - Integration patterns
+
+## Output Format
+
+Create a skill file at `~/.claude/skills/learned/[pattern-name].md`:
+
+```markdown
+# [Descriptive Pattern Name]
+
+**Extracted:** [Date]
+**Context:** [Brief description of when this applies]
+
+## Problem
+[What problem this solves - be specific]
+
+## Solution
+[The pattern/technique/workaround]
+
+## Example
+[Code example if applicable]
+
+## When to Use
+[Trigger conditions - what should activate this skill]
+```
+
+## Process
+
+1. Review the session for extractable patterns
+2. Identify the most valuable/reusable insight
+3. Draft the skill file
+4. Ask user to confirm before saving
+5. Save to `~/.claude/skills/learned/`
+
+## Notes
+
+- Don't extract trivial fixes (typos, simple syntax errors)
+- Don't extract one-time issues (specific API outages, etc.)
+- Focus on patterns that will save time in future sessions
+- Keep skills focused - one pattern per skill

package/seed/marketplaces/ecc/commands/loop-start.md

@@ -1,36 +1,36 @@
----
-description: Start a managed autonomous loop pattern with safety defaults and explicit stop conditions.
----
-
-# Loop Start Command
-
-Start a managed autonomous loop pattern with safety defaults.
-
-## Usage
-
-`/loop-start [pattern] [--mode safe|fast]`
-
-- `pattern`: `sequential`, `continuous-pr`, `rfc-dag`, `infinite`
-- `--mode`:
-  - `safe` (default): strict quality gates and checkpoints
-  - `fast`: reduced gates for speed
-
-## Flow
-
-1. Confirm repository state and branch strategy.
-2. Select loop pattern and model tier strategy.
-3. Enable required hooks/profile for the chosen mode.
-4. Create loop plan and write runbook under `.claude/plans/`.
-5. Print commands to start and monitor the loop.
-
-## Required Safety Checks
-
-- Verify tests pass before first loop iteration.
-- Ensure `ECC_HOOK_PROFILE` is not disabled globally.
-- Ensure loop has explicit stop condition.
-
-## Arguments
-
-$ARGUMENTS:
-- `<pattern>` optional (`sequential|continuous-pr|rfc-dag|infinite`)
-- `--mode safe|fast` optional
+---
+description: Start a managed autonomous loop pattern with safety defaults and explicit stop conditions.
+---
+
+# Loop Start Command
+
+Start a managed autonomous loop pattern with safety defaults.
+
+## Usage
+
+`/loop-start [pattern] [--mode safe|fast]`
+
+- `pattern`: `sequential`, `continuous-pr`, `rfc-dag`, `infinite`
+- `--mode`:
+  - `safe` (default): strict quality gates and checkpoints
+  - `fast`: reduced gates for speed
+
+## Flow
+
+1. Confirm repository state and branch strategy.
+2. Select loop pattern and model tier strategy.
+3. Enable required hooks/profile for the chosen mode.
+4. Create loop plan and write runbook under `.claude/plans/`.
+5. Print commands to start and monitor the loop.
+
+## Required Safety Checks
+
+- Verify tests pass before first loop iteration.
+- Ensure `ECC_HOOK_PROFILE` is not disabled globally.
+- Ensure loop has explicit stop condition.
+
+## Arguments
+
+$ARGUMENTS:
+- `<pattern>` optional (`sequential|continuous-pr|rfc-dag|infinite`)
+- `--mode safe|fast` optional

package/seed/marketplaces/ecc/commands/loop-status.md

@@ -1,77 +1,77 @@
----
-description: Inspect active loop state, progress, failure signals, and recommended intervention.
----
-
-# Loop Status Command
-
-Inspect active loop state, progress, and failure signals.
-
-This slash command can only run after the current session dequeues it. If you
-need to inspect a wedged or sibling session, run the packaged CLI from another
-terminal:
-
-```bash
-npx --package ecc-universal ecc loop-status --json
-```
-
-The CLI scans local Claude transcript JSONL files under
-`~/.claude/projects/**` and reports stale `ScheduleWakeup` calls or `Bash`
-tool calls that have no matching `tool_result`.
-
-## Usage
-
-`/loop-status [--watch]`
-
-## What to Report
-
-- active loop pattern
-- current phase and last successful checkpoint
-- failing checks (if any)
-- estimated time/cost drift
-- recommended intervention (continue/pause/stop)
-
-## Cross-Session CLI
-
-- `ecc loop-status --json` emits machine-readable status for recent local
-  Claude transcripts.
-- `ecc loop-status --home <dir>` scans a different home directory when
-  inspecting another local profile or mounted workspace.
-- `ecc loop-status --transcript <session.jsonl>` inspects one transcript
-  directly.
-- `ecc loop-status --bash-timeout-seconds 1800` adjusts the stale Bash
-  threshold.
-- `ecc loop-status --exit-code` exits `2` when stale loop or tool signals are
-  found, or `1` when transcripts cannot be scanned.
-- `--exit-code` with `--watch` requires `--watch-count` so watchdog scripts do
-  not wait forever for a process exit.
-- `ecc loop-status --watch` refreshes status until interrupted.
-- `ecc loop-status --watch --watch-count 3 --exit-code` refreshes a bounded
-  number of times, then exits with the highest status seen.
-- `ecc loop-status --watch --watch-count 3` emits a bounded watch stream for
-  scripts and handoffs.
-- `ecc loop-status --watch --write-dir ~/.claude/loops` maintains
-  `index.json` and per-session JSON snapshots for sibling terminals or
-  watchdog scripts.
-
-## Watch Mode
-
-When `--watch` is present, refresh status periodically. With `--json`, each
-refresh is emitted as one JSON object per line so another terminal or script can
-consume the stream.
-
-## Snapshot Files
-
-Use `--write-dir <dir>` when a separate process needs to inspect loop state
-without waiting for the current Claude session to dequeue `/loop-status`. The
-CLI writes:
-
-- `index.json` with one row per inspected session.
-- `<session-id>.json` with the full status payload for that session.
-
-These files are snapshots of local transcript analysis. They do not control or
-timeout Claude Code runtime tool calls.
-
-## Arguments
-
-$ARGUMENTS:
-- `--watch` optional
+---
+description: Inspect active loop state, progress, failure signals, and recommended intervention.
+---
+
+# Loop Status Command
+
+Inspect active loop state, progress, and failure signals.
+
+This slash command can only run after the current session dequeues it. If you
+need to inspect a wedged or sibling session, run the packaged CLI from another
+terminal:
+
+```bash
+npx --package ecc-universal ecc loop-status --json
+```
+
+The CLI scans local Claude transcript JSONL files under
+`~/.claude/projects/**` and reports stale `ScheduleWakeup` calls or `Bash`
+tool calls that have no matching `tool_result`.
+
+## Usage
+
+`/loop-status [--watch]`
+
+## What to Report
+
+- active loop pattern
+- current phase and last successful checkpoint
+- failing checks (if any)
+- estimated time/cost drift
+- recommended intervention (continue/pause/stop)
+
+## Cross-Session CLI
+
+- `ecc loop-status --json` emits machine-readable status for recent local
+  Claude transcripts.
+- `ecc loop-status --home <dir>` scans a different home directory when
+  inspecting another local profile or mounted workspace.
+- `ecc loop-status --transcript <session.jsonl>` inspects one transcript
+  directly.
+- `ecc loop-status --bash-timeout-seconds 1800` adjusts the stale Bash
+  threshold.
+- `ecc loop-status --exit-code` exits `2` when stale loop or tool signals are
+  found, or `1` when transcripts cannot be scanned.
+- `--exit-code` with `--watch` requires `--watch-count` so watchdog scripts do
+  not wait forever for a process exit.
+- `ecc loop-status --watch` refreshes status until interrupted.
+- `ecc loop-status --watch --watch-count 3 --exit-code` refreshes a bounded
+  number of times, then exits with the highest status seen.
+- `ecc loop-status --watch --watch-count 3` emits a bounded watch stream for
+  scripts and handoffs.
+- `ecc loop-status --watch --write-dir ~/.claude/loops` maintains
+  `index.json` and per-session JSON snapshots for sibling terminals or
+  watchdog scripts.
+
+## Watch Mode
+
+When `--watch` is present, refresh status periodically. With `--json`, each
+refresh is emitted as one JSON object per line so another terminal or script can
+consume the stream.
+
+## Snapshot Files
+
+Use `--write-dir <dir>` when a separate process needs to inspect loop state
+without waiting for the current Claude session to dequeue `/loop-status`. The
+CLI writes:
+
+- `index.json` with one row per inspected session.
+- `<session-id>.json` with the full status payload for that session.
+
+These files are snapshots of local transcript analysis. They do not control or
+timeout Claude Code runtime tool calls.
+
+## Arguments
+
+$ARGUMENTS:
+- `--watch` optional