Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/penwyp/claudepreference/browser-flow-fallbacksnpx skills add penwyp/ClaudePreference --skill browser-flow-fallbacksgit clone --depth 1 https://github.com/penwyp/ClaudePreferenceWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00050 | $0.00845 |
| Opus 5 | $0.00025 | $0.00423 |
| Sonnet 5 | $0.00010 | $0.00169 |
| Haiku 4.5 | $0.00005 | $0.00085 |
Grade A, and why
browser-flow-fallbacks scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Browser Flow Fallbacks
Use this skill to debug browser flows that intermittently stop progressing even though the surrounding state machine already mostly works.
Workflow
Phase 1: Locate the failing state branch
- Start from the latest logs, reported state, and current DOM.
- Find the branch that detected the state, the selector that matched, and the action that should have fired.
- Separate the failure type before editing: state misdetection, action failure, or transition failure after an apparently successful action.
Phase 2: Treat DOM as ground truth
- Prefer current semantic attributes over historical assumptions:
name,value,type,aria-*,data-*,form,readonly,disabled, visible text, and location path. - Distinguish similar controls such as forgot-password links, edit-email links, hidden template nodes, and generic submit buttons.
- Narrow broad selectors with required attributes or visible text needles instead of widening them further.
- Use selector constants for important controls. Keep selector changes close to the state branch that uses them.
- Bias toward visible, enabled, semantically correct elements rather than "anything clickable."
Phase 3: Add fallbacks beside the primary path
- Leave the main action as the most direct native interaction that should work in the common case.
- Add fallback in the same state branch, triggered only after a repeated unchanged snapshot.
- Prefer
form.requestSubmit(button)when the backend depends on the submitter button'sname/value. - Prefer DOM click fallback for non-submit controls, restricted to visible and enabled elements.
- For controlled inputs, verify the value after typing; if it did not stick, fallback to a native setter plus
inputandchangeevents. - Keep submit fallbacks separate from generic click fallbacks.
Phase 4: Prevent hot loops
- Track per-snapshot stall counts and fallback attempt counts separately from the primary action gate.
- Retry fallbacks on spaced intervals instead of every poll tick.
- Log stall count, fallback attempts, and next retry threshold.
- Do not exit early just because a fallback failed or the page stayed unchanged, unless the flow reached a terminal condition.
- Let the outer lifecycle timeout remain the final safety net.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 76 lines · 50 tokens per session scan A 8689ffa89310
browser-flow-fallbacks is a skill published in the GitHub repository penwyp/ClaudePreference (137 stars, last pushed 3mo ago), licensed MIT. It adds 50 tokens to every session and 845 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…
agent-host-chat-contributions
Build and review cross-cutting agent-host chat behavior through lifecycle contributions. Use when adding turn lifecycle side effects, prompt or context injection, restored-history transformation, protocol-action observation, or when reviewing changes that add code to AgentSideEffects or AgentService.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.