Generated banner for ThinkWiki
Generated logo for ThinkWiki

ThinkWiki

LLM wiki kit

First committed by wzdavid

Published in wzdavid/ThinkWiki. Publisher page

38 GitHub stars

What it is

Install once, talk to your agent. ThinkWiki turns documents and notes into a local Markdown wiki with inbox review, content knowledge graph, and browsable HTML workspace.
— the description by wzdavid

AutoGineer overview, from the brain’s own files

ThinkWiki is an agent-native skill designed to turn scattered information into a structured, durable local workspace. By integrating directly with skills-compatible AI agents, it allows users to manage their knowledge base through natural conversation rather than manual CLI commands. It supports a wide range of input formats, including PDFs, web pages, and various document types, organizing them into a system that features an inbox for review, a local viewer, and an interactive content knowledge graph. The system is built to be local-first, ensuring that Markdown files remain the source of truth, while providing HTML-based interfaces for visualizing relationships between topics, entities, and claims.

How it works

Memory model: LLM wiki

AutoGineer overview, from the brain’s own files

ThinkWiki functions as a skill installed into an AI agent's environment. It uses a set of Python scripts to manage a local directory of Markdown files. The system processes inputs through an inbox workflow, where content is reviewed before being ingested into the wiki. It generates a series of HTML outputs, including a workspace home, an inbox console, a page viewer, and a graph explorer. Users interact with these features by asking their agent to perform tasks like clipping content, building the knowledge graph, or serving the workspace via a local loopback server.

Folders
FolderRoleFiles
.githubagent-config1
docsdocs41
scriptsscripts34
templatestemplates13
teststests1

The agent reads

Requirements

Runtimes: Python

API keys (by name): THINKWIKI_EMBED_API_KEY, THINKWIKI_LLM_API_KEY

Set it up

  1. Clone the repository at the commit AutoGineer scanned:

    git clone https://github.com/wzdavid/ThinkWiki.git && cd ThinkWiki && git checkout 89f477d7a4095ba2ecf49ef9332e240c6f1208a1
  2. cd ThinkWiki && claude

  3. AutoGineer scanned these files at commit 89f477d.

  4. Not scanned by AutoGineerThe author’s README also describes installing it from a clone of its repository. Read its install section: AutoGineer did not scan that path. https://github.com/wzdavid/ThinkWiki/blob/89f477d7a4095ba2ecf49ef9332e240c6f1208a1/README.md#manual-install-optional
  5. First committed by wzdavid. Published in wzdavid/ThinkWiki. Licence: MIT License.

Usage

AutoGineer overview, from the brain’s own files

  • Initialize a new local wiki workspace
  • Clip web pages, files, or text into an inbox for later processing
  • Ingest reviewed items into the permanent wiki structure
  • Query the wiki for information with evidence-based responses
  • Generate and visualize a content knowledge graph
  • Serve the wiki workspace as a local HTML site for browser-based navigation
“Create a local knowledge base named Research Notes in my workspace.”
The agent initializes a new ThinkWiki workspace structure in the specified directory.
“Clip this article into the inbox: https://example.com/article”
The agent saves the content of the URL into the ThinkWiki inbox for later review.
“What did we already decide about context budgets?”
The agent searches the existing wiki pages and provides an answer supported by evidence from the knowledge base.
“Build the knowledge graph and open the workspace home in my browser.”
The agent generates the graph visualization and starts the local server to display the workspace in the browser.

Documentation by wzdavid

ThinkWiki

Image: Release Image: License Image: Python

ThinkWiki is an agent-native local knowledge base skill. Talk to your agent to turn scattered documents, web pages, notes, and conversations into a durable Markdown workspace — with inbox review, local browsing, and an interactive content knowledge graph you can open in a browser.

Chinese version: README.zh.md

Repository: https://github.com/wzdavid/ThinkWiki

Works With Skills-Compatible Agents

ThinkWiki follows the open Agent Skills format (SKILL.md + bundled scripts). If your agent can install skills and run local commands, it can run ThinkWiki.

You do not need to memorize CLI commands. Install the skill once, then create and manage your wiki entirely through conversation.

Agent / HostTypical use
Claude CodeInstall the repo as a skill, then ask it to build and query your wiki
OpenClawFull skill workflow; use serve + the built-in browser to open HTML outputs
TraeInstall under .trae/skills, then manage the wiki in chat
Hermes AgentLocal skill directory + shell execution
OpenAI Codex / Codex CLISkills-compatible coding agents with local file access
CursorAgent mode with project skills
Gemini CLISkills-compatible CLI agent
GitHub CopilotAgent / coding workflows in VS Code that support skills
Other skills hostsAny product that loads SKILL.md and can run python3 scripts/thinkwiki ... locally

