agentleFS
amanjotxamanjotx/Agent-Skills/skills/hydrate/SKILL.md

hydrate

Skill0 starsChanged 54 days agoMITView on GitHub

Sync Hydra DB standing with the current codebase using a git sync waypoint: explore code (delta-first when possible), compare to the one project knowledge source, rewrite it. Use when the user says /hydrate, hydrate, sync hydra, refresh project memory, or asks to keep Hydra updated with the repo.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 7 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep Hydra DB aligned with a fast-moving codebase.

    line 13
  2. Very specific:

    If {project}-standing is missing/empty, stop and recommend /ingest (or offer to run ingest if the user confirms).

    line 25
  3. Distinctive:

    Do not dump large markdown docs into context or Hydra as raw paste.

    line 31
  4. Distinctive:

    Never store secrets, env values, tokens, or credentials.

    line 32
  5. Distinctive:

    Keep writes distilled. Skip transient WIP and session checkpoints.

    line 41
  6. Distinctive:

    Do not rewrite personal-collection prefs while hydrating a project.

    line 42
  7. Distinctive:

    Never invent a git sha. Always refresh the waypoint after a successful sync when git is available.

    line 43
  8. Distinctive:

    Do not strip contracts to fit a single request.

    line 46
  9. Very specific:

    Always pass --collection {project} (do not use Hydra MCP)

    line 58
  10. Very specific:

    If missing/empty: recommend /ingest.

    line 69
  11. Very specific:

    Always rewrite ## Sync waypoint to current HEAD metadata from step 1.

    line 115
  12. Very specific:

    If leftover sibling ids exist (*-codebase-map, *-decisions-*, *-scars, *-product-locked), delete them.

    line 117

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/hydrate

Keep Hydra DB aligned with a fast-moving codebase. This is an incremental rewrite of one document, not a first-principles ingest and not a scatter of new source ids.

Default flow:

  1. Explore codebase (delta-first via Sync waypoint when valid)
  2. hydradb inspect {project}-standing --collection {project}
  3. Patch sections in that document; ingest the rewritten doc as knowledge under the same id (--kind knowledge --no-infer --collection {project})
  4. Advance the Sync waypoint to current HEAD

If {project}-standing is missing/empty, stop and recommend /ingest (or offer to run ingest if the user confirms).

Hard rules

  • Code wins when Hydra and code disagree. Fix standing in the same run.
  • Do not dump large markdown docs into context or Hydra as raw paste.
  • Never store secrets, env values, tokens, or credentials.
  • One project id only: {project}-standing. Never create sibling ids (*-codebase-map, *-decisions-*, *-scars, *-product-locked); delete those if they reappear.
  • Upsert standing as knowledge (--kind knowledge, --no-infer). Bare hydradb ingest --text is the memory store (1000-token cap, replace-not-append) — do not put standing there. Use the hydradb CLI with --collection {project}. Do not use Hydra MCP. Never export HYDRADB_COLLECTION globally.
  • Keep writes distilled. Skip transient WIP and session checkpoints.
  • Do not rewrite personal-collection prefs while hydrating a project.
  • Never invent a git sha. Always refresh the waypoint after a successful sync when git is available.
  • Preserve Problem / Product / Destination; refresh Current standing from code. Do not strip contracts to fit a single request.

What “in sync” means

Standing reflects current layout, wiring, shipped vs stub, verify commands, still-true locks, dated decisions, scars, and a waypoint at current HEAD.

Workflow

1. Identify project + current git tip

  • {project} slug; standing id {project}-standing
  • Always pass --collection {project} (do not use Hydra MCP)
  • git rev-parse HEAD / --short=12 / --abbrev-ref HEAD
  • git log -1 --format=%s and %cI
  • git status --porcelain

2. Fetch standing + waypoint

  • hydradb inspect {project}-standing --collection {project} only (not a 3–5 hit query)
  • Parse ## Sync waypoint → previous commit sha

If missing/empty: recommend /ingest.

3. Decide exploration mode

Validate the previous waypoint sha exists and is an ancestor of HEAD.

ConditionMode
Valid waypoint ancestor of HEADDelta-first
Missing / invalid / not ancestor / history rewriteBroader standing pass
Valid but very large structural deltaBroader pass, or recommend /ingest if standing is poor
HEAD matches waypoint, worktree cleanLight confirm; report “already at waypoint” if no drift
HEAD matches waypoint, worktree dirtyDelta includes dirty files

4. Explore

Delta-first: git log --oneline <waypoint>..HEAD, git diff --stat and material diffs, dirty paths, dependents/callers, verify scripts if those files changed.

Broader: root manifests, central entrypoints, active product surfaces, CI scripts, added/removed apps/packages/crates.

5. Diff: code vs standing

StatusAction
AccurateKeep in the rewritten doc
MissingAdd to the right section of standing
Stale / wrongCorrect in standing; do not leave a second memory
Provisional / noisy / secret / tacticalDo not store

Focus on material drift: new modules, stubs that became real, contract changes, verify commands, wiring, removed surfaces, overturned locks.

6. Write + advance waypoint

Rebuild the full markdown (same section order as /ingest) and ingest {project}-standing as knowledge with --no-infer:

hydradb ingest --kind knowledge --text "$(cat standing.md)" \
  --source-id {project}-standing --title "{Project} — standing" \
  --no-infer --collection {project}

Always rewrite ## Sync waypoint to current HEAD metadata from step 1.

If leftover sibling ids exist (*-codebase-map, *-decisions-*, *-scars, *-product-locked), delete them.

Waypoint block:

## Sync waypoint

- commit: <full sha>
- short: <12-char sha>
- branch: <branch name>
- subject: <one-line subject>
- committed_at: <ISO from git>
- captured_at: <ISO timestamp of this skill run>

7. Report back

Short: mode, previous → new waypoint, commit range if delta-first, sections changed, corrections (Hydra was wrong → code), skipped items, whether /ingest is recommended.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.