From docstore-superpowers
Use when any superpowers skill is about to persist a spec or plan document to a git file — e.g. brainstorming/writing-plans saying "save to docs/superpowers/… and commit to git". Also when bootstrapping where a codebase's planning docs live, or asked where a prior spec/plan went.
How this skill is triggered — by the user, by Claude, or both
Slash command
/docstore-superpowers:superpowers-docs-to-docstoreThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Superpowers skills default to writing planning documents (specs and plans) into git files under `docs/superpowers/…` and committing them. **In this org, those documents live in the DocStore MCP instead — never in git.**
Superpowers skills default to writing planning documents (specs and plans) into git files under docs/superpowers/… and committing them. In this org, those documents live in the DocStore MCP instead — never in git.
DocStore is the single source of truth: it persists across sessions and agents, is searchable, tagged, and versioned. A git file is exactly what this skill replaces. This is not a "store a copy too" rule — it is a redirect.
This skill is the user-preference tier (anchored in CLAUDE.md), which sits above superpowers skills in priority. Both brainstorming and writing-plans explicitly say "User preferences for [spec/plan] location override this default." This skill is that preference. When a skill's checklist says "write to docs/superpowers/… and commit to git," that step is the thing being overridden — you do the DocStore procedure below instead.
Whenever a superpowers skill reaches a doc-persistence step, map it:
| Source step | Document | Type tag |
|---|---|---|
brainstorming "Write the design doc … and commit to git" | design spec | spec |
writing-plans "Save plan to docs/superpowers/plans/…" | implementation plan | plan |
If a superpowers skill produced it as a document, it goes to DocStore — regardless of whether it "feels like a deliverable."
1. Resolve the project name (deterministic — no guessing). Project name = the git repo's basename:
basename "$(git rev-parse --show-toplevel)" # e.g. → aihub
Use that exact string. Never the full module path, the directory you happen to be in, or a date-stamped variant.
2. Ensure the project exists (org-visible).
list_projects (and search_documents for the topic). If a project with that exact name exists, reuse it. If not:
create_project(name: "<repo-basename>", visibility: "org", description: "Superpowers planning documents (spec, plan) for the <repo> codebase.")
Org visibility so the team and other agents discover it. Never private.
3. Create the document.
create_document(project_id, title, overview, body, tags):
Design: <topic> (spec), Plan: <feature> (plan).{spec, plan}, always superpowers, and one status tag (default status:not-started — see Document Status). e.g. ["spec", "superpowers", "status:not-started"]. Use the exact vocabulary — spec, not design/design-spec.Before creating, search_documents(query: <topic>, tags: [<type>, "superpowers"]) to avoid duplicating an existing doc.
4. Hand off for review via a temporary file. DocStore content isn't browsable in the editor, so download a read-only copy for the user to open:
get_document to fetch the body./tmp/docstore-<repo>-<type>-<topic-slug>.md.Example:
"Spec ready for review — opened a local copy at docstore-aihub-spec-rate-limit-headers.md. Source of truth: DocStore project aihub, doc id
<id>, tagsspec+superpowers+status:not-started. Tell me any changes and I'll update the DocStore doc."
5. Read and edit existing docs efficiently.
get_section to pull a single heading's content instead of get_document when you only need part of the doc. Scan list_documents overviews first.edit_document: mode=section to replace one heading, mode=replace for overview/body/tags. Pass base_version (the version you last read); a stale value is rejected so you re-read and retry. Use append_document to add to the end (no base_version, never clobbers). delete_section removes a heading.diff_versions to compare two versions; list_snapshots/get_snapshot to inspect history; restore_snapshot to roll back.Track each doc's lifecycle with a status tag alongside the type + superpowers tags. Closed vocabulary, exactly one per doc:
| Status tag | Meaning | Set when |
|---|---|---|
status:not-started | Authored; the work it governs hasn't begun | On creation (default) |
status:in-progress | The work it governs is underway | Execution begins (executing-plans / subagent-driven-development picks up the plan) |
status:completed | The work it governs is done and verified | After verification passes |
Change status with edit_document (mode=replace tags), keeping the type and superpowers tags — swap only the status: tag. Report the new status to the user when you change it.
docs/superpowers/…, do not git add/git commit it.docs/ does not satisfy the preference. Create the DocStore document. (The /tmp review copy is a throwaway view, not storage.)| Rationalization | Reality |
|---|---|
| "The skill's git step is the active instruction; the preference is just a soft 'prefer'." | This skill IS the user preference, and brainstorming/writing-plans explicitly defer to it. The git step is what's being overridden. |
| "I'll commit to git too, just to be safe / so it's in the PR." | Dual-write is a failure. DocStore is the single source of truth. Do not commit. |
| "A spec is a deliverable, not a planning doc, so the rule doesn't apply." | Specs and plans ARE superpowers documents. If a superpowers skill produced it, it goes to DocStore. |
"The file lives under docs/, so it's satisfied closely enough." | A git file is exactly what's being replaced. Create the DocStore document. |
"The skill scripts the final 'committed to <path>' line, so I'll say that." | Replace that line. Point to the DocStore project + tags + doc id (plus the /tmp review copy), never a committed filesystem path. |
| "I'll name the project whatever fits the topic." | Project name = repo basename, exactly. Wrong names create duplicate projects. |
git add/git commit a doc under docs/superpowers/ → STOP, use DocStore.docs/superpowers/specs|plans/ for storage → STOP (the only file you write is the throwaway /tmp review copy).docs/…" → STOP, give the DocStore location + /tmp link.basename of the repo root.{spec, plan} + superpowers + one status: tag → STOP, fix the tags.list_projects/search_documents first; name = repo basename, exactly.private instead of org — the team and other agents won't discover it.superpowers, and one status: tag.get_section.overview — overview is the abstract; the full content goes in body.Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.
npx claudepluginhub fishwaldo/skills --plugin docstore-superpowers