The-Interdependency
@The-Interdependency Organization
Public Skills
gonol-build
by The-Interdependency
Construction, closure, and replay contract for gonols across UCNS and EDCM. Load this when building or reviewing UCNS geometry used by gonols, or building EDCM character, word, definition, or recursive-relation gonols. UCNS owns geometry; EDCM owns text construction. The required EDCM order is characters -> words -> definitions -> recursive gonol relations. Pronunciation is not required unless an explicitly declared later experiment makes it part of the construction. Do not load for unrelated geometry, ordinary prose editing, or measurement over already-closed gonols.
llms-build
by The-Interdependency
"Self-declaring LLM instructions file (llms.txt) built on msdmd. Modules or central files declare LLMS blocks with project overview, key definitions, architecture summary, and agent usage rules. A runner aggregates them into a standardized root llms.txt and surfaces drift/gaps. Load this when creating, updating, or maintaining llms.txt for any repo consumed by LLMs or agents."
skill-usage
by The-Interdependency
Record and report evidence-bearing usage maturity for skills installed from The Interdependency skill-lib. Load this when any other skill-lib skill is invoked, and when asked for skill counts, usage history, maturity, reliability, experimental status, field-test status, operational status, or daily-use status.
domain-claims
by The-Interdependency
"Domain-first lexical and semantic governance for canonical terms. Load this when a word or phrase is being promoted into a theorem term, ontology primitive, schema field, encoding label, skill doctrine, cross-domain mapping, or other meaning-bearing control surface; when multiple domains use the same word differently; when an acronym, initialism, symbol, or compact handle is being mistaken for a fixed expansion or definition; or when conversational provenance is about to be attached to a definition. Do not load for ordinary prose, casual wording choices, or simple dictionary explanations that will not control canon or structure."
meta
by The-Interdependency
"METAPAT consultation router for The Interdependency. Load this when deciding which distinctions, relations, boundaries, transformations, scales, or cross-domain correspondences should organize downstream work; when the-interdependency skill's METAPAT consultation gate triggers; when an unresolved conceptual choice would constrain architecture, semantics, measurement, ontology, or later claims; or when explicitly asked to consult, apply, or interpret current METAPAT. Do not load merely for routine implementation under already-fixed conceptual contracts."
cap-build
by The-Interdependency
Self-declaring capability inventory built on msdmd. Each module declares the capabilities it exposes in a # === CAPABILITIES === block; a runner builds a capability map, verifies referenced surfaces still exist, reports duplicate or missing capability declarations, and surfaces visible gaps. Load this when declaring what a module can do, when building capability registries for agents, or when auditing exposed surfaces against declared capabilities.
skill-usage
by The-Interdependency
"Record and report evidence-bearing usage maturity for skills installed from The Interdependency skill-lib. Load this when any other skill-lib skill is invoked, and when asked for skill counts, usage history, maturity, reliability, experimental status, field-test status, operational status, or daily-use status."
domain-claims
by The-Interdependency
Domain-first lexical and semantic governance for canonical terms. Load this when a word or phrase is being promoted into a theorem term, ontology primitive, schema field, encoding label, skill doctrine, cross-domain mapping, or other meaning-bearing control surface; when multiple domains use the same word differently; when an acronym, initialism, symbol, or compact handle is being mistaken for a fixed expansion or definition; or when conversational provenance is about to be attached to a definition. Do not load for ordinary prose, casual wording choices, or simple dictionary explanations that will not control canon or structure.
risk-boundary-build
by The-Interdependency
"Self-declaring runtime risk and permission boundaries built on msdmd. Each module records auth, storage, network, user-data, admin, and operational effects in a # === BOUNDARIES === block; a runner audits sensitive files, reports unresolved hmmm boundaries, and surfaces visible coverage gaps. Load this when touching code with permissions, persistence, network calls, user data, admin behavior, migrations, or other risk-bearing effects."
loop-eng
by The-Interdependency
"Loop engineering for designing closed feedback cycles (Discover→Plan→Execute→Verify→Iterate), single-agent and fleet loops with subagent maker/checker separation, and automated verify-iterate workflows. Load this when building or orchestrating agent systems (a0p, AIMMH), EDCMBONE analysis pipelines, repeatable AI workflows, or any The-Interdependency project that benefits from structured loops instead of manual prompting. Cross-load with the-interdependency for org workflow context."
explore-data
by The-Interdependency
"Profile and explore a dataset to understand its shape, quality, and patterns. Use this when encountering a new table or file, checking null rates and column distributions, spotting data quality issues like duplicates or suspicious values, or deciding which dimensions and metrics to analyze."
a0p-instancing
by The-Interdependency
"Methodology for instancing agents in a0-betatest (the a0p research instrument), whose model diverges from canonical a0. Load this when adding or changing an AgentInstance / CharacterSheet CRUD path, a per-instance native ZFAE weight bank or its training/distillation loop, a ZFAE inference mode, a sentinel evaluation or pending-override gate, a per-agent safetensors checkpoint, or volatile sub-context memory — anywhere under a0-betatest backend/. Use it before writing code that creates, addresses, trains, runs, governs, or persists an a0p agent, so the code follows a0p's per-user CRUD + native-ZFAE + sentinel model instead of a0's spawn/fork/merge model. For canonical a0 and its mirror a0ucns, use agent-instantiation instead — a0p does NOT have sub_agent_spawn, a spawn executor, or InstanceMerge."
interdependent-work-graph
by The-Interdependency
Cross-repository coordination for The Interdependency. Load this when a task spans, consumes, compares, publishes to, or can change the contract between two or more repositories; when an agent is about to choose one repo as its workspace for a stack-level problem; when exact producer, evidence-source, skill, semantic, mathematical, or measurement identities must travel together; or when creating a shared stack manifest, multi-repo handoff, coordinated release, or cross-repo validation plan.
skill-build
by The-Interdependency
"Skill authoring and skill compliance workflow for The Interdependency skill-lib. Load this when creating a new SKILL.md, revising an existing skill, bringing repo skills into a shared compliance shape, designing a skill-specific test suite, deciding whether a skill is metadata-block or procedural, or asking the question set required before a skill can be accepted."
canon
by The-Interdependency
"Canonical-source and doctrine maintenance for The Interdependency skill library. Use this when deciding whether a claim, pattern, ratio, workflow, or repo-local practice should become canon; when moving source-backed behavior into a SKILL.md; when reconciling canonical skill-lib with repo-local .agents/skills/ copies; or when preserving unresolved doctrine as hmmm instead of guessing."
agent-instantiation
by The-Interdependency
Methodology for instantiating, forking, running, merging, and retiring agents in the a0 platform and its near-identical mirror a0ucns. Load this when adding or changing a sub-agent spawn path, a PCNA instance fork/merge, an agent definition or naming scheme, spawn caps or approval gating, an agent run/log table, a heartbeat-driven agent task, or a checkpoint of agent state. Use it before writing any code that creates, addresses, schedules, or tears down an agent or sub-agent, so the new code follows the platform's existing lifecycle, fork/merge, identity, and gating contracts rather than inventing a parallel one. NOTE: a0-betatest (a0p) has diverged to a different per-user CRUD + native-ZFAE instancing model — this skill's spawn/fork/merge sequence does NOT apply there; see "a0-betatest divergence".
doc-build
by The-Interdependency
Self-declaring documentation coverage built on msdmd. Each module declares the public, developer, operator, or agent-facing documentation it owns in a # === DOCS === block; a runner verifies linked docs and anchors exist, reports stale or missing documentation, and surfaces visible coverage gaps. Load this when adding or auditing module documentation, when tying code surfaces to docs, or when wiring documentation coverage checks into CI.
action-calibration
by The-Interdependency
Action sizing and escalation doctrine. Load this when choosing between the smallest decisive experiment and a maximal coherent program; when asked for the highest-leverage action, minimal versus maximal action, what to do next under time, attention, money, compute, or coordination constraints; when deciding whether to run a bounded falsifier before a full build; or when a task risks scope sprawl. Do not load for a trivial fixed-scope task, immediate emergency containment, or ordinary prioritization that has no evidence or escalation decision.
a0p-instancing
by The-Interdependency
Methodology for instancing agents in a0-betatest (the a0p research instrument), whose model diverges from canonical a0. Load this when adding or changing an AgentInstance / CharacterSheet CRUD path, a per-instance native ZFAE weight bank or its training/distillation loop, a ZFAE inference mode, a sentinel evaluation or pending-override gate, a per-agent safetensors checkpoint, or volatile sub-context memory — anywhere under a0-betatest backend/. Use it before writing code that creates, addresses, trains, runs, governs, or persists an a0p agent, so the code follows a0p's per-user CRUD + native-ZFAE + sentinel model instead of a0's spawn/fork/merge model. For canonical a0 and its mirror a0ucns, use agent-instantiation instead — a0p does NOT have sub_agent_spawn, a spawn executor, or InstanceMerge.
ratios
by The-Interdependency
"Self-declaring module composition ratios on msdmd — a single comment line on a file's first and last line (never a fenced block). The canonical seal is The-Interdependency/a0's compact positional N:M C:D I:O annotation (code:comment · consumed:declared · fan-in:fan-out), computed by a0's scripts/annotate.py; the named loc_comments=… imports_exports=… calls_definitions=… line is a portable, per-file adaptation for standalone libraries, verified by the stdlib ratios_check.py (drift/misplacement failures, visible gaps). JSON/Markdown are out of scope. Load this when recording a module's composition ratios, when authoring or extending the ratio registry, or when wiring ratio verification into CI."
doc-build
by The-Interdependency
"Self-declaring documentation coverage built on msdmd. Each module declares the public, developer, operator, or agent-facing documentation it owns in a # === DOCS === block; a runner verifies linked docs and anchors exist, reports stale or missing documentation, and surfaces visible coverage gaps. Load this when adding or auditing module documentation, when tying code surfaces to docs, or when wiring documentation coverage checks into CI."
owner-build
by The-Interdependency
Self-declaring module stewardship built on msdmd. Each module declares who owns, reviews, and escalates changes in a # === OWNERS === block; a runner reports unowned modules, unresolved hmmm owners, and missing review coverage for sensitive modules. Load this when assigning module ownership, routing reviews, auditing unowned code, or wiring stewardship coverage into CI.
msdmd
by The-Interdependency
"Module Self-Declared Metadata in Markdown — the foundational convention where each module declares its own structured metadata in a fenced comment block. Other skills in this lib (doc-build, cap-build, deps-build, owner-build, test-build, meta-module-build, risk-boundary-build, ratios, etc.) are thin applications on top of this convention. Load this when authoring a new metadata-driven skill, when extending the block schema, or when building a parser/executor for a new application."
plain-lens
by The-Interdependency
Building a plain-language, multi-lens companion view of dense canonical text — an easier on-ramp that does not replace or talk down to the source. Load this when you are asked to make an informationally dense document (canon, spec, articles, legal/normative text) easier to approach for newcomers; when building an "explain it through the lens of X" selector (domain, audience, or role); when designing progressive-disclosure or layered ELI-not-stupid reading UX; when a dynamic, data-driven site must keep its existing static page as a graceful fallback; or when you need an EDCM-style two-speaker tension reading between a body text and its footnotes/caveats. Use this when the risk is either drowning readers in density or insulting them with oversimplification.