gpt-web-fix-flow

GPT Web Fix Flow

Overview

Use this skill for a bounded project loop: create a safe context zip, send it to GPT Web for a fix/spec/investigation, let Oracle collect the returned zip from the GPT Web response, then automatically apply that zip into the live repo when Oracle materializes a valid local or cloud-readable artifact. After the returned zip has been fully applied, validated, and no longer needed, delete both the applied returned zip artifact and the generated context zip that was sent to GPT Web, so stale fix/context packages do not accumulate. If the returned zip cannot be downloaded, transferred, found, validated, or safely applied, stop and report the failing step, raw output/session path when available, and the next exact recovery input needed.

Follow the current repo's local instructions first. Read AGENTS.md when present. If the repo uses durable notes such as my_build/INDEX.md, read only the task-routed files and the user-provided handoff/zip files. Do not assume project-specific paths, runtimes, protocols, or validation commands unless the active project documents them.

Before an outbound GPT Web request, resolve the Oracle runtime case from an explicit user case, oracle_runtime.local.json, or inferred local runner fallback, then read only the matching case in references/oracle_runtime_cases.md. oracle_runtime.local.json lives in this skill directory, at the same level as SKILL.md; check exactly <skillDir>/oracle_runtime.local.json before any fallback or broad filesystem search. Do not rely on find depth limits to discover it. The runtime case controls shell syntax, paths, and browser transport only; it must not change the project package -> dry-run -> GPT Web -> stop-for-zip flow.

Use the bundled context packagers in scripts/package-gpt-web-context.ps1 and scripts/package-gpt-web-context.sh unless the active repo has a stricter documented packager. These scripts require explicit folders/files and accept either project-relative or absolute paths; do not package a hardcoded source set. Reusable package roots live in oracle_runtime.local.json field active_path, with per-root options in extra.

Strict Trigger Contract

• When the user explicitly names this skill, references its path, or says "use/follow this skill", using this flow is mandatory, not advisory.
• When this skill is called, immediately run the outbound GPT Web path: perform only the minimum checks needed to make safe attachments, package context, dry-run Oracle, send GPT Web, wait for the returned zip, then automatically apply it if Oracle materializes a valid local/cloud-readable artifact. Do not ask which mode to use unless the request is impossible to package safely.
• For a bug/feature/investigation request with this skill named, run the full outbound loop: package context, dry-run Oracle, send GPT Web, download/materialize the returned zip, apply it, then validate. Do not choose a local-only investigation path.
• Keep orchestrator investigation minimal before GPT Web: read the skill, repo instructions, task-routed durable notes, user artifacts, and only the path/output checks needed to package and send the request. Do not scan source/data to solve the problem yourself unless applying a returned zip or validating a concrete fix.
• Do not require the phrases local apply asset or bước 3 before applying a GPT Web returned artifact. Automatic application is allowed only when the artifact is the returned zip from the current outbound run, or when the user explicitly identifies a provided local/cloud-readable path as a GPT Web returned fix artifact. Ordinary repo files named handoff.md, context zips, or durable-note markdown files are attachments/context only and must not be applied merely because they exist.
• If the user provides a local artifact path without identifying it as a GPT Web returned fix artifact, treat it as an attachment/context candidate for GPT Web after basic existence, size, and filename checks.
• If packaging, Oracle/GPT Web, returned-zip download/transfer, archive validation, or application fails, report the failing step, raw output path if available, and the next exact command/path needed. Do not silently fall back to broad local analysis.
• Do not ask which Oracle runtime case to use when it can be resolved from the current user request or oracle_runtime.local.json. Ask only when no configured case exists and the runner OS cannot be inferred safely.

Mode Selection

• Default outbound GPT Web loop: use whenever this skill is called and the user did not provide an already-returned GPT Web artifact path. Perform the minimum safe attachment checks, package context, run Oracle dry-run, send GPT Web through browser mode, wait for GPT Web to create the returned zip, let Oracle automatically download/transfer that response artifact, then apply it when Oracle materializes exactly one valid local/cloud-readable zip artifact. If no valid returned zip is available, report the download/transfer/validation failure and stop with the browser tab kept open.
• Existing context zip only: treat the provided/generated zip as completed step 1, then call GPT Web with that zip and the user's screenshots/observations.
• Apply returned GPT Web artifact: use this mode when the user provides an explicit local/cloud-readable path to a downloaded or transferred GPT Web returned .zip, or explicitly identifies a non-zip handoff as the GPT Web returned fix artifact. A trigger phrase is no longer required. Ordinary repo files named handoff.md or durable-note markdown files are context attachments only and do not satisfy this mode unless the user explicitly identifies them as the returned GPT Web fix artifact.

