/runtime-observation

name: runtime-observation
description: Cross-cutting skill for runtime observation methodology. Five-phase observation discipline, container interaction patterns, observation record format, claim extraction, environment variation. Loaded by the analyzer agent for runtime observation roles.

Runtime Observation Methodology

Runtime observation produces ground truth. When you execute a command and record the output, that observation is an empirical fact -- not an interpretation, not an inference, not a guess. This skill defines how every runtime observation agent operates.

The Principle

**Run it. Record it. Cite it.**

You never guess what a target does. You run it and document what happens. Every observation is a witnessed fact: this input produced this output in this environment at this time.

When Runtime Observation Applies

Runtime observation applies to any target that can be executed inside a container:

| Target Type | Observation Method | Primary Agent | |-------------|-------------------|---------------| | CLI tools | Execute commands, capture stdout/stderr/exit codes | `cli-explorer` | | Web applications | HTTP requests, browser automation, form interaction | `web-ui-explorer` | | APIs and services | HTTP/gRPC/WebSocket requests, response analysis | `behavior-observer` | | Libraries and SDKs | Probe scripts that import and exercise the library | `behavior-observer` | | GUI applications | Browser automation for web-based GUIs | `web-ui-explorer` |

Targets that cannot be executed (static documentation, binary files without a runtime) are handled by other intelligence sources. Runtime observation is additive -- it enhances and corroborates intelligence from all other modes.

Source Origin

All runtime observation output is **RAW**. Running the target and recording its behavior produces artifacts that require sanitization before reaching the implementer. Even though the observations describe external behavior (not implementation internals), recording the target's responses creates a derivation chain.

Targets that cannot be executed in a sandbox (or where executing them has side effects the user declines to accept) should skip this mode.

• Output location: `workspace/raw/runtime/`
• Never write runtime observations to `workspace/output/` or `workspace/public/`.
• The origin label does not reduce the value of the observations. It is a provenance marker that controls downstream processing.

Container Requirement

All runtime observation happens inside containers. No exceptions. The target is never executed on the host machine. This is a hard safety requirement. The container is already running before any runtime observation agent begins work -- the orchestrator sets it up per the container-execution skill.

Agents MUST NOT attempt to build, start, stop, or remove containers. They interact with an already-running container.

Five-Phase Observation Methodology

Every runtime observation agent follows these five phases in order. You are not required to complete every phase for every target -- proceed as far as the target type and available time allow. But you MUST follow the phase order.

digraph observation_phases {
    rankdir=TB;

    "Start runtime observation" [shape=doublecircle];
    "Phase 1: Explore target surface area" [shape=box];
    "Phase 2: Test nominal paths with valid inputs" [shape=box];
    "Phase 3: Probe boundaries and limits" [shape=box];
    "Phase 4: Trigger error conditions" [shape=box];
    "Phase 5: Explore state transitions" [shape=box];
    "Convert observations to behavioral claims" [shape=box];
    "Observation complete" [shape=doublecircle];

    "Start runtime observation" -> "Phase 1: Explore target surface area";
    "Phase 1: Explore target surface area" -> "Phase 2: Test nominal paths with valid inputs";
    "Phase 2: Test nominal paths with valid inputs" -> "Phase 3: Probe boundaries and limits";
    "Phase 3: Probe boundaries and limits" -> "Phase 4: Trigger error conditions";
    "Phase 4: Trigger error conditions" -> "Phase 5: Explore state transitions";
    "Phase 5: Explore state transitions" -> "Convert observations to behavioral claims";
    "Convert observations to behavioral claims" -> "Observation complete";
}

Phase 1: Exploration

**Goal:** Discover what the target can do.

**Activities:**

• Run help commands (`--help`, `-h`, `help`, `man target`)
• Read menus, navigation bars, landing pages
• List available API endpoints (OpenAPI, GraphQL introspection, sitemap)
• Discover configuration options (environment variables, config files, CLI flags)
• Identify authentication requirements (does the target prompt for credentials?)
• Check version information (`--version`, `-V`, `/api/version`)

**Output:** A map of the target's surface area. What commands exist. What endpoints respond. What configuration is available. This is the foundation for all subsequent phases.

**Provenance:** Exploration observations are `confidence=confirmed` (the target responded with this output). Inferences about what a discovered feature does are `confidence=inferred` until tested.

Phase 2: Nominal Path Testing

**Goal:** Exercise the target's happy paths -- standard workflows with valid inputs that produce expected outputs.

**Activities:**

• Execute each command with the simplest valid arguments
• Submit forms with valid data
• Make API requests with well-formed payloads
• Follow the "getting started" workflow end-to-end
• Perform CRUD operations where applicable (create, read, update, delete)
• Test each output format option (JSON, text, CSV, etc.)

**Recording discipline:** For each nominal test, record:

• The exact input (command, request, form data)
• The exact output (stdout, response body, UI state)
• The exit code or HTTP status
• Any side effects (files created, state changed)

**Provenance:** Nominal path observations are `confidence=confirmed`. Each recorded input/output pair is a reproducible fact.

Ph