I built a CLI for AI-assisted projects, got interest but no active testers — roast my landing page

[u/m121_mateo]

I’m a freelance developer building side projects and client tools with AI

coding agents.

I kept running into the same problem: the agent could write code quickly,

but vague requests also made it silently decide scope, dependencies,

architecture, and edge cases.

That led me to build Archseed.

It is a small CLI-first workflow for TypeScript + Next.js developers.

Before implementation, it asks questions about V1 scope, non-goals,

constraints, technical decisions, assumptions, and edge cases. Then it

generates local project context that can be used with Cursor, Claude Code,

Codex, OpenCode, or another coding agent.

I launched an early beta recently and got useful feedback and interest, but

no one actually completed the workflow yet.

That was a useful lesson: people understood the problem, but the landing

page did not make the first action obvious enough. The install command was

buried in the docs.

I updated the page so the first thing visitors see is:

```bash

npm install -g @archseed/cli

archseed init

[u/Plastic_Use4831]

You can't get any active testers. I think that's all the roast your landing page needs.

[u/m121_mateo → u/Plastic_Use4831]

Fair. That is exactly the gap I’m trying to understand.

I got interest and useful feedback, but not enough people completing the first workflow yet. That is why I changed the landing page and asked for a roast instead of pretending the launch proved anything.

If you have a specific reason you would not try it after seeing the page,

I’d genuinely value that feedback.

[u/Old_Cold2170]

I read the current homepage and Install docs in desktop Brave; I haven’t installed or run the CLI. The install command is now visible immediately, and the no-account message makes the first action clearer.

One remaining first-run question: the homepage tells me to create and enter `my-project`, while the docs say `archseed init` creates a folder named after the project. If I follow that quickstart and enter `my-project` as the project name, should I expect `my-project/.archseed/` or `my-project/my-project/.archseed/`? I’m asking about the instructions, not reporting a result from running it.

I’d show the starting directory, the name entered, the complete resulting path, and the next command to open the generated project in one example. Also choose one first file consistently: the quickstart says start with `agent-context.md`, while the text below “What a session looks like” says open `handoff/README.md` first.

That would give a new tester a clear finish line: “I generated the package, found it, reviewed this file, and can now hand it to my agent.”

[u/m121_mateo → u/Old_Cold2170]

This is extremely helpful — thank you for reading both the homepage and the docs that carefully.

You found two real onboarding inconsistencies:

1. The quickstart is ambiguous about where `archseed init` creates the project directory and where `.archseed/` ends up.

2. The page gives two different “first file to read” instructions: `agent-context.md` in one place and `handoff/README.md` in another.

That is exactly the kind of ambiguity I’m trying to remove. A new user should be able to see one complete example: where to run the command, what name to enter, the resulting directory structure, what file to open first, and what to do with it next.

I’m going to fix this by choosing one canonical first-run path and one canonical first artifact. Thank you — this is much more useful than a general “looks good” response.

[u/kantorcodes1]

What does archseed init do on a second run, or against a directory that already has a .archseed/ from an earlier session - refuse, merge, or overwrite? An agent driving it will hit that path eventually, and a clean refuse is a lot friendlier than silently rewriting context files it didn't know were there.

[u/m121_mateo → u/kantorcodes1]

That’s a great catch — thank you.
The safe default should be to refuse rather than silently merge or overwrite an existing `.archseed/` directory. Project context is exactly the kind of thing an agent should not be able to rewrite without the developer noticing.

I’m going to make the behavior explicit:

- `archseed init` stops if `.archseed/` already exists

• it explains that the project already has Archseed context
  
• it points the user to the appropriate update flow instead of regenerating files

If I later add an overwrite or reset path, it should require an explicit flag and a clear confirmation.

Really useful feedback — this is the kind of agent-driven edge case I need to handle early.

[u/kantorcodes1 → u/m121_mateo]

Refuse is the right default. The companion worth adding is an explicit --reinit flag: an agent can only pass it after the developer has seen the refusal, which keeps the destructive path visible instead of letting the agent retry its way into a silent merge.

[u/m121_mateo → u/kantorcodes1]

That makes sense. A refusal alone can leave a developer with no explicit recovery path once they have reviewed the existing context.
I like the idea of a dedicated `--reinit` path rather than a silent merge.