New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Start Board Implementation

by gweslab in gweslab/cerf

Start the bring-up of a new board or ROM in CERF. An agent skill from gweslab/cerf.

MITAuto-check passed

Install Start Board Implementation

skills CLI
$ npx skills add gweslab/cerf --skill start-board-implementation -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install gweslab/cerf start-board-implementation --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/gweslab/cerf.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/start-board-implementation .claude/skills/start-board-implementation && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
start-board-implementation
GitHub stars
104
Token cost
~3.2k tokens
SKILL.md length
1,594 words
Files
1
Skills in repo
10
Repo updated
First seen
Licence
MIT

At a glance

Start the bring-up of a new board or ROM in CERF. An agent skill from gweslab/cerf.

  • Works in 5 steps: Board name given → ls bundled/devices/… → Path inside bundled/devices/ → stat it,… → Path outside bundled/devices/ → ask… → …
  • SKILL.md covers Phase 0 - Welcome, Phase A - Gates, Phase B - Establish the facts… and Phase C - Readiness table…, plus 2 more sections
  • Calls python

What it does

Start Board Implementation is an agent skill from gweslab/cerf. Start the bring-up of a new board or ROM in CERF.

Its SKILL.md is about 3.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: Universal Windows CE Emulator - CE Runtime Foundation. The licence is MIT.

Example prompts

  • “/start-board-implementation”

