Skip to content

Roadmap: repo provisioning + first field review#11

Merged
DanMat merged 1 commit into
mainfrom
docs/roadmap-field-feedback
Jul 21, 2026
Merged

Roadmap: repo provisioning + first field review#11
DanMat merged 1 commit into
mainfrom
docs/roadmap-field-feedback

Conversation

@DanMat

@DanMat DanMat commented Jul 21, 2026

Copy link
Copy Markdown
Owner

Captures two inputs: creating the remote repo as part of scaffolding, and the first unsolicited review from an agent that used Packkit to build a real internal full-stack tool.

The connecting thread

Packkit assumes a greenfield empty directory. The actual workflow is "the repo already exists" — either because you created it, or because you cloned it.

--here aborts when the target has any entry at all, and dirIsEmptyOrMissing counts dotfiles — so a bare .git/ from a fresh clone is enough to stop it. That's why the reviewer had to back up, move, and restore files, and it's the same wall you hit creating an empty repo and cloning it first. Repo provisioning and a merge mode are two halves of one gap.

Added to Next up

  • Create the repo, not just the folder--github [owner/name] via the gh CLI (so Packkit never handles a token), --git-remote <url> as the universal escape hatch. Opt-in, private by default. Side benefit: the repo URL currently gets typed by hand and feeds package.json links + README badges, so deriving it makes existing output correct.
  • Scaffold into a non-empty directory — merge mode that writes what's absent and never clobbers.

Added from the review

  • Full-stack monorepo preset — the highest-value item. monorepo hardcodes two library packages with no apps/; node-service and react-app already exist, so it's the composition that's missing.
  • packkit.json provenance — Packkit leaves zero footprint today, so a project can't say what it started from. Prerequisite for any future packkit upgrade.
  • One-line MCP install — largely closed by the registry publish already; what's left is a deep-link install button.
  • Preset discovery for agents — the review asked for a tool that exists under a different name (packkit_preview); the misremembering is itself the finding.
  • Post-scaffold checklist — extend what the CLI already prints.

Deliberately not acted on

Recorded with reasoning so they don't get re-raised: the "Node 22 vs 24 friction" is the engine preflight working as designed (it refuses to scaffold a project whose tooling can't run, and prints the exact fix), and the "overwrite risk" in --here is inverted — it aborts rather than overwrites.

🤖 Generated with Claude Code

Two sources: the idea to have Packkit create the remote repo, and an
unsolicited review from an agent that used Packkit to build a real
internal full-stack tool.

Both point at the same root cause. Packkit assumes a greenfield empty
directory, but the actual workflow is "the repo already exists" — either
because you made it, or because you cloned it. `--here` aborts on any
existing entry including a bare `.git/`, so clone-then-scaffold fails on
the clone. Repo provisioning and a merge mode are the two halves.

Also logged: full-stack monorepo preset (the composition of node-service
+ react-app is what's missing, not the parts), packkit.json provenance,
and the MCP install path — which the registry publish already mostly
closed.

Recorded two findings we should not act on as written: the Node version
"friction" is the engine preflight doing its job, and the `--here`
"overwrite risk" is inverted — it aborts rather than overwrites.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@DanMat
DanMat merged commit c42e257 into main Jul 21, 2026
4 checks passed
@DanMat
DanMat deleted the docs/roadmap-field-feedback branch July 21, 2026 19:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant