add-data-source

name	add-data-source
description	Suggest, elicit, and record external data sources for a project (Printing Press-aware)

Add Data Source

Suggest, elicit, and record external data sources for a project. Recommends Printing Press CLIs from its catalog when applicable; also covers native CLIs, sniff targets, CSV imports, and wishlist gaps. Callable any time — not coupled to project creation.

Arguments

$ARGUMENTS — optional project slug. If omitted, list projects and ask which one.

Behavior

1. Resolve the project page.

   If $ARGUMENTS is empty, list available projects:

   rubber-ducky --json wiki search "" --type project --verbose
   

   Ask the user to pick. Otherwise, treat $ARGUMENTS as the project slug and confirm wiki/projects/<slug>.md exists. If it doesn't, fail clearly — direct them to /start-project first.

2. Show what's already wired. Read existing data sources verbatim:

   rubber-ducky --json frontmatter get wiki/projects/<slug>.md data_sources
   

   List current entries (if any). This grounds the conversation and prevents redundant suggestions.

3. Elicit. Ask two questions, in order:

   • "What data would help with this project?" — free-text.
   • "Are you already using anything for this — a tool, app, or spreadsheet?" — high-signal. "I already use Monarch" tells you to (a) try to wire Monarch up first, (b) skip overlapping suggestions, (c) be honest if no good integration path exists.

4. Check Printing Press install state and inventory. One call covers both:

   rubber-ducky --json pp status
   rubber-ducky --json pp installed
   

   pp status tells you whether any printed CLIs are installed locally; pp installed lists them. If nothing is installed yet, share the install line for a curated starter set but don't block — catalog suggestions are still useful as a "here's what to install when you're ready" plan:

   npx -y @mvanhorn/printing-press install starter-pack
   

5. Browse the published catalog. Use PP's own consumer-side commands (the Go printing-press binary is an author tool — generate/verify/publish — and doesn't expose browse subcommands):

   npx -y @mvanhorn/printing-press list
   npx -y @mvanhorn/printing-press search <keyword>
   

   Both read the live registry at https://github.com/mvanhorn/printing-press-library. If npx is unavailable or offline, point the user at the same page in a browser; continue with non-PP options in that case.

6. Reason across four paths. PP is the strongest general option but not the only one. Evaluate each:

   • Catalog match (entry already published, e.g. mercury, stripe, notion) → install with npx -y @mvanhorn/printing-press install <name>. Record in frontmatter as pp:<name>.
   • Generate from a spec/URL (no published entry, but the API or site is reachable — e.g., Redfin, Realtor.com, a private API) → use the Claude Code slash command /printing-press <name-or-url>, which runs PP's full generation pipeline (research → spec → CLI → MCP). Record as pp:<name> once printed.
   • Non-PP path when a better option exists — native CLIs (gh, stripe-cli, mercury-cli), CSV import, an MCP server, or honest manual entry.
   • Wishlist when no path exists today (gated API requiring sponsorship, no public surface).

7. Compare and contrast. Pick 2–4 options. One short paragraph each, leading with the tradeoff that matters (auth complexity, freshness, scrape brittleness, cost). End with a single opinionated recommendation: "My pick: try <name> first because …"

   Anchor on the user's existing tool from step 3. If they named Monarch and no clean integration path exists, say so plainly: "Monarch doesn't expose a public API; the closest path is Plaid via PP, which talks to your bank directly." Don't pad with irrelevant catalog entries.

   Be honest about misfit. If the user banks with Chase and the only banking catalog entry is mercury, point out that Mercury's CLI helps Mercury customers — not Chase. Steer toward Plaid or CSV imports.

8. Record the decision on the project page. Three writes per chosen source:

   • data_sources frontmatter (append, never overwrite):

     rubber-ducky frontmatter array add wiki/projects/<slug>.md data_sources "<entry>"
     

     Entry conventions (always use a prefix — explicit beats implicit):

     • "pp:mercury" — Printing Press CLI for Mercury (installed or planned)
     • "sniff:https://www.redfin.com" — PP sniff target (URL-driven print)
     • "external:monarch" — user is using something off-platform (no integration)
     • "wishlist:mls" — known gap, no path yet
     • "cli:gh" — hand-written or official CLI like gh (not PP-printed)
     • "mcp:notion" — MCP server without a paired CLI

   • ## Description — extend with a clause naming what's now tracked, if relevant. Use the Edit tool.

   • ## Notes — append a dated entry. Use the Edit tool. Example:

     - 2026-05-09: Wired up Mercury via PP. Tracks checking balance and outgoing wires.
     

9. Hand off to PP. If the user wants to install something now, give them the exact next command and let them run it in their next message:

   • Already published in the library → npx -y @mvanhorn/printing-press install <name> (quick fetch, no generation).
   • Not yet published (sniff target, custom API, URL) → /printing-press <name-or-url> (runs the full generation pipeline as a separate Claude Code skill).

   Don't invoke either inline.

10. Confirm the gap closes. After the user reports back that PP finished printing, run:

    rubber-ducky --json pp gap <slug>
    

    The named PP CLI should no longer appear in gaps. If it still does, rubber-ducky pp installed will reveal whether the print succeeded.

Output

• Updated frontmatter (data_sources appended).
• Updated body (## Description extended where relevant; ## Notes gets a dated entry).
• A short "do this next" line with the exact PP command to run (when applicable).

Tone

Brief, opinionated, honest. Value is judgment, not enumeration. A list of every catalog entry that could be tangentially relevant is worse than two well-reasoned suggestions with the tradeoffs spelled out. When no clean path exists, say so plainly and record the gap as a wishlist entry — that's more useful than a forced recommendation.