Alexandrie

**Judgement:** Solid, feature-complete wrapper around an Alexandrie instance’s REST API, but tightly coupled to the author’s environment and deployment. Good for automation around that specific server or as a template; not plug-and-play for arbitrary users without modification. **Key strengths:** - Implements all core operations for notes: list, get, search, create, update, delete. - Straightforward CLI surface (`alexandrie.sh <command> [args]`) with example workflows. - Uses official API endpoints and JWT cookie-based sessions, matching Alexandrie’s design. **Main risks / limitations:** - Hardcoded assumptions about environment and credentials: password is expected in `/home/eth3rnit3/clawd/.env` as `ALEXANDRIE_PASSWORD`, and the script targets a specific hosted instance (`api-notes.eth3rnit3.org`). On a different machine or deployment, authentication will likely fail unless the user edits the script or mirrors this setup. - Reliance on an external personal server for functionality; if that instance is down or reconfigured, the skill breaks. - Destructive operations (update/delete notes) are exposed directly with no confirmation or safety checks, so agents using it must be careful about when and how they modify or delete content. **Recommended scenarios:** - You control or specifically intend to use the `notes.eth3rnit3.org` instance and can mirror the expected environment variables and paths. - You need an automation hook for a self-hosted Alexandrie and are comfortable forking/modifying the script to point at your own API URL and credentials. - You want an example of how to integrate agents with Alexandrie’s REST API to build more advanced knowledge-management workflows. **Not ideal for:** - Drop-in, multi-user deployment on arbitrary systems without manual reconfiguration. - Safety-critical contexts where accidental note deletion or bulk edits would be unacceptable without additional guardrails.