Requirement: a local environment with Python 3. ThinkWiki bootstraps its own runtime on first use. Pure cloud chat without local file or shell access cannot run a local wiki.

Get Started: Install Through Conversation

Point your agent at this repository and ask it to install the skill for you.

Example prompt:

Please install the ThinkWiki skill from https://github.com/wzdavid/ThinkWiki , bootstrap the runtime, and run a health check to confirm everything works on my machine.

The agent will typically clone or copy the skill into your host's skills directory, run bootstrap, and verify capabilities with doctor. You should not need to run those steps yourself unless you prefer manual setup.

After installation, start using it immediately:

Create a local knowledge base named My Wiki in my workspace.

Clip this article into the inbox first: https://example.com/article

Import this PDF into the wiki: /path/to/file.pdf

Answer from my wiki: what did we already decide about context budgets?

Build the knowledge graph and open the workspace home in my browser.

The agent reads SKILL.md, maps your intent to stable ThinkWiki actions, and reports what changed — including paths to Markdown pages and HTML outputs.

Why ThinkWiki

  • Agent-first: users talk to an agent, not to a long list of commands.

  • Local-first: Markdown files remain the source of truth on your machine.

  • HTML-first: inbox, viewer, graph, and governance pages are real browsable workspaces.

  • Knowledge-first: the graph is a content knowledge graph — topics, concepts, entities, claims, and governance — not just a file-link map.

What It Produces

ThinkWiki generates a workspace that includes:

  • output/index.html: unified workspace home

  • output/inbox/index.html: inbox review console

  • output/viewer/index.html: local page browser

  • output/graph/index.html: interactive graph explorer

  • output/graph/report.html: graph governance report

  • output/graph/entity-merge-review.html: entity merge review page

  • output/graph/entity-merge-plan.html: entity merge dry-run preview when requested

Preview
Workspace Home (output/index.html)

The unified workspace home summarizes recent changes, recommended next actions, inbox backlog, and a graph snapshot so you can decide whether to read, ingest, or explore.

Image: ThinkWiki workspace home preview

Inbox Review (output/inbox/index.html)

Review clipped web pages, files, and notes before formal ingest. Items are grouped into ready, review, and weak so you can process the highest-value captures first.

Image: ThinkWiki inbox review preview

Local Viewer (output/viewer/index.html)

Browse the entire wiki by page type, confidence, and status. Open any page directly in the viewer without leaving the local HTML workspace.

Image: ThinkWiki local viewer preview

Knowledge Graph (output/graph/index.html)

Explore the content knowledge graph interactively. Switch between knowledge, document, and suggested views to inspect semantic relations and candidate edges.

Image: ThinkWiki knowledge graph preview

Graph Governance Report (output/graph/report.html)

Inspect graph health signals such as isolated pages, hub stubs, fragile bridges, suggested links, and entity merge candidates before making structural changes.

Image: ThinkWiki graph governance report preview

Everyday Commands (In Plain Language)

Once ThinkWiki is installed, these are the kinds of requests users make most often:

You sayThinkWiki does
Create a wiki called Research NotesInitializes a local workspace
Clip / save this URL or file to inboxCaptures content for later review
Ingest the ready inbox itemsPromotes reviewed captures into wiki pages
What does my wiki say about X?Evidence-first Q&A from existing pages
Save this answer as a query pagePersists high-value outputs
Show me the knowledge graphBuilds/refreshes graph HTML
Review entity merge candidatesSurfaces alias collisions for manual confirmation
Open the wiki workspace in my browserRuns serve and returns http://127.0.0.1:8765/index.html

Core Capabilities

  • Initialize a local wiki workspace

  • Clip web pages, files, or pasted text into an inbox for later review

  • Import Markdown, PDF, DOCX, XLSX, XLS, PPTX, web pages, and plain text

  • Answer questions from existing wiki pages with evidence-first behavior

  • Save high-value outputs as query, synthesis, decision, or concept pages

  • Build a content knowledge graph with knowledge, document, and suggested views

  • Generate entity governance outputs, including ambiguous alias review and deterministic merge flows

  • Check runtime health, workspace status, and graph governance state

Content Knowledge Graph

