メニュー
Internal support capability for routing public-web fetch requests through the strongest honest access path and classifying blocked or partial fetch responses without turning those tactics into a public workflow concept.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | web-fetch |
| description | Internal support capability for routing public-web fetch requests through the strongest honest access path and classifying blocked or partial fetch responses without turning those tactics into a public workflow concept. |
This is a support capability, not a public workflow concept.
Users should still reach this through a public skill such as gather when a
public URL needs stronger retrieval tactics than a plain direct fetch.
Use the helpers. Resolve $SKILL_DIR per ../../shared/references/bootstrap-resolution.md, then run:
python3 "$SKILL_DIR/scripts/route_public_fetch.py" --url "https://www.reddit.com/r/python/"
python3 "$SKILL_DIR/scripts/classify_fetch_response.py" --path /tmp/fetch-response.html
python3 "$SKILL_DIR/scripts/acquire_public_url.py" --url "https://example.com/article"
gh or yt-dlp; record
them in the selected route.curl_cffi, defuddle, Patchright, and agent-browser as explicit
fallback stages with trace records, not as invisible magic. Headless
fallbacks stay read-only by default: impersonate browser-like fetches, render,
extract text/HTML, and inspect network candidates for collection intent
without clicking through auth, submitting forms, or solving challenges.gather into a giant site-by-site cookbook when this support
seam can carry the fetch tactics.references/runtime-contract.mdreferences/routing-table.mdscripts/route_public_fetch.pyscripts/classify_fetch_response.pyscripts/acquire_public_url.pyUse when a maintainer needs to cut, bump, or verify a repo release surface such as plugin versions, generated install manifests, and operator update instructions.
Use when a non-trivial design decision, code change, release, rename, deletion, spec, or workflow change needs a before-the-fact critique. Probe distinct failure angles, then run a counterweight pass that separates real blockers from over-worry before the change locks in.
Use after a meaningful work unit or when the user asks for a retrospective. Reviews what happened, what created waste, which decisions mattered, which named expert lens or direct counterfactual would have changed the next move, and which workflow/capability/memory improvements should make the next session better. Auto-selects `session` or `weekly` mode from context; ambiguous cases default to `session`.
Use when the goal is to understand and improve the repo's current quality bar. Detect existing gates, run the available ones, inspect concept integrity, test confidence, and security posture, then propose concrete quality moves instead of only complaining about what is missing.
Use when filing a GitHub issue from current context or resolving GitHub issues end-to-end through the adapter-resolved backend (`gh` by default, or a host-mediated capability such as `acme github`). Issue creation reports the observed problem before suggesting solutions; issue resolution treats GitHub as the source of truth, classifies the issue, runs a causal review for bug-class issues before designing the fix, and runs a resolution critique so the same class of issue does not recur.
Use when a repo needs its initial operating surface created or normalized. Bootstrap README, AGENTS.md, CLAUDE.md symlink policy, roadmap, and operator-acceptance docs from minimal ideation for greenfield repos, or realign those same surfaces for partially-initialized repos without pretending quality review or deep product ideation already happened.