Zip Selection

Resolve what to zip in this order:

1. explicit folders/files from the current user request;
2. any matching configured path in oracle_runtime.local.json field active_path when the user mentions that repo/path/name;
3. all entries in active_path when the user asks to use the configured package set without naming one path;
4. ask the user which folders/files to zip before calling GPT Web.

Do not guess a broad repository archive. active_path accepts both folders and files, either project-relative or absolute, for example ["src", "package.json", "/opt/one_hammer/.codex"]. Files outside RepoRoot are stored under external/... inside the zip so the archive does not contain absolute paths.

extra is an object keyed by the exact active_path value. Supported per-path fields:

• exclude: additional package-specific excludes for that selected path.
• prompt: a task/config-specific prompt addendum to append near the end of the GPT Web prompt when that selected path is packaged.

{
  "extra": {
    "/opt/one_hammer/.codex": {
      "exclude": ["/opt/one_hammer/.codex/claude-workers"]
    },
    "/opt/one_hammer/sdlc": {
      "exclude": [
        "/opt/one_hammer/sdlc/history",
        "/opt/one_hammer/sdlc/scripts",
        "*.png",
        "*.svg"
      ],
      "prompt": "Improve the maintainability and extensibility of the directly relevant code."
    }
  }
}

Pass the selected active_path entries as repeatable --path / -Path arguments and pass each selected entry's extra[<path>].exclude values as repeatable --exclude / -Exclude arguments. Excludes may be absolute paths, zip-entry-relative paths, or glob patterns such as *.png and *.svg. The bundled packagers automatically skip files and directories matched by the selected path's Git ignore rules using Git's own ignore machinery (git ls-files --exclude-standard and git check-ignore --no-index). extra.exclude is only for additional package-specific exclusions that are not already covered by .gitignore; there is no shared default exclude list.

Append each selected entry's extra[<path>].prompt as an explicit "Additional requirements" item near the end of the GPT Web prompt. Do not treat extra.prompt as a global requirement for unrelated paths.

Required Flow

1. Resolve the Oracle runtime case:

explicit user case > oracle_runtime.local.json > inferred local runner

When checking oracle_runtime.local.json, use the direct sibling path next to this skill file, e.g. <skillDir>/oracle_runtime.local.json. Do not search for it with a bounded find -maxdepth; a missed depth must not be treated as "no config exists".

Then read the matching case in references/oracle_runtime_cases.md. Do not load unrelated cases unless troubleshooting requires comparison.

2. Resolve the zip selection, then run or confirm the context packager output from the project root using the command style from the active runtime case.

Bundled Windows/PowerShell command:

$skillDir = '<path-to-gpt-web-fix-flow-skill>'
& "$skillDir\scripts\package-gpt-web-context.ps1" -RepoRoot (Get-Location).Path -Path @('src', 'package.json')

Bundled Linux command:

skill_dir="<path-to-gpt-web-fix-flow-skill>"
"$skill_dir/scripts/package-gpt-web-context.sh" --repo-root "$PWD" --path src --path package.json

3. Ask GPT Web for the fix/feature/investigation. Attach the generated context zip plus any screenshots or short observations from the user.
4. When GPT Web finishes, inspect Oracle output/session metadata for response artifacts. If Oracle downloaded/transferred exactly one valid local/cloud-readable .zip artifact from the current GPT Web response, immediately treat it as the authoritative fix artifact and continue to Apply Returned Zip without asking the user. If the returned zip was not downloaded/transferred, is missing, is invalid, or multiple ambiguous candidate zips exist, report the failure/ambiguity with the raw output/session path when available, keep the browser tab available, and stop. Do not apply from response text or a visible link alone.
5. Apply the returned artifact's inten

---

Content truncated.