olliecrow/browser-export

Browser Export

Use this skill when the user wants a full export/download pass from an official website or account portal, especially for statements, bills, tax documents, contract notes, or similar records.

This skill is for official browser-based export workflows only. It is not for scraping public websites at scale, and it is not for unofficial APIs or low-trust third-party clients.

Multi-agent collaboration

• Default to using subagents when they are likely to improve speed, quality, confidence, or keep the main context clean.
• Use subagents to widen coverage, dig deeper on one thread, get a fresh second opinion, or keep the main thread clean while side work runs.
• Split work into clear packets with owners, inputs, acceptance checks, and a synthesis step when parallelizing.
• Keep the main agent focused on synthesis, unblockers, and the next critical-path step; let subagents handle bounded side work that can run in parallel.
• Use single-agent execution only when scope is small or coordination overhead outweighs gains.

Proactive autonomy and knowledge compounding

• Be proactive: immediately take the next highest-value in-scope action when it is clear.
• Default to autonomous execution: do not pause for confirmation between normal in-scope steps.
• Request user input only when absolutely necessary: ambiguous requirements, material risk tradeoffs, missing required data/access, or destructive/irreversible actions outside policy.
• If blocked by command/tool/env failures, attempt high-confidence fallbacks autonomously before escalating.
• When the workflow uses plan/, ensure required plan directories exist before reading/writing them (create when edits are allowed; otherwise use an in-memory fallback and call it out).
• Treat transient external failures (network/portal/session expiry/timeouts) as retryable by default: run bounded retries with backoff and capture failure evidence before concluding blocked.
• On repeated invocations for the same objective, resume from prior findings/artifacts and prioritize net-new progress over rerunning identical steps unless verification requires reruns.
• Drive work to complete outcomes with verification, not partial handoffs.
• Treat iterative execution as the default for non-trivial work; run adaptive loop passes. Example loops (adapt as needed, not rigid): portal export preflight -> map sections -> export -> verify completeness -> cleanup -> re-scan gaps; portal audit enumerate -> compare local files -> verify missing ranges -> resume export.
• Keep looping until actual completion criteria are met: no actionable in-scope items remain, verification is green, and confidence is high.
• Run organise-docs frequently during execution to capture durable decisions and learnings, not only at the end.
• Create small checkpoint commits frequently with git-commit when changes are commit-eligible, checks are green, and repo policy permits commits.
• Never squash commits; always use merge commits when integrating branches.
• Prefer simplification over added complexity: aggressively remove bloat, redundancy, and over-engineering while preserving correctness.
• When you touch code, leave the touched area in a better state than you found it: clearer, simpler, tidier, and at least as performant unless the task requires an explicit trade-off.
• Use simple, plain English in user messages, docs, notes, reports, code comments, and other explanatory writing. Avoid jargon, fancy wording, and complex phrasing. When a technical term is needed for correctness, explain it in simple words the first time. Default to short user-facing responses. Think about what the user most wants to know, and lead with that. Do not dump every detail by default. Always include important changes, blockers, verification gaps, and any important assumptions, nuances, principles, or decisions that shaped the work. Add more detail only when the user asks for it or when uncertainty or risk makes it necessary.
• Prefer the official website's direct download/export surfaces over screenshotting or copy/paste capture.
• Prefer first-party direct file downloads over rendered-print fallbacks when the portal offers both.

Long-task checkpoint cadence

• For any non-trivial task (including long efforts), run recurring checkpoint cycles instead of waiting for a single end-of-task wrap-up.
• At each meaningful milestone with commit-eligible changes, and at least once per major phase, invoke git-commit to create a small logical checkpoint commit once relevant checks are green and repo policy permits commits.
• At the same cadence, invoke organise-docs whenever durable learnings/decisions appear, and prune stale plan/ scratch artifacts.
• If either checkpoint is blocked (for example failing checks or low-confidence documentation), resolve or record the blocker immediately and retry before expanding scope.

Security and privacy posture (must follow)

