berylorg
@berylorg
Public Skills
subagent-orchestration
by berylorg
Coordinate root-only, one-level subagents when they reduce total team effort or provide required independence; route model and reasoning deliberately while retaining authority, review, and safety gates.
engineering-rigor
by berylorg
"Define and apply proportionate defensive-programming, verification, failure-handling, and adversarial-review requirements through mandatory # Engineering Rigor sections in authoritative feature, system, and workspace-project design.md files. Use when creating or revising design authority, selecting rigor profiles or modifiers, deciding whether robustness work or review findings are required, deriving implementation acceptance criteria, or calibrating review depth to trust, exposure, operating envelope, blast radius, and consequence."
implementation-planning
by berylorg
"Maintain root doc/plan.md implementation plans. Use before implementation work, including single-package work, to verify architecture readiness before creating or updating the authoritative plan; enforce # Scope and # Phase N status structure; keep one acceptance boundary per phase; pause and replan on material scope growth; maintain a compact sliding execution window; derive phase work, edge cases, verification, and proportionate completion review from applicable design authority and its effective engineering-rigor contract; record blockers; and respect other active planning authorities."
architectural-rework
by berylorg
Manage clean architectural replacement work with concise rework trackers and without incremental migratory compatibility. Use when a project, feature, system, or subproject is under rework, old docs or source must be archived and removed from live authority, target design must remain in authoritative docs, the durable plan must consume bounded tracker slices, completed tracker work must be compacted, a completed rework must be sealed, or Codex must avoid migration adapters while replacing architecture.
project-doc-authority
by berylorg
Maintain project documentation authority. Use when deciding or reconciling where feature, system, package or subproject, additional project-declared, root or parent, plan, rework, research, failure, dependency, API, module, process, or engineering-rigor rules belong; preserving required Goals/Decisions/Engineering Rigor structure; resolving contradictions; or identifying what controls implementation.
system-design-docs
by berylorg
Create and maintain authoritative system-level design docs under doc/systems/<system>/design.md. Use when internal architecture or engineering rigor spans multiple features or packages but is not itself a user-visible feature contract or a single package boundary, such as execution pipelines, storage/projection systems, backend/provider integration, event ingestion, consistency models, caching, identity, provenance, or cross-package state ownership.
rag-rat-project-docs
by berylorg
Use optional rag-rat semantic retrieval for project Markdown, especially AIPM-prescribed design, plan, rework, GUI, memory, failure, world, and package documents. Use when this skill is installed and work may discover, read, create, edit, move, or delete those documents; set up the pinned Node-free MCP integration when needed, search semantically before broad manual navigation, and block on a fully current index after AI-authored Markdown changes.
workspace-package-policy
by berylorg
Apply generic multi-package workspace rules. Use when working in repositories with workspace projects, subprojects, aggregating directories, modules, manifests, package-level design docs and engineering-rigor declarations, filesystem policies, .gitignore boundaries, ENV.md environment facts, or large source files that may need splitting.
feature-design-docs
by berylorg
Create and maintain authoritative feature-level design docs for user-visible product behavior at doc/features/<feature>/design.md. Use when defining product workflows, UI behavior, visible states, disabled/error states, acceptance rules, feature engineering rigor, feature-owned user interactions, supplemental feature docs, or mockups; use system-design-docs instead for internal cross-package architecture.
gui
by berylorg
Unified GUI documentation and implementation contracts, terminology, integration slots, feature GUI mounts, reusable widget specs, and built-in widget references. Use when naming, designing, implementing, reviewing, or documenting GUI windows, slots, feature GUI composition, widget specs, project-local widgets under doc/gui/widgets, external GUI spec registries, built-in controls, UI roles, widget CSS notation, or reusable GUI contracts.
multi-agent-vcs
by berylorg
Safely use Git when multiple agents concurrently edit disjoint paths in one working tree. Use whenever agents share a Git checkout.
rust-first-automation
by berylorg
Choose and implement Rust instead of shell for complex Beryl automation. Use when planning, creating, replacing, extending, or reviewing benchmark and evidence harnesses, build or release tooling, migrations, code generators, data transforms, process orchestration, resumable workflows, or scripts in Beryl and its owned dependency forks that involve structured state, schemas, hashing, atomic publication, replay, concurrency, multiple child processes, long runtimes, or multi-stage error handling. Also use when an existing PowerShell, Bash, or Nushell script is growing beyond a simple one-shot command or thin launcher.
exploration-memory
by berylorg
Preserve reusable notes from expensive third-party investigations under doc/memory. Use when academic or topic research, standards review, official documentation lookup, public repository inspection, package registry investigation, build-system-resolved dependency research, source-code exploration, benchmarks, algorithms, UX evidence, legal or regulatory references, or other external sources inform design, planning, implementation, or review and should be retained for reuse.
agent-environment-health
by berylorg
Keep agent-created or agent-caused compute resources bounded and safely reclaimed throughout a task. Use for software and non-software work that creates temporary data, intermediates, logs, caches, downloads, processes, listeners, ports, locks, concurrent workers, or session-scoped environment changes, especially before heavy or long-running work, at handoff, or after success, failure, cancellation, or interruption. Do not use for general machine administration or resources whose ownership is uncertain.
failure-logging
by berylorg
Log significant invalidated approaches and course corrections. Use when implementation, design, dependency exploration, migration, live testing, test execution, or operations reveal that an approach is technically invalid, unsafe, too costly, or contrary to design/plan authority and the lesson belongs under doc/failures/<scope>.md for future reasoning.
cargo-projects
by berylorg
Apply strict Rust Cargo workspace rules. Use when working in Cargo workspaces or crates, editing Cargo.toml dependencies, adding third-party crates, documenting crate APIs, placing tests, running verification, consulting Cargo.lock, resolving features, or creating Cargo dependency investigation memory under doc/memory.
gpui-scroll-surfaces
by berylorg
Use when creating, reviewing, or optimizing GPUI scrollable lists, tables, trees, sidebars, pickers, transcript rows, settings rows, activity logs, or any repeated row surface. Ensures an explicit bounded rendering strategy, virtualization/windowing decision, stable identity, focus/popover preservation, and scroll performance diagnostics before or during implementation.