@thjodann/wk 1.0.2 → 1.0.4

package/docs/setup.md

@@ -139,12 +139,13 @@ wk site --audience user
 
 Before running `wk theme init`, the agent should inspect the host repo's actual
 visual sources: app/global CSS, design tokens, theme files, landing page styles,
-and app shell/layout styles. `wk theme preview` and `wk theme init` also inspect
-those files automatically when they are present, then fall back to README and
-package metadata for naming and copy. In styled web apps, this lets
+app shell/layout styles, brand image assets, favicon files, and repo-local font
+files. `wk theme preview` and `wk theme init` also inspect those files
+automatically when they are present, then fall back to README and package
+metadata for naming and copy. In styled web apps, this lets
 `.wikiwiki/site-theme.json` start with the host product's likely color mode,
 accent spectrum, radius, font family, gradients, glass/gloss, shadows, badges,
-and tag colors.
+tag colors, product mark, and typography.
 
 After the theme is in place, seed a small set of high-signal records before
 publishing the first site: product promise, privacy/data boundary, architecture
@@ -155,6 +156,7 @@ event. Then verify the generated site like a real local artifact:
 - check Auto, Light, and Dark controls
 - check local links and source-file links
 - check search
+- check the tab favicon, sidebar mark, home logo/wordmark, and custom fonts
 - check contrast for body text, muted text, accents, badges, and tags
 - keep `wiki-site/` generated; edit `.wikiwiki/site-theme.json` and records
 
@@ -206,6 +208,11 @@ while overwriting the bundled `wk` skill files:
 wk install-agent codex --yes --force
 ```
 
+Once installed, a bare `wk`, `/wk`, `$wk`, or linked `$wk` request means "show
+me the generated wiki site." The skill should return one concise link to an
+existing `wiki-site/index.html`; it should not run status/spin, generate files,
+start a server, or explain the skill for that bare invocation.
+
 To install manually on macOS or Linux:
 
 ```sh

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@thjodann/wk",
-  "version": "1.0.2",
+  "version": "1.0.4",
   "description": "Wikiwiki is an agent-native living documentation system for code repos.",
   "license": "MIT",
   "type": "commonjs",

package/skills/wk/SKILL.md

@@ -11,6 +11,18 @@ Use `wk` as the repo-local memory loop for agents. It keeps durable project know
 
 Prefer JSON output, preserve user work, and treat structured records as the source of truth. Records are the ledger; articles are the wiki. Lean on deterministic CLI commands for status, validation, rendering, site generation, and search; use model judgment for deciding what knowledge matters, updating public article prose, attaching source records, and polishing drafts. The generated site should feel like the user's project wiki; keep Wikiwiki itself quiet unless credit or setup context is needed.
 
+## Bare Invocation Default
+
+When the user invokes only `wk`, `/wk`, `$wk`, or `[$wk](...)` with no
+additional request, treat it as "show me the generated wiki site." Do not run
+the normal status/spin workflow, do not modify files, and do not explain the
+skill. Find the current repo root or workspace, prefer an existing
+`wiki-site/index.html`, and return a single concise Markdown link using the
+absolute local file path. If the site is already known to be served through a
+local URL, a direct URL to that same generated site is also acceptable. Do not
+start a server just for a bare invocation. If no generated site exists, say so
+briefly and suggest `wk site --audience all` or the repo's `wiki:site` script.
+
 ## Start Of Work
 
 1. Find the repo root before running `wk`.
@@ -128,8 +140,9 @@ wiki. Make the first generated site feel native to the host project:
 1. Run `wk setup --profile mixed --audience all --agent codex` in Codex-compatible IDEs so repo setup also installs the companion `/wk` skill.
 2. Inspect README/docs/package metadata for product identity and durable facts.
 3. Inspect actual visual sources before writing a theme: app/global CSS, design
-   tokens, theme files, landing page styles, app shell/layout styles, and any
-   existing brand palette files.
+   tokens, theme files, landing page styles, app shell/layout styles, brand
+   image assets, favicon files, repo-local font files, and any existing brand
+   palette files.
 4. Run `wk theme preview --json`. If the preview looks right, run
    `wk theme init`; otherwise pass explicit `--project-name`, `--description`,
    or `--mood`, then preview again.
@@ -137,8 +150,9 @@ wiki. Make the first generated site feel native to the host project:
    architecture, distribution/support, important symbols, and a devlog event.
 6. Run `wk validate`, `wk render`, and `wk site --audience all`.
 7. Verify the generated site locally: Auto/Light/Dark controls, default theme,
-   search, local links/source-file links, and contrast for body text, muted
-   text, accents, badges, and tags.
+   favicon, sidebar mark, home logo/wordmark, custom fonts, search, local
+   links/source-file links, and contrast for body text, muted text, accents,
+   badges, and tags.
 
 Do not edit generated CSS in `wiki-site/`. The source of truth is
 `.wikiwiki/site-theme.json` plus structured records.
@@ -248,4 +262,4 @@ steps and use the normal Wikiwiki flow.
 
 ## Site Theme Guidance
 
-When asked to make the human wiki match a project, edit `.wikiwiki/site-theme.json` rather than generated CSS. Prefer `wk theme preview --json` and `wk theme init` first because they inspect CSS/design sources when present. If you hand-edit, use the host project's real visual language literally: default color mode, paired light/dark palettes, accent spectrum, neutral surfaces, sidebar/hero/card gradients, brand gradient, badge/tag colors, focus ring, gloss, shadows, border radius, code background, and font family. Then run `wk validate`, `wk render`, and `wk site`.
+When asked to make the human wiki match a project, edit `.wikiwiki/site-theme.json` rather than generated CSS. Prefer `wk theme preview --json` and `wk theme init` first because they inspect CSS/design sources, brand image assets, favicon files, and repo-local font files when present. If you hand-edit, use the host project's real visual language literally: default color mode, paired light/dark palettes, accent spectrum, neutral surfaces, sidebar/hero/card gradients, brand gradient, logo/wordmark/favicon paths, badge/tag colors, focus ring, gloss, shadows, border radius, code background, font files, and font family. Then run `wk validate`, `wk render`, and `wk site`.