organize-files
The organize-files skill restructures the shared notes directory into a navigable hierarchy by deduplicating files, standardizing naming, creating topic-based subdirectories within research/ and experiments/, repairing links, and logging all changes to an audit trail. Use it when the notes/ directory becomes crowded or disorganized, duplicate content emerges, naming conventions break down, or after phases of heavy file creation that make finding notes difficult.
git clone --depth 1 https://github.com/Human-Agent-Society/CORAL /tmp/organize-files && cp -r /tmp/organize-files/coral/template/skills/organize-files ~/.claude/skills/organize-filesSKILL.md
# Organize Files
Restructure the shared notes directory so every agent can find what they need quickly.
For a complete before/after walkthrough on a realistic messy notes/ tree — including the dedup pass, naming fixes, subdirectory creation, link repair, and audit-log entry — see [`references/worked-example.md`](references/worked-example.md). Read it once before your first reorganization; it makes the abstract steps below concrete.
For recovery procedures and judgment calls (move script aborted partway, false-positive duplicates, files that look misplaced in `_synthesis/`, contradicting `_open-questions.md`, races between agents…), see [`references/edge-cases.md`](references/edge-cases.md).
## When to Use
- Too many flat files in `research/` or `experiments/`
- Duplicate or near-duplicate notes
- Inconsistent naming (spaces, uppercase, agent IDs in filenames)
- After a deep-research or consolidate phase that created many files
- You can't find a note you know exists
## Notes Directory Structure
```
notes/
├── index.md ← table of contents (research + experiments only)
├── raw/ ← immutable sources (DON'T touch)
├── research/ ← deep-research findings (organize within)
│ ├── <topic>/ ← group by topic or theme
│ └── ...
├── experiments/ ← eval reflections and results (organize within)
│ ├── <approach>/ ← group by approach or technique
│ └── ...
├── _synthesis/ ← consolidate owns this (DON'T touch)
├── _connections.md ← consolidate owns this
├── _open-questions.md
└── _organization-log.md ← append-only log of what you changed
```
## Process
### 1. Audit
Get the current state:
```bash
bash .coral/public/skills/organize-files/scripts/audit.sh
```
Or manually: `ls -R {shared_dir}/notes/` and count files per directory.
Also check for content-level issues:
- **Contradictions** — do any notes claim opposite things? Update or flag them in `_open-questions.md`.
- **Stale info** — research notes that experiments have disproven. Update with actual results.
- **Orphan pages** — notes not listed in `index.md`. Add them.
- **Missing cross-references** — related notes that don't link to each other.
- **Gaps** — techniques mentioned but never researched, or researched but never tried.
### 2. Plan
Write out your target structure before moving anything. Organize **within** `research/` and `experiments/` — add subdirectories by topic when a dir has 5+ files:
```
research/
├── algorithms/ (3+ notes)
├── optimization/ (3+ notes)
└── ...
experiments/
├── optimization/ (3+ notes)
├── debugging/ (3+ notes)
└── ...
```
Rules:
- **Minimum 3 files per subdirectory** — don't create a dir for 1-2 files
- **Max 2 levels deep** — `experiments/optimization/learning-rate.md` is the limit
- **Name by topic** — `algorithms/` not `agent1-work/`
- **Don't touch `raw/`** — immutable source material
- **Don't touch `_synthesis/`, `_connections.md`, `_open-questions.md`** — owned by consolidate
### 3. Deduplicate
Find near-duplicates:
```bash
python .coral/public/skills/organize-files/scripts/find_duplicates.py .coral/public/notes --threshold 0.5
```
For pairs above the threshold where the verdict is not immediately obvious from a quick read — same topic vs. different angle vs. different topic with shared boilerplate vs. genuinely contradicting — spawn the **Dedup Judge** subagent. It reads both notes blinded (no author / timestamp / length metadata) and returns a structured verdict (`same-topic-merge` / `different-angle-fold` / `contradicting-do-not-merge` / `keep-both-rename`) with concrete merge or rename instructions. See [`agents/dedup-judge.md`](agents/dedup-judge.md). Use it especially when:
- The two notes were written by different agents (recency / author bias is highest).
- One note is much longer than the other (length bias makes the long one feel authoritative).
- The notes appear to disagree but you can't tell if it's a real conflict or a scope difference.
For obvious cases — verbatim duplicates, or clearly different topics that shared a paragraph — just decide directly.
When merging confirmed duplicates, **preserve provenance from both notes** — never just pick one and discard:
- **Union the `## References` lists** (de-duplicated by URL or `raw/` filename). Losing a citation loses an audit trail that an agent may need months later.
- **Keep the more specific claims from each note**, not just whichever was longer. A short note with concrete numbers usually has higher information density than a long one with vague prose.
- **Combine `tags` and `aliases`** rather than picking one set. Both were correct in their original context.
Move originals to `_archive/` so the merge is reversible.
When two notes **contradict** each other, don't merge:
- Flag the conflict in `_open-questions.md` (existing rule).
- Also stamp `contradictedBy: [other-note-slug]` into each note's frontmatter so future readers see the conflict at the note level — `_open-questions.md` collects them, but agents reading the note directly should see the warning without a separate lookup.
### 4. Move and Rename
Use the move script for safe moves with frontmatter tracking:
```bash
python .coral/public/skills/organize-files/scripts/move_note.py SOURCE DEST
```
Naming: `kebab-case-like-this.md`, topic first, no agent IDs, no bare dates, under 60 chars.
### 5. Update Index
Regenerate `index.md`:
```bash
python .coral/public/skills/organize-files/scripts/generate_index.py .coral/public/notes
```
The index should only list `research/` and `experiments/` entries — not `raw/`.
Then resolve cross-links — moves and renames break any `[[old-slug]]` references in note bodies:
```bash
python .coral/public/skills/organize-files/scripts/resolve_links.py .coral/public/notes --dry-run
# review the diff, then:
python .coral/public/skills/organize-files/scripts/resolve_links.py .coral/public/notes
```
The resolver walks every note, scans the body for plain-teVerify and debug changes to CORAL itself — smallest reproduce loop per area (grader / daemon / CLI / hooks / manager / workspace / hub / template / config / web), where to look when something breaks (hung graders, agent restart loops, stalled agents, missing heartbeat actions, corrupted shared state, broken worktree symlinks, grader import errors, wrong-task resume), how to inspect a live or finished run under `.coral/public/`, and the canonical lint/test commands. Use when editing code under `coral/` or chasing a CORAL bug, NOT when adding a new task or extending the framework.
Add a new component to the CORAL framework itself — a new agent runtime under `coral/agent/builtin/` (claude_code/codex/cursor_agent style), a new CLI command in `coral/cli/`, a new bundled skill or subagent template under `coral/template/skills/` or `coral/template/agents/`, a new hook in `coral/hooks/`, a new field in `coral/config.py`, or a framework-level extension to the grader stack under `coral/grader/`. NOT for writing a per-task grader or adding an example task — use `coral-new-task` for that. NOT for debugging existing code — use `coral-debug`.
End-to-end recipe for adding a new task under `examples/` — the three pieces that have to line up (`task.yaml`, `seed/`, and `grader/`), what to put in each, the `TaskGrader` API surface, the `coral validate` → smoke-test loop, and the common mistakes (repo_path pointing at the wrong dir, score direction backwards, hidden answer keys leaking into seed/, grader writing to codebase_path which the daemon force-removes, private-vs-public confusion, missing `run()` signature). Use whenever the user wants to add a new CORAL task or port an existing benchmark into CORAL.
Research the problem domain before coding. Web search for techniques, save raw sources, write structured findings, update the index.
Autonomously create, test, and optimize skills by detecting reusable patterns in your own work. Use when you notice repeated tool sequences, recurring code patterns across attempts, or insights that should be captured as a packaged skill. Also use to benchmark and iterate on existing skills.
The fast path from zero to a running CORAL experiment — what CORAL is and when to reach for it, installing the `coral` CLI, registering a runtime with `coral setup`, and the `.coral_workspace/` convention for pointing CORAL at code you already have and want optimized. Use this whenever the user asks "what is coral", "should I use coral for this", wants to install or get coral set up, hits a "command not found" for coral or doesn't have it installed yet, or says "use coral to optimize / speed up / improve this code" and you need the end-to-end onboarding from install to a launched run. Hands off to `setting-up-coral` (runtime bindings), `creating-a-coral-task` (grader authoring), and `running-coral-experiments` (operating a run) for depth.
Author a new CORAL task — the three pieces that must line up (`task.yaml`, `seed/`, a packaged `grader/`), the `coral init` → `coral validate` → smoke-test loop, and how to pick a grader pattern (stdout float, test pass-rate, ratio-vs-baseline, multi-metric, or an LLM rubric judge). Use whenever the user wants to create a CORAL task, write or wire a grader, port a benchmark into CORAL, score open-ended outputs (reports/memos) with a judge, or debug a grader that crashes on the seed / ranks the leaderboard backwards / leaks the answer key. Deep references for the TaskGrader API, grader patterns, rubric judges, and the full task.yaml schema live alongside this skill.
Run and manage CORAL experiments from the operator side — launch agents with `coral start` (dotlist overrides, model/count, tmux vs local), monitor with `coral status` / `coral log` / `coral show` / the web dashboard, and drive the loop with `coral resume` (inject instructions, fork from an attempt), `coral heartbeat` (tune reflection cadence), and `coral stop`. Use whenever the user wants to start a CORAL run, check on agents, read scores/leaderboard, steer or resume a run, diagnose agents that keep restarting or fail every eval, scale to more agents or islands, or stop a run. Deep references for steering/heartbeat tuning and scaling/troubleshooting live alongside this skill.