/**
 * Skill-body ↔ tool-contract consistency check (Proposal 009, Tier 1).
 *
 * A skill's `body` (prose injected into the system prompt) can quietly contradict
 * the tools it actually unlocks, and the model then **refuses a tool that is right
 * there** — or is told about one it can't call. The library already knows each
 * skill's real tool set (`inject.tools`), so it can flag the mismatch at authoring
 * time instead of at run time.
 *
 * Tier 1 is DETERMINISTIC (no LLM): pure string + schema checks. The semantic
 * contradictions it can't see — e.g. "the body calls an OPTIONAL arg required" —
 * are Tier 2 (LLM-advisory, opt-in). Both checks here are WARNINGS, never errors:
 * a body naming a foreign tool is often an intentional `read_skill` handoff hint.
 */
import type { Injection } from './types.js';
import type { GraphProblem } from './skillGraphCheckup.js';
/** The tool names a skill unlocks (`inject.tools[].schema.name`). */
export declare function skillToolNames(skill: Injection): readonly string[];
/**
 * Check ONE skill's body against its tool contract. Pure + side-effect-free.
 *
 * @param skill           the skill to check
 * @param knownToolNames  every tool name reachable in the wider graph/agent (lets
 *                        the check tell a cross-skill HANDOFF from a typo). Omit to
 *                        check a skill in isolation (only its own tools are "known").
 */
export declare function checkSkillContract(skill: Injection, knownToolNames?: ReadonlySet<string>): GraphProblem[];
/** Run the contract check across many skills with a shared known-tool set. Pure. */
export declare function checkSkillContracts(skills: readonly Injection[]): GraphProblem[];
//# sourceMappingURL=skillContract.d.ts.map