Storybloq - Project Context & Session Management

storybloq tracks tickets, issues, roadmap, and handovers in a .story/ directory so every AI coding session builds on the last instead of starting from zero.

Invocation differs by client: use /story in Claude Code, $story in Codex, or ask naturally to use the Storybloq skill.

Step 0.5: Active session guard (runs BEFORE argument routing)

This guard runs on EVERY /story invocation regardless of subcommand (/story, /story auto, /story review, /story plan, /story guided, /story handover, /story snapshot, /story export, /story design, /story review-lenses, /story settings, /story help, /story status, etc.). It MUST complete before ANY other action in this invocation.

Guard prelude: force-surface deferred MCP tools. Before running step 1 of this guard, make a single ToolSearch call with query: "storybloq" (max_results: 20). On Claude Code desktop/web, storybloq_* tool schemas are deferred — without this prelude the subsequent storybloq_status call in step 1 is not dispatchable. The prelude is explicitly part of the guard, not a separate pre-guard step; it satisfies the whitelist below.

• If ToolSearch itself is not available or returns an error on this harness, SKIP the prelude and continue to step 1. Do NOT treat a missing ToolSearch tool as evidence that MCP is unavailable — step 1's storybloq_status call will either succeed (MCP already surfaced) or its failure will route the skill to the Step 0 setup/CLI-fallback path below.
• The prelude is idempotent: on terminal CLI sessions where storybloq_* tools are already in the base list, it simply returns the same tool set.

Whitelist semantics (not blacklist). While the guard is unresolved, the ONLY actions permitted are: (a) the guard's ToolSearch prelude described above, (b) the guard's own storybloq_status call as defined in step 1 below, (c) reading the surfaced session metadata, and (d) the guard's AskUserQuestion flow. NO other MCP call, file write, file read, or skill-file dispatch is permitted -- this includes storybloq_handover_create, storybloq_snapshot, storybloq_export, storybloq_ticket_create, storybloq_ticket_update, storybloq_issue_*, storybloq_note_*, storybloq_autonomous_guide with any action other than the user-authorized resume / cancel, and any read or write inside .story/sessions/<active-sessionId>/. Subcommand-specific dispatch (to autonomous-mode.md, design/design.md, review-lenses/review-lenses.md, setup-flow.md, reference.md, etc.) is also blocked. The guard is a hard gate, not a soft warning.

1. Call storybloq_status once. If the output contains a ## Active Sessions heading, OR any subsequent guide call in this invocation fails with an "existing session" / "resumable session" error, you must STOP and surface the situation to the user:

   • Extract for each surfaced session: the full sessionId (required for every guide call), plus state, mode, and ticket (if any). Derive the displayed token <T> from the full sessionId per the Step 3 definition. If storybloq_status exposes only a truncated/rendered ID and no way to recover the full sessionId for a surfaced session (and the guide-error fallback in Step 3 also does not name a full sessionId), STOP. Do NOT offer Resume or Cancel. Tell the user: "A session appears to be active but its full sessionId cannot be recovered from the skill's tools. Please inspect .story/sessions/ or run storybloq session list before retrying."
   • Render one Active Autonomous Session block per session (format defined in Step 3).
   • End with the session-aware AskUserQuestion defined in Step 3.
   • Until the user chooses, no other action is permitted (see whitelist semantics above).
   • Do NOT write any file under .story/sessions/<active-sessionId>/. That directory is owned by the running instance and any cross-instance write races with the owner.

2. If there are no active sessions AND no subsequent "existing/resumable session" errors from any MCP call in this invocation, proceed to the "How to Handle Arguments" routing table and the rest of the normal flow. Reuse the storybloq_status response from this step when Step 2 asks for it; do NOT call storybloq_status again in the same invocation except in the Step 3 guide-error augmentation path explicitly described there.

3. Re-trigger rule for start. Any later storybloq_autonomous_guide call with action: "start" in the SAME /story invocation MUST re-run Step 0.5 from the top first, regardless of any prior user choices in this invocation. The guard's prior resolution authorizes only the specific Resume/Cancel/Other branch chosen at that moment; it never authorizes starting a new autonomous session later.

This guard has precedence over every "do not ask the user" rule elsewhere in this skill file and in autonomous-mode.md. Foreign-session resume or cancel ALWAYS requires explicit user confirmation through AskUserQuestion.

How to Handle Arguments

/story is one smart command. Parse the user's intent from context:

• /story -> full context load (default, see Step 2 below)
• /story auto -> start autonomous mode (read autonomous-mode.md in the same directory as this skill file; if not found, tell user to run storybloq setup --client all)
• /story auto T-183 T-184 ISS-077 -> start targeted autonomous mode with ONLY those items in order (read autonomous-mode.md; pass the IDs as targetWork array in the start call)
• /story review T-XXX -> start review mode for a ticket (read autonomous-mode.md in the same directory as this skill file; if not found, tell user to run storybloq setup --client all)
• /story plan T-XXX -> start plan mode for a ticket (read autonomous-mode.md in the same directory as this skill file; if not found, tell user to run storybloq setup --client all)
• /story handover -> draft a session handover. Summarize the session's work, then call storybloq_handover_create with the drafted content and a descriptive slug
• /story snapshot -> save project state (call storybloq_snapshot MCP tool)
• /story export -> export project for sharing. Ask the user whether to export the current phase or the full project, then call storybloq_export with either phase or all set
• /story status -> quick status check (call storybloq_status MCP tool)
• /story settings -> manage project settings (see Settings section below)
• /story design -> evaluate frontend design (read design/design.md in the same directory as this skill file; if not found, tell user to run storybloq setup --client all)
• /story design <platform> -> evaluate for specific platform: web, ios, macos, android (read design/design.md in the same directory as this skill file)
• /story review-lenses -> run multi-lens review on current diff (read review-lenses/review-lenses.md in the same directory as this skill file; if not found, tell user to run storybloq setup --client all). Note: the autonomous guide invokes lenses automatically when reviewBackends includes "lenses" -- this command is for manual/debug use.
• /story federation -> set up multi-repo orchestrator (read federation-setup.md in the same directory as this skill file; if not found, tell user to run storybloq setup --client all)
• /story help -> show all capabilities (read reference.md in the same directory as this skill file; if not found, tell user to run storybloq setup --client all)

If the user's intent doesn't match any of these, use the full context load.

Step 0: Check Setup

Check if the storybloq MCP tools are available.

Deferred tools note (Claude Code app). Claude Code desktop/web may register MCP tools at session start but defer exposing their full schemas to your tool list until you explicitly request them. A naive "look for storybloq_status in available tools" check fails on a cold s