• Use only the official portal or officially linked first-party document hosts unless the user explicitly approves another path.
• Keep credentials, session cookies, downloaded documents, and account identifiers local-only.
• Do not upload downloaded documents to third-party temporary hosts or external conversion tools.
• Do not paste secrets into notes, handoffs, or committed files.
• If logs or tool output echo credential-bearing URLs, redact them before storing or quoting them.
• Prefer local download directories outside the repo unless the user explicitly asks for checked-in metadata or notes.

Terminal state contract (must follow)

The skill is complete only when all of the following are true:

• Objective completion: the requested export or completeness audit is achieved, or explicitly marked blocked with concrete blocker evidence.
• Workflow completion: every required workflow step is resolved as done, blocked, or not-applicable, with brief evidence or rationale.
• Step-level terminal completion: each numbered subtask must have explicit completion evidence (artifact, command output, or written rationale) before advancing.
• Verification completion: required checks/validations for this skill are executed, or any unavailable checks are explicitly called out with impact.
• Findings completion (where applicable): report only evidence-backed findings; if no high-confidence critical findings are present, explicitly state that.
• Loop completion: no actionable in-scope next step remains under the current objective.

Stop only after this terminal contract is satisfied; otherwise continue iterating.

Terminal state examples (adapt to skill)

• done: requested documents were exported or the completeness audit was finished, with coverage verified and remaining gaps explicitly recorded.
• blocked: login, portal access, download controls, or site limits still prevent completion after bounded retries; blocker evidence and exact unblock steps are reported.
• not-applicable: optional cleanup or metadata-promotion steps are explicitly skipped with rationale.

Required companion skills

• Use [$playwright] for browser automation.
• Use [$organise-docs] when durable portal-specific learnings or export procedures should be captured.
• Use [$cleanup] if temporary manifests, duplicate downloads, or scratch notes need consolidation after the export pass.

Standard workflow

1. Preflight

• Confirm the target portal, account scope, and where downloads should land locally.
• Confirm browser automation works and the download directory is writable.
• If the user already logged in, reuse the current authenticated state when possible.

2. Build a completeness ledger

• Create a local ledger in plan/current/notes.md or plan/artifacts/ listing:
  • portal name,
  • account/sub-account sections,
  • document classes,
  • earliest date reached,
  • latest date reached,
  • total files downloaded,
  • open gaps or blocked sections.
• Update the ledger as you progress.

3. Export systematically

• Work one section at a time.
• Prefer explicit date filters, year selectors, or paginated history views over ad hoc browsing.
• After each section, verify files landed locally and match the expected file type/count.
• When the site offers both summary pages and original PDFs/CSVs, export the original files.

4. Verify completeness

• Check that the earliest available history was reached or explicitly blocked.
• Check that all relevant sub-accounts or tabs were visited.
• Compare portal-visible counts/ranges against local files when possible.
• Record any missing ranges, portal limits, or unavailable historic documents explicitly.

5. Close out

• Leave a concise handoff if the run is interrupted.
• Summarize what was downloaded, what remains, and any portal quirks discovered.
• Promote durable export procedure notes only if they are likely to recur.

Interruption handoff (required)

• Before stopping, switching sessions, or yielding after auth/session expiry, write a concise handoff in plan/handoffs/ or plan/current/notes.md.
• Include:
  • portal and account/sub-account currently in scope,
  • sections completed,
  • earliest/latest coverage reached,
  • files downloaded so far,
  • blocker or reason for pause,
  • exact next browser action.
• Do not store secrets, one-time codes, or session cookies in the handoff.

Reporting format

Keep the report short by default.

In most cases include only:

1. Outcome summary.
2. Portal and account scope covered.
3. Gaps, blockers, or portal limits.
4. Download location and next step or resume instruction when needed.

Add completeness-ledger detail, file counts, or extra evidence only when the user asks, when completeness is unclear, or when the export is blocked.

Prompt templates

• [$browser-export] export all statements and bills from <portal> using the official website only, keep downloads local-only, and verify earliest-to-latest history coverage.
• [$browser-export] process <portal> account one section at a time, keep a completeness ledger, and leave a resume handoff if login/session expiry interrupts the run.
• [$browser-export] audit whether all available files from <portal> have already been collected locally; identify exact gaps by date range and document class.