agentsclimarketplace

Reference inventory and source map

Skill lubochka/xiigen-mvp-engine/.claude/skills/universal/reference-inventory-and-source-map

Self-building AI code generation engine that generates application flows instead of implementing them. AGPL-3.0.From the repository description

Install
npx -y skills add lubochka/xiigen-mvp-engine --skill reference-inventory-and-source-map

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.3 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

Reference Inventory and Source Map

Purpose

Use this so no claim in a plan, review, or report is unsourced, no cited library/artifact is asserted to exist without proof, and no external material is used without a license check.

When to Use

Invoke when authoring or reviewing any plan/review/report that states facts about the codebase, cites a library or artifact, or imports external material.

Why this exists for mvp

Today mvp has only a FLOW-specific source map (flow-prep-library/A-TO-B-SOURCE-MAP*.md). There is no UNIFIED source-map gate over the whole TS monorepo, and no explicit license/source boundary for Anthropic/OpenAI/Google SDK material. This skill is that unified gate; the A-TO-B map remains a flow-scoped specialization of it.


G08 universal content from llm_mvp_core — the unified source map

1. Every claim traces to a source row

Each factual claim in a plan/review/report gets a row:

| claim | source_id | path | line_range | source_layer |
source_layer (provenance, NOT authority):
  IMPLEMENTATION  — server/src/**.ts, client/src/**.tsx, rag/**.py  (actual code)
  TEST            — **/*.spec.ts (Jest), **/*.e2e.ts (Playwright), rag/test_*.py (pytest)
  DESIGN_DOC      — a plan / manifest / .xiigen wiki-domain doc (intent, not proof)
  RECONCILIATION  — a STATE / registry / index file asserting status

A DESIGN_DOC row may NOT be reported as an IMPLEMENTATION fact. When layers disagree, code (IMPLEMENTATION/TEST) wins and the disagreement is itself a finding.

2. Benchmark / foreign / transcript material is evidence-only

Another model's plan, an attached benchmark, a pasted transcript, an old plan, a STATE file, or a sub-agent packet is allowed_use=evidence_only and may_create_requirement=false unless the current human instruction explicitly reactivates a specific line. A benchmark detail enters the plan only through an explicit accept/reject/defer row, never silently.

3. License / source gate (mvp)

External material used to justify a design or, especially, to seed any shared learning, must pass a license check before use:

PREFERRED for shared/common use : MIT / Apache-2.0 (record upstream URL + LICENSE reference).
NOT common-training material     : unknown-license, GPL, or private/user material — evidence-only
                                   or user-adaptive/private, never common, without explicit approval.
SDK material (Anthropic/OpenAI/Google) : cite the SDK's own license + the exact API surface used;
                                   do NOT copy SDK-licensed source text into mvp skills/code as if
                                   it were mvp-owned. Route through the fabric interface, not a copy.

Private user prompts/chats/local project files train the adaptive/user leg only, never the common leg, unless explicitly redacted and approved.

4. Disjoint evidence

A claim and the evidence that proves it must not be the same artifact. "The plan says X, and the proof is that the plan says X" is circular. Proof for an IMPLEMENTATION claim is code or a test, from a different source row than the claim's own statement.

5. Population proof for named artifacts/libraries

When a claim names an artifact set or library ("the wiki-domain docs cover N topics", "library L is used across the server"), prove the population with a real command this session:

grep -rc "<symbol>" server/src | <count>            # usage population
find rag -name "test_*.py" | wc -l                  # test population
ls .xiigen/wiki-domain/documentation/*.md | wc -l   # generated-doc population (hundreds — count it)

A named-population claim without a count is unsupported. For .xiigen/wiki-domain material (hundreds of auto-generated .md), population proof is mandatory before any "covers/complete" claim.

mvp evidence specifics

  • path + line_range on .ts / .tsx (server/client) and .py (rag sidecar).
  • Verify counts with grep -rc, npx jest ("Tests:" line), find ... | wc -l.
  • The .xiigen/wiki-domain manifests are DESIGN_DOC/third-party-derived evidence, not IMPLEMENTATION of mvp behavior.

Avoid

  • Do not state a codebase fact without a path+line_range row.
  • Do not promote a DESIGN_DOC/benchmark line into a requirement without an explicit accept row.
  • Do not seed common learning from unknown/GPL/private material.
  • Do not import source architecture, algorithms, design patterns, training, DPO, source domains, source classes, or source-specific paths.

Completion Signal

  • Every claim has a source row, every named population has a count, license/disjoint/population gates pass, and benchmark material is quarantined as evidence-only.

Note-only (NOT ported — stays in G12, R5)

The trainable-model source roots (DPO pair roots, checkpoint/training-data pointers) are owned by llm_mvp_core; here the source map records the .xiigen manifest/locator pointer to the shared model, not its training-data inventory.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most operations skills give in ~1.2k tokens

Counted across 483 of the 484 authors here whose files we hold, read 2026-08-07

  • Collect monitoring data throughout the simulationin 14 of 483, across 6 files
  • Set the random seed for reproducibilityin 14 of 483, across 6 files
  • Validate simulations against analytical solutionsin 12 of 483, across 4 files
  • Clarify goals, constraints, and inputsin 11 of 483, across 2 files
  • Implement contract tests for integration pointsin 11 of 483, across 2 files
  • Implement strangler fig infrastructure with API gatewayin 11 of 483, across 2 files
  • Audit modernized components for security vulnerabilitiesin 11 of 483, across 2 files
  • Avoid Python blocking calls in processesin 10 of 483, across 3 files
  • Use resource context managers for automatic cleanupin 9 of 483, across 2 files
  • Maintain consistent time unitsin 9 of 483, across 2 files
  • Validate outcomes against success criteriain 8 of 483, across 1 file
  • Analyze the legacy codebase for technical debtin 8 of 483, across 1 file

Said here and by no other author read

  • trace every factual claim to a source row
  • assign a valid source layer to every row
  • treat benchmark and transcript material as evidence only
  • record a license check for external material
  • route SDK material through the fabric interface
  • prove named artifact populations with a command

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.