@funnycode/myclaude 0.1.55 → 0.1.60

package/seed/marketplaces/ecc/skills/ecc-tools-cost-audit/SKILL.md

@@ -1,160 +1,160 @@
----
-name: ecc-tools-cost-audit
-description: Evidence-first ECC Tools burn and billing audit workflow. Use when investigating runaway PR creation, quota bypass, premium-model leakage, duplicate jobs, or GitHub App cost spikes in the ECC Tools repo.
-origin: ECC
----
-
-# ECC Tools Cost Audit
-
-Use this skill when the user suspects the ECC Tools GitHub App is burning cost, over-creating PRs, bypassing usage limits, or routing free users into premium analysis paths.
-
-This is a focused operator workflow for the sibling [ECC-Tools](../../ECC-Tools) repo. It is not a generic billing skill and it is not a repo-wide code review pass.
-
-## Skill Stack
-
-Pull these ECC-native skills into the workflow when relevant:
-
-- `autonomous-loops` for bounded multi-step audits that cross webhooks, queues, billing, and retries
-- `agentic-engineering` for tracing the request path into discrete, provable units
-- `customer-billing-ops` when repo behavior and customer-impact math must be separated cleanly
-- `search-first` before inventing helpers or re-implementing repo-local utilities
-- `security-review` when auth, usage gates, entitlements, or secrets are touched
-- `verification-loop` for proving rerun safety and exact post-fix state
-- `tdd-workflow` when the fix needs regression coverage in the worker, router, or billing paths
-
-## When To Use
-
-- user says ECC Tools burn rate, PR recursion, over-created PRs, usage-limit bypass, or premium-model leakage
-- the task is in the sibling `ECC-Tools` repo and depends on webhook handlers, queue workers, usage reservation, PR creation logic, or paid-gate enforcement
-- a customer report says the app created too many PRs, billed incorrectly, or analyzed code without producing a usable result
-
-## Scope Guardrails
-
-- work in the sibling `ECC-Tools` repo, not in `everything-claude-code`
-- start read-only unless the user clearly asked for a fix
-- do not mutate unrelated billing, checkout, or UI flows while tracing analysis burn
-- treat app-generated branches and app-generated PRs as red-flag recursion paths until proved otherwise
-- separate three things explicitly:
-  - repo-side burn root cause
-  - customer-facing billing impact
-  - product or entitlement gaps that need backlog follow-up
-
-## Workflow
-
-### 1. Freeze repo scope
-
-- switch into the sibling `ECC-Tools` repo
-- check branch and local diff first
-- identify the exact surface under audit:
-  - webhook router
-  - queue producer
-  - queue consumer
-  - PR creation path
-  - usage reservation / billing path
-  - model routing path
-
-### 2. Trace ingress before theorizing
-
-- inspect `src/index.*` or the main entrypoint first
-- map every enqueue path before suggesting a fix
-- confirm which GitHub events share a queue type
-- confirm whether push, pull_request, synchronize, comment, or manual re-run events can converge on the same expensive path
-
-### 3. Trace the worker and side effects
-
-- inspect the queue consumer or scheduled worker that handles analysis
-- confirm whether a queued analysis always ends in:
-  - PR creation
-  - branch creation
-  - file updates
-  - premium model calls
-  - usage increments
-- if analysis can spend tokens and then fail before output is persisted, classify it as burn-with-broken-output
-
-### 4. Audit the high-signal burn paths
-
-#### PR multiplication
-
-- inspect PR helpers and branch naming
-- check dedupe, synchronize-event handling, and existing-PR reuse
-- if app-generated branches can re-enter analysis, treat that as a priority-0 recursion risk
-
-#### Quota bypass
-
-- inspect where quota is checked versus where usage is reserved or incremented
-- if quota is checked before enqueue but usage is charged only inside the worker, treat concurrent front-door passes as a real race
-
-#### Premium-model leakage
-
-- inspect model selection, tier branching, and provider routing
-- verify whether free or capped users can still hit premium analyzers when premium keys are present
-
-#### Retry burn
-
-- inspect retry loops, duplicate queue jobs, and deterministic failure reruns
-- if the same non-transient error can spend analysis repeatedly, fix that before quality improvements
-
-### 5. Fix in burn order
-
-If the user asked for code changes, prioritize fixes in this order:
-
-1. stop automatic PR multiplication
-2. stop quota bypass
-3. stop premium leakage
-4. stop duplicate-job fanout and pointless retries
-5. close rerun/update safety gaps
-
-Keep the pass bounded to one to three direct fixes unless the same root cause clearly spans multiple files.
-
-### 6. Verify with the smallest proving steps
-
-- rerun only the targeted tests or integration slices that cover the changed path
-- verify whether the burn path is now:
-  - blocked
-  - deduped
-  - downgraded to cheaper analysis
-  - or rejected early
-- state the final status exactly:
-  - changed locally
-  - verified locally
-  - pushed
-  - deployed
-  - still blocked
-
-## High-Signal Failure Patterns
-
-### 1. One queue type for all triggers
-
-If pushes, PR syncs, and manual audits all enqueue the same job and the worker always creates a PR, analysis equals PR spam.
-
-### 2. Post-enqueue usage reservation
-
-If usage is checked at the front door but only incremented in the worker, concurrent requests can all pass the gate and exceed quota.
-
-### 3. Free tier on premium path
-
-If free queued jobs can still route into Anthropic or another premium provider when keys exist, that is real spend leakage even if the user never sees the premium result.
-
-### 4. App-generated branches re-enter the webhook
-
-If `pull_request.synchronize`, branch pushes, or comment-triggered runs fire on app-owned branches, the app can recursively analyze its own output.
-
-### 5. Expensive work before persistence safety
-
-If the system can spend tokens and then fail on PR creation, file update, or branch collision, it is burning cost without shipping value.
-
-## Pitfalls
-
-- do not begin with broad repo wandering; settle webhook -> queue -> worker first
-- do not mix customer billing inference with code-backed product truth
-- do not fix lower-value quality issues before the highest-burn path is contained
-- do not claim burn is fixed until the narrow proving step was rerun
-- do not push or deploy unless the user asked
-- do not touch unrelated repo-local changes if they are already in progress
-
-## Verification
-
-- root causes cite exact file paths and code areas
-- fixes are ordered by burn impact, not code neatness
-- proving commands are named
-- final status distinguishes local change, verification, push, and deployment
+---
+name: ecc-tools-cost-audit
+description: Evidence-first ECC Tools burn and billing audit workflow. Use when investigating runaway PR creation, quota bypass, premium-model leakage, duplicate jobs, or GitHub App cost spikes in the ECC Tools repo.
+origin: ECC
+---
+
+# ECC Tools Cost Audit
+
+Use this skill when the user suspects the ECC Tools GitHub App is burning cost, over-creating PRs, bypassing usage limits, or routing free users into premium analysis paths.
+
+This is a focused operator workflow for the sibling [ECC-Tools](../../ECC-Tools) repo. It is not a generic billing skill and it is not a repo-wide code review pass.
+
+## Skill Stack
+
+Pull these ECC-native skills into the workflow when relevant:
+
+- `autonomous-loops` for bounded multi-step audits that cross webhooks, queues, billing, and retries
+- `agentic-engineering` for tracing the request path into discrete, provable units
+- `customer-billing-ops` when repo behavior and customer-impact math must be separated cleanly
+- `search-first` before inventing helpers or re-implementing repo-local utilities
+- `security-review` when auth, usage gates, entitlements, or secrets are touched
+- `verification-loop` for proving rerun safety and exact post-fix state
+- `tdd-workflow` when the fix needs regression coverage in the worker, router, or billing paths
+
+## When To Use
+
+- user says ECC Tools burn rate, PR recursion, over-created PRs, usage-limit bypass, or premium-model leakage
+- the task is in the sibling `ECC-Tools` repo and depends on webhook handlers, queue workers, usage reservation, PR creation logic, or paid-gate enforcement
+- a customer report says the app created too many PRs, billed incorrectly, or analyzed code without producing a usable result
+
+## Scope Guardrails
+
+- work in the sibling `ECC-Tools` repo, not in `everything-claude-code`
+- start read-only unless the user clearly asked for a fix
+- do not mutate unrelated billing, checkout, or UI flows while tracing analysis burn
+- treat app-generated branches and app-generated PRs as red-flag recursion paths until proved otherwise
+- separate three things explicitly:
+  - repo-side burn root cause
+  - customer-facing billing impact
+  - product or entitlement gaps that need backlog follow-up
+
+## Workflow
+
+### 1. Freeze repo scope
+
+- switch into the sibling `ECC-Tools` repo
+- check branch and local diff first
+- identify the exact surface under audit:
+  - webhook router
+  - queue producer
+  - queue consumer
+  - PR creation path
+  - usage reservation / billing path
+  - model routing path
+
+### 2. Trace ingress before theorizing
+
+- inspect `src/index.*` or the main entrypoint first
+- map every enqueue path before suggesting a fix
+- confirm which GitHub events share a queue type
+- confirm whether push, pull_request, synchronize, comment, or manual re-run events can converge on the same expensive path
+
+### 3. Trace the worker and side effects
+
+- inspect the queue consumer or scheduled worker that handles analysis
+- confirm whether a queued analysis always ends in:
+  - PR creation
+  - branch creation
+  - file updates
+  - premium model calls
+  - usage increments
+- if analysis can spend tokens and then fail before output is persisted, classify it as burn-with-broken-output
+
+### 4. Audit the high-signal burn paths
+
+#### PR multiplication
+
+- inspect PR helpers and branch naming
+- check dedupe, synchronize-event handling, and existing-PR reuse
+- if app-generated branches can re-enter analysis, treat that as a priority-0 recursion risk
+
+#### Quota bypass
+
+- inspect where quota is checked versus where usage is reserved or incremented
+- if quota is checked before enqueue but usage is charged only inside the worker, treat concurrent front-door passes as a real race
+
+#### Premium-model leakage
+
+- inspect model selection, tier branching, and provider routing
+- verify whether free or capped users can still hit premium analyzers when premium keys are present
+
+#### Retry burn
+
+- inspect retry loops, duplicate queue jobs, and deterministic failure reruns
+- if the same non-transient error can spend analysis repeatedly, fix that before quality improvements
+
+### 5. Fix in burn order
+
+If the user asked for code changes, prioritize fixes in this order:
+
+1. stop automatic PR multiplication
+2. stop quota bypass
+3. stop premium leakage
+4. stop duplicate-job fanout and pointless retries
+5. close rerun/update safety gaps
+
+Keep the pass bounded to one to three direct fixes unless the same root cause clearly spans multiple files.
+
+### 6. Verify with the smallest proving steps
+
+- rerun only the targeted tests or integration slices that cover the changed path
+- verify whether the burn path is now:
+  - blocked
+  - deduped
+  - downgraded to cheaper analysis
+  - or rejected early
+- state the final status exactly:
+  - changed locally
+  - verified locally
+  - pushed
+  - deployed
+  - still blocked
+
+## High-Signal Failure Patterns
+
+### 1. One queue type for all triggers
+
+If pushes, PR syncs, and manual audits all enqueue the same job and the worker always creates a PR, analysis equals PR spam.
+
+### 2. Post-enqueue usage reservation
+
+If usage is checked at the front door but only incremented in the worker, concurrent requests can all pass the gate and exceed quota.
+
+### 3. Free tier on premium path
+
+If free queued jobs can still route into Anthropic or another premium provider when keys exist, that is real spend leakage even if the user never sees the premium result.
+
+### 4. App-generated branches re-enter the webhook
+
+If `pull_request.synchronize`, branch pushes, or comment-triggered runs fire on app-owned branches, the app can recursively analyze its own output.
+
+### 5. Expensive work before persistence safety
+
+If the system can spend tokens and then fail on PR creation, file update, or branch collision, it is burning cost without shipping value.
+
+## Pitfalls
+
+- do not begin with broad repo wandering; settle webhook -> queue -> worker first
+- do not mix customer billing inference with code-backed product truth
+- do not fix lower-value quality issues before the highest-burn path is contained
+- do not claim burn is fixed until the narrow proving step was rerun
+- do not push or deploy unless the user asked
+- do not touch unrelated repo-local changes if they are already in progress
+
+## Verification
+
+- root causes cite exact file paths and code areas
+- fixes are ordered by burn impact, not code neatness
+- proving commands are named
+- final status distinguishes local change, verification, push, and deployment