ThinkWiki v1.6.0 builds a schema v2 graph with default_view = knowledge.

The knowledge view can contain:

  • page-backed nodes such as source, topic, concept, decision, synthesis, query, and entity

  • claim nodes extracted from structured wiki content

  • semantic relations such as about, belongs_to, depends_on, asserts, supports, contradicts, and suggests_related_to

This means the graph is not limited to raw file references. It can represent knowledge structure, evidence structure, and entity governance directly.

Browse HTML Outputs

Agent chat UIs usually cannot render ThinkWiki HTML inline. Ask your agent to start the built-in loopback server when you want to inspect inbox, viewer, graph, or governance pages:

Start the ThinkWiki output server and give me the workspace URL.

Or run it yourself:

python3 scripts/thinkwiki serve --root /path/to/my-wiki

By default this serves <wiki-root>/output/ at http://127.0.0.1:8765/. Start from http://127.0.0.1:8765/index.html.

On OpenClaw, after serve is running, the agent can also open the workspace home with:

openclaw browser --browser-profile openclaw open http://127.0.0.1:8765/index.html

On other agents, open the same URL in your system browser, or use whatever browser tool the host provides.

Use serve --print-urls when you only need the URL list without starting the server.

Environment Variables

Remote AI features are disabled by default. Configure only what you need:

Content generation (crystallize, digest)

Requires all three variables. Any OpenAI-compatible chat completion endpoint works (MiniMax, OpenAI, DeepSeek, local Ollama, etc.).

VariableRequiredPurpose
THINKWIKI_LLM_API_KEYYes, to enableAPI key for the configured LLM provider
THINKWIKI_LLM_BASE_URLYes, to enableChat completions URL, e.g. https://api.openai.com/v1/chat/completions
THINKWIKI_LLM_MODELYes, to enableModel name, e.g. gpt-4o-mini or MiniMax-M3
THINKWIKI_LLM_TEMPERATURENoOptional temperature override

Without a complete LLM configuration, crystallize and digest use local heuristics only.

Entity embedding (entity-merge-review, graph-report, health)

Enabled when THINKWIKI_EMBED_API_KEY is set. Defaults to SiliconFlow BGE-M3; override the endpoint or model if needed.

VariableRequiredPurpose
THINKWIKI_EMBED_API_KEYYes, to enableAPI key for the embedding provider
THINKWIKI_EMBED_BASE_URLNoEmbedding URL(s), comma-separated; default https://api.siliconflow.cn/v1/embeddings
THINKWIKI_EMBED_MODELNoEmbedding model; default BAAI/bge-m3

Register a free SiliconFlow key at https://siliconflow.cn if you want the default embedding setup.

Manual Install (Optional)

If you prefer to set up the skill yourself instead of asking an agent:

git clone https://github.com/wzdavid/ThinkWiki ThinkWiki
cd ThinkWiki
python3 scripts/thinkwiki bootstrap
python3 scripts/thinkwiki doctor --repo-root .

Then install the folder into your agent's skills directory according to that host's documentation.

CLI Reference (For Agents And Power Users)

ThinkWiki keeps one stable entry point that agents call under the hood:

python3 scripts/thinkwiki <command> [args]

Common commands: init, clip, ingest, inbox, viewer, graph, graph-report, entity-merge-review, entity-merge-apply, serve, health, status, doctor.

See SKILL.md for the agent behavior contract and intent mapping.

Repository Docs

  • README.md: concise English project overview

  • README.zh.md: Chinese overview

  • SKILL.md: skill behavior contract for agent hosts

  • CHANGELOG.md: release history

License

MIT

scripts/build_demo_wiki.py

Shown as plain text.

#!/usr/bin/env python3
from __future__ import annotations

"""
ThinkWiki Script: build_demo_wiki

Purpose:
- Generate the demo wiki used for README screenshots and repository-facing examples.

Usage:
- Run directly when you need to refresh `docs/demo-wiki`.
- Run `python scripts/<script> --help` for direct CLI details when the file exposes its own arguments.
"""


import argparse
import json
import textwrap
from pathlib import Path


ROOT_FILES = {
    ".wiki-schema.md": "# marker\n",
    "index.md": "# ThinkWiki Demo Wiki\n",
    "overview.md": "# Overview\n\nThis demo wiki powers the README screenshots.\n",
    "purpose.md": "# Purpose\n\nShow real viewer and graph outputs for ThinkWiki.\n",
    "log.md": "# Log\n",
}

