@funnycode/myclaude 0.1.70 → 0.1.71

package/seed/marketplaces/ecc/skills/ralphinho-rfc-pipeline/SKILL.md

@@ -1,67 +1,67 @@
----
-name: ralphinho-rfc-pipeline
-description: RFC-driven multi-agent DAG execution pattern with quality gates, merge queues, and work unit orchestration.
-origin: ECC
----
-
-# Ralphinho RFC Pipeline
-
-Inspired by [humanplane](https://github.com/humanplane) style RFC decomposition patterns and multi-unit orchestration workflows.
-
-Use this skill when a feature is too large for a single agent pass and must be split into independently verifiable work units.
-
-## Pipeline Stages
-
-1. RFC intake
-2. DAG decomposition
-3. Unit assignment
-4. Unit implementation
-5. Unit validation
-6. Merge queue and integration
-7. Final system verification
-
-## Unit Spec Template
-
-Each work unit should include:
-- `id`
-- `depends_on`
-- `scope`
-- `acceptance_tests`
-- `risk_level`
-- `rollback_plan`
-
-## Complexity Tiers
-
-- Tier 1: isolated file edits, deterministic tests
-- Tier 2: multi-file behavior changes, moderate integration risk
-- Tier 3: schema/auth/perf/security changes
-
-## Quality Pipeline per Unit
-
-1. research
-2. implementation plan
-3. implementation
-4. tests
-5. review
-6. merge-ready report
-
-## Merge Queue Rules
-
-- Never merge a unit with unresolved dependency failures.
-- Always rebase unit branches on latest integration branch.
-- Re-run integration tests after each queued merge.
-
-## Recovery
-
-If a unit stalls:
-- evict from active queue
-- snapshot findings
-- regenerate narrowed unit scope
-- retry with updated constraints
-
-## Outputs
-
-- RFC execution log
-- unit scorecards
-- dependency graph snapshot
-- integration risk summary
+---
+name: ralphinho-rfc-pipeline
+description: RFC-driven multi-agent DAG execution pattern with quality gates, merge queues, and work unit orchestration.
+origin: ECC
+---
+
+# Ralphinho RFC Pipeline
+
+Inspired by [humanplane](https://github.com/humanplane) style RFC decomposition patterns and multi-unit orchestration workflows.
+
+Use this skill when a feature is too large for a single agent pass and must be split into independently verifiable work units.
+
+## Pipeline Stages
+
+1. RFC intake
+2. DAG decomposition
+3. Unit assignment
+4. Unit implementation
+5. Unit validation
+6. Merge queue and integration
+7. Final system verification
+
+## Unit Spec Template
+
+Each work unit should include:
+- `id`
+- `depends_on`
+- `scope`
+- `acceptance_tests`
+- `risk_level`
+- `rollback_plan`
+
+## Complexity Tiers
+
+- Tier 1: isolated file edits, deterministic tests
+- Tier 2: multi-file behavior changes, moderate integration risk
+- Tier 3: schema/auth/perf/security changes
+
+## Quality Pipeline per Unit
+
+1. research
+2. implementation plan
+3. implementation
+4. tests
+5. review
+6. merge-ready report
+
+## Merge Queue Rules
+
+- Never merge a unit with unresolved dependency failures.
+- Always rebase unit branches on latest integration branch.
+- Re-run integration tests after each queued merge.
+
+## Recovery
+
+If a unit stalls:
+- evict from active queue
+- snapshot findings
+- regenerate narrowed unit scope
+- retry with updated constraints
+
+## Outputs
+
+- RFC execution log
+- unit scorecards
+- dependency graph snapshot
+- integration risk summary

package/seed/marketplaces/ecc/skills/recsys-pipeline-architect/SKILL.md

@@ -1,114 +1,114 @@
----
-name: recsys-pipeline-architect
-description: Design composable recommendation, ranking, and feed pipelines using the six-stage Source→Hydrator→Filter→Scorer→Selector→SideEffect framework popularized by xAI's open-sourced For You algorithm. Use this skill whenever the user is building any system that picks "the top K items for a (user, context)" — social feeds, content CMSs, RAG rerankers, task prioritizers, notification triage, search reranking, ad ranking.
-origin: community
----
-
-# recsys-pipeline-architect
-
-A spec-and-scaffold skill for building composable recommendation, ranking, and feed pipelines. It encodes the **six-stage pattern** — Source → Hydrator → Filter → Scorer → Selector → SideEffect — popularized by xAI's open-sourced [For You algorithm](https://github.com/xai-org/x-algorithm) (Apache 2.0). This skill is an independent reimplementation of the pattern (MIT) — no code copied from the original.
-
-Upstream: <https://github.com/mturac/recsys-pipeline-architect>
-
-## When to Use
-
-- User wants to build any system that picks "the top K items for a user/context"
-- User asks "how should I rank X" or describes a feed/personalization problem
-- User has a scoring function and needs the pipeline plumbing around it
-- User wants to migrate from a single relevance score to multi-action prediction with tunable weights
-- User is wrapping an LLM/ML scorer and needs filters, hydrators, side-effects, and a runnable scaffold in their stack (TypeScript / Go / Python)
-- Triggers: "recommendation system", "feed algorithm", "ranking pipeline", "for you feed", "candidate pipeline", "content recommender", "pipeline architecture for recsys", "RAG retrieval reranker"
-
-## When NOT to Use
-
-- Model architecture work (transformer design, two-tower retrieval, embedding training) — this skill is plumbing *around* the model, not the model itself
-- Pure ML training pipelines — the scoring function is the user's responsibility
-- Operating a deployed pipeline (monitoring, autoscaling) — out of scope
-
-## The six-stage framework
-
-| # | Stage | Job | Parallel? |
-|---|---|---|---|
-| 1 | **Source** | Fetch candidates from one or more origins | Yes — multiple sources run in parallel |
-| 2 | **Hydrator** | Enrich each candidate with metadata needed for filtering and scoring | Yes — independent hydrators run in parallel |
-| 3 | **Filter** | Drop candidates that should never be shown (blocked, expired, duplicate, ineligible) | Sequential — each filter sees fewer items |
-| 4 | **Scorer** | Assign each surviving candidate one or more scores | Sequential — later scorers see earlier scores |
-| 5 | **Selector** | Sort by final score, return top K | Single op |
-| 6 | **SideEffect** | Cache served IDs, log impressions, emit events, update counters | Async — must never block the response |
-
-### Why this exact order
-
-- Sources before hydration: know what candidates exist before paying to enrich them
-- Hydration before filtering: many filters need metadata the source did not provide
-- Filtering before scoring: scoring is the expensive stage; drop the ineligible first
-- Scorer chain (not single scorer): real systems compose ML scoring + diversity reranking + business rules
-- Selector after scoring: keeps scoring deterministic and cacheable
-- SideEffects last and async: side effects must never block the user response
-
-## Workflow when invoked
-
-Walk the user through these eight steps:
-
-1. **Clarify the use case** (one round, three questions): items being ranked? input context? language/runtime?
-2. **Identify the candidate sources**: usually in-network (followed/owned/subscribed) + out-of-network (ML retrieval / trending / similar-to-liked)
-3. **List required hydrations**: for each filter and scorer, what data does it need that the source did not provide?
-4. **List the filters**: duplicate, self, age, block/mute, previously-served, eligibility. Order matters — cheap before expensive.
-5. **Design the scorer chain**: primary (ML) → combiner (multi-action with weights) → diversity → business rules
-6. **Selector**: sort descending by final score, take top K (or stratified mix for in-network/out-of-network)
-7. **SideEffects**: cache served IDs, emit impression events, update counters, log analytics — all fire-and-forget
-8. **Generate the scaffold** in the user's stack
-
-## Key trade-offs to surface (don't default silently)
-
-### 1. Single score vs multi-action prediction
-
-- **Single score**: train one model to predict relevance. To change behavior → retrain.
-- **Multi-action**: predict `P(action)` for many actions (read, like, share, skip, report), combine with weights at serving time. To change behavior → change weights. No retraining.
-
-The X For You system uses multi-action with both positive and negative weights. Recommend multi-action when the user expects to tune frequently.
-
-### 2. Candidate isolation in scoring
-
-- **Isolated**: each candidate scored independently. Deterministic, cacheable.
-- **Joint**: candidates attend to each other during scoring (e.g., transformer over batch). More expressive but non-deterministic across batches.
-
-Default to isolation. Joint only when there's a specific reason (e.g., explicit batch-aware diversity).
-
-### 3. Online vs offline
-
-- **Request-time (online)**: pipeline runs on each request. Latency budget: 100–300ms. Default.
-- **Pre-computed (offline batch)**: pipeline runs periodically, results cached. Lower latency, lower freshness.
-- **Hybrid**: candidate retrieval offline, ranking online.
-
-## Hard rules
-
-1. **Do not invent benchmark numbers.** "How much faster?" → "depends on workload, run it yourself."
-2. **Attribution discipline.** When the pattern is referenced, attribute as "popularized by xAI's open-sourced For You algorithm" / `github.com/xai-org/x-algorithm` (Apache 2.0).
-3. **No trademark use.** Do not name the user's artifact "X-like" or use "For You" branding. Pattern is free; brand is not. Suggested naming: "candidate pipeline", "feed pipeline", "ranking pipeline", "recsys pipeline".
-4. **Surface trade-offs.** Multi-action vs single, isolation vs joint, online vs offline — never default silently.
-5. **The generated scaffold must run.** No pseudocode passing as code.
-6. **Filter order matters.** Cheap before expensive. Universal before user-specific.
-7. **Side effects never block.** Wrap in fire-and-forget patterns (goroutines / promises without await / asyncio tasks).
-
-## Anti-Patterns
-
-- Scoring before filtering (wastes compute on candidates that will be dropped anyway)
-- Synchronous side effects (cache writes / impression emits blocking the response)
-- A single "relevance" score when the product needs to tune for multiple objectives (engagement vs safety vs diversity vs ads)
-- Joint scoring as default (non-deterministic, harder to cache, doesn't compose with reranking stages)
-- Generating pseudocode "for illustration" — the scaffold must actually run
-
-## Upstream contents
-
-The upstream repository at <https://github.com/mturac/recsys-pipeline-architect> ships:
-
-- Full `SKILL.md` with the complete 8-step workflow
-- 5 load-on-demand reference docs: interfaces in 4 languages (TS/Go/Python/Rust), multi-action scoring pattern, candidate isolation, filter cookbook (12 patterns), scorer cookbook (weighted sum, MMR, diversity penalty, position debiasing)
-- 3 runnable example scaffolds, every one green on its test suite:
-  - Strapi v5 plugin (TypeScript / Jest — 3/3 pass)
-  - Zentra-compatible pipeline (Go with generics — 3/3 pass)
-  - PMAI task prioritizer (Python / FastAPI / pytest — 3/3 pass)
-- v0.1.0 release tagged
-- MIT license; pattern attributed to xAI X For You algorithm (Apache 2.0)
-
-Install via skills.sh: `npx skills add mturac/recsys-pipeline-architect`
+---
+name: recsys-pipeline-architect
+description: Design composable recommendation, ranking, and feed pipelines using the six-stage Source→Hydrator→Filter→Scorer→Selector→SideEffect framework popularized by xAI's open-sourced For You algorithm. Use this skill whenever the user is building any system that picks "the top K items for a (user, context)" — social feeds, content CMSs, RAG rerankers, task prioritizers, notification triage, search reranking, ad ranking.
+origin: community
+---
+
+# recsys-pipeline-architect
+
+A spec-and-scaffold skill for building composable recommendation, ranking, and feed pipelines. It encodes the **six-stage pattern** — Source → Hydrator → Filter → Scorer → Selector → SideEffect — popularized by xAI's open-sourced [For You algorithm](https://github.com/xai-org/x-algorithm) (Apache 2.0). This skill is an independent reimplementation of the pattern (MIT) — no code copied from the original.
+
+Upstream: <https://github.com/mturac/recsys-pipeline-architect>
+
+## When to Use
+
+- User wants to build any system that picks "the top K items for a user/context"
+- User asks "how should I rank X" or describes a feed/personalization problem
+- User has a scoring function and needs the pipeline plumbing around it
+- User wants to migrate from a single relevance score to multi-action prediction with tunable weights
+- User is wrapping an LLM/ML scorer and needs filters, hydrators, side-effects, and a runnable scaffold in their stack (TypeScript / Go / Python)
+- Triggers: "recommendation system", "feed algorithm", "ranking pipeline", "for you feed", "candidate pipeline", "content recommender", "pipeline architecture for recsys", "RAG retrieval reranker"
+
+## When NOT to Use
+
+- Model architecture work (transformer design, two-tower retrieval, embedding training) — this skill is plumbing *around* the model, not the model itself
+- Pure ML training pipelines — the scoring function is the user's responsibility
+- Operating a deployed pipeline (monitoring, autoscaling) — out of scope
+
+## The six-stage framework
+
+| # | Stage | Job | Parallel? |
+|---|---|---|---|
+| 1 | **Source** | Fetch candidates from one or more origins | Yes — multiple sources run in parallel |
+| 2 | **Hydrator** | Enrich each candidate with metadata needed for filtering and scoring | Yes — independent hydrators run in parallel |
+| 3 | **Filter** | Drop candidates that should never be shown (blocked, expired, duplicate, ineligible) | Sequential — each filter sees fewer items |
+| 4 | **Scorer** | Assign each surviving candidate one or more scores | Sequential — later scorers see earlier scores |
+| 5 | **Selector** | Sort by final score, return top K | Single op |
+| 6 | **SideEffect** | Cache served IDs, log impressions, emit events, update counters | Async — must never block the response |
+
+### Why this exact order
+
+- Sources before hydration: know what candidates exist before paying to enrich them
+- Hydration before filtering: many filters need metadata the source did not provide
+- Filtering before scoring: scoring is the expensive stage; drop the ineligible first
+- Scorer chain (not single scorer): real systems compose ML scoring + diversity reranking + business rules
+- Selector after scoring: keeps scoring deterministic and cacheable
+- SideEffects last and async: side effects must never block the user response
+
+## Workflow when invoked
+
+Walk the user through these eight steps:
+
+1. **Clarify the use case** (one round, three questions): items being ranked? input context? language/runtime?
+2. **Identify the candidate sources**: usually in-network (followed/owned/subscribed) + out-of-network (ML retrieval / trending / similar-to-liked)
+3. **List required hydrations**: for each filter and scorer, what data does it need that the source did not provide?
+4. **List the filters**: duplicate, self, age, block/mute, previously-served, eligibility. Order matters — cheap before expensive.
+5. **Design the scorer chain**: primary (ML) → combiner (multi-action with weights) → diversity → business rules
+6. **Selector**: sort descending by final score, take top K (or stratified mix for in-network/out-of-network)
+7. **SideEffects**: cache served IDs, emit impression events, update counters, log analytics — all fire-and-forget
+8. **Generate the scaffold** in the user's stack
+
+## Key trade-offs to surface (don't default silently)
+
+### 1. Single score vs multi-action prediction
+
+- **Single score**: train one model to predict relevance. To change behavior → retrain.
+- **Multi-action**: predict `P(action)` for many actions (read, like, share, skip, report), combine with weights at serving time. To change behavior → change weights. No retraining.
+
+The X For You system uses multi-action with both positive and negative weights. Recommend multi-action when the user expects to tune frequently.
+
+### 2. Candidate isolation in scoring
+
+- **Isolated**: each candidate scored independently. Deterministic, cacheable.
+- **Joint**: candidates attend to each other during scoring (e.g., transformer over batch). More expressive but non-deterministic across batches.
+
+Default to isolation. Joint only when there's a specific reason (e.g., explicit batch-aware diversity).
+
+### 3. Online vs offline
+
+- **Request-time (online)**: pipeline runs on each request. Latency budget: 100–300ms. Default.
+- **Pre-computed (offline batch)**: pipeline runs periodically, results cached. Lower latency, lower freshness.
+- **Hybrid**: candidate retrieval offline, ranking online.
+
+## Hard rules
+
+1. **Do not invent benchmark numbers.** "How much faster?" → "depends on workload, run it yourself."
+2. **Attribution discipline.** When the pattern is referenced, attribute as "popularized by xAI's open-sourced For You algorithm" / `github.com/xai-org/x-algorithm` (Apache 2.0).
+3. **No trademark use.** Do not name the user's artifact "X-like" or use "For You" branding. Pattern is free; brand is not. Suggested naming: "candidate pipeline", "feed pipeline", "ranking pipeline", "recsys pipeline".
+4. **Surface trade-offs.** Multi-action vs single, isolation vs joint, online vs offline — never default silently.
+5. **The generated scaffold must run.** No pseudocode passing as code.
+6. **Filter order matters.** Cheap before expensive. Universal before user-specific.
+7. **Side effects never block.** Wrap in fire-and-forget patterns (goroutines / promises without await / asyncio tasks).
+
+## Anti-Patterns
+
+- Scoring before filtering (wastes compute on candidates that will be dropped anyway)
+- Synchronous side effects (cache writes / impression emits blocking the response)
+- A single "relevance" score when the product needs to tune for multiple objectives (engagement vs safety vs diversity vs ads)
+- Joint scoring as default (non-deterministic, harder to cache, doesn't compose with reranking stages)
+- Generating pseudocode "for illustration" — the scaffold must actually run
+
+## Upstream contents
+
+The upstream repository at <https://github.com/mturac/recsys-pipeline-architect> ships:
+
+- Full `SKILL.md` with the complete 8-step workflow
+- 5 load-on-demand reference docs: interfaces in 4 languages (TS/Go/Python/Rust), multi-action scoring pattern, candidate isolation, filter cookbook (12 patterns), scorer cookbook (weighted sum, MMR, diversity penalty, position debiasing)
+- 3 runnable example scaffolds, every one green on its test suite:
+  - Strapi v5 plugin (TypeScript / Jest — 3/3 pass)
+  - Zentra-compatible pipeline (Go with generics — 3/3 pass)
+  - PMAI task prioritizer (Python / FastAPI / pytest — 3/3 pass)
+- v0.1.0 release tagged
+- MIT license; pattern attributed to xAI X For You algorithm (Apache 2.0)
+
+Install via skills.sh: `npx skills add mturac/recsys-pipeline-architect`

package/seed/marketplaces/ecc/skills/recursive-decision-ledger/SKILL.md

@@ -1,79 +1,79 @@
----
-name: recursive-decision-ledger
-description: Use when the user asks for repeated rollouts, marked decision processes, high-dimensional search, stochastic optimization, local-optima exploration, ensemble comparison, or recursive reasoning with a visible evidence trail.
-origin: ECC
-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# Recursive Decision Ledger
-
-Use this skill when the user is trying to force deeper computation through
-repeated rollouts or "Prime Gauss" style recursive prompting. Preserve the useful
-part: repeated trials, prior memory, fresh information, and explicit marks.
-Remove the unsafe part: pretending the loop proves certainty.
-
-## Ledger Contract
-
-Every rollout should record:
-
-- rollout id and timestamp;
-- prior accepted winner and prior watchlist;
-- fresh information ingested;
-- search space size;
-- model families or heuristics used;
-- trial count and effective trial count;
-- top candidates;
-- decision marks;
-- coherence marks against the prior ledger;
-- promotion gate result.
-
-Prefer JSONL for append-only ledgers and Markdown for human summaries.
-
-## Rollout Loop
-
-1. Load the prior ledger.
-2. Capture new information at time-step zero.
-3. Run the bounded search.
-4. Mark each candidate: accept, watch, reject, decay watch, or needs replay.
-5. Compare winners against prior winners and latest marked rollout.
-6. Downgrade candidates when drift, tail risk, stale data, or failed replay
-   invalidates the previous mark.
-7. Append artifacts before summarizing.
-
-## Coherence Mark
-
-Include a compact coherence mark:
-
-```text
-Ensemble matches prior winner: true
-Recursive matches prior winner: false
-Latest rollout match: true
-Live promotion allowed: false
-Reason: replay and freshness gates not satisfied
-```
-
-## Promotion Rules
-
-For trading, capital allocation, production deploys, migrations, or destructive
-ops, recursive confidence is not approval.
-
-Default to paper, dry-run, read-only, preview, or staged mode unless the user
-explicitly approves the live action and the repo/service gate supports it.
-
-Promote only when:
-
-- the candidate beats the prior accepted winner on the chosen metric;
-- correctness and replay checks pass;
-- risk limits are explicit;
-- the evidence is durable;
-- the user has approved the live step when needed.
-
-## Summary Shape
-
-Lead with the decision, not the drama:
-
-```text
-Rollout 15 complete. The prior winner still holds, but edge deteriorated 17%.
-Status: watch, not live. Next gate: 20 replay fills with fresh orderbook age
-below threshold.
-```
+---
+name: recursive-decision-ledger
+description: Use when the user asks for repeated rollouts, marked decision processes, high-dimensional search, stochastic optimization, local-optima exploration, ensemble comparison, or recursive reasoning with a visible evidence trail.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Recursive Decision Ledger
+
+Use this skill when the user is trying to force deeper computation through
+repeated rollouts or "Prime Gauss" style recursive prompting. Preserve the useful
+part: repeated trials, prior memory, fresh information, and explicit marks.
+Remove the unsafe part: pretending the loop proves certainty.
+
+## Ledger Contract
+
+Every rollout should record:
+
+- rollout id and timestamp;
+- prior accepted winner and prior watchlist;
+- fresh information ingested;
+- search space size;
+- model families or heuristics used;
+- trial count and effective trial count;
+- top candidates;
+- decision marks;
+- coherence marks against the prior ledger;
+- promotion gate result.
+
+Prefer JSONL for append-only ledgers and Markdown for human summaries.
+
+## Rollout Loop
+
+1. Load the prior ledger.
+2. Capture new information at time-step zero.
+3. Run the bounded search.
+4. Mark each candidate: accept, watch, reject, decay watch, or needs replay.
+5. Compare winners against prior winners and latest marked rollout.
+6. Downgrade candidates when drift, tail risk, stale data, or failed replay
+   invalidates the previous mark.
+7. Append artifacts before summarizing.
+
+## Coherence Mark
+
+Include a compact coherence mark:
+
+```text
+Ensemble matches prior winner: true
+Recursive matches prior winner: false
+Latest rollout match: true
+Live promotion allowed: false
+Reason: replay and freshness gates not satisfied
+```
+
+## Promotion Rules
+
+For trading, capital allocation, production deploys, migrations, or destructive
+ops, recursive confidence is not approval.
+
+Default to paper, dry-run, read-only, preview, or staged mode unless the user
+explicitly approves the live action and the repo/service gate supports it.
+
+Promote only when:
+
+- the candidate beats the prior accepted winner on the chosen metric;
+- correctness and replay checks pass;
+- risk limits are explicit;
+- the evidence is durable;
+- the user has approved the live step when needed.
+
+## Summary Shape
+
+Lead with the decision, not the drama:
+
+```text
+Rollout 15 complete. The prior winner still holds, but edge deteriorated 17%.
+Status: watch, not live. Next gate: 20 replay fills with fresh orderbook age
+below threshold.
+```