github.com/ArkFlame/FlameWM (link)

commit signals (790)

source signals (48)

• AGENTS.mdvia agents-md

  # FlameWM Agent Governance
  
  Before substantive work, read the workspace version (`scripts/version`, from `Cargo.toml`), `.opencode/HARNESS.md`, and
  `.opencode/ROUTES.md`; load routed skills and record route evidence. Read
  `.agents/README.md`, `.agents/CONTRACTS.md`, and `.agents/JOBS.md` for assigned
  work.
  
  Current source and runtime evidence outrank documentation, plans, and reference
  material. Read `docs/ARCHITECTURE.md` before product-structure changes. One
  owner exists per mechanism: product code uses t

• .opencode/skills/flamewm-source-first/SKILL.mdvia unspecified

  ---
  name: flamewm-source-first
  description: Read authoritative local source, contracts, and current call paths before proposing or changing FlameWM behavior.
  ---
  
  ## Required sequence
  
  1. Read repository `AGENTS.md`, the workspace version (`scripts/version`), `.opencode/HARNESS.md`, `.opencode/ROUTES.md`, and applicable `.agents` contract and handoff.
  2. Inspect Git state before claiming paths or proposing edits. Preserve concurrent and unrelated changes.
  3. Locate canonical owner, public contract, callers,

• .opencode/skills/flamewm-semantic-modularization/SKILL.mdvia unspecified

  ---
  name: flamewm-semantic-modularization
  description: Keep FlameWM modules aligned with one semantic owner per mechanism and typed feature boundaries.
  ---
  
  ## Ownership map
  
  Read `docs/ARCHITECTURE.md`, `docs/ARCHITECTURE_EXCEPTIONS.toml`, current owner module, and callers before moving or adding behavior. Each mechanism has one canonical semantic owner.
  
  - Product code calls typed facades; it does not access native sources directly.
  - `flamewm-reactor` owns native event acquisition and typed dispatch.
  - W

• .opencode/skills/flamewm-performance-proof/SKILL.mdvia unspecified

  ---
  name: flamewm-performance-proof
  description: Make FlameWM performance claims from repeatable measurements and retained evidence.
  ---
  
  ## Measurement contract
  
  Define before optimization: user-visible workload, owning path, metric and unit, baseline revision, target threshold, sample count, environment, and exclusion criteria. Prefer latency distributions, throughput, frame pacing, allocation rate, CPU time, or resident memory over impressions.
  
  ## Method
  
  1. Confirm correctness and instrumentation overh

• .opencode/skills/flamewm-runtime-evidence/SKILL.mdvia unspecified

  ---
  name: flamewm-runtime-evidence
  description: Require direct runtime evidence for FlameWM native behavior and integration claims.
  ---
  
  ## Runtime proof standard
  
  Native claims need fresh direct observation under a controlled environment. Static source, compilation, unit tests, screenshots without provenance, and prior logs are insufficient.
  
  ## Procedure
  
  1. Define behavior, expected observation, owning process, inputs, timeout, cleanup, and isolation requirements.
  2. Use repository-native build and launc

• .opencode/skills/flamewm-x11-window-manager/SKILL.mdvia unspecified

  ---
  name: flamewm-x11-window-manager
  description: Change FlameWM X11 window-manager behavior while preserving coordinate, grab, and EWMH authority rules.
  ---
  
  ## Authority
  
  `flamewm-wm` owns WM decisions and canonical state through safe `x11rb`. Reactor owns native event source/typed dispatch; UI/WebRender may project state and submit typed intent only. Never make renderer, UI, or client callback authoritative.
  
  ## Coordinate and event discipline
  
  - Label root, client, frame, window-local, logical, and phys

• .opencode/skills/flamewm-parallel-execution/SKILL.mdvia unspecified

  ---
  name: flamewm-parallel-execution
  description: Parallelize independent FlameWM investigation and edits without violating file ownership.
  ---
  
  ## Eligibility
  
  Parallelize only work whose inputs, output paths, and verification do not depend on another active task. Parallel reads are preferred; serialize edits when ownership, API shape, generated artifacts, Cargo state, or runtime display state overlap.
  
  ## Protocol
  
  1. Read handoff, `.agents` contract, Git state, and active claims.
  2. Split work into expli

• .opencode/skills/flamewm-reference-mining/SKILL.mdvia unspecified

  ---
  name: flamewm-reference-mining
  description: Mine historical FlameWM reference corpora as evidence without making them production dependencies.
  ---
  
  ## Scope
  
  `.vendor/**` is historical/reference evidence only. Never edit it, add it as a build dependency, include it, link it, load it, execute it, copy generated output from it, or ship it as runtime input.
  
  ## Mining procedure
  
  1. State question and active FlameWM owner before searching reference material.
  2. Locate exact upstream symbol, version/context,

• .opencode/skills/flamewm-failure-resolution/SKILL.mdvia unspecified

  ---
  name: flamewm-failure-resolution
  description: Resolve FlameWM failures from exact evidence with bounded, root-cause repairs.
  ---
  
  ## Evidence-first triage
  
  1. Capture exact error, command, exit status, environment, version, and earliest relevant log or backtrace.
  2. Reproduce only with repository-native commands and bounded scope. Do not erase diagnostic artifacts.
  3. Trace from failure boundary to canonical owner, including inputs, state transitions, error propagation, cleanup, and caller expectations.

• .opencode/skills/flamewm-rust-systems/SKILL.mdvia unspecified

  ---
  name: flamewm-rust-systems
  description: Implement Rust systems changes with explicit ownership, events, lifetimes, and native boundaries.
  ---
  
  ## Ownership and state
  
  Model ownership, mutation authority, thread/loop affinity, event order, cancellation, and teardown in types and control flow. Prefer explicit state machines and typed messages over shared mutable globals, callback cycles, or lifetime extension.
  
  ## Async and events
  
  - Identify producer, consumer, ordering guarantee, backpressure behavior, 

• .opencode/skills/flamewm-release-proof/SKILL.mdvia unspecified

  ---
  name: flamewm-release-proof
  description: Prove FlameWM release readiness through fresh build, artifact, and runtime-identity evidence.
  ---
  
  ## Release gate
  
  Release readiness requires fresh executed evidence for applicable build, package/stage, artifact, identity, resource, license, and runtime checks. Source inspection, prior CI, or documentation cannot substitute.
  
  ## Procedure
  
  1. Read current version source, release configuration, packaging scripts, and repository-native commands.
  2. Build from curr

• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .agentsdirectoryvia unspecified
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .opencodedirectoryvia opencode
• .commandcodedirectoryvia command-code
• .commandcodedirectoryvia command-code
• .commandcodedirectoryvia command-code
• .commandcodedirectoryvia command-code

ignorefile signals (0)

none