English | 한국어
- Why
- Install
- Usage
- Skills
- Wiki Structure
- Separation of Concerns
- Design Principles
- Contributing
- License
A lightweight agent skill tool for managing planning, design, and development documents in a shared wiki repository. Multiple repos share the same wiki via symlinks, and each repo's agent only sees the documents it needs. It also provides workflows for PRD creation, functional spec management, ERD design, and work tracking. The workflows reflect the author's personal approach, so they're designed to be easy to supplement with other skills or replace with your own.
After agent skills emerged, various harnesses appeared to help build better products. Tools for creating PRDs, design assistants, full-lifecycle coverage from planning to deployment. But the main friction I kept running into was managing documents scattered across multiple repos. I mostly work in environments where repositories are split across teams, and I wanted a structure where collaborators and agents in different repos could all look at the same knowledge base.
Over several months of building and refining, I focused on simplicity and flexibility so that anyone can use it. That's dot-wiki.
What I wanted:
- Keep PRDs and design docs in one place, accessible from any repo as they grow
- Don't lock down the document structure. Provide a default guideline, let users customize
- Let users choose any tool to create documents. Switch workflows freely
To solve these three problems, I built dot-wiki. It uses an independent Git repo as a wiki, connected from each project via .wiki symlink. The wiki only stores documents. What to see is managed in each project's AGENTS.md.
~/Workspace/
├── my-app/
│ ├── .wiki → ../shared-wiki symlink
│ └── AGENTS.md ## Wiki Focus (docs for this repo)
├── my-api/
│ ├── .wiki → ../shared-wiki symlink
│ └── AGENTS.md ## Wiki Focus (docs for this repo)
└── shared-wiki/ independent Git repo
├── CONTRIBUTING.md
├── common/ shared docs (PRD, ERD, etc.)
└── projects/
├── my-app/ my-app specific docs
└── my-api/ my-api specific docs
# Full install
npx skills add dev-goraebap/dot-wiki --all -g
# Wiki infrastructure + feedback only
npx skills add dev-goraebap/dot-wiki --skill wiki-init --skill wiki-connect --skill wiki-focus --skill wiki-health --skill feedback -gEach skill can trigger automatically based on context, but we recommend invoking them explicitly with slash commands like /wiki-init. Explicit invocation gives you the right action at the right time.
Core of dot-wiki. Handles wiki creation, connection, focus management, and health checks.
Create a wiki — Run /wiki-init in your project. Creates the wiki repo, symlink, and sets up AGENTS.md with Wiki Focus. dot-wiki follows the AGENTS.md standard. Most agents (Codex, Copilot, Cursor, Windsurf, etc.) read it automatically. For agents that don't (Claude Code, Gemini CLI), bridge setup is guided during init.
| Agent | AGENTS.md | Bridge |
|---|---|---|
| Codex, Copilot, Cursor, Windsurf, Amp, Goose, Roo Code | Auto | — |
| Claude Code | Add @AGENTS.md to CLAUDE.md |
Guided by /wiki-init |
| Gemini CLI | Add to .gemini/settings.json |
Guided by /wiki-init |
| Cline | Symlink into .clinerules/ |
Guided by /wiki-init |
Connect another repo — Run /wiki-connect in another repo. Auto-detects existing wikis in the parent directory, or asks for the path.
Manage focus — /wiki-focus adds or removes documents from Wiki Focus. Each repo's AGENTS.md is independent, so different repos can focus on different documents from the same wiki.
## Wiki Focus
- .wiki/CONTRIBUTING.md
- .wiki/common/prd.md
- .wiki/projects/my-app/architecture.mdHealth check — /wiki-health validates the symlink, AGENTS.md, focus documents, and directory structure.
Optional document generation tools. Replaceable with any tool you prefer.
Capture ideas — /workflow-idea asks 3-5 key questions and generates a PRD and functional spec (domain-based tracking table) together. Each spec item includes a Work Items column that links to work-item files automatically.
Design ERD — /workflow-erd generates ERDs from the functional spec or PRD. Supports conceptual, logical, and physical levels in Mermaid format. A solid ERD design improves downstream UI design and API implementation quality.
Manage work — /workflow-next-plan is a work management hub built on the functional spec. It handles the full lifecycle: coverage dashboard, work-item creation, Git branch management, and linking completed work back to the spec.
Feature Coverage: 12 total
━━━━━━━━━━━━━━━━━━━━━━━━
done: 5 (42%)
partial: 2 (17%)
pending: 4 (33%)
deferred: 1 (8%)
Workflow: check coverage, create work-item, branch from develop/main, implement, merge with --no-ff, tag, link back to spec. One work-item can map to multiple feature IDs. Supports both develop-based (Git Flow) and main-based (GitHub Flow) branching.
Send feedback — Run /feedback to submit bug reports, feature requests, or questions to the dot-wiki GitHub repository. Collects type and description, auto-gathers environment info. Uses gh CLI if authenticated, otherwise opens a pre-filled URL in the browser.
The PRD skill is inspired by Ryan Carson's ai-dev-tasks (Three File System, Apache 2.0) approach, with prompts written from scratch for the wiki structure.
The workflow layer is not required. If you need more specific documents (ERD, API specs, sitemaps, design systems), use other skills or tools to create them and organize with the wiki layer. Any workflow can be swapped in.
| Skill | Command | Role | Layer |
|---|---|---|---|
wiki-init |
/wiki-init |
Create wiki + symlink + AGENTS.md setup | Wiki |
wiki-connect |
/wiki-connect |
Connect existing wiki + AGENTS.md setup | Wiki |
wiki-focus |
/wiki-focus |
Manage Wiki Focus in AGENTS.md | Wiki |
wiki-health |
/wiki-health |
Environment diagnostics | Wiki |
workflow-idea |
/workflow-idea |
PRD + functional spec generation | Workflow |
workflow-erd |
/workflow-erd |
ERD generation (conceptual/logical/physical) | Workflow |
workflow-next-plan |
/workflow-next-plan |
Work management hub (work-items + Git + spec linkage) | Workflow |
feedback |
/feedback |
Send feedback via GitHub Issue | Utility |
.wiki/
├── CONTRIBUTING.md structure guide (customizable)
├── common/ shared docs (PRD, ERD, functional spec)
└── projects/
├── my-app/
│ └── work-items/ work-item files (versioned)
└── my-api/
└── work-items/ work-item files (versioned)
dot-wiki clearly separates three concerns:
| Concern | Location | Description |
|---|---|---|
| Document storage | .wiki/ (wiki repo) |
Stores documents only. No state management |
| Focus (what to see) | Project AGENTS.md |
Per-repo, independent. Auto-read by agents |
| Operating rules | .wiki/CONTRIBUTING.md |
Commit rules, sync rules. Shared across all repos |
The CONTRIBUTING.md created during wiki init includes two rules:
Commit Rule — When wiki documents are modified, the agent asks whether to commit. Commits are made in the actual wiki repo (resolved via .wiki symlink), not the project repo.
Sync Rule — During development, if requirements change, new requirements emerge, scope shifts, or technical constraints make the original plan infeasible, the agent suggests updating the related wiki documents (PRD, functional spec, etc.).
These rules live in CONTRIBUTING.md, so they apply uniformly across all repos sharing the wiki.
- Designed for individuals or small teams. One person maintains one repo.
- No enforced structure. Provides
common/andprojects/as defaults. Edit.wiki/CONTRIBUTING.mdto customize freely. - No tool lock-in. The workflow layer is optional. Any tool's output can go into the wiki.
I want this simple tool to keep getting better. But working on it alone, I sometimes worry whether my perspective is too narrow, or whether it's even useful to anyone else. If you share a similar pain point, or if these skills help even a little, I'd really appreciate it if you'd share feature ideas or improvements via issues.
MIT