package/seed/marketplaces/ecc/skills/email-ops/SKILL.md

@@ -1,121 +1,121 @@
----
-name: email-ops
-description: Evidence-first mailbox triage, drafting, send verification, and sent-mail-safe follow-up workflow for ECC. Use when the user wants to organize email, draft or send through the real mail surface, or prove what landed in Sent.
-origin: ECC
----
-
-# Email Ops
-
-Use this when the real task is mailbox work: triage, drafting, replying, sending, or proving a message landed in Sent.
-
-This is not a generic writing skill. It is an operator workflow around the actual mail surface.
-
-## Skill Stack
-
-Pull these ECC-native skills into the workflow when relevant:
-
-- `brand-voice` before drafting anything user-facing
-- `investor-outreach` for investor, partner, or sponsor-facing mail
-- `customer-billing-ops` when the thread is a billing/support incident rather than generic correspondence
-- `knowledge-ops` when the message or thread should be captured into durable context afterward
-- `research-ops` when a reply depends on fresh external facts
-
-## When to Use
-
-- user asks to triage inbox or archive low-signal mail
-- user wants a draft, reply, or new outbound email
-- user wants to know whether a mail was already sent
-- the user wants proof of which account, thread, or Sent entry was used
-
-## Guardrails
-
-- draft first unless the user clearly asked for a live send
-- never claim a message was sent without a real Sent-folder or client-side confirmation
-- do not switch sender accounts casually; choose the account that matches the project and recipient
-- do not delete uncertain business mail during cleanup
-- if the task is really DM or iMessage work, hand off to `messages-ops`
-
-## Workflow
-
-### 1. Resolve the exact surface
-
-Before acting, settle:
-
-- which mailbox account
-- which thread or recipient
-- whether the task is triage, draft, reply, or send
-- whether the user wants draft-only or live send
-
-### 2. Read the thread before composing
-
-If replying:
-
-- read the existing thread
-- identify the last outbound touch
-- identify any commitments, deadlines, or unanswered questions
-
-If creating a new outbound:
-
-- identify warmth level
-- select the correct channel and sender account
-- pull `brand-voice` before drafting
-
-### 3. Draft, then verify
-
-For draft-only work:
-
-- produce the final copy
-- state sender, recipient, subject, and purpose
-
-For live-send work:
-
-- verify the exact final body first
-- send through the chosen mail surface
-- confirm the message landed in Sent or the equivalent sent-copy store
-
-### 4. Report exact state
-
-Use exact status words:
-
-- drafted
-- approval-pending
-- sent
-- blocked
-- awaiting verification
-
-If the send surface is blocked, preserve the draft and report the exact blocker instead of improvising a second transport without saying so.
-
-## Output Format
-
-```text
-MAIL SURFACE
-- account
-- thread / recipient
-- requested action
-
-DRAFT
-- subject
-- body
-
-STATUS
-- drafted / sent / blocked
-- proof of Sent when applicable
-
-NEXT STEP
-- send
-- follow up
-- archive / move
-```
-
-## Pitfalls
-
-- do not claim send success without a sent-copy check
-- do not ignore the thread history and write a contextless reply
-- do not mix mailbox work with DM or text-message workflows
-- do not expose secrets, auth details, or unnecessary message metadata
-
-## Verification
-
-- the response names the account and thread or recipient
-- any send claim includes Sent proof or an explicit client-side confirmation
-- the final state is one of drafted / sent / blocked / awaiting verification
+---
+name: email-ops
+description: Evidence-first mailbox triage, drafting, send verification, and sent-mail-safe follow-up workflow for ECC. Use when the user wants to organize email, draft or send through the real mail surface, or prove what landed in Sent.
+origin: ECC
+---
+
+# Email Ops
+
+Use this when the real task is mailbox work: triage, drafting, replying, sending, or proving a message landed in Sent.
+
+This is not a generic writing skill. It is an operator workflow around the actual mail surface.
+
+## Skill Stack
+
+Pull these ECC-native skills into the workflow when relevant:
+
+- `brand-voice` before drafting anything user-facing
+- `investor-outreach` for investor, partner, or sponsor-facing mail
+- `customer-billing-ops` when the thread is a billing/support incident rather than generic correspondence
+- `knowledge-ops` when the message or thread should be captured into durable context afterward
+- `research-ops` when a reply depends on fresh external facts
+
+## When to Use
+
+- user asks to triage inbox or archive low-signal mail
+- user wants a draft, reply, or new outbound email
+- user wants to know whether a mail was already sent
+- the user wants proof of which account, thread, or Sent entry was used
+
+## Guardrails
+
+- draft first unless the user clearly asked for a live send
+- never claim a message was sent without a real Sent-folder or client-side confirmation
+- do not switch sender accounts casually; choose the account that matches the project and recipient
+- do not delete uncertain business mail during cleanup
+- if the task is really DM or iMessage work, hand off to `messages-ops`
+
+## Workflow
+
+### 1. Resolve the exact surface
+
+Before acting, settle:
+
+- which mailbox account
+- which thread or recipient
+- whether the task is triage, draft, reply, or send
+- whether the user wants draft-only or live send
+
+### 2. Read the thread before composing
+
+If replying:
+
+- read the existing thread
+- identify the last outbound touch
+- identify any commitments, deadlines, or unanswered questions
+
+If creating a new outbound:
+
+- identify warmth level
+- select the correct channel and sender account
+- pull `brand-voice` before drafting
+
+### 3. Draft, then verify
+
+For draft-only work:
+
+- produce the final copy
+- state sender, recipient, subject, and purpose
+
+For live-send work:
+
+- verify the exact final body first
+- send through the chosen mail surface
+- confirm the message landed in Sent or the equivalent sent-copy store
+
+### 4. Report exact state
+
+Use exact status words:
+
+- drafted
+- approval-pending
+- sent
+- blocked
+- awaiting verification
+
+If the send surface is blocked, preserve the draft and report the exact blocker instead of improvising a second transport without saying so.
+
+## Output Format
+
+```text
+MAIL SURFACE
+- account
+- thread / recipient
+- requested action
+
+DRAFT
+- subject
+- body
+
+STATUS
+- drafted / sent / blocked
+- proof of Sent when applicable
+
+NEXT STEP
+- send
+- follow up
+- archive / move
+```
+
+## Pitfalls
+
+- do not claim send success without a sent-copy check
+- do not ignore the thread history and write a contextless reply
+- do not mix mailbox work with DM or text-message workflows
+- do not expose secrets, auth details, or unnecessary message metadata
+
+## Verification
+
+- the response names the account and thread or recipient
+- any send claim includes Sent proof or an explicit client-side confirmation
+- the final state is one of drafted / sent / blocked / awaiting verification