Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

wikify-connect-repo

Étoiles45

Forks5

Mis à jour4 juillet 2026 à 03:38

Connect ingested code silos on the concept axis — cross-link the same concept (a Pallas kernel, an optimization technique) across repos, inline like a normal wiki: the host wiki's concept page links down to each repo's implementation, and each implementation links back up. Selective by design — you choose WHICH concepts to connect (connecting everything drowns the pages). Trigger at the tail of an ingest (from the 2nd repo on) or when the user asks to connect / cross-link the ingested repos. No new page types; idempotent and re-runnable.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

vlasenkoalexey

vlasenkoalexey/tpu_performance_autoresearch_wiki

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name

wikify-connect-repo

description

wikify-connect-repo

A single ingest produces a silo (wiki/<subdir>/<slug>/ with overview.md + concepts/ + catalog/). This skill wires silos together on the concept axis, inline, as a normal wiki — through the concept pages the host already curates (wiki/concepts/*.md). The concept page links down to each repo's implementation page; each implementation links up to the concept. No side-table, no new page type, no _connect/ artifact — just links on existing pages.

Selective by design. Connecting every concept to every repo drowns the pages. So the human picks which concepts to connect at this phase — that is the whole point of the interactive step.

The Python/LLM split is hard here too. Candidate proposal + the link insertion are pure Python (wikify connect). The only judgment is which concepts to connect (and, optionally, pruning a stray name-match) — done at the ask below.

Preconditions

The wiki has ≥2 ingested silos (the first repo has nothing to connect to) and a concept vocabulary directory (wiki/concepts/*.md). If either is missing, STOP — nothing to do.
Run from the wiki root (where wiki/ and config/ live). Non-interactive/batch: do only --refresh (regenerate already-connected concepts); never auto-connect new ones.

Procedure

Propose (deterministic; no model, writes nothing). Run:
```
wikify connect
```
It prints each vocabulary concept that has candidate implementations across the silos (most-implemented first), the repos involved, and which concepts are already connected (✓). A candidate is tag (an explicit concepts: frontmatter match — authoritative) or a name/token match. Nothing is written yet.
Ask what to connect (interactive — the selective step). Show the human the proposed concepts and ask which to connect. Recommend the highest-value ones for the wiki's lens (e.g. the Pallas kernels + optimization techniques), not all of them — the goal is a useful spine, not a fully-connected graph. If a chosen concept's candidate list has an obvious name-collision (open the silo page to check when unsure), note the repo/rel-path to drop via --exclude.
Apply (deterministic). Wire the chosen concepts:
```
wikify connect --apply <key1,key2,...>   [--exclude <repo/rel-path,...>]
```
This writes, inside regenerable connect:auto blocks (hand prose untouched):
- on each wiki/concepts/<key>.md — a ## In this wiki's repos list linking down to every implementation page, grouped by repo;
- on each linked silo concept page — a one-line up-link back to the concept(s) it's part of.
When this run follows a new ingest (the usual trigger), also refresh the concepts that were connected before, so they pick up the new repo's implementations:
```
wikify connect --refresh
```
This skill owns --refresh — the ingest skill only hands off here and never runs wikify connect itself.
Deepen a hub (optional; LLM, only where asked). For a concept worth a real cross-repo narrative, edit its wiki/concepts/<key>.md prose outside the connect:auto block: a tight lens-framed definition, a short how the implementations differ synthesis grounded in the linked silo pages, and inbound backlinks (experiments/observations that used it). The auto block stays the machine-maintained link list; your prose sits above it. Never rewrite the linted silo pages — only their one-line up-link block is machine-managed.
Record. Append one line to the host log.md per its convention (e.g. ## [YYYY-MM-DD] connect | <n> concepts wired across <m> repos).

Notes

Idempotent / re-runnable. Connection state is the wiki pages (a concept page with a connect:auto block is connected — no side-file). After a new ingest, wikify connect --refresh regenerates every already-connected concept's links (picking up the new repo's matches); re-running --apply on the same keys produces no churn.
Vocabulary is the host's. The concept keys are wiki/concepts/ filenames (or --vocab <dir>), never wikify's — a non-code or non-TPU wiki brings its own. To add a concept to the spine, add a wiki/concepts/<key>.md and connect it.
Dependency links (repos that import each other) are a separate, future op (design.md Stage 7 "(a) dependency links"): re-resolving an external citation against another silo's SCIP index. Not yet automated here; this skill covers the concept-correspondence half.

Plus depuis ce dépôt

même dépôt

wikify-ingest-repo

vlasenkoalexey/tpu_performance_autoresearch_wiki

Ingest a code repo into a grounded, lint-clean markdown wiki an agent can answer internals questions from. Idempotent reconcile — first build, version bump (--ref), or an added concept are all the same operation. Trigger when the user asks to wikify/ingest a repo, build an internals wiki, or update one. Accepts a repo URL or local path as the argument and bootstraps `config/<slug>.md` itself — the user never hand-writes config.

2026-07-0445

lint

vlasenkoalexey/tpu_performance_autoresearch_wiki

Run the LINT operation defined in SCHEMA.md across the wiki. Checks every invariant the schema declares — orphan pages, broken links, missing profile/HLO sections, missing hypothesis-firing audits, stuck `status: in_progress` stubs, missing stub labels (Hypothesis/Mechanism/Predicted signal/Falsification criterion), log routing violations (loop-iteration in global log; ingest in per-lane log), stale codebase commit pins, model-page variant-matrix drift, knobs-translation-matrix coverage gaps, model-optimization-index catalog rot, per-model refuted-patterns referencing non-existent v-IDs, experiment commits on the code-repo side missing `exp:` footer, and more. Fixes mechanical issues automatically; surfaces judgment calls as a punch list for the user. Invoke periodically (every few days during active iteration), from `/stop-experiment` at session end (already wired), or whenever the wiki shape changed substantially (post-rename, post-bulk-import, post-SCHEMA-update).

2026-07-0345

ingest-source

vlasenkoalexey/tpu_performance_autoresearch_wiki

Ingest a paper, article, blog post, talk, or documentation page into the wiki. Encodes SCHEMA's INGEST-SOURCE operation as a callable skill. Reads the raw source (PDF/HTML under raw/sources/ or fetched from URL), confirms emphasis with the human before writing, files wiki/sources/<year>-<slug>.md, updates connections (concepts/codebases/models that touched the source), generates hypothesis candidates if applicable, and updates wiki/index.md + wiki/log.md per the operations contract. Invoke when ingesting any new perf-relevant source — the discussion step prevents misemphasis and the connection updates keep the wiki graph coherent. NOT for codebases (use INGEST-CODEBASE / a future /ingest-codebase skill) or per-experiment notes (those live in wiki/experiments/).

2026-07-0345

create-experiment

vlasenkoalexey/tpu_performance_autoresearch_wiki

Bootstrap a new model family for the autoresearch loop. Creates the folder structure under wiki/experiments/, scaffolds the model-level program.md from a template (asking the user about lanes, sizes, hardware targets, sequence length, and architecture invariants), optionally creates lane-level program.md stubs, and creates model page stubs under wiki/models/. Invoke once per new model family before /start-experiment can run on it.

2026-06-0245

create-retrospective

vlasenkoalexey/tpu_performance_autoresearch_wiki

Generate a comprehensive retrospective for a `(model, lane)` pair that maps the explored search space, identifies coverage gaps from the topic taxonomy (`model-optimization-index.md`) and Pallas kernel catalog, surfaces premature-exhaustion signals (single-axis-probe vs kernel-port imbalance, frontier-stuck duration), and proposes ranked next directions. **Reads ALL experiment pages in the lane** — not a sample — because the retrospective's value depends on comprehensive coverage of what's been tried. Includes a lightweight cross-lane brief by default. Manually callable; intended to be invoked when the agent reports "out of ideas" or hits the stuck-frontier signature, BEFORE concluding the lane is exhausted. Output is a dated analysis page at `wiki/analyses/<YYYY-MM-DD>-<model>-<lane>-retrospective.md`; the skill does NOT act on its own recommendations — it produces analysis, the loop / `/formulate-hypothesis` acts.

2026-06-0245

edit-model-code

vlasenkoalexey/tpu_performance_autoresearch_wiki

Coding-discipline guidelines for surgically modifying model code inside a per-experiment fork in the autoresearch loop. Adapts Andrej Karpathy's LLM-coding guidelines (think before coding, simplicity first, surgical changes, goal-driven execution) to this project's invariants — no semantics drift, one mechanism per experiment, the training run is the test, no kernel fallbacks. Invoke BEFORE opening any model-code file in the experiment fork (step 4 of program.md's "experiment loop"). Helps weaker LLMs stay disciplined under autoresearch-loop pressure where the agent is autonomous and can't ask clarifying questions. NOT for wiki edits, infra scripts, or trunk merges — those are out of scope.

2026-06-0245

name

wikify-connect-repo

description

wikify-connect-repo

Selective by design. Connecting every concept to every repo drowns the pages. So the human picks which concepts to connect at this phase — that is the whole point of the interactive step.

Preconditions

The wiki has ≥2 ingested silos (the first repo has nothing to connect to) and a concept vocabulary directory (wiki/concepts/*.md). If either is missing, STOP — nothing to do.
Run from the wiki root (where wiki/ and config/ live). Non-interactive/batch: do only --refresh (regenerate already-connected concepts); never auto-connect new ones.

Procedure

Propose (deterministic; no model, writes nothing). Run:
```
wikify connect
```
It prints each vocabulary concept that has candidate implementations across the silos (most-implemented first), the repos involved, and which concepts are already connected (✓). A candidate is tag (an explicit concepts: frontmatter match — authoritative) or a name/token match. Nothing is written yet.
Ask what to connect (interactive — the selective step). Show the human the proposed concepts and ask which to connect. Recommend the highest-value ones for the wiki's lens (e.g. the Pallas kernels + optimization techniques), not all of them — the goal is a useful spine, not a fully-connected graph. If a chosen concept's candidate list has an obvious name-collision (open the silo page to check when unsure), note the repo/rel-path to drop via --exclude.
Apply (deterministic). Wire the chosen concepts:
```
wikify connect --apply <key1,key2,...>   [--exclude <repo/rel-path,...>]
```
This writes, inside regenerable connect:auto blocks (hand prose untouched):
- on each wiki/concepts/<key>.md — a ## In this wiki's repos list linking down to every implementation page, grouped by repo;
- on each linked silo concept page — a one-line up-link back to the concept(s) it's part of.
When this run follows a new ingest (the usual trigger), also refresh the concepts that were connected before, so they pick up the new repo's implementations:
```
wikify connect --refresh
```
This skill owns --refresh — the ingest skill only hands off here and never runs wikify connect itself.
Deepen a hub (optional; LLM, only where asked). For a concept worth a real cross-repo narrative, edit its wiki/concepts/<key>.md prose outside the connect:auto block: a tight lens-framed definition, a short how the implementations differ synthesis grounded in the linked silo pages, and inbound backlinks (experiments/observations that used it). The auto block stays the machine-maintained link list; your prose sits above it. Never rewrite the linted silo pages — only their one-line up-link block is machine-managed.
Record. Append one line to the host log.md per its convention (e.g. ## [YYYY-MM-DD] connect | <n> concepts wired across <m> repos).

Notes

Idempotent / re-runnable. Connection state is the wiki pages (a concept page with a connect:auto block is connected — no side-file). After a new ingest, wikify connect --refresh regenerates every already-connected concept's links (picking up the new repo's matches); re-running --apply on the same keys produces no churn.
Vocabulary is the host's. The concept keys are wiki/concepts/ filenames (or --vocab <dir>), never wikify's — a non-code or non-TPU wiki brings its own. To add a concept to the spine, add a wiki/concepts/<key>.md and connect it.
Dependency links (repos that import each other) are a separate, future op (design.md Stage 7 "(a) dependency links"): re-resolving an external citation against another silo's SCIP index. Not yet automated here; this skill covers the concept-correspondence half.