opencode-skills-collection 4.1.18 → 4.1.20

package/bundled-skills/ecommerce-listing-image-set/SKILL.md

@@ -11,7 +11,7 @@ author: beatra-ai
 tags: [ecommerce, product-images, text-to-image, mcp, paid-api, beatra]
 tools: [claude, codex, cursor, gemini]
 license: "MIT-0"
-license_source: "https://github.com/beatra-ai/ecommerce-product-images-skill/blob/ef9056dcb0d886ad8eb1e3a49803c1143598506c/LICENSE"
+license_source: "https://github.com/beatra-ai/ecommerce-product-images-skill/blob/c70a939466ce192fa15eb60a46e83980def6c938/LICENSE"
 ---
 
 # Ecommerce Product Images Skill
@@ -24,21 +24,20 @@ Turn real product photos and confirmed SKU facts into a matching ecommerce image
 This catalog entry is a **reviewed pointer, not the executable package**. It
 contains no client code and performs no Beatra operation by itself. The package
 it points to bundles three standard-library Python scripts that make network
-calls, store a credential, and can replace their own files. Read
+calls and store a credential. It has no self-updater: it never downloads
+code and never changes its own files. Read
 [Install](#install-pinned-verified-approved-twice) and
 [Security & Safety Notes](#security--safety-notes) before activating it.
 
 | Pinned identity | Value |
 | --- | --- |
-| Package | `ecommerce-listing-image-set` `0.2.0` |
-| Archive | `https://cdn.beatra.ai/agent-packages/ecommerce-listing-image-set/v0.2.0/ecommerce-listing-image-set-skill-0.2.0.zip` |
-| Archive SHA-256 | `84c0c7df4c1180212b76392a120a95f1f9b5ad4b74f73748642aeab704511b6a` |
-| Source tree | [`beatra-ai/ecommerce-product-images-skill@ef9056d`](https://github.com/beatra-ai/ecommerce-product-images-skill/tree/ef9056dcb0d886ad8eb1e3a49803c1143598506c/skills/ecommerce-listing-image-set) (full SHA `ef9056dcb0d886ad8eb1e3a49803c1143598506c`) |
+| Package | `ecommerce-listing-image-set` `0.2.8` |
+| Source commit | [`beatra-ai/ecommerce-product-images-skill@c70a939`](https://github.com/beatra-ai/ecommerce-product-images-skill/tree/c70a939466ce192fa15eb60a46e83980def6c938/skills/ecommerce-listing-image-set) (full SHA `c70a939466ce192fa15eb60a46e83980def6c938`) |
+| Package tree | `5a5b569f794bb6fc9ecd4897cb2a62dbbac34e43` (Git tree ID of `skills/ecommerce-listing-image-set` at that commit) |
 | License | MIT No Attribution (MIT-0) |
 
-The archive holds regular files only (no symlinks, no executable bits, no
-binaries). Confirm that with the inspect commands below. Every file must be
-byte-identical to the source tree at the pinned commit.
+The pinned tree holds regular files only (no symlinks, no executable bits, no
+binaries). Confirm that with the inspect commands below.
 
 ## When to Use This Skill
 
@@ -48,72 +47,55 @@ byte-identical to the source tree at the pinned commit.
 
 ## Install (pinned, verified, approved twice)
 
-### Step 1: Download and verify into a review directory
+### Step 1: Fetch the pinned tree into a review directory
 
-Explain that this downloads an external package from `cdn.beatra.ai`, then ask
+Explain that this fetches an external package from `github.com`, then ask
 for approval. Only after approval:
 
 ```bash
 umask 077
 review_dir="$(mktemp -d)"
 cd "$review_dir" || exit 1
-curl -fsSLO "https://cdn.beatra.ai/agent-packages/ecommerce-listing-image-set/v0.2.0/ecommerce-listing-image-set-skill-0.2.0.zip"
-printf '%s  %s\n' \
-  '84c0c7df4c1180212b76392a120a95f1f9b5ad4b74f73748642aeab704511b6a' \
-  'ecommerce-listing-image-set-skill-0.2.0.zip' | shasum -a 256 -c -
+git clone --quiet --filter=blob:none --no-checkout https://github.com/beatra-ai/ecommerce-product-images-skill.git src
+git -C src checkout --quiet c70a939466ce192fa15eb60a46e83980def6c938 -- skills/ecommerce-listing-image-set
+test "$(git -C src rev-parse 'c70a939466ce192fa15eb60a46e83980def6c938:skills/ecommerce-listing-image-set')" = '5a5b569f794bb6fc9ecd4897cb2a62dbbac34e43' && echo TREE-OK
 ```
 
-Stop if the check does not print `OK`. The expected digest comes from this
-catalog entry, not from a file on the same CDN.
+Stop if the last command does not print `TREE-OK`. The expected commit and
+tree IDs come from this catalog entry, not from the package or its website,
+and Git addresses every fetched object by its hash.
 
 ### Step 2: Inspect before activation
 
 ```bash
-unzip -l ecommerce-listing-image-set-skill-0.2.0.zip
-unzip -q ecommerce-listing-image-set-skill-0.2.0.zip
-find ecommerce-listing-image-set -type l -print            # expect no output
-find ecommerce-listing-image-set -type f -perm -111 -print # expect no output
-grep -n '"auto_update": True' ecommerce-listing-image-set/scripts/mcp_client.py
+git -C src ls-tree -r c70a939466ce192fa15eb60a46e83980def6c938 -- skills/ecommerce-listing-image-set | awk '$1 != "100644"'  # expect no output
+grep -n -E 'maybe_auto_update|download_update|_apply_update' src/skills/ecommerce-listing-image-set/scripts/mcp_client.py  # expect no output
 ```
 
-Optionally confirm byte identity with the public source tree (a second,
-independent host):
-
-```bash
-git clone --quiet --filter=blob:none --no-checkout https://github.com/beatra-ai/ecommerce-product-images-skill.git src
-git -C src checkout --quiet ef9056dcb0d886ad8eb1e3a49803c1143598506c -- skills/ecommerce-listing-image-set
-(cd ecommerce-listing-image-set && find . -type f | LC_ALL=C sort | xargs shasum -a 256) > archive.sha
-(cd src/skills/ecommerce-listing-image-set && find . -type f | LC_ALL=C sort | xargs shasum -a 256) > tree.sha
-cmp archive.sha tree.sha && echo IDENTICAL
-```
+The first check lists any symlink, executable, or submodule entry; the second
+finds the entry points of the self-updater that earlier versions shipped.
 
-Report to the user what the review found: `SKILL.md`, `manifest.json`, the
-bundled Markdown references, and `scripts/authorize.py`,
+Report to the user what the review found: `SKILL.md`, `manifest.json`,
+`install-source.json` (the one-line marker `{"schema_version":1,"source":"github"}`),
+the bundled Markdown references, and `scripts/authorize.py`,
 `scripts/mcp_client.py`, `scripts/uninstall.py` (Python 3.10+, standard
 library only, no dependency installation, no lifecycle hooks). Summarize the
-network, credential, local-state, telemetry, and self-update behavior listed
-under [Security & Safety Notes](#security--safety-notes).
+network, credential, local-state, telemetry, and version-notice behavior
+listed under [Security & Safety Notes](#security--safety-notes).
 
-### Step 3: Copy in and disable self-update before any other command
+### Step 3: Copy in
 
 Ask for a **second, separate** approval, because this changes agent
 configuration. Then copy the reviewed tree to the host's skills directory
-(Claude Code shown; use the equivalent path for other hosts) and immediately
-turn off silent self-update for that exact path:
+(Claude Code shown; use the equivalent path for other hosts):
 
 ```bash
 dest="$HOME/.claude/skills/ecommerce-listing-image-set"
-test ! -e "$dest" || { echo "destination exists; stop and ask the user"; exit 1; }
-cp -R ecommerce-listing-image-set "$dest"
-python3 "$dest/scripts/mcp_client.py" update --auto off
+test ! -e "$dest" && test ! -L "$dest" || { echo "destination exists; stop and ask the user"; exit 1; }
+cp -R "src/skills/ecommerce-listing-image-set" "$dest"
 ```
 
-The last command must print
-`Automatic Beatra package updates are disabled.` It writes only
-`~/.beatra/updates/<id>/state.json` and makes no network request. Run it
-before `authorize.py`, `verify`, `tools`, `upload`, or `call`: in this
-pinned version self-update is **on by default**. The setting is keyed to the
-resolved install path, so repeat it after moving or re-copying the directory.
+There is no update switch to turn off in this version.
 
 ### Step 4: Authorize as its own decision
 
@@ -156,16 +138,17 @@ arguments; never submit a replacement while the task is running.
 
 ## Update
 
-This entry does not endorse the package's silent self-update. Keep
-`update --auto off` in place and do not run `update --auto on` or a bare
-`update` without explicit approval.
+This pinned version cannot update itself: it has no code that downloads or
+replaces package files. `update` only reports what the store or tool that
+installed the copy offers; for a copy installed by the steps above it finds
+no such record and says to update the way you installed it. See the version
+notice under [Security & Safety Notes](#security--safety-notes).
 
-To move to a newer version, repeat Steps 1 to 3 for that version in a new
-review directory, verify its digest against the matching tree in `beatra-ai/ecommerce-product-images-skill`
-(a version not listed in this entry has not been reviewed here), show the
-user the file-level changes against the installed copy, and replace the
-directory only after approval. `update --check` reports the available version
-from `beatra.ai` without changing files.
+To move to a newer version, repeat Steps 1 to 3 for that commit in a new
+review directory, show the user the file-level changes against the installed
+copy (for example `git -C src diff --stat c70a939 <new-commit> -- skills/ecommerce-listing-image-set`),
+and replace the directory only after approval. A version not listed in this
+entry has not been reviewed here.
 
 ## Uninstall
 
@@ -177,21 +160,25 @@ python3 "$dest/scripts/uninstall.py"
 
 Read the JSON decision. `disconnected` means this was the last Beatra skill on
 the device: the token was revoked (when `revoked` is `true`) and the files
-`credentials.json`, `installation.json`, `host.json`, `skills.json`, and
-`registrations.json` under `~/.beatra` were removed. `keep_connection` means
-another Beatra skill still uses the shared token, which stays. Then, after
-confirming the path with the user, delete `$dest`.
+`credentials.json`, `installation.json`, `host.json`, `skills.json`,
+`network.json`, `balance-holds.json`, `pending_authorization.json`, and
+`.authorize.lock` under `~/.beatra` were removed. `keep_connection` means
+another Beatra skill still uses the shared token, which stays.
+`revoke_retry` means the server refused the revocation and nothing changed;
+run it again shortly. The script never deletes the package directory: after
+confirming the path it prints with the user, delete `$dest`.
 
 `uninstall.py` does not remove `~/.beatra/updates/`. When the decision is
 `disconnected` and no other Beatra skill is installed, remove that directory
-too; otherwise leave it. A token that could not be revoked expires after 15
-days idle and can be revoked at once in the Beatra Console under Agents.
+and then the empty `~/.beatra`; otherwise leave them. A token that could not
+be revoked expires after 15 days idle and can be revoked at once in the
+Beatra Console under Agents.
 
 ## Best Practices
 
 - ✅ Keep one approval per paid call, per upload set, and per install step.
 - ✅ Report net charged credits from the terminal task, not the estimate.
-- ❌ Do not re-enable self-update or install an unreviewed version silently.
+- ❌ Do not replace the installed copy with an unreviewed version silently.
 - ❌ Do not print, paste, or move the token out of `~/.beatra/credentials.json`.
 - ❌ Do not retry a paid call with a new request ID after an uncertain response.
 
@@ -202,47 +189,79 @@ days idle and can be revoked at once in the Beatra Console under Agents.
   upstream model providers and can change; the service is provided as is.
 - Outputs are probabilistic, not guaranteed unique or non-infringing, and need
   human review before publication.
-- This catalog entry reviews only the pinned archive above. A newer version is
+- This catalog entry reviews only the pinned tree above. A newer version is
   a different review.
 
 ## Security & Safety Notes
 
 `risk: critical` is deliberate.
 
-- **Network.** Authorization uses `api.beatra.ai`; every tool call and upload
-  goes to `mcp.beatra.ai`. With self-update left on, the client also fetches
-  `https://beatra.ai/skills/ecommerce-listing-image-set/install.json` and archives from
-  `cdn.beatra.ai`.
-- **Self-update (on by default in this pinned version).** Before `verify`,
-  `tools`, `upload`, or `call`, the client checks for a newer release at most
-  once every 24 hours and, if one exists, replaces package-owned files without
-  per-update preview or approval. It pins host and path, verifies checksums
-  from Beatra's own discovery document and CDN, and rolls back on failure, but
-  those digests are not independently anchored. This entry therefore requires
-  `update --auto off` before first use, as in Step 3.
+- **Network.** Every request is HTTPS and refuses redirects. Authorization
+  uses `api.beatra.ai` and tool calls go to `mcp.beatra.ai`; an upload is a
+  `PUT` of the approved file to the HTTPS address the server returns, without
+  the bearer token. Unless a cached decision is still valid (10 minutes to 7
+  days), each run first asks `https://api.beatra.ai/skill-route`, and also
+  `https://api.beatra.cn/skill-route` when the first is slow or answers `cn`,
+  which network to use. These probes carry no credential or package identity.
+  When the answer is `cn`, authorization and tool calls go to `api.beatra.cn`
+  and `mcp.beatra.cn` with the same bearer token, and the version notice
+  reads from `www.beatra.cn`; Beatra serves these `.cn` hosts from mainland
+  China.
+  `python3 "$dest/scripts/mcp_client.py" network --use ai` pins the `.ai`
+  hosts and stops the probes; a failed version-notice read can still retry
+  once on the other network.
+- **Version notice, no self-update.** This version has no code that downloads
+  or replaces package files and writes nothing inside the install directory.
+  Before `verify`, `tools`, `upload`, or `call`, at most once every 24 hours
+  per install path, it records the check time and looks, read-only, for
+  records another installer left beside the package (ClawHub `origin.json`,
+  SkillHub or `skills` CLI lock entries, `gh skill` frontmatter). A copy
+  installed by the steps above normally has none and makes no request. When
+  one is found, it reads `https://beatra.ai/skills/ecommerce-listing-image-set/sources.json`
+  (no credential, 3-second timeout, 64 KiB cap) and, if that installer offers a
+  newer version, prints one line to stderr with the installer's own update
+  command. It never runs the command.
 - **Uploads and third parties.** Prompts and uploaded media are sent to Beatra
   and forwarded to the third-party model provider executing the task. Beatra
-  is hosted outside mainland China. See the
+  runs the service outside mainland China; on the `cn` route (see Network)
+  requests reach it through Beatra's hosts in mainland China. See the
   [privacy policy](https://beatra.ai/en/privacy).
 - **Billing.** Paid tools consume prepaid credits. Credits for tasks that fail
   for reasons attributable to Beatra or the upstream model are returned
   automatically; otherwise purchases are non-refundable, and actual usage can
   exceed the estimate and leave a negative balance. See the
   [terms](https://beatra.ai/en/terms).
-- **Credentials.** `authorize.py` runs an OAuth device flow, opens the browser,
-  and stores one bearer token in `~/.beatra/credentials.json` (directory
-  `0700`, file `0600`). The token never goes into argv, environment variables,
-  or output. It carries full Beatra scope, including `wallet:spend`, has a
-  sliding 15-day idle lifetime, and is shared by every Beatra skill on the
-  device.
+- **Credentials.** `authorize.py` runs an OAuth device flow, opens the browser
+  on the approval page, and stores one bearer token in
+  `~/.beatra/credentials.json` (directory `0700`, file `0600`). The token never
+  goes into argv, environment variables, or output. It carries full Beatra
+  scope, including `wallet:spend`, has a sliding 15-day idle lifetime, and is
+  shared by every Beatra skill on the device. While the user has not yet
+  selected Allow, the pending device code is kept in
+  `~/.beatra/pending_authorization.json` (`0600`) so a rerun finishes the same
+  approval instead of opening a new one. When `verify`, `tools`, `upload`, or
+  `call` finds no working token, the client makes one check of that saved
+  approval and stores the token if the user has already selected Allow; it
+  never starts a new authorization or opens a browser.
 - **Local state.** `~/.beatra/` also holds `installation.json` (random
   installation reference), `host.json` (agent platform and hostname),
-  `skills.json` (installed Beatra skill paths), `registrations.json`, and
-  `updates/<id>/state.json` plus update backups when updates run.
-- **Telemetry.** The device flow sends the hostname as the device name, the
-  package slug and version, and the detected agent platform (for example
-  `claude-code`, from environment variables). On first use the client makes a
-  non-billable `beatra.installations.register` call, and every tool call adds
+  `skills.json` (installed Beatra skill paths), `network.json` (route
+  decision, with a country code when the route answer includes one),
+  `balance-holds.json` (after an insufficient-credit refusal, that tool is
+  answered locally for up to 30 minutes; `call --recheck-balance` sends one
+  call), a short-lived `.authorize.lock`, and, per install path,
+  `updates/<id>/state.json` (last version check), `source.json` (install
+  source), and `registration.json` (last registration). Files are `0600`
+  except `host.json`, which follows the umask.
+- **Telemetry.** Authorization sends the hostname as the device name, the
+  package slug and version, the detected agent platform (for example
+  `claude-code`, from environment variables), and the installation reference.
+  After connecting, at most once a day unless the version, platform, route, or
+  install source changes, the client makes a non-billable
+  `beatra.installations.register` call with those package and platform
+  fields, the release channel, the network route, the install source
+  (`github` for this tree), and coarse runtime facts: OS and OS version, CPU
+  architecture, Python version, locale, and UTC offset. Every tool call adds
   `source_package_slug` and `source_platform`. There is no opt-out for these
   fields.
 - **Retention.** Account data is kept for the life of the account. Task
@@ -254,6 +273,6 @@ days idle and can be revoked at once in the Beatra Console under Agents.
 
 ## Additional Resources
 
-- [Source tree at the pinned commit](https://github.com/beatra-ai/ecommerce-product-images-skill/tree/ef9056dcb0d886ad8eb1e3a49803c1143598506c/skills/ecommerce-listing-image-set)
+- [Source tree at the pinned commit](https://github.com/beatra-ai/ecommerce-product-images-skill/tree/c70a939466ce192fa15eb60a46e83980def6c938/skills/ecommerce-listing-image-set)
 - [Product page](https://beatra.ai/skills/ecommerce-listing-image-set)
 - [Terms](https://beatra.ai/en/terms) and [privacy policy](https://beatra.ai/en/privacy)

package/bundled-skills/goal-instruction-writer/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 wusumac
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/bundled-skills/goal-instruction-writer/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: goal-instruction-writer
+description: "Preview, draft, refine, or audit durable agent Goals with acceptance evidence, drift controls, proportional verification, and bounded waiting. Use for multi-stage work, not one-shot prompts."
+category: agent-orchestration
+risk: safe
+source: "https://github.com/wu736139669/goal-instruction-writer"
+source_repo: wu736139669/goal-instruction-writer
+source_type: community
+date_added: "2026-10-18"
+author: wu736139669
+tags: [goals, planning, drift-control, verification]
+tools: [codex]
+license: "MIT"
+license_source: "https://github.com/wu736139669/goal-instruction-writer/blob/1e5d106a2092c1ab8ab4f2f5836cf85167d1b3e7/LICENSE"
+---
+
+# Goal Instruction Writer
+
+## Overview
+
+Turn a vague request into a ready-to-run Goal instruction that an agent can
+execute without guessing what success, progress, or stopping means. Preserve
+the user's intent, language, authority boundaries, and requested scope.
+This skill designs and audits the instruction contract; runtime access,
+permissions, and external approvals still come from the host agent and user.
+Describe the checks while writing a Goal; execute the underlying task only
+when the user has also requested execution.
+
+Read [references/goal-contract.md](references/goal-contract.md) when drafting
+or auditing a Goal. Read [references/examples.md](references/examples.md) only
+when a worked example would clarify the requested task. For work that spans
+multiple phases, artifacts, or more than a few iterations, also read
+[references/drift-control.md](references/drift-control.md). For preview-first
+workflows, read [references/loop-preview.md](references/loop-preview.md).
+
+## When to Use
+
+- Use when the user asks to preview, draft, refine, or audit a Goal for a multi-stage agent task.
+- Use when acceptance evidence, scope, verification cadence, drift recovery, or external waiting is ambiguous.
+- Use for instruction design; ordinary one-shot prompts do not need this skill. Use `goal-loop` when the request is primarily about operating a host's native Goal loop.
+
+## Choose the mode
+
+- **Draft:** build a Goal from a rough request.
+- **Refine:** preserve an existing Goal while closing missing objective,
+  evidence, loop, or termination fields.
+- **Audit:** identify ambiguity, unbounded repetition, unverifiable criteria,
+  and unsafe or unauthorized transitions; propose the smallest fixes.
+- **Convert:** turn a checklist, ticket, or project brief into a Goal without
+  expanding its scope.
+- **Preview:** show the concrete loop, branches, drift gates, and stop
+  conditions before writing the final Goal. Do not emit an executable Goal or
+  perform external work in this mode.
+
+If the mode is not stated, infer it from the input. Ask only questions whose
+answers would change the objective, authority, acceptance evidence, or legal
+terminal state. Otherwise state assumptions and continue.
+
+## Preview before drafting
+
+Use preview-first when the user asks to “先看循环”, “preview”, “先设计流程”,
+or similar. Also prefer it for multi-stage, costly, irreversible, or materially
+uncertain work. For a short, reversible task, a direct draft is enough.
+
+The preview is a design checkpoint, not an approval to execute:
+
+1. State the provisional outcome, baseline, and assumptions.
+2. Show the loop as concrete state transitions, including the first work unit,
+   success and failure branches, progress evidence, drift checks, phase gates,
+   and legal stop states. Distinguish iteration checks from broader phase or
+   delivery checks, including evidence reuse and bounds for expensive checks.
+3. List the decisions that could change the loop or its scope. For feedback,
+   adoption, pilot, launch, or validation work, include the evidence threshold,
+   what counts, and the feedback window.
+4. End with a clear handoff: wait for the user to confirm or revise the loop
+   before generating the final Goal.
+
+When the user confirms, carry the accepted preview into the final Goal without
+quietly changing its loop, scope, or terminal rules. If the user revises it,
+regenerate the preview or record the changed decision first. A preview response
+must not claim that the Goal is complete and must not perform external side
+effects merely because a loop was described.
+
+## Build the three-layer contract
+
+### 1. Goal: define the outcome
+
+Write one sentence with an observable end state. It should say what artifact,
+behavior, decision, or verified change will exist when the work is complete.
+Then make the contract concrete:
+
+- **Baseline:** what exists now and which revision, source, or facts are
+  authoritative.
+- **Scope:** what may change and what is frozen.
+- **Acceptance criteria:** observable checks tied to evidence, not activities
+  such as “keep working” or “try harder.”
+- **Dependencies and authority:** tools, access, owner decisions, and external
+  gates the agent may or may not cross.
+- **Deliverable:** the files, decision, report, or message that will be handed
+  back.
+
+For Goals about feedback, adoption, pilots, launches, or validation, define a
+**feedback evidence threshold** before drafting: what counts as feedback,
+whether an entry point is enough or at least `N` non-author responses are
+required, and the timebox or attempt window. Do not count author-only activity
+unless the user explicitly chooses that threshold.
+
+Prefer one load-bearing outcome per Goal. Split unrelated outcomes into
+separate Goals. Replace vague verbs such as “improve,” “handle,” or “finish”
+with a measurable result.
+
+## Prevent drift in long-running work
+
+For a long or multi-stage Goal, freeze a compact **Goal Anchor** before the
+first iteration: the one-sentence outcome, criterion IDs, frozen scope, and
+current phase. Treat it as an invariant. A new discovery may change the plan,
+but it must not silently change the outcome, acceptance criteria, or authority.
+An explicit owner decision creates a new Goal version or scope-change record.
+
+At every iteration, record three links before acting:
+
+1. **Target criterion:** which acceptance criterion this work advances.
+2. **Expected delta:** what observable evidence should change if it works.
+3. **Scope reason:** why this action is inside the frozen boundary now.
+
+After verification, classify the result as:
+
+- `ON_TARGET`: the named criterion moved or new relevant evidence supports a
+  justified next step.
+- `SIDE_QUEST`: useful but not required for this Goal; park it in a deferred
+  list instead of expanding the loop.
+- `DRIFTED`: the action changed the goal or scope without authorization, the
+  next step cannot be justified from the Anchor, or the no-progress threshold
+  is reached; stop and realign.
+
+Run a phase gate every 3–5 iterations by default, at each milestone, and before
+an irreversible or high-cost action. Re-read the Anchor, compare the current
+state with the baseline, mark criteria open or verified, review deferred side
+quests, and choose one justified next action. Never rewrite criteria to make
+completed work appear on target.
+
+### 2. Loop: define how progress is made
+
+Use a bounded iteration with a visible progress signal:
+
+1. **Inspect** the current state and the last durable cursor.
+2. **Select** the smallest next work unit, name its target criterion, expected
+   delta, and scope reason.
+3. **Act** within the allowed scope and authority.
+4. **Verify** the result against the relevant criterion using the verification
+   strategy below; capture the evidence.
+5. **Classify** the result as `ON_TARGET`, `SIDE_QUEST`, or `DRIFTED` and apply
+   the corresponding drift rule.
+6. **Record** the delta, remaining gap, decision, and next cursor before
+   another iteration.
+
+State the iteration limit that fits the task: a timebox, tool or token budget,
+maximum attempts, or a finite work-unit list. Add a no-op rule: do not repeat
+the same action without new information; after a repeated failure, change the
+hypothesis or stop with the blocker. The loop must be able to explain why the
+next iteration is different from the previous one.
+
+For external dependencies, record the unmet criterion, next check time or
+relevant notification, and deadline. Before that trigger, continue independent
+work or yield with the checkpoint preserved. Waiting and a due check that
+confirms the dependency is still pending do not count as failed actionable
+attempts toward the default two-equivalent-no-progress threshold. Actual tool
+calls and elapsed time still count against host limits. See
+[scheduled waits](references/drift-control.md#scheduled-external-waits)
+for polling, resumption, and deadline rules.
+
+#### Verification strategy
+
+Include a short verification strategy in the Goal. Preserve explicit user and
+repository acceptance requirements while controlling when checks run:
+
+- **Iteration checks:** choose the smallest checks sufficient for the affected
+  behavior. Broaden for change impact, new failures, unresolved uncertainty,
+  or a required gate.
+- **Phase and delivery checks:** once the relevant implementation is stable,
+  complete the remaining required regression, build, integration, and artifact
+  checks. A phase gate reviews current evidence; it does not automatically
+  repeat the entire validation and delivery pipeline.
+- **Evidence reuse:** tie results to the checked source or artifact, relevant
+  inputs, dependencies, and environment. Carry forward results while those
+  conditions remain valid. Documentation or receipt changes do not invalidate
+  unrelated runtime checks. Distinguish reused evidence from newly run checks.
+- **Rerun reason:** before repeating a check, name the change or new evidence
+  that invalidates its result and select the affected checks. A source or
+  artifact change invalidates dependent evidence, including consumer checks
+  when the consumed artifact changes.
+- **Cost and completion:** give expensive checks suitable command timeouts or
+  attempt bounds. A timeout leaves its criterion unverified; report the gap.
+  Finish when all criteria have valid evidence and delivery is complete;
+  further checking needs a concrete unresolved concern or invalidated result.
+
+### 3. Termination: define legal endings
+
+Make the terminal states explicit and mutually understandable:
+
+- **Complete:** every acceptance criterion is verified and the deliverable is
+  available.
+- **Blocked:** a named dependency, missing authority, or unresolved failure
+  prevents the next meaningful action; report the exact unblock needed.
+- **Paused:** the owner explicitly asks to pause; preserve the cursor and do
+  not resume without authorization.
+- **Timeboxed/Budgeted:** the limit is reached before completion; report the
+  verified progress, remaining gap, and the safest next action.
+- **Stopped:** the owner cancels the work or an action would exceed the granted
+  authority; do not silently continue.
+- **Realignment required:** a drift check fails; stop the current loop, preserve
+  the checkpoint, and resume only after the next action is re-anchored. Use
+  `GOAL REALIGNMENT REQUIRED` when a local terminal label is needed.
+
+Do not use “continue until satisfied,” “try indefinitely,” or a success claim
+based only on effort. If the task has a local convention for terminal strings,
+preserve it; otherwise give each state a short, exact label and require the
+final response to include it. A goal or acceptance criterion cannot be changed
+just because the current work became difficult or interesting.
+
+## Produce the answer
+
+Return the result in the user's language. Unless they request another format,
+use this order:
+
+1. **Design notes:** one short paragraph explaining the objective, loop, and
+   termination and drift-control choices; list assumptions or high-value open
+   questions.
+2. **Loop preview:** in Preview mode, show the state transitions, branches,
+   evidence, drift gates, terminal states, and unresolved decisions; stop there
+   and wait for confirmation.
+3. **Ready-to-paste Goal:** in Draft, Refine, or Convert mode, include the full
+   instruction in a fenced block with `Objective`, `Goal anchor`, `Baseline and
+   scope`, `Acceptance criteria`, `Feedback evidence` when applicable,
+   `Verification strategy`, `Execution loop`, `Drift control`, `Limits and no-op
+   rule`, `Termination`, and `Reporting` sections.
+4. **Audit notes:** if refining or auditing, name each remaining ambiguity and
+   the smallest change that resolves it.
+
+The ready-to-paste block must be executable as an instruction, not a discussion
+of how one might write an instruction. Keep acceptance checks and terminal
+states concrete enough that a later reviewer can decide them from evidence.
+
+## Examples
+
+```text
+Preview a Goal for a playable Godot game slice. Preserve save compatibility,
+separate focused iteration checks from the Mac and Android delivery gate,
+and define observable completion conditions. Do not execute the project.
+```
+
+```text
+Audit a Goal that waits for an external review until an agreed UTC deadline.
+Preserve a next-check trigger and budget limits, avoid premature polling,
+and keep independently actionable documentation work moving.
+```
+
+For worked contracts, read [the examples](references/examples.md). Public,
+English [workflow cases](https://github.com/wu736139669/goal-instruction-writer/blob/main/docs/cases/README.md)
+record the evidence and limits of the maintainer's use.
+
+## Limitations
+
+- This skill designs instructions; execution, permissions, persistence, and invocation come from the host and the user.
+- A saved next-check time does not create a scheduler. The host must supply the timer, event, or later authorized invocation and checkpoint access.
+- The documented waiting branch has not been validated by a live wait/resume test.
+- Drafting or previewing a Goal does not itself authorize the underlying task.
+
+## Provenance
+
+Adapted from the MIT-licensed [Goal Instruction Writer](https://github.com/wu736139669/goal-instruction-writer)
+at [commit 1e5d106](https://github.com/wu736139669/goal-instruction-writer/commit/1e5d106a2092c1ab8ab4f2f5836cf85167d1b3e7).
+The four bundled references and license retain the upstream bytes. Catalog
+metadata, explicit activation guidance, examples, and limitations adapt the
+entry to this library; the core Goal-writing contract is retained.

package/bundled-skills/goal-instruction-writer/references/contribution-walkthrough.md

@@ -0,0 +1,9 @@
+# Contribution walkthrough
+
+- Import Goal Instruction Writer from public commit `1e5d106a2092c1ab8ab4f2f5836cf85167d1b3e7` under its MIT license.
+- Preserve all four supporting references and the MIT license; add catalog frontmatter, activation boundaries, examples, limitations, and provenance.
+- Omit the optional Codex `agents/openai.yaml` interface and invocation metadata from this catalog copy to comply with the ordinary fork-intake path policy. The canonical upstream package retains that file; the instruction body and four supporting references are unchanged by this packaging adjustment.
+- Keep this contribution walkthrough under `references/`, an allowed support directory. This adaptation does not change the repository's intake rules or request a policy exception.
+- Complement `goal-loop`: this skill designs and audits the instruction contract, including preview branches, proportional verification, and scheduled-wait checkpoints. Host loop operation remains outside this package.
+- [English cases and evidence limits](https://github.com/wu736139669/goal-instruction-writer/blob/main/docs/cases/README.md).
+- Waiting/resumption remains documented intent pending a live wait/resume test. No scheduler or new execution authority is added.