nectar vs smith

Head-to-head with Smith (attckdigital). Sourced from the nectar prior-art corpus (captured 2026-06). Smith is the closest single prior art; credit it generously. Brand voice: lowercase wordmarks, sentence case, mono for ids, paths, and commands, no emoji.

nectar vs smith

Page: compare-nectar-vs-smith | Slug: compare/nectar-vs-smith | Version: 1.0 | Date: July 2026 | Status: Draft for approval

Head-to-head with Smith (attckdigital). Sourced from the nectar prior-art corpus (captured 2026-06). Smith is the closest single prior art; credit it generously. Brand voice: lowercase wordmarks, sentence case, mono for ids, paths, and commands, no emoji.


#The short version

smith is the closest thing to nectar's description model, and we learned from it. it keeps a per-file description and re-describes only what changed. nectar takes that idea and adds the three things smith lacks: stable identity, a durable store you own, and recall that fuses with your memory.

#What smith is

smith maintains a small description file next to each source file. it records a hash of the file and the hash it was last described against; when those diverge, the file is stale, and a describe command re-describes only the stale ones. teammates who clone the repo inherit the descriptions instead of paying the cost again. it is the same lazy, committed, incremental approach nectar uses.

#What nectar borrows from smith

we credit smith plainly. three of nectar's design choices come straight from it:

  • lazy description with staleness tracking. our per-version describe_status is smith's hash-mismatch flag.
  • commit the descriptions so teammates inherit them. our committed map is smith's committed description layer.
  • batch the work to keep the cost low.

#Where nectar fills the gap

dimension smith nectar
file identity none; descriptions are keyed by path, so a move loses them a stable tag minted once; the description follows a rename or move
where descriptions live sidecar files next to your source a durable store you own, projected to one committed map
touches your source yes; it writes into files like CLAUDE.md never; the one file it writes is its own map
freshness manual; you run the index command continuous; a background watcher reacts after you pause editing
fuses with memory no; it is a standalone navigator yes; code recall joins session and skill recall in one query

the honest summary: nectar's description model is smith's model, with the identity, storage, source-safety, and recall dimensions rewritten to fit a memory stack.

#When to pick which

  • pick smith if you want a lightweight, self-contained per-file description layer committed alongside your code.
  • pick nectar if you also need descriptions that survive refactors, a store you own, source that is never modified, and code recall fused with your assistant's memory.

#Sources

from smith's public materials and the nectar prior-art survey, captured 2026-06. written in our own words and dated.