web-content-grounding

name	web-content-grounding
description	Draft skill generated by self-evolve for trajectory-backed task handling.
self_evolve	{"release_state":"verified","verified_run_id":"cli-237769318064","verified_candidate_id":"llm-mutator-487fc645f0d0","verified_at":"2026-07-21T07:14:33.812248Z"}

Web Content Grounding

Use trajectory evidence to solve the task and prefer grounded observations over prior assumptions. Persist large or unknown-size sources before inspecting them, then work from bounded structured extracts with source locations. After the first successful structured extraction, immediately persist its artifact and evidence manifest entry before collecting anything else. Stop redundant collection once the requested output and sufficient verified evidence exist, and return a bounded answer with a concise claim-to-evidence ledger. Record a failed tool path before switching once to a materially different bounded strategy.

Finalization After Successful Endpoint Interaction

Evidence Protocol and Task Completion

Distinguish transport completion from task completion at every stage. A successful handshake, HTTP status, structured envelope, metadata record, tool-execution summary, or first data-plane response is a delivery signal, not task completion. The task is complete only when the persisted payload directly and verifiably supports every claim the user requested.

Artifact-First Acquisition

Persist large or unknown-size tool output to disk before inspecting it. Never inspect output inline from a tool response without first redirecting it to an artifact. After persisting, inspect using explicit byte-bounded excerpts or selected structured fields from the artifact file. A line-count limit such as head -N is not a byte bound; use explicit byte ranges or structured-field selectors.

Non-Compacted Evidence

Every final claim must be supported by a non-compacted artifact reference. Do not rely on metadata-only or summary digests as sole evidence for a detailed claim. If raw tool evidence was suppressed or compacted, re-acquire a bounded artifact-backed excerpt that directly contains the supporting content before including the claim in the final answer.

Immediate Persistence of First Usable Response

Persist the first usable response to disk immediately upon arrival and write its evidence manifest entry before any further analysis. However, persistence alone does not complete the task. After persisting, verify claim by claim that the payload directly supports the requested output.

Claim-by-Claim Verification

Before finalizing, check each claim in the proposed answer against the persisted artifact:

1. Identify each distinct factual claim in the proposed answer.
2. For each claim, locate the specific artifact file, byte range, or structured field that directly contains supporting content.
3. If every claim has direct artifact support, finalize the answer with a claim-to-evidence ledger.
4. If any claim lacks direct support, do not include that claim unsupported, and do not invent the missing content.

Bounded Fallback

If the first persisted payload does not directly support all requested claims, make exactly one materially different bounded artifact-backed attempt. Persist a manifest entry for that attempt regardless of whether it supplies the missing content. After that single fallback:

• If the new payload supports the remaining claims, finalize with the updated ledger.
• If it does not, return an explicit insufficiency statement identifying which claims remain unsupported.

Do not issue more than one fallback attempt. Do not invent missing content. Do not encode case-specific endpoints, prompts, or identifiers.

Stop Condition

Stop collecting only when the persisted payload directly supports the requested claims or after the single fallback has been attempted. Do not continue probing, parsing, or verifying beyond that point. Return the bounded result immediately after assembling the ledger or the insufficiency statement.

Bounded Evidence Ledger

Return the final answer with a bounded evidence ledger containing:

• For each claim: the claim text, the artifact file path, the byte range or structured field reference, and a concise excerpt or field value that directly supports the claim.
• The evidence manifest entry identifiers for all persisted artifacts used.

Do not include redundant collection paths, repeated probe attempts, or metadata-only references in the ledger.

Task Semantic Completion Invariant

Transport vs Task Completion

Transport completion means a response was received and persisted. Task completion means the persisted payload directly and verifiably supports every claim the user requested. These are not equivalent. A structured envelope, HTTP 200 status, metadata record, or tool-execution summary confirms transport but does not confirm task completion. Always perform claim-by-claim verification against artifact-backed evidence before finalizing. If verification fails, use the bounded fallback described above. Never add a blanket first-response-means-complete rule. Never encode case-specific behavior, endpoints, or identifiers.