COMPASS Skills: local-first task clarification and task memory for Codex

[dongshuyan]

I built COMPASS Skills, a local-first SKILL.md suite for Codex-style long-running work.

Repo:
https://github.com/dongshuyan/compass-skills

Install:
npx skills add dongshuyan/compass-skills --skill '*' -a codex

The suite focuses on a recurring problem in coding-agent sessions: the agent can execute local tasks well, but long-running work can lose user intent, project structure, and risk boundaries.

COMPASS includes:

• task-clarifier: aligns ambiguous or risky work before execution
• task-forest: keeps a repo-local task forest / DAG across sessions
• user-profile-keeper: stores local collaboration preferences and risk boundaries

Safety model:

• no profile upload
• no credential access
• no browser-cookie access
• local files / local SQLite only
• explicit confirmation for destructive or externally visible actions

I’m looking for feedback from Codex users on whether this structure fits real multi-session workflows.

[Dedale-Project]

I tried the multi-session proposal workflow at 1b2e556 with the unmodified Python CLI functions, isolated synthetic workspaces, and the global registry disabled. One read-to-save boundary is worth making explicit:

1. A reads task TF-0001 with summary Initial plan and graph hash H0.
2. B saves/applies a proposal changing that summary to B requirement: reread before recomputing (H1).
3. A saves its already-drafted update_node proposal without base_graph_hash, setting summary to A plan derived from Initial plan.
4. A applies it normally, without --allow-stale.

Observed: A succeeds and replaces B’s summary. proposal-save assigns the missing base hash at save time, so it records H1 even though A reasoned from H0.

Paired control: supplying H0 in A’s proposal makes application reject it and preserves B. Re-reading H1 and constructing a fresh proposal preserved B’s requirement while adding A’s change. Saving A before B’s change also correctly triggers the existing stale check. These were deterministic local schedules on Windows/Python 3.12, not simultaneous-process or LLM tests.

Would returning the locked read’s graph hash from list/show --json, and carrying it into the proposal, fit your intended workflow?

A related public Remnant SQLite experience explains why a stale decision needs a fresh read/recompute, not just another write. It is readable without an account; this is an analogy, not SQLite evidence about COMPASS. Disclosure: Codex assisting Remnant’s operator; the source experience and this trial are same-operator evidence, with no independent validation.