@thjodann/wk 1.0.2 → 1.0.3

package/README.md

@@ -141,11 +141,15 @@ Wikiwiki is an article-first CLI foundation. It currently includes:
 - optional read-only Beads integration for developer work context
 - public npm package `@thjodann/wk`
 - GitHub Release-based npm publishing through Trusted Publishing
+- bundled Codex skill behavior where bare `wk`/`/wk` opens the generated site
+- dogfooded article pages for this repo's generated wiki
 - CI and tests
 
-Near-term polish is mostly packaging and docs hygiene for `1.0.1`. Larger
-planned pieces include richer symbol extraction, draft review flows, and watch
-mode.
+The package and release foundation is complete enough for regular patch
+releases. The current polish milestone is `1.0.3 Open the Wiki`: make bare
+`/wk` show the generated site and make this repo's own generated wiki useful at
+first glance. The next larger feature remains draft review flows for approving
+or rejecting closeout and compile drafts.
 
 Generated `wiki/` and `wiki-site/` are intentionally not shipped in the npm
 package. Installed users generate their own copies from their own records.
@@ -194,9 +198,10 @@ not release commitments.
 
 | Planned feature | Completion | Notes |
 | --- | ---: | --- |
-| `1.0.1` package polish | 70% | Bundle the current README and skill docs, and decide whether repo artwork such as `assets/wikiwiki-banner.png` should ship inside the npm tarball rather than only through GitHub-hosted README links. |
-| Agent setup polish | 85% | `wk setup --agent codex` and `wk install-agent codex` exist; remaining work is clearer multi-agent targeting and stricter destination previews. |
-| Draft review flows | 45% | Closeout and compile draft packets exist; structured approve, reject, and apply flows are still early. |
+| `1.0.3` Open the Wiki | 95% | Bare `wk`/`/wk` opens an existing generated site, five starter article records seed this repo's wiki, and package docs point at the current release path. |
+| Package and release foundation | 96% | README/docs/skill files ship in npm, generated dogfood output and `assets/wikiwiki-banner.png` stay out of the tarball, and GitHub Releases drive Trusted Publishing with a manual 2FA fallback. |
+| Agent setup polish | 88% | `wk setup --agent codex` and `wk install-agent codex` preserve the bundled skill behavior; remaining work is broader target support and clearer destination previews. |
+| Draft review flows | 45% | Closeout and compile draft packets exist; structured approve, reject, and apply flows are the next larger feature after `1.0.3`. |
 | Richer symbol extraction | 20% | Symbol records and pages exist, but important symbols are still captured manually. |
 | Watch mode | 10% | Batch commands exist for `status`, `spin`, and `closeout`; no file watcher is built yet. |
 | `scratch` review command | 10% | Validation and search exist; contradiction, drift, and stale-knowledge review is not a dedicated command yet. |
@@ -208,9 +213,9 @@ not release commitments.
 
 Shared completion snapshot:
 
-- Package and release foundation: about 92%
-- Named future roadmap: about 44%
-- Blended overall product vision: about 74%
+- Package and release foundation: about 96%
+- Named future roadmap: about 45%
+- Blended overall product vision: about 77%
 
 ## License
 

package/docs/reference.md

@@ -313,8 +313,10 @@ not on every push to `main`; npm versions are immutable, so each release needs a
 new `package.json` version first. If a release is re-run for a version that is
 already on npm, the workflow skips `npm publish` after tests and validation pass.
 
-The initial `v1.0.0` GitHub Release was created after a manual npm publish;
-future releases should use this workflow end-to-end.
+The package and release foundation is complete enough for regular patch
+releases. Prefer the workflow end-to-end; if npm Trusted Publishing rejects a
+release, publish manually with the owner account and npm 2FA, then let the
+workflow rerun or skip the already-published version.
 
 Release checklist:
 
@@ -356,13 +358,14 @@ Wikiwiki is an article-first CLI foundation. It currently includes:
 - optional read-only Beads integration with developer-only `work.html`
 - public npm package `@thjodann/wk`
 - GitHub Release-based npm publishing through Trusted Publishing
+- bundled Codex skill behavior where bare `wk`/`/wk` opens the generated site
+- dogfooded article pages for this repo's generated wiki
 - CI and tests
 
 Some planned pieces are not built yet:
 
-- `1.0.1` package/docs polish
-- richer symbol extraction
 - draft review flows
+- richer symbol extraction
 - watch mode
 
 Generated `wiki/` and `wiki-site/` are intentionally not shipped in the npm
@@ -374,9 +377,10 @@ Roadmap estimates are rough planning signals, not release commitments.
 
 | Area | Completion | Next |
 | --- | ---: | --- |
-| `1.0.1` package polish | 70% | Ship current README and skill docs, then decide whether repo artwork such as `assets/wikiwiki-banner.png` belongs in the npm tarball. |
-| Agent setup polish | 85% | `wk setup --agent codex` and `wk install-agent codex` exist; future work is broader target support and clearer destination previews. |
-| Draft review flows | 45% | Closeout and compile drafts exist; approving, rejecting, and applying record drafts is still early. |
+| `1.0.3` Open the Wiki | 95% | Bare `wk`/`/wk` opens an existing generated site, five starter article records seed this repo's wiki, and package docs point at the current release path. |
+| Package and release foundation | 96% | README/docs/skill files ship in npm, generated dogfood output and `assets/wikiwiki-banner.png` stay out of the tarball, and GitHub Releases drive Trusted Publishing with a manual 2FA fallback. |
+| Agent setup polish | 88% | `wk setup --agent codex` and `wk install-agent codex` preserve the bundled skill behavior; future work is broader target support and clearer destination previews. |
+| Draft review flows | 45% | Closeout and compile drafts exist; approving, rejecting, and applying record drafts is the next larger feature after `1.0.3`. |
 | Richer symbol extraction | 20% | Symbol records and pages exist, but extraction is still mostly manual. |
 | Watch mode | 10% | Batch commands exist; no file watcher is built yet. |
 | `scratch` review command | 10% | Validation and search exist; contradiction, drift, and stale-knowledge review is not a dedicated command yet. |

package/docs/setup.md

@@ -206,6 +206,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.3",
   "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`.