gpt-webui-skillsCAUTION

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

idea / brain dump
↓
INTENT MODE, only when needed
↓
PLAN MODE, for project-level decisions
↓
concrete non-trivial code change
↓
OPENSPEC WORKFLOW
Explore → Propose → Apply → Verify/quality gates → Archive
↓
done

Projects without a native OpenSpec workflow may use SPEC MODE → DEV MODE.
LOCAL HANDOFF remains available when execution must continue elsewhere.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: dev-mode
description: Autonomous ChatGPT WebUI development that implements an agreed specification, verifies the result, resumes safely across per-turn tool limits, and hands unfinished local work to a coding agent without losing context.
---

# Dev Mode

Implement the agreed specification and prove the result.

## OpenSpec projects

For a non-trivial code change in a project that already uses OpenSpec, load `openspec-workflow` before implementation.

Identify the exact existing OpenSpec change and implement through the project's native Apply semantics. If no suitable change exists, do not improvise one from chat memory and start coding anyway. Route through OpenSpec Explore or Propose first.

Dev Mode owns execution; OpenSpec owns the current change contract.

Dev Mode is execution-oriented. Do not reopen settled product decisions merely because another implementation route is possible.


## Start from durable truth

Before changing code:

1. identify the target repository and current branch/PR state;
2. load the canonical specification or OpenSpec change;
3. inspect the relevant current code;
4. determine the highest-value unfinished implementation task;
5. understand the acceptance evidence required for that task.

Do not reconstruct intent from vague chat memory when the repository or spec contains the answer.

## Execute the specification

Work through the specification in coherent implementation slices.

For each slice:

- inspect before editing;
- make the smallest coherent change that advances the spec;
- preserve existing project conventions unless the spec intentionally changes them;
- update or add tests where the behavior warrants them;
- run or inspect the strongest verification available;
- keep the repository in a recoverable state.

Prefer completed vertical behavior over piles of disconnected scaffolding.

Do not create scripts to fix scripts to fix scripts when a direct change is available. Repository archaeology is not a product feature.

## Respect the decision boundary

Use this rule:

```text
repo fact → inspect it
implementation detail inside the spec → decide and execute
spec inconsistency in OpenSpec project → update/reconcile the OpenSpec change
standalone spec inconsistency → reconcile in Spec Mode
material product/scope decision above one change → return to Plan Mode
```

Do not silently change user-visible behavior, scope, non-goals, or acceptance criteria to make implementation easier.

A purely technical adjustment that preserves the agreed behavior may proceed when it is clearly within the specification's intent.

## Git and external-action safety

Treat the user's request as the boundary of authorization.

Do not expand the task into unrelated repository changes.

Never force-push, delete important branches, merge a pull request, publish a release, change production infrastructure, or perform another high-impact irreversible action unless the user explicitly requested that action.

When repository-specific contribution rules exist, follow them.

## Verification

Do not equate "code was written" with "done."

Use the strongest evidence available, such as:

- tests;
- type checking;
- linting;
- build output;
- CI status;
- focused runtime checks;
- diff inspection;
- acceptance scenarios from the spec.

When a verification path is unavailable, state exactly what remains unverified instead of manufacturing confidence.

Before completion, compare the implemented result against the specification's acceptance criteria.

## Review the integrated result

After implementation, inspect the whole changed surface for:

- incomplete wiring;
- duplicated or dead paths;
- regressions introduced by parallel edits;
- stale temporary files or debug code;
- mismatches between implementation and specification;
- tests that pass without exercising the intended behavior.

Fix issues that are inside the authorized scope.

## Durable progress

Dev Mode may span many ChatGPT WebUI turns.

Keep progress recoverable in the repository or another existing durable project source of truth.

A checkpoint should preserve:

- repository;
- branch/PR/change identifier;
- specification being implemented;
- completed tasks;
- unfinished tasks;
- files or areas currently being changed;
- verification already run and its result;
- blockers;
- exact next operation.

Do not rely on hidden chat context as the only record of substantial unfinished work.

## Local Handoff phase

Use this final optional phase when:

- the user explicitly asks to continue with Codex, Claude Code, or another local agent;
- the next work requires local filesystem, terminal, runtime, emulator, hardware, credentials, or tooling unavailable to WebUI;
- WebUI has completed the useful remote portion and the remaining work is better performed locally.

A handoff is a continuation, not a new planning session.

Before handing off, synchronize against the latest available repository state and canonical spec so the packet does not describe stale work.

Produce a self-contained **Local Agent Handoff** containing:

1. **Objective** — what the local agent is continuing.
2. **Repository state** — repo, branch, relevant PR/commit, and working-state assumptions.
3. **Canonical specification** — exact OpenSpec change/spec or other source-of-truth location.
4. **Settled decisions** — only decisions the local agent must preserve.
5. **Completed work** — what WebUI already finished.
6. **Current frontier** — exact unfinished implementation work.
7. **Relevant files** — where the local agent should look first.
8. **Verification** — tests/build/CI already run and their results.
9. **Blockers/constraints** — environment or implementation constraints still active.
10. **Next action** — the first concrete local operation.
11. **Definition of done** — evidence required before the local agent may claim completion.

End the packet with this instruction:

```text
Continue from this state. Do not restart discovery, re-plan settled produc

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (4)

- **Security/privacy:** never upload sensitive private artifacts, screenshots, references or benchmark details to public repositories or third-party tools without authorization. Use synthetic public e

return hashlib.sha1(b"blob " + str(len(data)).encode() + b"\x00" + data).hexdigest()

- **Security/privacy:** never upload sensitive private artifacts, screenshots, references or benchmark details to public repositories or third-party tools without authorization. Use synthetic public e

Use offline Node builtins and optional free locally installed renderer. Capability probe first; do not claim inaccessible tests passed. Do not access credentials or paid APIs. The `gauntlet-loop` skil

Gates applied: no_behavioural_pass.