Development

A development guide for adding browser modules to the layered Space Agent runtime, including where code belongs and how extensions, components, and Alpine stores connect.

In plain words
What is it for?
Use it when building a browser module, deciding between first-party and custom layers, or connecting page shells, extensions, components, and Alpine state.
Why use it?
It explains the repository's layers and module structure, reducing the risk of putting code in the wrong location or bypassing the intended frontend patterns.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/binary16labs/prime-silo/development
Any agent
npx skills add binary16labs/prime-silo --skill development
Clone the repo
git clone --depth 1 https://github.com/binary16labs/prime-silo

Made for: Claude Code, Codex.

Per session 25 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 784 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 100% copy Near-identical to another mod in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00025 $0.00784
Opus 5 $0.00013 $0.00392
Sonnet 5 $0.00005 $0.00157
Haiku 4.5 $0.00003 $0.00078

Measured 2d ago against content hash 869ef286b786, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

Development scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

This is a copy

100% identical to Development — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

app/L0/_all/mod/_core/admin/ext/skills/development/SKILL.md · 75 lines

How it starts

The opening of the file, as written. The whole thing — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Use this skill when the user asks how to build a module, where code should live, how layers work, or how the extension/component/Alpine runtime composes the frontend.

Layer Model

  • L0 is firmware. Repo-owned first-party code belongs here.
  • L1 is group customware. Use it for group-level overrides and additions.
  • L2 is user customware. Use it for per-user overrides and additions.
  • First-party source for this repository should normally live under app/L0/_all/mod/_core/....
  • L1 and L2 are runtime state, not the home for durable repo-owned product code.

Module Layout

  • Browser modules are namespaced as mod/<author>/<repo>/....
  • A first-party module usually lives at app/L0/_all/mod/_core/<feature>/.
  • Keep real implementation files in the module folder.
  • Keep ext/html/ adapter files and ext/js/ hook files thin. They should usually mount a real component or provide a focused hook, not hold the whole feature.

How The Frontend Composes

  1. Page shells in server/pages/ stay thin and expose <x-extension id="..."> anchors.
  2. Matching HTML extension files live under mod/<author>/<repo>/ext/html/<anchor>/....
  3. Those extension files usually mount a real component with <x-component path="/mod/...">.
  4. <x-component> loads the component HTML, styles, scripts, and nested components.
  5. Alpine stores and small module utilities own the behavior.

Example pattern:

<x-extension id="page/admin/body/start"></x-extension>
<x-component path="/mod/_core/admin/views/shell/shell.html"></x-component>

Alpine And Store Pattern

  • Component HTML owns structure and bindings.
  • Stores created through space.fw.createStore(...) own state, async work, persistence, and API calls.
  • Small utility modules own parsing and rendering helpers.
  • Do not move large feature logic into long inline x-data blocks.

JS Extension Hooks

  • Use space.extend(import.meta, async function name(...) { ... }) for behavioral extension seams.
  • /start hook files run before the wrapped function.
  • /end hook files run after the wrapped function.
  • JS hook files live under mod/<author>/<repo>/ext/js/<extension-point>/....
  • Use HTML anchors for structural seams and space.extend(...) for behavioral seams.

Read the full file on GitHub · 75 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 75 lines · 25 tokens per session scan A 869ef286b786

Subscribe to this mod's changes

Development is a skill published in the GitHub repository binary16labs/prime-silo (5 stars, last pushed 9d ago), licensed MIT. It adds 25 tokens to every session and 784 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to Development, differing in 0 lines, and is treated as a copy.

Related

Other skills, from other repositories

dingtalk_channel_connect

Use a headed browser to automatically complete DingTalk channel integration for QwenPaw. Applicable when the user mentions DingTalk, developer console, Client ID, Client Secret, bot, Stream mode, binding or configuring a channel. Supports pausing when a login page is detected and resuming after the user logs in.

agentscope-ai/QwenPaw · 69 tokens

browser_cdp

Use this skill when the user explicitly wants to connect to a running Chrome browser, scan local CDP ports, specify a cdpport, or share a single browser across multiple agents/tools. By default browser opens no debugging port; pass an explicit cdpport only when the user wants another local tool to attach.

agentscope-ai/QwenPaw · 70 tokens

browser_cdp

当用户明确希望连接到已运行的 Chrome 浏览器、扫描本地 CDP 端口、显式指定 cdpport,或让多个 agent / 工具共享同一个浏览器时,使用本 skill。browser 默认不开放调试端口;仅当用户明确希望其他本地工具附加时才显式传入 cdpport。.

agentscope-ai/QwenPaw · 85 tokens

browser_visible

当用户需要控制 browser 的浏览器启动方式时,使用本 skill。browser 默认由 Playwright 直接管理、不开放调试端口(需让其他本地工具附加时显式传 cdpport);headed 控制是否显示窗口,privatemode 保留用于兼容、不再改变默认行为,browserargs 传入额外的 Chromium 启动参数,executablepath 指定自定义浏览器可执行文件路径。.

agentscope-ai/QwenPaw · 108 tokens

browser_visible

Use this skill when the user needs to control the browser launch mode for browser. By default browser is managed by Playwright and opens no debugging port (pass an explicit cdpport to let another local tool attach); headed controls whether the window is visible, and privatemode is kept for backward compatibility and…

agentscope-ai/QwenPaw · 75 tokens

browser

Drive a live browser with async Python against QwenPaw's builtin Browser SDK. The full reference is below; re-load this browser skill after context compaction.

agentscope-ai/QwenPaw · 35 tokens