This directly addresses the three agent-init failure modes I diagnosed in #534 — all three fixes are correct and the test coverage is solid.

Fix 1 (--version): parser.add_argument("--version", action="version", version=f"mempalace {__version__}") is exactly right. Using argparse's built-in action="version" is the canonical approach — it exits 0 (not 2), which is what SKILL.md prerequisite checks need. The version.py import is already in the file. Clean.

Fix 2 (--yes in instructions): The EOFError on input() is a silent killer for headless agents. Adding --yes to instructions/init.md is the right fix over the alternatives (the --yes flag already existed via #8 — this was a docs gap, not a code gap). The added prose explaining why the flag is required is useful; most instruction files don't explain the rationale and agents cargo-cult the command without understanding it.

Fix 3 (mine prerequisite): Adding Step 0 to mine.md is the right UX. The "auto-init when yaml is missing" alternative I mentioned in #534 has a real footgun: agents mining a subdirectory would silently create a palace in the wrong place. Explicit prerequisite documentation is safer.

Tests: All four new tests are behavioral, not structural — they verify the flag works and the instructions contain the right text. The test_cmd_init_yes_skips_interactive_prompts approach of asserting confirm_entities receives yes=True is exactly right (verifies the plumbing, not the argparse config).

One small observation: test_mine_instructions_mention_init_prerequisite checks for "mempalace init" and "mempalace.yaml" in the content. It would also be worth asserting "mempalace init --yes" specifically (so a future edit that removes --yes from mine.md would fail). Not a blocker, just a tighter assertion.

LGTM. We hit variant 2 of this in our own setup early on — had to trace the EOFError back to the --yes gap manually. Having it documented in the skill instructions will save everyone that debugging cycle.

MemPalace-AGI integration — 208 discoveries, 120 tests | dashboard

Thanks @web3guru888 — good catch on the assertion. Just pushed a follow-up commit tightening test_mine_instructions_mention_init_prerequisite to assert "mempalace init --yes" specifically instead of just "mempalace init". That way a future edit dropping --yes from mine.md would fail the test.

Note: #562 also fixes the SKILL.md (mempalace status instead of --version) and the init instructions (--yes flag). We skipped adding --version to the CLI since mempalace status already serves as the health check.

Thanks for flagging the overlap with #562.

Looking at the diff, there are a couple of differences in approach:

1. --version: feat: batch writes, concurrent mining, MCP tools, hooks, export, search improvements #562 works around the missing flag by changing SKILL.md to use mempalace status. Our PR adds the actual --version flag to the CLI — --version is a standard convention that users and tools expect (pip --version, git --version, etc.), so having it exist is independently useful beyond just the SKILL.md prerequisite check.

2. init --yes explanation: feat: batch writes, concurrent mining, MCP tools, hooks, export, search improvements #562 changes the command but doesn't explain why --yes is needed. Our PR adds context about the EOFError so future editors of init.md understand the constraint and don't accidentally remove it.

3. mine prerequisite: feat: batch writes, concurrent mining, MCP tools, hooks, export, search improvements #562 doesn't address the missing init prerequisite in mine.md — agents following mine instructions still hit ERROR: No mempalace.yaml found with no guidance.

Happy to coordinate — if #562 lands first, I can rebase and keep just the parts that don't overlap (--version flag, mine.md Step 0, tests).

@adiKhan12 — the differentiation is well-argued. The three differences are real:

On --version: Agreed that adding the actual flag is independently correct. mempalace status works as a health check but --version is a separate expectation — most tooling (shell scripts, CI, dependency manifests) keys off --version not on status. The two serve different purposes. The #562 workaround solves the immediate SKILL.md problem; your approach also closes the UX gap for anyone else who reaches for --version instinctively.

On the mine Step 0: This is the one #562 is missing that matters most in agent contexts. An agent that follows mine.md without having run init will get a silent failure or cryptic error — the prerequisite note is necessary for robust agent automation, and it's not something #562 addressed.

On rebasing: The rebase-and-keep approach you described is the right path. If #562 merges first, a rebased version that trims to just (1) --version flag + its test and (2) the mine.md Step 0 addition would be a clean, non-conflicting follow-on. The init --yes context might also be worth keeping since neither PR currently has that explanation, depending on which init.md changes survive.

The tightened test assertion (asserting mempalace init --yes rather than just mempalace init) is exactly the right call — that's the kind of regression guard that pays off six months from now.

Nice addition! We incorporated this --version flag into our fork (jphein/mempalace@fe5cd56) and included it in PR #562 which bundles several community fixes. Thanks @adiKhan12!