Menu
Use when working on add driver, device support; provides the FinnOS-specific adding a driver workflow and evidence gates.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when working on arm64, aarch64, AAVMF; provides the FinnOS-specific arm64 platform development workflow and evidence gates.
Use when working on toolchain, OVMF, AAVMF; provides the FinnOS-specific build environment management workflow and evidence gates.
Use when working on build script, target profile, image; provides the FinnOS-specific build orchestration workflow and evidence gates.
Use when working on CI, GitHub Actions, required check; provides the FinnOS-specific ci maintenance workflow and evidence gates.
Use when working on architecture abstraction, platform interface, parity; provides the FinnOS-specific cross-architecture design workflow and evidence gates.
Use when working on status, completion percentage, verified; provides the FinnOS-specific evidence and status reporting workflow and evidence gates.
| name | adding-driver |
| title | Adding a Driver |
| version | 1 |
| status | active |
| owners | [] |
| triggers | ["add driver","device support"] |
| prerequisites | ["driver-architecture","interrupt-exception-handling","unsafe-rust-low-level-safety","reliability-fault-injection","agent-handoff"] |
| related_docs | ["HARDWARE_SUPPORT.md","docs/development/driver-development.md",".agents/checklists/driver-change.md"] |
| category | Execution workflows |
| conditional_skills | [] |
| implementation_gates | ["Report blocked instead of bypassing discovery, isolation, IRQ, or DMA ownership."] |
| related_milestones | ["M4 Devices and Storage"] |
| last_verified | {"base_commit":"d21a477","date":"2026-07-16","worktree_dirty":true,"context":"base commit plus uncommitted audit and agent-system worktree"} |
| description | Use when working on add driver, device support; provides the FinnOS-specific adding a driver workflow and evidence gates. |
adding-driver (Execution workflows; skill maturity: planning-gated).
Implement one specified device through discovery, resources, MMIO/PIO, DMA, IRQ, timeout, recovery, tests, and support docs.
Use for requests mentioning add driver, device support, or when a dependency points to this skill. Load only after repository entry and before design or implementation.
Report blocked instead of bypassing discovery, isolation, IRQ, or DMA ownership. Do not load it only because a future FinnOS document mentions the subsystem.
driver-architectureinterrupt-exception-handlingunsafe-rust-low-level-safetyreliability-fault-injectionagent-handoffRead the full prerequisite closure in topological dependency order. If one cannot be satisfied, move the task to Blocked or Deferred; do not omit the dependency.
Conditional skills:
Implementation gates are roadmap/runtime conditions, not additional documents to load automatically:
HARDWARE_SUPPORT.mddocs/development/driver-development.md.agents/checklists/driver-change.mdRe-read implementation and tests referenced by those documents. The documents establish intent/status boundaries, not runtime proof.
No general driver can currently be added end-to-end because resource broker/userspace/IRQ/DMA prerequisites are absent.
Registry verification used base commit d21a477 plus the dirty worktree context "base commit plus uncommitted audit and agent-system worktree" on 2026-07-16. This is not an integrated-revision claim. Reverify after HEAD, active PRs, or relevant source changes.
git status, recent history, active related issue/PR, and selected roadmap item.An evidence-backed adding a driver result with scoped artifacts, tests, documentation, and handoff. Include acceptance evidence, residual limitations, and next dependency rather than only code.
./tools/finn check
Run commands from the repository root. A command listed here is a baseline/gate, not evidence that absent future functionality has a runnable target.
State shared semantics explicitly; isolate x86-64 and ARM64 mechanisms.
State guest architecture separately from host architecture and emulator model. Maintain a parity row for changed semantics and document intentional differences.
Preserve the boundary described by the current state: No general driver can currently be added end-to-end because resource broker/userspace/IRQ/DMA prerequisites are absent. Apply .agents/checklists/pre-change.md; for kernel, driver, security, architecture, or UI work also apply the matching checklist.
Make Test QEMU faults then update exact hardware claim observable with a negative case, then run the narrow and aggregate gates. Do not permanently hard-code test counts; counts belong to dated evidence reports.
Update the canonical behavior/status document, relevant architecture/reference material, test/build instructions, limitations, and this skill registry if any command, gate, or current-context statement changes.
Confirm dependency gates and public spec before relying on downstream assumptions.Use .agents/templates/handoff-template.md. Include objective, starting/final Git state, task state, skills used, files, exact commands/results, evidence classification, docs/status changes, unknowns, blockers, risks, next action, and next skills. Distinguish locally verified worktree changes from integrated behavior.
Request: "Work on add driver." Correct response: begin by confirm dependency gates and public spec, then add exact device matching, and require evidence for test qemu faults then update exact hardware claim before changing status. Incorrect response: create a plausible subsystem scaffold and mark the roadmap item complete because it compiles.
Canonical source: .agents/scripts/skill_registry.py. Increment version for material policy/workflow/gate changes, update last_verified only after reinspection, run python3 .agents/scripts/render_skills.py, review generated diffs, then run python3 .agents/scripts/validate.py --all. Follow .agents/GOVERNANCE.md; never hand-edit generated skills.