Skip to content

Releases: AnjanJ/shipkit

Release list

v2.7.0 — One-command episodic memory setup

v2.7.0 — One-command episodic memory setup Latest
Latest

Choose a tag to compare

View all tags
@AnjanJ AnjanJ released this 07 Jul 18:39
v2.7.0
1505c45

Episodic memory, now one command. Setting up MemPalace so grandfather/eve can recall why past decisions were made used to mean hand-running four commands and hand-building a fiddly ~/.claude/projects/-Users-... transcript path. Now it's a single skill.

/shipkit:connect-memory

Run it and it:

  • detects what's already done and skips it (safe to re-run),
  • installs MemPalace if missing (uv/pipx),
  • registers it at user scope (so only the elder agents can reach it),
  • auto-derives your transcript directory — the step you used to get wrong,
  • splits concatenated transcripts, then backfills this project's history (dry-run first, then for real),
  • reminds you to restart Claude Code.

Once per machine to install/register, once per project to backfill.

/shipkit:connect-memory                 # set it up for this project
/shipkit:connect-memory --wing myapp    # override the wing name
/shipkit:connect-memory --reinstall     # force re-install on a broken setup

/shipkit:setup now points you to it as a next step, so you discover the option instead of digging through docs.

Still opt-in

MemPalace stays unbundled (a separate package + ~300 MB model). Skip it and the elders fall back to git history for decision questions — nothing breaks. This release only automates the setup the docs already described by hand.

Changelog: CHANGELOG.md

Assets 2
Loading

v2.6.0 — Spec-Driven Development

v2.6.0 — Spec-Driven Development

Choose a tag to compare

View all tags
@AnjanJ AnjanJ released this 07 Jul 18:21
v2.6.0
e8828fc

Spec-driven development comes to shipkit. The project knowledge layer now looks forward — specs and decision records become durable, verified .shipkit/ artifacts the elders read. This release folds in the 2.5.0 SDD core and the 2.6.0 completion work.

The three questions

On non-trivial work, two always-on rules put the spec-driven discipline in effect — what are we building (requirements in EARS) / how should it work (design as decision records) / how will we know it's done (acceptance criteria as tests, TDD/BDD-first).

Highlights

  • /shipkit:spec <feature> — guided interview through the three questions; writes .shipkit/specs/<feature>/{spec,design,tasks}.md with an approval gate on requirements and native Plan Mode before tasks.
  • /shipkit:decide — captures a project-wide decision as a five-part record (Context · Alternatives · Case-for · Case-against · Decision + a concrete falsifiability clause) in .shipkit/decisions/.
  • Falsifiability clauses make decisions queryable for staleness — ask grandfather "are any past decisions now falsified?" and it checks each clause's condition against current reality.
  • Elders read .shipkit/ — grandfather/eve treat specs and decision records as first-class sources (verified records beat git log/recall for "why"); eve sees open specs across the portfolio.
  • Spec-drift freshness hook — nudges once per accepted spec whose code has moved past it.
  • Narrated capability playbooks — the User Guide now walks you through a new (greenfield) repo, a legacy/inherited repo, and using the elders, step by step.

Also

  • Registry Active Specs column so eve answers "which projects have an open spec?" from the registry alone.
  • /unsetup explicitly never deletes .shipkit/ — your specs and decisions are project work product.
  • Docs: a "How Shipkit Works" section clarifying what fires automatically vs. what you invoke.

Full changelog: CHANGELOG.md · Design: docs/design/spec-driven-development.md

Loading