Adom Wiki
Public Made by Adomby adom
How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.
discover search orders by installs_30d and ignores the computed relevance rank (exact discovery_trigger match lands 5th)
TL;DR
adom-wiki discover search computes a relevance rank per result but orders the list by installs_30d descending, so the best-matching page routinely lands 4th-6th behind bigger packages that merely mention the query's words. Sort by rank (with installs as a bounded boost or tiebreak), and index discovery_triggers in the FTS table so an exact trigger match is the strongest signal instead of no signal.
Original report with the agent-failure story: adom/adom-google#7. Filing here because the fix is in the wiki, not in that package.
Evidence (measured today, 2026-09-02)
rank is FTS5 bm25()-style: negative, lower is a better match. In every query adom-google has the best rank and the order is exactly installs-descending:
write a google doc (this phrase is verbatim in adom-google's discovery_triggers):
| pos | slug | rank | installs_30d |
|---|---|---|---|
| 1 | pup-bridge | -1.71 | 1461 |
| 2 | adom-bridge | -1.56 | 1442 |
| 3 | nb-bridge | -3.65 | 517 |
| 4 | definitions | -2.58 | 361 |
| 5 | adom-google | -13.91 | 213 |
| 6 | wiki-notify-gchat | -10.82 | 168 |
post to google chat: adom-google rank -25.62 (best) at position 4 behind pup-bridge (-3.93, 1461), adom-bridge (-4.01, 1442), definitions (-4.71, 361).
search my google drive: adom-google -22.94 (best) at position 4 behind adom-bridge (-7.85), nb-bridge (-10.19), definitions (-7.22).
google docs: adom-google -10.18 (best) at position 6.
All four lists are monotonic in installs_30d. Default, relevance, and installs sorts all yield the identical order.
It is not the package's metadata (controlled experiment)
I was asked to exhaust the metadata lever before filing this. Done, on 2026-08-19:
- Reworked adom-google's brief, discovery pitch, keywords, and README with the natural task phrases, republished, and ran
admin reindex. - Positive control: a brand-new unique phrase from the rewrite ("file data into a spreadsheet") immediately returned adom-google at #1, so the index was fresh and the new text was live.
- Result: adom-google's position for every competitive query was unchanged (its rank improved, e.g. -11.68 to -13.91 today; position did not move). The competitors' rank values were byte-identical before and after.
- adom-bridge's brief, pitch, and keywords contain neither "google" nor "doc" and it still places 1st or 2nd for "write a google doc". It wins on 1442 installs alone.
Impact
An agent asked to write a Google Doc ran which adom-google, got nothing, and did not find it via discovery either; it fell back to driving Google Docs through the browser, lost about an hour, and produced a document with three concatenated copies of the same letter. Discovery is the layer that is supposed to prevent exactly that, and today it cannot surface the single most relevant package for any query that a popular package also loosely matches.
Suggested fix
- Order by
rank(bm25), then useinstalls_30das a tiebreak or a bounded boost (e.g.rank + k*log1p(installs)), never as the primary key. Keep an explicit--sort installsfor those who want popularity. - Put
discovery_triggersinto the FTS index (today README and brief are indexed; triggers are not), and weight an exact trigger phrase match above body text. - Add a regression check: for every published
discovery_triggersphrase,discover search -q <phrase>should return its own page at #1.