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.
SDTK-WIKI
Your project's memory layer — the docs, decisions, and knowledge of one product, indexed for agents
SDTK-WIKI is the project memory layer of the SDTK lifecycle: it indexes your repo's own docs in place into a local knowledge graph (atlas), serves a docs + graph viewer, and answers deterministic grounded search/query over the full corpus — no cloud, no LLM in the CLI. (Looking for a personal, cross-project second brain? That job moved to the standalone SDTK-BRAIN tool.)
Public packageProject memory layerCanonical wiki/No cloud state
sdtk-wiki — atlas + kanban
> 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
- While you work
Every doc you write, every decision you log, every spec the suite produces gets ingested into the wiki + graph.
sdtk-wiki init --no-open # index your project docs into the atlas graph - Two weeks later
You sit back down. Open the project. Forgot what 'order-tracking-v2' was about.
sdtk-wiki query "order tracking v2 acceptance" - 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 - 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.
Beginner-friendly workflow
The intended flow is init (builds the atlas graph over your project docs), then query/search/ask over the full corpus — with the docs + graph viewer one command away. The old ingest/compile pipeline is deprecated in favor of the standalone SDTK-BRAIN tool.
Quality loop + multi-workspace viewer
Report-first linting (orphans, broken links, stale claims, contradictions) keeps the memory honest, and the viewer's multi-workspace switcher (atlas build --workspace name=path) can show your project wiki and a standalone SDTK-BRAIN vault side by side.
Design Prototype tab
The wiki viewer ships a 4th Design tab alongside Dashboard, Docs, and Graph. Open it to browse style presets, prompt the sdtk-design pipeline, watch it stream live, and annotate prototype elements — all in the viewer. The resulting DESIGN_FEEDBACK file lands in docs/design/feedback/, same as the standalone Preview Studio. Requires sdtk-design-kit installed.
Current command and workflow surface
Beginner workflow
sdtk-wiki init --no-open
sdtk-wiki search "multi-agent"
sdtk-wiki ask --question "how does X work?"
sdtk-wiki lint
sdtk-wiki atlas open
Knowledge operations
sdtk-wiki lint
sdtk-wiki discover --plan
sdtk-wiki enrich --source github --mode review
sdtk-wiki search "agent framework"
Viewer
sdtk-wiki atlas build # index docs into the viewer graph
sdtk-wiki atlas open # open viewer: Dashboard / Docs / Graph / Design tabs
sdtk-design open # open viewer directly at Design tab (requires sdtk-design)
Storage contract
Project docs are indexed in place; .sdtk/wiki holds the graph/machine state
.sdtk/wiki is internal state, reports, provenance, and graph data
.sdtk/atlas remains only the legacy SPEC Atlas compatibility path
Runtime support
| Runtime | Project | User | Notes |
|---|---|---|---|
| CLI | Yes | Package install | Runs locally inside the target project and writes project-local wiki output and .sdtk/wiki state. |
| Claude | Yes | Guide-aware | Generated AGENTS.md and CLAUDE.md are intended to help agent sessions read the local wiki contract before working. |
| Codex | Yes | Guide-aware | Generated AGENTS.md anchors Codex sessions to the project memory layer and safety rules. |
Validated truth
- The product boundary is independent from SDTK-SPEC; SDTK-WIKI owns the project wiki, graph, lint, and grounded query. The personal second-brain pipeline (ingest/compile/enrich/discover) is deprecated here — it moved to the standalone SDTK-BRAIN tool.
- 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, search/query/ask, lint, and maintain the project memory layer.
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.
- Orchuses
- PMuses
- BAuses
- ARCHuses
- DEVuses
- 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 ->DesignSDTK-DESIGN
Use SDTK-DESIGN to turn requirements and project context into reviewable screen briefs, prototypes, and design handoff evidence.
Open page ->ImplementationSDTK-CODE
Use SDTK-CODE after handoff when implementation, debugging, verification, and ship readiness become active.
Open page ->OperationsSDTK-OPS
Use SDTK-OPS when deployment, CI/CD, monitoring, incidents, and operational verification become active.
Open page ->