Requirements

  • Python 3

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Board name given → ls bundled/devices/ and **match by FAMILY, not exact
  2. Path inside bundled/devices/ → stat it, use it.
  3. Path outside bundled/devices/ → ask whether to copy it into
  4. One candidate → record its ROM path, continue.
  5. Several candidates for the same board (NORMAL - a board commonly ships

What it can do on your machine

Read from SKILL.md and the folder at commit 6b8df83. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • python

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Start Board Implementation loads about 3.2k tokens when it runs. Until then it costs about 19 tokens; SKILL.md has 1,594 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~19
When it runs · the whole SKILL.md, loaded when a task matches
~3.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from gweslab/cerf at commit 6b8df83, republished under its MIT licence (© gweslab). 1,594 words, ~3,169 tokens.

Download SKILL.mdSave it as .claude/skills/start-board-implementation/SKILL.md (or your agent's skills folder).
name
start-board-implementation
description
Start the bring-up of a new board or ROM in CERF.

Start Board Implementation - new-board bring-up

Obey CLAUDE.md and every agent_docs/ page; this ritual never overrides them.

Governing principle: the ROM is the only trusted starting point, and YOU establish every fact yourself. A stated SoC/board is a hint, not a fact - confirm board, SoC, CPU, and CERF's existing support from the ROM bytes + the internet before writing a line. A bring-up that starts on an unverified assumption wastes dozens of sessions.

Phase 0 - Welcome

Open with a brief, warm welcome + thank-you BEFORE Gate A1:

🎉 Welcome - and thank you for contributing a new board to CERF! I'll start from your ROM, confirm the board/SoC facts myself, and lay out what the bring-up will take before we commit to it.

A line or two, then straight into the gates. The welcome never delays a gate.

Phase A - Gates

Gate A1 - Acquire the ROM (fail only if nothing resolves)

The user does not have to type a path - naming the board ("implement simpad sl4") is enough. All regular dev ROMs live under bundled/devices/, so that listing is your index.

  1. Board name given → ls bundled/devices/ and match by FAMILY, not exact string (do NOT depend on cerf.json - optional, usually absent for a user's own ROM). Tolerate variant/generation/letter/separator differences: "simpad cl4", "simpad sl4", "SIMpad SL4" all resolve to the simpad_sl4_* bundles. You are identifying the board, not string-equality testing a folder.
  2. Path inside bundled/devices/ → stat it, use it.
  3. Path outside bundled/devices/ → ask whether to copy it into bundled/devices/ first (where every dev ROM lives); proceed once placed, or if the user says to run it in place.
  4. One candidate → record its ROM path, continue.
  5. Several candidates for the same board (NORMAL - a board commonly ships multiple ROM generations) → SUCCESS, not a problem. Same board id; name the generations, take the newest (or ask one short "which generation?"), continue.

HARD RULE - candidates found ≠ "absent". If ls surfaced any plausible bundle for the named family, you have RESOLVED - you may NEVER report "no ROM / not found" while holding a list of matching bundles. A variant/letter token mismatch against bundles that are clearly the same family is a RESOLVE, never a fail. Never assert presence/absence from memory; ls in THIS run and read it like a human picking the obvious match.

Only if ls produced ZERO plausible candidates - STOP and FAIL:

❌ I couldn't find any ROM for "<what the user said>" under bundled/devices/. Point me at the ROM path directly, then re-run /start-board-implementation.

Gate A2 - IDA MCP connectivity (warn + ask if absent)

Reverse engineering confirms every fact below and drives the whole loop.

  • The presence check IS the "list instances" call. ToolSearch query ida, find the instance-list tool, load its schema, CALL it. Whether the tool is available to call is the entire test - callable = IDA MCP running; no such tool = not running.

  • Call succeeds → ✅ running. 0 open instances is NORMAL - IDA is usually closed and ROMs unextracted at the start; the call succeeding is the proof, not the count. You bring IDA up yourself when a step needs it (Phase B / B1).

  • No list-instances tool to call at all → not running. Do not fail - warn and ask:

    ⚠️ No IDA MCP detected. Without reverse engineering I'm badly limited - bring-up is decompile-driven (cracking the kernel OEMAddressTable for page tables, decoding which driver touches each register), and going blind tends to dead-end and burn far more sessions. The MCP server lives in this repo: tools/ida_server.py (load inside IDA) + tools/claude_ida.py (the MCP client); tools/open_ida.py --wait <pe> opens a module. Install those and reconnect for a real shot.

    Continue anyway without RE? [yes|no]

    No → stop. Yes → continue, marking the RE-dependent table rows ⚠️.

Phase B - Establish the facts (you, from the ROM + the internet)

Minimum traversal to fill the table. You are IDENTIFYING, not implementing. Each fact gets a source.

  • B0 - Which acceptance pipeline? Before extraction, settle what the file IS (agent_docs/rom_acceptance.md): flat XIP, a recognised container (B000FF / NOSAJ / ARNOLD), or a whole-storage dump the guest's own boot path reads. Check the leading magic, the presence of ECEC markers (a CE2-era image legitimately has none → ResolveRomhdrStructural), and whether the image is a raw bus capture needing normalization (aliasing, wrap, pad). This decides whether B1's extractor can even run.
  • B1 - Extract & inventory the modules. The ROM is usually NOT extracted yet - you do it: tools/extract_bundles.py produces per-module PEs under references/extracted-roms/<device>/<rom>/fs/Windows/. Open a module with python tools/open_ida.py --wait <pe> (--wait blocks until it's usable; background it if you have parallel research). Note kernel/coredll/gwes/filesys/ device/driver module names - driver names are SoC tells (e.g. *_mx31.dll → i.MX31).
  • B2 - Confirm the declared board is the right one. The declared board_id selects the BoardContext (agent_docs/rules.md § "Per-device facts come from the ROM"); confirm that declaration names the silicon actually in the ROM before writing a BoardContext asserting it. meta.soc_family and the user's word are hints, never facts. Evidence, in order of weight: the B1 driver/module names (an OEM BSP names its drivers after its own silicon); the register bases the OAL actually addresses; then the OEM's model string if one appears in the blob. A byte match is evidence only once you have shown the bytes are the string and not arbitrary data.
  • B3 - Board already in CERF? Read the devices table in bundled/db.json; list cerf/boards/ + bundled/devices/. Match the B2 identity → fully present / different-ROM-revision / absent.
  • B4 - SoC / CPU family. From the identity + driver/OEM names, determine the SoC, its CPU architecture (CpuArch::Arm / CpuArch::Mips - which JIT engine the board runs), and the specific core with its ISA level (ARM720T, ARM920T, SA-11xx, ARM1136, Cortex-A8; R3000A/R3900/R4100/R5000-class MIPS, …). Confirm via the internet (datasheet / Linux arch/arm/mach-* or arch/mips/, QEMU, device specs) - not the user's word.
  • B5 - SoC implemented in CERF? Reusable SoC? Read the socs table in bundled/db.json; list cerf/socs/ + cerf/cpu/. Is this SoC present? Is the core's strategy set under cerf/cpu/<core>/ - ArmProcessorConfig/CoprocEmitter on ARM, MipsProcessorConfig/MipsCp0Emitter on MIPS? If absent, is there a close relative sharing silicon/core? Reuse is the difference between a short and a long bring-up - name it.
Show full SKILL.md (606 more words)Show less

Phase C - Readiness table (FIXED structure - identical for everyone)

Emit exactly this. Same columns/rows/order every run. Finding = the fact + its source; Status = one emoji (✅ present/reusable/good · ⚠️ caution/new work/unconfirmed · ❌ missing/blocker).

## /start-board-implementation - bring-up readiness

| # | Check                          | Finding                                   | Status |
|---|--------------------------------|-------------------------------------------|--------|
| 1 | ROM acquired                   | <bundle / path>                           | ✅/❌  |
| 2 | IDA MCP connectivity           | <running, N instances | not running>      | ✅/⚠️  |
| 3 | Board identity                 | <declared board.id> confirmed by <tells>  | ✅/⚠️  |
| 4 | Board already in CERF          | <db.json row exists | absent>             | ✅/❌  |
| 5 | SoC / CPU family               | <SoC>, <core>, <CpuArch + isa level>      | ✅/⚠️  |
| 6 | SoC implemented in CERF        | <cerf/socs/<x> present | absent>           | ✅/❌  |
| 7 | Reusable / similar SoC or core | <what reuses what | none - from scratch>  | ✅/⚠️  |

Under the table, the session estimate from rows 6-7:

  • SoC supported + peripherals reusable → ~5-40 sessions (board complexity still swings this widely).
  • New CPU/SoC from scratch → ~40-100+ sessions, impossible to bound up front.

Then ask on its own line:

Start the bring-up? [yes|no]

STOP and wait. Do not begin work, do not create any document, until yes.

Phase D - On yes: seed tracking, teach the workflow, start

D1 - /tracking create (the yes authorizes this one write)

Invoke the tracking skill's CREATE for a new board bring-up doc. It's an umbrella / progress tracker (many independent peripheral workstreams), so keep it a coarse index. Seed it with:

  • TASK & WHY - bring up board <X>; why it matters; empty FORBIDDEN CONCLUSIONS / BANNED APPROACHES.
  • A standing VERIFY GATE line (survives compaction): "Every finished implementation chunk - a peripheral, an ArmProcessorConfig/CoprocEmitter, the PageTableBuilder, the BoardContext, the LCD/INTC/timer/ DMA/touch models - is run through /verify BEFORE the next chunk, verdict recorded in that session's /tracking update (CODE STATE, verbatim with file:line). Never skip the gate on JIT/MMU/CPU changes."
  • A PROCEDURE line pointing at the durable method: "Follow the bring-up loop and ground rules in .claude/skills/start-board-implementation/SKILL.md § The bring-up loop." (Plus the committed reference set: CLAUDE.md, agent_docs/rules.md, agent_docs/debugging.md, agent_docs/code_style.md.)
  • Session 0 - paste the Phase C readiness table verbatim (identity + source, SoC/CPU, what CERF has, reuse plan, estimate). The durable baseline a compacted agent resumes from. Real work starts at Session 1.

The yes authorizes this single create only - not standing authorization; every later write needs its own /tracking update from the user.

D2 - Teach the cross-session workflow (say this to the user)

For a productive multi-session bring-up:

  • End of each session: /tracking update (you invoke it).
  • Then /compact.
  • Then /tracking restore next session to reload the world.

One protecting rule: never run /tracking because I asked you to. If I propose updating the tracking doc, that's a bailout - only YOU decide when a session ends. I never raise the tracking document myself.

D3 - Run the bring-up loop (the procedure below)

Pick the entry point from the table, then run § The bring-up loop:

  • New SoC/core (rows 6-7 ❌) → start at the CPU/JIT strategy set for the board's CpuArch: author ArmProcessorConfig + CoprocEmitter, or MipsProcessorConfig + MipsCp0Emitter, from the CPU architecture reference manual + the core TRM (downloaded to references/<soc>/ first), then the PageTableBuilder / memory map, then the peripheral loop.
  • SoC supported (rows 6-7 ✅) → start at the board's bundled/db.json row and its <board_id>_id.h (see agent_docs/database.md), then the BoardContext concrete returning that id, and set board.id + rom.primary in the bundle's cerf.json + the PageTableBuilder (crack the kernel's OEMAddressTable in IDA), then the peripheral loop.

The bring-up loop (the engine)

The kernel boots, hits an unimplemented register/MMIO address, and HaltUnsupportedAccess fatals with the PA + guest PC. One blocker per cycle, each step obeying the rules in CLAUDE.md / agent_docs/ (don't restate them - follow them):

  1. Build (CLAUDE.md § Build) - confirm it actually succeeded.
  2. Run with a SHORT GNU timeout and a per-task --log-file (agent_docs/debugging.md § Timeout). Never background cerf; never read stdout.
  3. Read the FIRST FATAL|unsupported|unmapped|rejected|Halt line - that PA + guest PC is the blocker.
  4. Decode the PA → peripheral block from the datasheet memory map.
  5. Research it the nuclear-bisection way (agent_docs/debugging.md): find the register in the SoC manual, decompile the guest PC that touched it for the exact semantics, write the citation excerpt under references/<soc>/.
  6. Implement the blocker fully - no fake-success stub; the mandatory-real peripherals are never stubbed (agent_docs/rules.md § Board Implementation).
  7. /verify, fix any CRITICAL PROBLEM FOUND;
  8. Repeat until GUI, then interaction - the user-observable bring-up target.

© gweslab, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/start-board-implementation of gweslab/cerf.

Open the folder on GitHubat commit 6b8df83

Compare with similar skills

Start Board Implementation next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Start Board Implementation compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Start Board Implementation this skillgweslab/cerf104—~3.2kAutomated safety check: PassMIT
Boardalirezarezvani/claude-skills28k—~610Automated safety check: PassMIT
Paperclip Boardpaperclipai/paperclip99k—~5.3kAutomated safety check: PassMIT
Board Governancesickn33/agentic-awesome-skills47k1 repos~4.1kAutomated safety check: PassMIT
Announcement Boardsickn33/agentic-awesome-skills47k1 repos~3.4kAutomated safety check: PassMIT
Pre Boardingsickn33/agentic-awesome-skills47k1 repos~3.5kAutomated safety check: PassMIT

Similar skills

  • Board

    alirezarezvani/claude-skills

    Read, write, and browse the AgentHub message board for agent coordination.

    28k GitHub stars~610 tokensUpdated 1 mo ago
    Agent WorkflowsAuto-check passed

  • Paperclip Board

    paperclipai/paperclip

    Manage a Paperclip company as a board member via chat. An agent skill from paperclipai/paperclip.

    99k GitHub stars~5.3k tokensUpdated today
    Auto-check passed

  • Board Governance

    sickn33/agentic-awesome-skills

    Board and governance register: meeting date, agenda, decision, resolution number, vote result, action owner and due date.

    47k GitHub starsUsed in 1 repo~4.1k tokens
    Auto-check passed

  • Announcement Board

    sickn33/agentic-awesome-skills

    Announcement board: author, category, department, priority, audience, publish and expiry dates, status and acknowledgements, as CSV, SQL, JSON Schema or Notion on request.

    47k GitHub starsUsed in 1 repo~3.4k tokens
    Documents & OfficeAuto-check passed

  • Pre Boarding

    sickn33/agentic-awesome-skills

    Pre-boarding checklist: task, employee and department, owner, category, joining and due dates, documents received, laptop, email and account-record readiness, status.

    47k GitHub starsUsed in 1 repo~3.5k tokens
    Auto-check passed

  • Agent Project Board Sync

    ruvnet/ruflo

    Agent skill for project-board-sync - invoke with $agent-project-board-sync

    74k GitHub starsUsed in 2 repos~2.9k tokens
    Auto-check passed

More from gweslab/cerf

All 10 skills in this repo

  • Cerf

    gweslab/cerf

    List the project skills and offer the environment doctor. An agent skill from gweslab/cerf.

    104 GitHub stars~1.2k tokensUpdated today
    Auto-check passed

  • Changelog Append

    gweslab/cerf

    Add a changelog entry for a change that was just made (only user triggered, no agent self-invocation).

    104 GitHub stars~864 tokensUpdated today
    Auto-check passed

  • Commit

    gweslab/cerf

    Create a git commit with a short message that describes the diff.

    104 GitHub stars~1.2k tokensUpdated today
    Auto-check passed

  • Tracking

    gweslab/cerf

    Manage the cross-session tracking document with restore, create, update, or compact (only user triggered, no agent self-invocation).

    104 GitHub stars~22k tokensUpdated today
    Auto-check passed

  • Verify

    gweslab/cerf

    Spawn a hostile reviewer that checks a claim or a diff against the project rules.

    104 GitHub stars~5.4k tokensUpdated today
    Auto-check passed

  • Verify Options

    gweslab/cerf

    Audit a list of options for bailouts and rule violations before the user picks one.

    104 GitHub stars~11k tokensUpdated today
    Auto-check passed

Questions about Start Board Implementation

What does Start Board Implementation do?

Start the bring-up of a new board or ROM in CERF. An agent skill from gweslab/cerf. Start Board Implementation is an agent skill from gweslab/cerf. Start the bring-up of a new board or ROM in CERF.

How do I install Start Board Implementation in Claude Code?

Run `npx skills add gweslab/cerf --skill start-board-implementation -a claude-code`. Or copy the skill folder (.claude/skills/start-board-implementation in gweslab/cerf) into .claude/skills/start-board-implementation in your project. Claude Code loads it when a task matches its description.

How do I install Start Board Implementation in Codex?

Run `npx skills add gweslab/cerf --skill start-board-implementation -a codex`. Or copy the skill folder (.claude/skills/start-board-implementation in gweslab/cerf) into .agents/skills/start-board-implementation in your project. Codex loads it when a task matches its description.

Can I use Start Board Implementation in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add gweslab/cerf --skill start-board-implementation -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/start-board-implementation, .gemini/skills/start-board-implementation, .github/skills/start-board-implementation and .opencode/skills/start-board-implementation in your project.

What does Start Board Implementation need to run?

Going by SKILL.md and its folder, Start Board Implementation needs the command-line tools its instructions call (python). Our summary lists: Python 3.

Does Start Board Implementation access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Start Board Implementation safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Start Board Implementation use?

Start Board Implementation is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Start Board Implementation use?

About 3.2k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Start Board Implementation?

Skills that share tags, products or a category with Start Board Implementation: Board (alirezarezvani/claude-skills, 28k stars), Paperclip Board (paperclipai/paperclip, 99k stars), Board Governance (sickn33/agentic-awesome-skills, 47k stars) and Announcement Board (sickn33/agentic-awesome-skills, 47k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Start Board Implementation?

gweslab (a GitHub organization) maintains it in gweslab/cerf, which has 104 GitHub stars. The repository holds 10 skills in this directory. The repository was last updated on October 7, 2026.

Source: gweslab/cerf on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.