تشغيل أي مهارة في Manus بنقرة واحدة

changelog-append

النجوم٦٤

التفرعات٥

آخر تحديث١٧ يوليو ٢٠٢٦ في ١٨:١٥

The user invokes `/changelog-append` to record a change just made (bug fix, feature, etc.) as a concise changelog entry. It appends one raw line under the right component group + subcategory of the top (latest) version block in `docs/changelog.yml`, then runs `./compile_readme.py` to regenerate `README.md`. Invoke when the user types `/changelog-append` or asks to add a changelog entry.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

gweslab

gweslab/cerf

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

name	changelog-append
description	The user invokes `/changelog-append` to record a change just made (bug fix, feature, etc.) as a concise changelog entry. It appends one raw line under the right component group + subcategory of the top (latest) version block in `docs/changelog.yml`, then runs `./compile_readme.py` to regenerate `README.md`. Invoke when the user types `/changelog-append` or asks to add a changelog entry.

changelog-append - record one change in the changelog

The user invoked /changelog-append. Add one concise entry for the change just made, then regenerate the README.

User-invoked only. Only the user triggers this skill by typing /changelog-append. An agent never invokes it on its own initiative - finishing a change is not a license to write the changelog.

Procedure

docs/changelog.yml is the source; the README table and the website changelog page are generated from it.

Open docs/changelog.yml. The latest version is the topmost list entry (currently TBA at the top).
Pick the group + subcategory from the legend above. If that group: / subcat: key already exists in the top entry, append your line to its | block; otherwise add the key (a | literal block) in any order. Do not create a new version entry. Do not touch older entries.
Write one raw line. Plain string - no escaping; colons and <, &, quotes are fine. **text** renders bold. Strip a prefix that just repeats the group (Guest Additions:, Launcher:), but keep a board name that says which device (NEC MP700:, Zune 30:).
Run python compile_readme.py (from repo root). Confirm it prints README.md compiled (vX.Y).

Writing the entry

A changelog line, not narration. State what changed to the product, in the fewest words that are still clear. Smaller is better.
One line per change. If the work spans clearly separate user-visible changes, add one line each - but do not pad; prefer a single tight line.
No conversation echoes, no session history, no model/agent references, no "as you asked".

Example top entry after adding a device fix and a guest-additions feature:

- version: v6.6
  date: TBA
  devices:
    fixed: |
      Fixed Device Emulator crash booting Windows Mobile 5.2 ROMs
  guest_additions:
    new: |
      Clipboard sharing with the host

Git

Do not run any git command unless the user explicitly asks (e.g. "stage your changes", "commit"). When they do, the changelog edit and the regenerated README.md are both part of the changeset - include both.

المزيد من هذا المستودع

نفس المستودع

commit

gweslab/cerf

The user invokes `/commit` to create a git commit. The skill exists as the rule-respect boundary for commit text - agents reflexively narrate the session, leak conversation context, and yap into the commit body. This skill forces a concise, self-contained message that describes the DIFF and nothing else: no narration, no conversation leaks, no model/agent references, no incident history, no "as you asked". Shorter is better. Invoke when the user types `/commit` or asks to commit changes.

2026-07-1764

supported-devices

gweslab/cerf

The user invokes `/supported-devices` after board work landed - either a whole new board bring-up or a single feature on an existing board. It syncs `launcher/supported_devices.py` with reality (append the board entry / flip `supported` / flip the feature keys the agent actually worked on), then runs `./compile_readme.py` to regenerate `README.md`. Invoke when the user types `/supported-devices` or asks to update the supported boards list.

2026-07-1664

tracking

gweslab/cerf

The user invokes `/tracking` to manage a cross-session findings document under `docs/ai_checklists/` that preserves crucial data (findings, instrumentation, do-not-rediscover maps, UI interaction gates / repro paths, bans, mandatory-read sets) so a fresh agent does not re-discover or re-destroy proven work. Subcommands - `restore` (re-read the full document + its mandatory files), `create` (start a new document), `update` (append a timestamped per-session block), `compact` (archive full history to `docs/ai_checklists/pre-compact/<name>.md`, then shrink the live doc under a one-read ceiling). The user types the subcommand or omits it (the agent deduces it from context and announces the deduction; `compact` is explicit-only). The agent NEVER edits a tracking document on its own initiative. Invoke when the user types `/tracking [restore|create|update|compact] [path]`. Any agent-initiated mention of this skill is a bailout attempt.