RAW_FILES = {
    "platform-spec": "# Platform Spec\n\nExecution specs coordinate people, tools, and context.\n",
    "eval-loops": "# Eval Loops\n\nEvaluation loops connect product metrics, prompts, and review workflows.\n",
    "review-checklist": "# Review Checklist\n\nHuman review keeps model behavior aligned with policy and delivery goals.\n",
}

INBOX_FILES = {
    "team-retrospective": "# Team Retrospective\n\nCollect this note in inbox first, then decide whether it should become a source page.\n",
}

INBOX_METADATA = {
    "2026-06-20-team-retrospective.json": {
        "kind": "web",
        "adapter": "wechat",
        "title": "Team Retrospective",
        "siteName": "ThinkWiki Channel",
        "author": "ThinkWiki Team",
        "publishDate": "2026-06-20 10:00:00",
        "url": "https://mp.weixin.qq.com/s/thinkwiki-demo",
        "captureMode": "wait",
        "captureState": "wait_completed",
        "captureReason": "ready",
        "reviewHint": "The capture looks complete enough for final review before formal ingest.",
        "captureAttempts": 2,
        "captureElapsedSeconds": 1.2,
        "mediaPolicy": "always",
        "mediaStatus": "localized",
        "mediaCount": 1,
        "localizedMediaCount": 1,
        "mediaDir": "normalized/assets/inbox/2026-06-20-team-retrospective",
        "normalizedPath": "normalized/inbox/2026-06-20-team-retrospective.md",
        "rawPath": "raw/inbox/2026-06-20-team-retrospective.md",
    },
}

