How do I install the Neru Add Platform Feature skill?

Run npx skillmds@latest add y3owk1n/neru-add-platform-feature in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Neru Add Platform Feature safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Neru Add Platform Feature?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Neru Add Platform Feature free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Neru Add Platform Feature?

y3owk1n (@y3owk1n) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Neru Add Platform Feature by y3owk1n

Name: Neru Add Platform Feature
Author: y3owk1n

Neru Add Platform Feature

Implement or stub Neru functionality for a specific OS/backend: port contract, build-tagged file slots, factory wiring, CodeNotSupported stubs, capability matrix, contract tests, and the docs ownership table. Use for any change under internal/adapter/platform or any *_darwin/_linux/_windows file. Not for pure-Go domain logic.

y3owk1n Updated Sep 17, 2026

File contents

Platform work in Neru

Platform code carries Neru's strictest guardrails, and this is where agents most often guess. A change that lands cleanly sits in an existing file slot, crosses the boundary through a port, returns CodeNotSupported wherever it is unimplemented, and reports itself honestly in the capability matrix.

Before writing code

Read internal/adapter/platform/AGENTS.md — the single home for the rules this skill obeys: the One Rule, file slots, the factory and Linux's runtime compositor axis, loud stubs, capability honesty, coordinates, generated Wayland bindings. Add the darwin/ or linux/ guide for the native boundary you touch.
Read internal/adapter/platform/profile.go. It is the source of truth for each subsystem's backend family, primary-modifier expectations, and whether a backend needs CGO. CGO is a per-backend decision, not a per-OS one.
Read the port you're implementing in internal/ports/. If the capability doesn't have a port yet, define the interface there first and add a mock in internal/ports/mocks.

Tests

Unit tests with port mocks stay platform-neutral.
Real-OS behavior goes in *_integration_<os>_test.go tagged //go:build integration && <os>.
Contract tests pin CodeNotSupported per subsystem, not per stub. Update the subsystem's existing one if it has one, and write a new one when a caller could read the stub's nil as success, so a later "implementation" that silently no-ops fails a test. internal/adapter/platform/AGENTS.md names the ones that exist.

Docs (same change, not a follow-up)

docs/CROSS_PLATFORM.md has the ownership table ("Documentation Checklist") — each fact has exactly one home. Capability status goes in docs/CROSS_PLATFORM.md, never in docs/ARCHITECTURE.md (shape, not status). Linux setup specifics go in docs/LINUX_SETUP.md / docs/LINUX_DESKTOPS.md.

Verify

just lint                      # depguard enforces the One Rule
go test ./internal/architecture/
just test-foundation

Cross-compile the platforms you touched (just build-linux, just build-windows) even when you can't run them — build tags hide breakage from a darwin-only just build. Then the standard pre-commit gate, and ask a maintainer to run integration tests on the target OS if you can't.

---name: neru-add-platform-featuredescription: Implement or stub Neru functionality for a specific OS/backend: port contract, build-tagged file slots, factory wiring, CodeNotSupported stubs, capability matrix, contract tests, and the docs ownership table. Use for any change under internal/adapter/platform or any *_darwin/_linux/_windows file. Not for pure-Go domain logic.---# Platform work in NeruPlatform code carries Neru's strictest guardrails, and this is where agentsmost often guess. A change that lands cleanly sits in an existing file slot,crosses the boundary through a port, returns `CodeNotSupported` wherever it isunimplemented, and reports itself honestly in the capability matrix.## Before writing code1. Read `internal/adapter/platform/AGENTS.md` — the single home for the rules this skill obeys: the One Rule, file slots, the factory and Linux's runtime compositor axis, loud stubs, capability honesty, coordinates, generated Wayland bindings. Add the `darwin/` or `linux/` guide for the native boundary you touch.2. Read `internal/adapter/platform/profile.go`. It is the source of truth for each subsystem's backend family, primary-modifier expectations, and whether a backend needs CGO. CGO is a **per-backend** decision, not a per-OS one.3. Read the port you're implementing in `internal/ports/`. If the capability doesn't have a port yet, define the interface there first and add a mock in `internal/ports/mocks`.## Tests- Unit tests with port mocks stay platform-neutral.- Real-OS behavior goes in `*_integration_<os>_test.go` tagged `//go:build integration && <os>`.- Contract tests pin `CodeNotSupported` per subsystem, not per stub. Update the subsystem's existing one if it has one, and write a new one when a caller could read the stub's `nil` as success, so a later "implementation" that silently no-ops fails a test. `internal/adapter/platform/AGENTS.md` names the ones that exist.## Docs (same change, not a follow-up)`docs/CROSS_PLATFORM.md` has the ownership table ("Documentation Checklist") —each fact has exactly one home. Capability status goes in`docs/CROSS_PLATFORM.md`, never in `docs/ARCHITECTURE.md` (shape, not status).Linux setup specifics go in `docs/LINUX_SETUP.md` / `docs/LINUX_DESKTOPS.md`.## Verify```bashjust lint # depguard enforces the One Rulego test ./internal/architecture/just test-foundation```Cross-compile the platforms you touched (`just build-linux`,`just build-windows`) even when you can't run them — build tags hide breakagefrom a darwin-only `just build`. Then the standard pre-commit gate, and ask amaintainer to run integration tests on the target OS if you can't.

Frequently asked questions