en un clic
oscortex
oscortex contient 11 skills collectées depuis DotCorr, avec une couverture métier par dépôt et des pages de détail sur le site.
Skills dans ce dépôt
Audit and clean OSCortex for redundancy, AI slop, dead pivots, and missing reusability. Trigger on: cleanup, audit, duplicate code, technical debt, refactor, bloat, pivot, remove old code, one path, code reusability, or before large features. Excludes landing/.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
Enforce A2UI protocol compliance for all OSCortex UI components. Trigger when: adding a new Osc* widget, creating a new interactive component, modifying the oscortex_ui package, or any question about A2UI support. Ensures every new component has an A2UI renderer mapping and is exported correctly.
Canonical OSCortex OS architecture — kernel vs Flutter userspace, process isolation, shell vs apps, runtime install model. Use when designing features, refactoring boot/app launch, writing docs, or any question about how OSCortex should work (not legacy hacks).
OSCortex Git branching, CI gates, PR compliance, and production release flow. Use when committing, pushing, opening PRs, merging to develop/main, releasing ISOs, setting up GitHub Actions, or any question about which branch to work on.
OSCortex hardware and driver model — display/GPU path, device classes, syscalls, multi-arch rules, CDP WASM drivers. Use when adding or changing drivers, input, audio, storage, net, compositor backends, or any question about hardware support vs CPU porting.
OSCortex kernel driver tests — unit tests in tests/kernel/, QEMU integration in tests/integration/, run via tests/run_all.sh or cargo xtask test. Use when adding or changing kernel drivers, arch shims, platform init, or docs/hardware compliance.
Design systems guidelines, layout rules, and components code-base for OSCortex landing page and interfaces, derived from lightfield.app style.
Internal smoke-test skill for validating that workspace skill discovery works. Use only when explicitly asked to test skill loading, frontmatter parsing, or agent customization plumbing.
Canonical OSCortex OS architecture — kernel vs Flutter userspace, process isolation, shell vs apps, runtime install model. Use when designing features, refactoring boot/app launch, writing docs, or any question about how OSCortex should work (not legacy hacks).
OSCortex hardware and driver model — display/GPU path, device classes, syscalls, multi-arch rules, CDP WASM drivers. Use when adding or changing drivers, input, audio, storage, net, compositor backends, or any question about hardware support vs CPU porting.