Frequently asked questions.

Storybloq makes autonomous software work recoverable, inspectable, and provable. It gives Claude Code and Codex durable project state, live visibility, and independent plan and code review through files stored inside the repo.

No. Storybloq does not certify that generated code is correct. It preserves the evidence behind the work: plans, review verdicts, findings, handovers, and git-tracked project state. Tests, CI, and release gates remain authoritative.

No. Storybloq sits on top of Claude Code or Codex. You keep using your client exactly as you do now. Storybloq adds structured project state and a visual dashboard so your sessions build on each other instead of starting from scratch.

Run npm install -g @storybloq/storybloq@latest, then storybloq setup --client all. That installs the CLI, registers the MCP server with Claude Code and Codex, and sets up the Storybloq skill. To upgrade later, re-run the same two commands. @latest pulls the newest version and setup re-syncs the skill files and hook entries. The Mac app is a separate App Store download.

Inside your project in a .story/ directory. Local files tracked by git. No server, no cloud storage, no account required. You can read, edit, and version everything yourself.

A session handover is a written record of what happened during an AI coding session: what was built, what decisions were made, why those decisions were made, what is still open, and what should happen next. Git shows what changed. Handovers explain why.

Type /story in Claude Code, or invoke the Storybloq skill as $story in Codex. It loads the current project state: tickets, issues, recent handovers, and lessons learned. Your AI client knows what was built, what is blocked, and what to work on next. No guesswork.

Yes. The CLI and /story session prime are useful on their own. The Mac app adds a visual layer: a kanban board, handover viewer, and real-time project status.

Yes. The same durable state, visibility, and review loop work for collaborative sessions. Autonomous mode adds hands-off execution when the scope is well-defined.

Autonomous mode lets a supported AI client work through a backlog of tickets on its own: picking work, planning, reviewing the plan, implementing, reviewing the code, committing, and moving to the next ticket. Progress is recorded so the run can survive context compaction and resume from durable project state.

Both support /story-style context loading ($story in Codex), autonomous mode, MCP, and hooks. Codex can orchestrate when exact callable subagent tools are available. Codex Desktop can open or relay a response to an owning task; Codex CLI gives a safe manual-switch fallback. The Claude Agent View-backed storybloq dispatch command does not yet have a product-managed Codex backend.

Storybloq has first-class setup for Claude Code and Codex. The .story/ directory is a standard file convention that any tool can read; other MCP-capable clients can still use the files and server, but the polished skill and hook flows are maintained for Claude Code and Codex first.

Spec-kit and Storybloq solve different problems in the same camp. Spec-kit is spec-driven: each new feature gets a templated specs/ folder with structured requirements, plan, and tasks, and a /speckit.implement command that executes them. Storybloq is state-driven: project-wide tickets, issues, handovers, lessons, and session-to-session continuity that survive across many features. They stack naturally. Use spec-kit for spec-to-code on a new feature; use Storybloq for session continuity across the project lifecycle. Same camp (repo-native operational systems), different layers.

Yes, and it is the recommended setup if you already use spec-kit. Spec-kit handles the per-feature delivery pipeline (constitution, specify, plan, tasks, implement). Storybloq tracks the project state that survives across features: which features are in progress, what handovers exist between sessions, what lessons the project has learned. A deeper integration is scoped (read spec-kit's tasks.md as Storybloq tickets, route /speckit.implement through Storybloq's autonomous mode). Until that ships, you can use both products manually with no conflict: spec-kit's artifacts live under specs/, Storybloq's live under .story/.

No. Storybloq is state-driven. We track what is happening in the project (tickets, issues, handovers, lessons, session continuity), not what should be built (specs). If you want a spec-driven framework, GitHub's spec-kit is the most mature option in that category. The two are complementary, not substitutes.

Yes. Put a single .story/ at a wrapper directory above your sub-repos, leave each sub-repo to its own git history, and Storybloq walks up the directory tree to find the shared .story/ from any sub-repo session. Tickets, issues, handovers, and lessons are visible everywhere; commits go to each sub-repo's own remote. See the multi-repo pattern guide at /multi-repo for the full setup.

No. Storybloq works with your existing setup. Claude Code or Codex in your terminal, your editor, your workflow. Nothing changes except that your project now has structured memory.

Yes. The CLI and Mac app are both free.

All project data stays local. The Mac app includes optional anonymous analytics and crash reporting (via Sentry and TelemetryDeck, both EU-hosted), off by default. You can opt in on first launch or in Settings. No project content is ever sent anywhere.