ワンクリックでManusで任意のスキルを実行

kernel-pipeline

スター23

フォーク2

更新日2026年7月16日 09:01

Orchestrazione completa della pipeline kernel su un bug: T1 compressione (hook, ambientale) -> T2 repo slice -> T3 carta del task -> fix -> T4 verifica. Usala per bug non banali in repo medio-grandi; per bug piccoli usa direttamente kernel-repo-slice o niente.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Pinperepette

Pinperepette/context-kernel

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

kernel-pipeline — C' = T4(T3(T2(T1(C))))

Ogni stadio e' un operatore con un invariante dichiarato. T1 (compressione degli output dei tool) e' ambientale: gli hook la applicano gia'. Questa skill orchestra il resto.

Quando

Bug non banale in repo con molti file. Se il repo e' piccolo o il fix e' ovvio, salta la pipeline: il costo degli stadi deve valere meno del vagare.

Stadi

T2 — slice del repo (deterministico): segui kernel-repo-slice col sintomo. Ottieni il manifest C2. In Pi puoi delegare al tool isolato kernel_scout; in Claude Code all'agent kernel-scout.
T3 — carta del task (semantico, citabile): segui kernel-invariants sui file di C2. Ottieni la carta C3. In Pi puoi delegare al tool isolato kernel_extractor; in Claude Code all'agent kernel-extractor.
Fix: lavora SOLO da C3 + i file citati. Regola page-fault: se serve un file fuori slice, leggilo e ANNOTA il miss (file + perche' serviva).
T4 — verifica: ripassa la carta vincolo per vincolo contro il diff. A campione (fix delicati): kernel-verify con Q = il bug, x = i file citati interi, pi(x) = la carta — la risposta cambia? In Pi puoi delegare al tool isolato kernel_verifier; in Claude Code all'agent kernel-verifier.

Telemetria (per la curva rate-distortion)

A fine giro annota quattro numeri nel report:

rate: file in slice / file scansionati (dal manifest)
fault: quanti page fault (file fuori slice letti davvero)
repair: costo dei fault (righe lette fuori slice)
verdetto T4: vincoli rispettati / violati

Un fault alto con repair basso = la slice era aggressiva ma il modello regge (bene). Vincoli violati non citati = T3 ha perso segnale (male: stringere T3, non allargare T2).

Persistenza (OBBLIGATORIA a fine giro)

Oltre al report, appendi UNA riga JSON per run a ~/.context-kernel-pipeline.jsonl (e' il dataset della curva rate-distortion). Schema — coi numeri veri del run:

python3 - <<'PYEOF'
import json, os, datetime
rec = {
    "ts": datetime.datetime.now().isoformat(timespec="seconds"),
    "repo": "/path/del/repo", "scanned": 1415, "slice": 123,
    "fault": 2, "repair_righe": 15,
    "verdetto": "PASS", "vincoli": "12/12",
    "note": "cosa ha morso il fault, se c'e' stato",
}
rec["rate"] = round(1 - rec["slice"] / rec["scanned"], 3)
with open(os.path.expanduser("~/.context-kernel-pipeline.jsonl"), "a") as f:
    f.write(json.dumps(rec) + "\n")
PYEOF

このリポジトリの他の Skills

同じリポジトリ

kernel-repo-slice

Pinperepette/context-kernel

T2 della pipeline kernel: proietta un intero repository sul working set rilevante per un bug (P_Q a livello repo). Usalo PRIMA di esplorare un repo grande quando hai un sintomo concreto: stack trace, messaggio d'errore, file indiziati. Output: manifest ordinato con motivazioni + esclusioni recuperabili (page fault).

2026-07-2323

kernel-ops

Pinperepette/context-kernel

Operazioni e diagnostica del plugin context-kernel a linguaggio naturale, senza dover digitare slash command. Usala quando l'utente chiede — con parole sue — lo stato o la salute del kernel, quanti token ha risparmiato, un health-check (doctor), di giudicare i campioni A/B (answer-invariance), di recuperare un output parcheggiato/eliso (recall), la carta del task attiva, uno smoke test della compressione, o i tassi/prior appresi (tune). Esempi: "come va il context-kernel", "quanto ho risparmiato", "fai il doctor del kernel", "controlla che il plugin sia a posto", "giudica gli A/B", "recupera quell'output parcheggiato", "che carta del task ho attiva". Instrada verso lo script giusto; le attuazioni che SCRIVONO stato restano sempre esplicite.

2026-07-2023

kernel-slice

Pinperepette/context-kernel

Estrae la fetta minimale di un file Python o Go rilevante per un simbolo (funzione/classe/tipo), scartando tutto cio' che non puo' influenzarne il comportamento. Usalo prima di leggere per intero un file grande quando ti interessa solo un simbolo specifico.

2026-07-1823

kernel-invariants

Pinperepette/context-kernel

T3 della pipeline kernel: dall'output dello slicer estrae la CARTA DEL TASK — i vincoli che il fix deve rispettare, ognuno con citazione file:riga. Converte massa di codice in proposizioni verificabili. Usala dopo kernel-repo-slice e prima di scrivere il fix.

2026-07-1723

kernel-verify

Pinperepette/context-kernel

Verifica se una compressione/proiezione del contesto ha preservato la risposta (answer-invariance A(x) = A(pi(x))). Usa la sessione corrente per rispondere e giudicare — nessuna chiave API, nessun costo extra oltre l'abbonamento.

2026-07-1623

name	kernel-pipeline
description	Orchestrazione completa della pipeline kernel su un bug: T1 compressione (hook, ambientale) -> T2 repo slice -> T3 carta del task -> fix -> T4 verifica. Usala per bug non banali in repo medio-grandi; per bug piccoli usa direttamente kernel-repo-slice o niente.

kernel-pipeline — C' = T4(T3(T2(T1(C))))

Ogni stadio e' un operatore con un invariante dichiarato. T1 (compressione degli output dei tool) e' ambientale: gli hook la applicano gia'. Questa skill orchestra il resto.

Quando

Bug non banale in repo con molti file. Se il repo e' piccolo o il fix e' ovvio, salta la pipeline: il costo degli stadi deve valere meno del vagare.

Stadi

T2 — slice del repo (deterministico): segui kernel-repo-slice col sintomo. Ottieni il manifest C2. In Pi puoi delegare al tool isolato kernel_scout; in Claude Code all'agent kernel-scout.
T3 — carta del task (semantico, citabile): segui kernel-invariants sui file di C2. Ottieni la carta C3. In Pi puoi delegare al tool isolato kernel_extractor; in Claude Code all'agent kernel-extractor.
Fix: lavora SOLO da C3 + i file citati. Regola page-fault: se serve un file fuori slice, leggilo e ANNOTA il miss (file + perche' serviva).
T4 — verifica: ripassa la carta vincolo per vincolo contro il diff. A campione (fix delicati): kernel-verify con Q = il bug, x = i file citati interi, pi(x) = la carta — la risposta cambia? In Pi puoi delegare al tool isolato kernel_verifier; in Claude Code all'agent kernel-verifier.

Telemetria (per la curva rate-distortion)

A fine giro annota quattro numeri nel report:

rate: file in slice / file scansionati (dal manifest)
fault: quanti page fault (file fuori slice letti davvero)
repair: costo dei fault (righe lette fuori slice)
verdetto T4: vincoli rispettati / violati

Un fault alto con repair basso = la slice era aggressiva ma il modello regge (bene). Vincoli violati non citati = T3 ha perso segnale (male: stringere T3, non allargare T2).

Persistenza (OBBLIGATORIA a fine giro)

Oltre al report, appendi UNA riga JSON per run a ~/.context-kernel-pipeline.jsonl (e' il dataset della curva rate-distortion). Schema — coi numeri veri del run:

python3 - <<'PYEOF'
import json, os, datetime
rec = {
    "ts": datetime.datetime.now().isoformat(timespec="seconds"),
    "repo": "/path/del/repo", "scanned": 1415, "slice": 123,
    "fault": 2, "repair_righe": 15,
    "verdetto": "PASS", "vincoli": "12/12",
    "note": "cosa ha morso il fault, se c'e' stato",
}
rec["rate"] = round(1 - rec["slice"] / rec["scanned"], 3)
with open(os.path.expanduser("~/.context-kernel-pipeline.jsonl"), "a") as f:
    f.write(json.dumps(rec) + "\n")
PYEOF