SDTK

SDTK-WIKI

Build a local second brain your AI can actually read

SDTK-WIKI is the public local second-brain product in the suite. It turns Markdown-heavy project knowledge into a canonical wiki folder, internal graph state, semantic extraction reports, source-quality checks, and deterministic local query without turning the workflow into a cloud service.

Public packageLocal second brainCanonical wiki/No cloud state

> YOUR PROJECT REMEMBERS ITSELF

The reason next weekend doesn't start from zero.

Every other AI dev tool forgets your project the moment you close the tab. SDTK-WIKI is the local memory layer that runs underneath the whole suite — so your AI starts each session already knowing what was decided, what is half-built, and what is shipped. This is the single feature that turns nights and weekends into compounding progress instead of a series of restarts.

Without a memory layer

  • You spend the first 30-45 min re-reading your own code
  • You forget which trade-offs you already rejected
  • Your AI re-asks questions you answered last week
  • Decisions live in chat history that already expired

With SDTK-WIKI

  • Sit down, run a query, get the relevant context in seconds
  • Decisions stay in the wiki, indexed and queryable
  • AI sessions start with grounded context from your repo
  • Knowledge graph survives every chat window closing
  1. While you work

    Every doc you write, every decision you log, every spec the suite produces gets ingested into the wiki + graph.

    sdtk-wiki ingest ./docs ./governance
  2. Two weeks later

    You sit back down. Open the project. Forgot what 'order-tracking-v2' was about.

    sdtk-wiki query "order tracking v2 acceptance"
  3. In seconds

    Wiki returns the relevant BA spec, the design decisions, the open tasks, and what was already shipped.

    → BA_SPEC + ARCH_DESIGN + REVIEW_PACKET + open backlog
  4. Before you write more code

    Your AI now starts the session knowing the context, not asking you to re-explain it.

    No 45-minute re-orientation. Straight to the next decision.

When a solo founder reaches for this

Next Friday night. Two weeks since you touched this project. Normally you'd spend 45 minutes re-reading your own code and decisions. Instead: open the repo, sdtk-wiki query 'where did I leave order tracking', read the indexed BA spec + open backlog + last review packet, and start the next decision within 5 minutes. This is what 'progress compounds' actually means.

Product truth

What this toolkit does today

These cards summarize the current shipped or internal surface exactly as it exists in the local source tree.

Canonical project wiki

New builds write human-facing knowledge into <project>/wiki while .sdtk/wiki remains internal state for reports, graph data, raw registry, provenance, and maintenance evidence.

Beginner-friendly workflow

The intended flow is init, ingest, compile --mode safe --apply, then query. Advanced wiki commands remain available for diagnostics, but the public product path stays simple.

Second-brain quality loop

SDTK-WIKI adds source-quality linting, local query/search, discover planning, enrichment review, and safe maintenance planning so the wiki can grow without silent destructive mutation.

Current command and workflow surface

Beginner workflow

sdtk-wiki init --no-open
sdtk-wiki ingest .\source-md
sdtk-wiki compile --mode safe --apply
sdtk-wiki query "multi-agent"
sdtk-wiki maintain --mode safe

Knowledge operations

sdtk-wiki lint
sdtk-wiki discover --plan
sdtk-wiki enrich --source github --mode review
sdtk-wiki search "agent framework"

Storage contract

<project>/wiki is the canonical generated second brain
.sdtk/wiki is internal state, reports, provenance, and graph data
.sdtk/atlas remains only the legacy SPEC Atlas compatibility path

Runtime support

RuntimeProjectUserNotes
CLIYesPackage installRuns locally inside the target project and writes project-local wiki output and .sdtk/wiki state.
ClaudeYesGuide-awareGenerated AGENTS.md and CLAUDE.md are intended to help agent sessions read the local wiki contract before working.
CodexYesGuide-awareGenerated AGENTS.md can anchor Codex sessions to the project-local second-brain and safety rules.

Validated truth

  • The product boundary is independent from SDTK-SPEC; SDTK-WIKI owns local wiki, graph, second-brain, extraction, lint, and query work.
  • The canonical human-facing output is <project>/wiki; .sdtk/wiki is internal state.
  • The beginner command flow avoids timestamped report variables and favors simple facade commands.
  • Search/query are local and read-only; destructive cleanup remains report-first unless a future safety design explicitly enables more.

Boundaries and honest limits

  • SDTK-WIKI does not replace SDTK-SPEC for formal SDLC governance, PM/BA/ARCH/DEV/QA traceability, or release gates.
  • SDTK-WIKI does not restore the retired SPEC Atlas Ask capability.
  • Web discover/fetch is not enabled by default; discover remains plan-first unless explicitly expanded in a later release.
  • Ask/RAG should not be marketed as production-grade until wiki.ask runtime and entitlement preconditions are present.
  • Cleanup/prune must remain safe/report-first unless a later safety gate explicitly permits mutation.

Source-of-truth docs

Canonical usage guide

products/sdtk-wiki/governance/SDTK_WIKI_USAGE_GUIDE.md

Install, initialize, ingest, compile, query, lint, and maintain a project-local second brain.

Package README

products/sdtk-wiki/distribution/sdtk-wiki-kit/README.md

npm-facing package truth for sdtk-wiki-kit and the current public command surface.

Internal state

.sdtk/wiki

Project-local reports, provenance, raw registry, graph output, and maintenance evidence.

Position in the SDTK control plane

Where SDTK-WIKI sits in the chain

SDTK-WIKI is the memory layer that wraps every owner. It is the only product that reads across all packs so context, decisions, and lookups survive between work sessions.

  1. Orchuses
  2. PMuses
  3. BAuses
  4. ARCHuses
  5. DEVuses
  6. QAuses

Highlighted owners actively use SDTK-WIKI as their execution pack.

Family links

Move across the SDTK suite without losing context

These product pages map the current suite boundaries so users can move from specification to coding to operations deliberately.

Governance

SDTK-SPEC

Use SDTK-SPEC for formal requirements, architecture, traceability, and downstream handoffs.

Open page ->Design

SDTK-DESIGN

Use SDTK-DESIGN to turn requirements and project context into reviewable screen briefs, prototypes, and design handoff evidence.

Open page ->Implementation

SDTK-CODE

Use SDTK-CODE after handoff when implementation, debugging, verification, and ship readiness become active.

Open page ->Operations

SDTK-OPS

Use SDTK-OPS when deployment, CI/CD, monitoring, incidents, and operational verification become active.

Open page ->