Design Wiki

Maintain this repository as a reusable framework for a compounding, source-grounded design knowledge base shared by designers and Agents. Designers use it to learn and make judgments; Agents consult the same knowledge to support task decisions and execution. Present this shared purpose in capability and audience questions. The framework supplies structure and operating rules; all substantive knowledge must come from the user's sources or explicitly authorized research. Treat academic research and industry practice as complementary evidence; choose evidence by the kind of claim being made rather than assuming one universal hierarchy.

This Skill is also its own writable knowledge workspace. Resolve every relative path and ./wiki command from the directory containing this SKILL.md, even when the host invokes the Skill while working in another project. Do not copy knowledge into the caller's repository, and do not overwrite an existing user-content/ during installation or update.

For an explicit install or update request, read the root README.md section “Agent 安装协议” and agents/install-manifest.json, then execute the applicable GitHub or ZIP path. Do not merely restate the instructions.

For all user-facing replies, follow the presentation rules in profiles/design/references/onboarding.md: explain design outcomes, show only relevant conversational commands, and keep internal paths and execution mechanics out of responses. Capability questions start with positioning and core uses; concrete requests receive brief steps and related commands, followed by execution when requested.

Before editing or answering from the wiki, read AGENTS.md. project.json selects the content root and active profile. Then read only the profile references needed for the operation:

• For domain boundaries and knowledge types, read profiles/design/references/knowledge-model.md.
• For ingest, query, synthesis, review, or lint behavior, read profiles/design/references/workflows.md.
• For observe, compare, extract-pattern, recommend, or equivalent design requests, read profiles/design/references/design-commands.md. Run the corresponding command with --json, then actually read/inspect the evidence and complete the supplied workflow. CLI task preparation is not a completed analysis. Default output is a conversation report; saving uses the existing ingest or staged synthesis workflow when requested.
• For underlying changes → design challenges → principles, use ./wiki derive-principles "design scope" --json and read profiles/design/references/derive-principles.md. Optional --source restricts the analysis to supplied materials; otherwise consult ingested knowledge. Trace each candidate principle through a challenge to time-bounded evidence, and preserve causal uncertainty. This is a read-only Agent analysis until the user requests staged persistence.
• When consulting knowledge during another design task, read profiles/design/references/task-consultation.md. Use ./wiki search "task question" --json, then ./wiki read <page-id> --json; assess context and evidence before recommending an action. This remains a read-only query, not permission to ingest or change the caller's project.
• For visual materials and visual evidence in any task, follow visual-materials.md: display actual images alongside interpretation and citations; retain and embed images when saving. Knowledge reads include image data; use image inputs or visual tools to inspect it, not base64 text alone.
• For source quality, citations, freshness, and rights, read profiles/design/references/source-and-evidence-policy.md.
• For page creation, use the closest matching file in profiles/design/templates/ and fall back to core/templates/.
• For evaluation work, read user-content/evals/README.md.
• For knowledge-graph generation or site presentation, read core/references/knowledge-graph.md.
• For capability questions, task-specific help, or onboarding, read profiles/design/references/onboarding.md, inspect the current user-content/ state, and give only the most relevant next steps.

Use ./wiki check after material wiki changes. Use ./wiki build when pages are added, renamed, or retired, then inspect the derived changes and check again.

Use ./wiki graph after relationship changes. ./wiki dev and ./wiki build regenerate the site's public graph; normal content mode intentionally excludes navigation scaffolds.

Preserve user-content/raw/. Never silently convert an author's claim, a vendor statement, or an agent inference into an established fact. Important syntheses should pass through user-content/staging/ unless the user explicitly asks for a draft-only exploration.

Do not answer design-domain questions from scaffold pages alone. When the user's wiki lacks evidence, state the gap and ask for sources or obtain authorization before researching externally.