WIKI_FILES = {
    "wiki/sources/platform-spec.md": """
    ---
    title: Platform Spec
    type: source
    created: 2026-06-19
    updated: 2026-06-19
    summary: A source page describing why execution specs and context must be treated as one delivery system.
    sources:
      - raw/articles/platform-spec.md
    tags:
      - source
      - platform
    confidence: extracted
    status: active
    ---

    # Platform Spec

    ## Summary

    Execution specs coordinate people, tools, and context into one delivery system instead of isolated prompts.

    ## Connections

    - [AI Native Team](../concepts/ai-native-team.md)
    - [Model Platform](../topics/model-platform.md)
    - [Execution Spec](../concepts/execution-spec.md)
    """,
    "wiki/sources/eval-loops.md": """
    ---
    title: Eval Loop Notes
    type: source
    created: 2026-06-19
    updated: 2026-06-19
    summary: Notes from an internal workshop on evaluation loops, review lanes, and release confidence.
    sources:
      - raw/articles/eval-loops.md
    tags:
      - source
      - eval
    confidence: extracted
    status: active
    ---

    # Eval Loop Notes

    ## Summary

    Evaluation loops turn prompts into an observable delivery system by connecting tests, feedback, and release gates.

    ## Connections

    - [Eval Loops](../topics/eval-loops.md)
    - [Context Budget](../decisions/context-budget.md)
    """,
    "wiki/sources/review-checklist.md": """
    ---
    title: Review Checklist
    type: source
    created: 2026-06-19
    updated: 2026-06-19
    summary: A source page explaining how human review, acceptance criteria, and escalation paths fit together.
    sources:
      - raw/articles/review-checklist.md
    tags:
      - source
      - review
    confidence: extracted
    status: active
    ---

    # Review Checklist

    ## Summary

    Human review closes the loop between generated output, execution policy, and customer-facing quality.

    ## Connections

    - [AI Native Team](../concepts/ai-native-team.md)
    - [Execution Policy](../decisions/execution-policy.md)
    """,
    "wiki/topics/model-platform.md": """
    ---
    title: Model Platform
    type: topic
    created: 2026-06-19
    updated: 2026-06-19
    summary: Topic page for reusable context, evaluation workflows, and internal tooling.
    sources:
      - wiki/sources/platform-spec.md
      - wiki/sources/eval-loops.md
    tags:
      - topic
      - platform
    confidence: mixed
    status: active
    ---

    # Model Platform

    ## Summary

    A model platform combines reusable prompts, context policies, evaluation loops, and internal tooling.

    ## Included Sources

    - [Platform Spec](../sources/platform-spec.md)
    - [Eval Loop Notes](../sources/eval-loops.md)
    - [Execution Spec](../concepts/execution-spec.md)
    """,
    "wiki/topics/eval-loops.md": """
    ---
    title: Eval Loops
    type: topic
    created: 2026-06-19
    updated: 2026-06-19
    summary: Topic page about review lanes, regression checks, and feedback loops for model releases.
    sources:
      - wiki/sources/eval-loops.md
      - wiki/sources/review-checklist.md
    tags:
      - topic
      - eval
    confidence: mixed
    status: active
    ---

    # Eval Loops

    ## Summary

    Eval loops connect prompts, acceptance criteria, automated checks, and human review before release.

    ## Included Sources

    - [Eval Loop Notes](../sources/eval-loops.md)
    - [Review Checklist](../sources/review-checklist.md)
    - [Context Budget](../decisions/context-budget.md)
    """,
    "wiki/concepts/ai-native-team.md": """
    ---
    title: AI Native Team
    type: concept
    created: 2026-06-19
    updated: 2026-06-19
    summary: A team model that treats models, context, and workflow as one operating system for delivery.
    sources:
      - wiki/sources/platform-spec.md
      - wiki/topics/model-platform.md
      - wiki/topics/eval-loops.md
    tags:
      - concept
      - team
    confidence: verified
    status: active
    ---

    # AI Native Team

    ## Summary

    AI native teams are organized around executable specs, reusable context, and human review loops rather than isolated tools.

    ## Details

    The operating model depends on model platform capabilities, review lanes, and explicit execution policy.

    ## Connections

    - [Model Platform](../topics/model-platform.md)
    - [Eval Loops](../topics/eval-loops.md)
    - [Execution Policy](../decisions/execution-policy.md)
    - [Execution Spec](../concepts/execution-spec.md)
    """,
    "wiki/concepts/execution-spec.md": """
    ---
    title: Execution Spec
    type: concept
    created: 2026-06-19
    updated: 2026-06-19
    summary: A reusable specification that binds task framing, context, policy, and review expectations together.
    sources:
      - wiki/sources/platform-spec.md
      - wiki/sources/review-checklist.md
    tags:
      - concept
      - spec
    confidence: verified
    status: active
    ---

    # Execution Spec

    ## Summary

    Execution specs define what the model should do, which context it may use, and how review should validate the result.

    ## Connections

    - [AI Native Team](../concepts/ai-native-team.md)
    - [Execution Policy](../decisions/execution-policy.md)
    - [Context Budget](../decisions/context-budget.md)
    """,
    "wiki/decisions/execution-policy.md": """
    ---
    title: Execution Policy
    type: decision
    created: 2026-06-19
    updated: 2026-06-19
    summary: Decision page that recommends treating context and execution as first-class platform capabilities.
    sources:
      - wiki/concepts/ai-native-team.md
      - wiki/concepts/execution-spec.md
    tags:
      - decision
    confidence: verified
    status: active
    ---

    # Execution Policy

    ## Summary

    Teams should adopt execution specs and context review as platform capabilities instead of ad hoc prompt work.

    ## Reasoning

    The policy links delivery quality to reusable context, evaluation loops, and review checkpoints.
    """,
    "wiki/decisions/context-budget.md": """
    ---
    title: Context Budget
    type: decision
    created: 2026-06-19
    updated: 2026-06-19
    summary: Decision page that limits context sprawl and requires explicit budget ownership in prompts and tools.
    sources:
      - wiki/sources/eval-loops.md
      - wiki/concepts/execution-spec.md
    tags:
      - decision
      - context
    confidence: verified
    status: active
    ---

    # Context Budget

    ## Summary

    Each delivery flow should define a context budget so prompts, retrieval, and review steps stay observable and affordable.
    """,
    "wiki/syntheses/delivery-system.md": """
    ---
    title: Delivery System Synthesis
    type: synthesis
    created: 2026-06-19
    updated: 2026-06-19
    summary: Synthesis page summarizing how source, topic, concept, and decision pages reinforce one another.
    sources:
      - wiki/sources/platform-spec.md
      - wiki/sources/eval-loops.md
      - wiki/concepts/ai-native-team.md
      - wiki/decisions/execution-policy.md
    tags:
      - synthesis
    confidence: mixed
    status: active
    ---

    # Delivery System Synthesis

    ## Findings

    - Platform, concept, and decision pages align on treating context and execution as one delivery system.
    - Review loops and context budgets make the operating model observable enough to scale.
    """,
    "wiki/queries/what-makes-ai-native-team.md": """
    ---
    title: What Makes an AI Native Team
    type: query
    created: 2026-06-19
    updated: 2026-06-19
    summary: Saved query summarizing the defining traits of an AI native delivery team.
    sources:
      - wiki/concepts/ai-native-team.md
      - wiki/decisions/execution-policy.md
    tags:
      - query
    confidence: mixed
    status: active
    ---

    # What Makes an AI Native Team

    ## Answer

    AI native teams treat model behavior, execution specs, context policy, and review loops as one coordinated delivery system.

    ## Consulted Pages

    - [AI Native Team](../concepts/ai-native-team.md)
    - [Execution Policy](../decisions/execution-policy.md)
    """,
}


