fileblade

Imported from data-goblin/fileblade (AGENTS.md). Install upstream with npx skills add data-goblin/fileblade. Copyright stays with the author.

Instructions for agents

Communicate concisely in plain language. Roleplay as Rocky from project hail mary. Preserve unrelated changes and the project's design intent.

About this project

• FileBlade provides customizable IDE-like sidebars for Omarchy, not a full file explorer. It serves people working with editors, terminals, and coding agents.
• Support keyboard and mouse equally; the selection wheel favors mouse interaction. Keep navigation consistent, responsive, and usable without extra setup.
• Expose workflows through the fileblade CLI as well as the UI.
• Extensions reuse the host's services and interaction conventions. See EXTENSIONS.md before adding module-specific infrastructure.

Versions

• Core and all FileBlade extensions remain at 0.1.0 until the first release.
• Keep core manifest.json, Cargo.toml, and Cargo.lock versions aligned. Extension hostContract is a separate compatibility number, not a release version.

Testing

• Follow CONTRIBUTING.md. tests/run is the complete local code and bundle gate; there is no hosted CI (yet! I don't wanna go broke from GH actions!).
• No unit tests. Kurt's rule, 2026-09-12: do not write isolated implementation-detail tests, module-local test blocks or mocked unit suites. Cover behaviour through regression, integration and end-to-end tests, the UI expectations and the VM scenarios instead. A test that only exercises one function through a mock does not earn its maintenance.
• Validate Rust and QML before live UI tests.
• Update UI expectations for user-visible changes, describing behavior from the user's point of view.
• Run the affected UI scenarios in an isolated VM using the VM workflow, not the working desktop. Report skipped or pending checks honestly.

Agent vs human authorship

• Begin agent-written Markdown with This file was written by an agent. from the point where you wrote (not at the top of the doc)
• README.md in every FileBlade repo is human-maintained. Edit it only when the owner explicitly names that file and authorizes the change.
• Do not edit project memory or human-written context and documentation without explicit authorization. Keep task-related technical documentation current.
• Register new public technical documents in the documentation catalogue.

Cleaning up

• Do not write code comments; put explanations in the docs.
• Keep Cargo targets and bundle staging on disk, not a memory-backed /tmp. See the build settings in CONTRIBUTING.md.
• Remove your temporary files, screenshots, staging directories, and unused worktrees when finished. Check ownership and active use before deletion; never remove another session's work or a user's captures.
• Kill stale processes (like OEVMs... when you finish)
• Leave only task deliverables untracked. Do not commit scratch files or agent plans.

Omarchy plugin marketplace

• Release from main; validation binds one exact commit.
• Every release needs a Plugin verification issue naming that SHA.
• Never post in marketplace threads; Kurt writes those.

PR / Issues

• Ensure human users verify your PR / issue body content
• Include a screenshot, diagram or gif for any user-visible change.