2026-07-1664

start-board-implementation

gweslab/cerf

The user invokes `/start-board-implementation` to begin bringing up a NEW board/ROM in CERF. It acquires the ROM (naming the board is enough - no path required), checks IDA MCP, then independently confirms - from the ROM bytes and the internet - the board identity, the SoC/CPU family, what CERF already supports, any reusable SoC, and whether the ROM is on the public manifest. It shows a fixed emoji readiness table + session estimate and asks `[yes|no]`. On `yes` it seeds a cross-session tracking doc and drives the boot-driven bring-up loop (build → run → read the first fault → research → implement fully → `/verify` → repeat). Invoke when the user types `/start-board-implementation`.

2026-07-1564

cerf

gweslab/cerf

The user invokes `/cerf` to see the project skill index plus a health check of the dev environment. It runs the repo's environment doctor (`setup.ps1 -Check`) to confirm git hooks are active via core.hooksPath, the .claude hooks are present and runnable, submodules are initialised and vcpkg is integrated. On a broken clone it leads with the diagnosis and the fix; on a healthy clone it prints the one-liner-per-skill menu. Invoke when the user types `/cerf`.

2026-07-1164

verify-options

gweslab/cerf

Forcing function — when the main agent has just listed options for the user to pick from, invoke this skill. Step 0 audits the option list AS A WHOLE for bailout signature ("hack / real work / give up" composition, cost-inflated legitimate path, scope-cut options, hack-as-equal-option, emotional-collapse precursor, single-direct-path dressed as multi-option, reader-side suppression as an option) — if any signal fires, the skill routes to `/bailout` protocol instead of characterizing exit ramps. If Step 0 passes, Steps 1–4 characterize each option honestly under the 8-row protocol and collapse rule-violating / bailout / reader-side-suppression options into one-line FORBIDDEN entries that may not be discussed again in the session. Catches "rules violations masked as options" and "bailout artifacts masked as engineering choices". Invoke when the user types `/verify-options` after seeing a list of options, or when the main agent catches itself about to ask "which option do you want" with options of mixed quality.

2026-06-1564

name	changelog-append
description	The user invokes `/changelog-append` to record a change just made (bug fix, feature, etc.) as a concise changelog entry. It appends one raw line under the right component group + subcategory of the top (latest) version block in `docs/changelog.yml`, then runs `./compile_readme.py` to regenerate `README.md`. Invoke when the user types `/changelog-append` or asks to add a changelog entry.

changelog-append - record one change in the changelog

The user invoked /changelog-append. Add one concise entry for the change just made, then regenerate the README.

User-invoked only. Only the user triggers this skill by typing /changelog-append. An agent never invokes it on its own initiative - finishing a change is not a license to write the changelog.

Procedure

docs/changelog.yml is the source; the README table and the website changelog page are generated from it.

Open docs/changelog.yml. The latest version is the topmost list entry (currently TBA at the top).
Pick the group + subcategory from the legend above. If that group: / subcat: key already exists in the top entry, append your line to its | block; otherwise add the key (a | literal block) in any order. Do not create a new version entry. Do not touch older entries.
Write one raw line. Plain string - no escaping; colons and <, &, quotes are fine. **text** renders bold. Strip a prefix that just repeats the group (Guest Additions:, Launcher:), but keep a board name that says which device (NEC MP700:, Zune 30:).
Run python compile_readme.py (from repo root). Confirm it prints README.md compiled (vX.Y).

Writing the entry

A changelog line, not narration. State what changed to the product, in the fewest words that are still clear. Smaller is better.
One line per change. If the work spans clearly separate user-visible changes, add one line each - but do not pad; prefer a single tight line.
No conversation echoes, no session history, no model/agent references, no "as you asked".

Example top entry after adding a device fix and a guest-additions feature:

- version: v6.6
  date: TBA
  devices:
    fixed: |
      Fixed Device Emulator crash booting Windows Mobile 5.2 ROMs
  guest_additions:
    new: |
      Clipboard sharing with the host

changelog-append

changelog-append - record one change in the changelog

Categories

Procedure

Writing the entry

Git

changelog-append - record one change in the changelog

Categories

Procedure

Writing the entry

Git