@theronap/cortex-mcp 0.9.97 → 0.9.99

package/lib/skills.mjs

@@ -131,6 +131,52 @@ function installInto(skillsRoot, skills, { removeNames = [] } = {}) {
  * @param {{ quiet?: boolean }} opts  quiet → only emit on actual change (for the SessionStart hook)
  * @returns {{ installed: string[], repaired: string[], unchanged: string[], targets: string[] }}
  */
+// Skills renamed in C3 (ADR-0033). The old name keeps working for one release via a forwarding
+// stub, then both the map and the stubs are deleted.
+//
+// The stub is a REAL skill that delegates, not a message that the command moved. A stub which only
+// announces the rename breaks every caller that invokes the old name from automation — and this repo
+// has a rule about surfaces that report something other than what happened. The model reads the stub,
+// follows the pointer, and does the actual work, so `/cortex-log` behaves exactly as it always did.
+export const RENAMED_SKILLS = {
+  'cortex-log': 'agnoclast-log',
+  'cortex-context': 'agnoclast-context',
+  'cortex-author-docs': 'agnoclast-author-docs',
+  'cortex-walkthrough': 'agnoclast-walkthrough',
+}
+
+/** PURE. The forwarding stub's SKILL.md body. */
+export function forwardingStub(oldName, newName) {
+  return `---
+name: ${oldName}
+description: Renamed to /${newName}. This forwarding stub keeps the old command working and will be removed in a later release.
+---
+
+This skill is now **${newName}**.
+
+Read \`~/.claude/skills/${newName}/SKILL.md\` and follow it in full. Everything it says applies
+here unchanged — this file exists only so \`/${oldName}\` keeps working for automation and habit
+that still names the old command. Do the work the real skill describes; do not stop at this notice.
+`
+}
+
+/** Write a forwarding stub for every renamed skill whose new form is present. Best-effort: a stub
+ *  that cannot be written is a lost alias, never a failed install. */
+function installForwardingStubs(skillsRoot, log) {
+  for (const [oldName, newName] of Object.entries(RENAMED_SKILLS)) {
+    try {
+      if (!existsSync(join(skillsRoot, newName, 'SKILL.md'))) continue
+      const dir = join(skillsRoot, oldName)
+      const file = join(dir, 'SKILL.md')
+      const body = forwardingStub(oldName, newName)
+      if (existsSync(file) && readFileSync(file, 'utf8') === body) continue
+      ensureDir(file)
+      writeFileSync(file, body)
+      log(`  ✓ ${oldName} → forwards to ${newName}`)
+    } catch { /* an alias is a convenience, never a reason to fail the install */ }
+  }
+}
+
 export function installSkills(opts = {}) {
   const quiet = !!opts.quiet
   const log = (m) => { if (!quiet) process.stdout.write(m + '\n') }
@@ -151,6 +197,7 @@ export function installSkills(opts = {}) {
     summary.unchanged.push(...r.unchanged)
     const changed = [...r.installed, ...r.repaired]
     if (changed.length) log(`  ✓ ${cli.id}: ${changed.join(', ')} → ${skillsRoot}`)
+    installForwardingStubs(skillsRoot, log)
   }
 
   if (quiet && (summary.installed.length || summary.repaired.length)) {
@@ -361,6 +408,35 @@ export async function runSkills(argv = []) {
   if (argv[0] === 'push') return runSkillsPush(argv.slice(1))
 
   const quiet = argv.includes('--quiet')
+
+  // ── C2 (ADR-0033 §5): move the MCP config key to its new name. ─────────────
+  // This runs from the SessionStart hook because that is the only channel that reaches every seat
+  // without asking anyone to do anything. It is safe here for two reasons that both matter:
+  //
+  //   • It is SELF-GUARDING. runKeyMigration adds the new namespace's allow rules and re-reads them
+  //     from disk BEFORE flipping the key, and aborts leaving the machine on the old name if they
+  //     did not land. The C1 release already pre-authorized both namespaces, so on a seat that took
+  //     C1 there is nothing left to add — but a seat that skipped C1 entirely is handled too, which
+  //     is the whole reason the guard lives on the machine rather than in the release cadence.
+  //   • It is idempotent and cheap after the first run: a state file read, then nothing.
+  //
+  // FAIL-SOFT, like every other hook step. A migration hiccup must never block a session from
+  // starting; the next SessionStart tries again.
+  try {
+    const { runKeyMigration } = await import('./migrate_key.mjs')
+    const res = runKeyMigration()
+    if (!quiet && res.status === 'migrated') {
+      process.stdout.write(`  ✓ MCP config key moved ${res.from} → ${res.to}. Restart to load it under the new name.\n`)
+    }
+    if (res.status === 'aborted') {
+      // Loud on stderr even when quiet: an abort means the machine is INTENTIONALLY still on the old
+      // key, and a silent abort is indistinguishable from never having tried.
+      process.stderr.write(`agnoclast: key migration held off at "${res.step}" (${res.reason}) — still on the old name, will retry.\n`)
+    }
+  } catch (e) {
+    process.stderr.write(`agnoclast: key migration skipped (${e?.message ?? e}) — will retry next session.\n`)
+  }
+
   if (!quiet) process.stdout.write('\nAgnoclast skills — installing managed skills…\n')
   const r = installSkills({ quiet })
   if (!quiet) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@theronap/cortex-mcp",
-  "version": "0.9.97",
+  "version": "0.9.99",
   "description": "Connect your AI assistant to Cortex — your org's projects, activity, gaps, and directives, scoped to you.",
   "type": "module",
   "bin": {

package/skills/author-docs/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: cortex-author-docs
+name: agnoclast-author-docs
 description: Push new/changed documentation (specs, plans, design docs) from disk into Agnoclast as authored wiki pages. Run after writing a spec/plan/design doc, when the user asks to sync docs to Agnoclast, or as part of session close-out.
 ---
 
@@ -17,7 +17,7 @@ the doc and author a synthesis. Never dump raw markdown into a page.
 
 - Right after you write or substantially update a spec/plan/design/runbook doc on disk.
 - When the user asks to push/sync docs to Agnoclast.
-- During session close-out (`/cortex-log` runs this as a sweep step).
+- During session close-out (`/agnoclast-log` runs this as a sweep step).
 
 ## Steps
 

package/skills/context/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: cortex-context
+name: agnoclast-context
 description: Automatically hydrate Agnoclast context at the start of a substantive session. Use when Agnoclast MCP is available and the user has made a real request, so the first answer is grounded in query-centered org context instead of the static baseline alone.
 ---
 

package/skills/log/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: cortex-log
+name: agnoclast-log
 description: Close out a work session into Agnoclast — summarize what happened, confirm it reached the org, and surface anything teammates should know. Run at or near the end of any working session.
 ---
 
@@ -62,7 +62,7 @@ No arguments. Read the conversation context.
    already authored a node mid-session and nothing changed since, `author` will report "no change" —
    that's fine.
 6. **Sweep pending documentation** — run `npx -y @theronap/cortex-mcp docs-scan --json`; if any
-   docs are pending, follow the `cortex-author-docs` skill (author each into its page, then
+   docs are pending, follow the `agnoclast-author-docs` skill (author each into its page, then
    `docs-scan --mark`). Specs/plans written to disk this session must not die on disk — a spec IS
    a page. If no roots are registered or nothing is pending, skip silently.
 7. **Reconcile the sweep (don't trust it).** Step 5 relies on your in-the-moment judgment of "what

package/skills/walkthrough/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: cortex-walkthrough
+name: agnoclast-walkthrough
 description: Run the guided Agnoclast walkthrough for someone new. Use when the person asks for the walkthrough, a tutorial, or getting started — "give me the walkthrough", "walk me through this", "how do I use this", "show me around", "what can this do", "remind me how this works" — or when a brand-new user needs orienting for the first time.
 ---