map-vs-territory

Verify discrepancies between documentation, comments, variable names, and runtime behavior.

Updated Mar 31, 2026
One-click install
npx skills add https://github.com/calvyntwh/karu-custom-skills --skill map-vs-territory
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: map-vs-territory
Source: https://github.com/calvyntwh/karu-custom-skills/tree/main/skills/map-vs-territory
Command: npx skills add https://github.com/calvyntwh/karu-custom-skills --skill map-vs-territory

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Detects and resolves mismatches between documentation, comments, variable names, and actual runtime behavior so engineers can trust observed results instead of outdated maps. This reduces debugging time, prevents integration failures, and avoids incorrect refactors driven by wrong assumptions.

Core Features & Use Cases

  • Reality-first verification: Prescribes probing strategies (logs, runtime inspection, network responses, disk state) to confirm what the system actually does.
  • Safety-aware protocol: Includes a pre-flight checklist to avoid running unsafe or irreversible commands in production contexts.
  • Self-improvement & audit logging: Provides patterns and optional correction logs to capture recurring documentation drift and guide systemic fixes.
  • Use Cases: Debugging API contract drift, validating third-party integrations, investigating legacy code where comments no longer match implementation.

Quick Start

Use the map-vs-territory skill to verify whether the API response and runtime types match the documentation and log any systemic discrepancies.

Frequently Asked Questions about map-vs-territory

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify if API documentation matches actual runtime behavior?

Runtime behavior verification uses safe probes like log inspection, network response checks, and type checks to expose discrepancies between documentation and actual system execution. It prescribes observing live system state to confirm what code actually does.

Why do my code comments and variable names not match the debugging output?

Comments and variable names diverge from debugging output due to documentation drift during legacy code evolution. Runtime inspection and log probing expose the true territory, confirming observed behavior over outdated static maps.

What is the best way to debug API contract drift during third-party integration?

Debugging API contract drift requires comparing live network responses and runtime types against external documentation. Running safe runtime probes and validating actual responses identifies where the integration map diverges from the territory.

Can I run runtime inspection probes in a production environment?

Runtime inspection probes operate safely in production by following a pre-flight checklist to avoid irreversible side effects. The protocol restricts operations to safe read-only probes, log inspection, and network response checks.

How do I log systemic documentation drift found during code review?

Log systemic documentation drift during code review using optional correction logs to capture recurring mismatches between comments and implementation. This self-improvement pattern guides systemic fixes and recommends specific documentation updates.