def write_text(path: Path, content: str) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(textwrap.dedent(content).strip() + "\n", encoding="utf-8")


def build_demo(root: Path) -> None:
    root.mkdir(parents=True, exist_ok=True)

    for relative in [
        "wiki/sources",
        "wiki/topics",
        "wiki/concepts",
        "wiki/decisions",
        "wiki/syntheses",
        "wiki/queries",
        "raw/articles",
        "raw/inbox",
        "normalized/articles",
        "normalized/assets/inbox/2026-06-20-team-retrospective",
        "normalized/inbox",
        "output/inbox",
        "output/graph",
        "output/viewer",
    ]:
        (root / relative).mkdir(parents=True, exist_ok=True)

    for name, content in ROOT_FILES.items():
        (root / name).write_text(content, encoding="utf-8")

    for slug, content in RAW_FILES.items():
        write_text(root / "raw" / "articles" / f"{slug}.md", content)
        write_text(root / "normalized" / "articles" / f"{slug}.md", content)

    for slug, content in INBOX_FILES.items():
        write_text(root / "raw" / "inbox" / f"2026-06-20-{slug}.md", content)
        write_text(root / "normalized" / "inbox" / f"2026-06-20-{slug}.md", content)

    for relative, payload in INBOX_METADATA.items():
        write_text(root / "normalized" / "inbox" / relative, json.dumps(payload, ensure_ascii=False, indent=2))
    write_text(
        root / "normalized" / "assets" / "inbox" / "2026-06-20-team-retrospective" / "cover.txt",
        "placeholder localized media asset",
    )

    for relative, content in WIKI_FILES.items():
        write_text(root / relative, content)


def main() -> int:
    parser = argparse.ArgumentParser(description="Build the demo wiki used for README screenshots.")
    parser.add_argument(
        "--root",
        default=str(Path(__file__).resolve().parent.parent / "docs" / "demo-wiki"),
        help="Target demo wiki root",
    )
    args = parser.parse_args()
    root = Path(args.root).resolve()
    build_demo(root)
    print(root)
    return 0


if __name__ == "__main__":
    raise SystemExit(main())
98 files · 5 not served here

Advantages

  • Enables natural language management of a knowledge base without requiring the user to memorize complex CLI commands. evidence: README.md
  • Maintains Markdown files as the local source of truth, ensuring data portability and ownership. evidence: README.md
  • Provides a rich, interactive content knowledge graph that maps semantic relations like claims and entities rather than just file links. evidence: README.md

Limitations

  • Requires a local environment with Python 3 and cannot function in pure cloud-based chat environments without local file or shell access. evidence: README.md
  • Agent chat UIs typically cannot render the generated HTML interfaces inline, requiring the use of a separate browser or a local loopback server. evidence: README.md

Security

Risk level: No risk found

This brain runs

Agent instructions that run or fetch something (5)

  • SKILL.md: If the user wants a new workspace, run `init`.
  • SKILL.md: After `viewer`, `graph`, `inbox`, or `graph-report`, run `serve` when the user wants to browse the results.
  • SKILL.md: If a long-running `serve` process is not practical in the current session, run `serve --print-urls` and tell the user to start `serve` locally, then open the printed workspace URL.
  • SKILL.md: After starting `serve`, give the user the workspace home URL first (`http://127.0.0.1:8765/index.html` by default) and, in OpenClaw, offer to open it with `openclaw browser --browser-profile openclaw open <url>`. · uses the network
  • SKILL.md: If the host cannot keep a long-running process alive, run `serve --print-urls` to show the URLs and ask the user to start `serve` in a local terminal or background job.

Attribution and licence

First committed by
GitHub avatar of wzdavidwzdavid
Publisher
Wei Zhang (Community)
Source
wzdavid/ThinkWiki · commit 89f477d
Licence
MIT License (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
wzdavid

AutoGineer is not affiliated with or endorsed by wzdavid.

Install from source

5 of its files are not served here, so there is no ZIP. wzdavid/ThinkWiki at 89f477d