Skip to content
Back to skills

Task Store Designer

ASecurity

Design the task store for a long-running MCP tool: state shape, ttl, durability, cancellation, crash recovery. Use when you need help with task store designer.

  • 8 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 8, 2026
businesssql

Works with

  • terminal
  • cli
  • mcp

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add anubhavg-icpl/vibe --skill task-store-designer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Task Store Designer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Task Store Designer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/anubhavg-icpl-task-store-designer/badge)](https://www.skillsdirectory.com/skills/anubhavg-icpl-task-store-designer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: task-store-designer
description: Design the task store for a long-running MCP tool: state shape, ttl, durability, cancellation, crash recovery. Use when you need help with task store designer.
license: CC-BY-NC-SA-4.0
phase: 13
lesson: 13
metadata:
  version: 1.0.0
  tags: [mcp, tasks, durable-store, long-running, sep-1686]
---

Given a long-running tool (research, build, export, report generation), design the task store that backs SEP-1686 task augmentation.

Produce:

1. State shape. Minimum fields: `id`, `state`, `progress`, `result`, `error`, `ttl`, `created_at`. Optional: `request_meta`, `parent_task_id` (for future subtasks).
2. Durability choice. Filesystem for toy; SQLite for single-process; Redis for multi-replica. Justify.
3. taskSupport flag. `forbidden`, `optional`, or `required` per tool; one-line justification.
4. Cancellation plan. How the worker checks a cancel signal; what happens on partial progress.
5. Crash recovery. Boot-time reload rule; what `CRASH_RECOVERY` failures look like to the client.

Hard rejects:
- Any store that loses completed results within ttl.
- Any task state without explicit terminal states (`completed`, `failed`, `cancelled`).
- Any cancellation that is not idempotent.

Refusal rules:
- If the tool runs under 5 seconds, refuse to promote to a task. Synchronous is simpler.
- If the task would generate more than 10 MB of result, refuse and recommend streaming content blocks.
- If the server does not have a process capable of persisting state (stateless edge function), refuse and recommend moving to a durable runtime.

Output: a one-page store design with state shape, durability choice, taskSupport flag, cancellation plan, and crash-recovery rule. End with one-line advice on whether SEP-1686 subtasks will affect this design when they ship.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…