ctxr-cli 0.36.0 → 0.37.0

package/templates/skills/ctxr-session-lifecycle.md

@@ -22,10 +22,11 @@ session's worktree is gone. The name becomes a git ref and a directory, so keep
 that should not be written down.
 
 Before starting, bring the store's canonical clone up to date — the repository's main worktree, not
-whichever checkout you are standing in. From the canonical clone: `git fetch origin`, then
-`git merge --ff-only origin/__DEFAULT_BRANCH__`. If it is on another branch, carries uncommitted
-changes, or the fast-forward fails because it has diverged from origin, report exactly that and start
-the session anyway — never check it out, reset it, stash, or force the merge to make it comply. The
+whichever checkout you are standing in. In a shell, run `ctxr sync`; through the store's server, skip
+this step, because the server keeps its own clone current. It fetches `__DEFAULT_BRANCH__` and
+fast-forwards the canonical clone, and leaves it alone when it is on another branch, carries uncommitted
+changes, or has diverged from origin. If it reports that, report exactly that and start the session
+anyway — never check it out, reset it, stash, or force the merge to make it comply. The
 session's base is unaffected either way, because `ctxr session start` branches from the
 `origin/__DEFAULT_BRANCH__` it fetches itself. What a stale clone costs is the context you read out of
 it: notes, catalog sections, the graph document, and AGENTS.md would all be the versions it last had.
@@ -56,7 +57,7 @@ It reports each session with its open pull request and the decision made on the
 
 Skip this section when the store mounts no other stores under `shared/`.
 
-- After you bring the canonical clone up to date, run `ctxr shared-stores sync`. It clones a missing mount and fast-forwards the others.
+- After you bring the canonical clone up to date, run `ctxr shared-stores sync` in a shell; through the store's server, skip this step, because the server keeps no mounts. It clones a missing mount and fast-forwards the others.
 - Report a mount that sync left alone, with its reason. Do not reset, stash or force it. Why: local work in a mount is somebody's session.
 - To write into a mount for the work of this store's session, change into `shared/<name>`. Run `ctxr session start --joins <session>` there, with this store's session name. Why: the mount's session then joins this one, and one decision covers both pull requests.
 - The command refuses outside a mount, or for a session this store does not have. Report the refusal. Do not start a plain session instead.

package/templates/skills/mcp/_layer-step.md

@@ -0,0 +1,18 @@
+## 1. Which layer?
+
+The connector's instructions list this store's layers, each with its description, under *This store*;
+AGENTS.md's "Placing a new note" section lists them too. Choose by what the content fundamentally IS, not by
+surface keywords; a label on a location says nothing about what is actually kept there.
+
+- A layer whose description names an end state, a finish line or a deadline takes only what has a finish
+  line: if it never closes, it does not belong there. An item in that layer that can never close is a smell
+  — it either clutters the layer as open-forever or gets retired prematurely. Never create one on purpose;
+  an ongoing responsibility with a standard to maintain belongs in a layer whose description says so.
+- A layer whose description says it holds completed, abandoned or inactive items is where the other layers'
+  finished or dropped items go — never a first placement. Retire a note with `ctxr archive <path>` (a
+  tracked move; frontmatter untouched).
+
+If the store lists no layers, there is no layer decision: place the note next to the notes it will link to
+most (`ctxr graph query neighbors <path>` on the closest existing note shows that cluster) and let wikilinks
+carry the structure. If no layer fits, use the catch-all location AGENTS.md names and revisit the placement
+later.

package/templates/skills/mcp/_relation-grouping-step.md

@@ -0,0 +1,5 @@
+5. Group proposals by the relation vocabulary the connector's instructions list under *This store*, each
+   with its definition. The section headings carrying these names are what `ctxr graph build` types edges
+   from, so a link written under the right heading becomes a typed edge on the next build. Format each item
+   as `[[Note]]` — reason. Choose between two adjacent relations by their definitions, not their names, and
+   remember that an edge is recorded only on the note carrying the link.

package/templates/plugin/claude-mcp.json

@@ -1,8 +0,0 @@
-{
-  "mcpServers": {
-    "__NAME__": {
-      "type": "http",
-      "url": "__MCP_URL__"
-    }
-  }
-}

package/templates/skills/mcp/_preamble.md

@@ -1,44 +0,0 @@
-## Before this skill: the store's tools stand in for a checkout
-
-You are working through this store's server, not in a checkout of it. Nothing runs a shell here, so no
-`git`, `gh` or `ctxr` command runs as written. The skill below was written for an agent with a checkout:
-follow it as written, and take each step it names through the tool these tables give.
-
-### Commands
-
-__COMMAND_TABLE__
-
-A command marked none has no counterpart here: skip that step and say nothing about it. Each other tool takes its command's options as fields, each named for its option without the leading
-dashes, and the session the command names as `session`: the session worktree's directory name, which
-`session_start` returns and `session_list` lists. `session_start` takes the session's name as `label`.
-
-Every other `ctxr` step runs through the `ctxr` tool when the command only reads, and through `ctxr_write`
-when it writes. Pass the words after `ctxr` as `args`, one word per entry: a step that says to run
-`ctxr lint` is the `ctxr` tool with `args` set to `["lint"]`. Name a session as `session` to run the command
-in that session's working tree; `ctxr_write` always needs one. When a command reads a file you prepared,
-pass the file's text as `input` and write `@input` in `args` where its path goes.
-
-### Git steps
-
-__GIT_STEP_TABLE__
-
-Commits, pushes and pull requests happen only in `session_submit`. A step marked none is the server's own
-work: it keeps the store's clone current, and `session_start` branches from the freshly fetched default
-branch. Skip that step and say nothing about it.
-
-### Paths
-
-`session_start` returns the session's root, a path such as `__WORKTREES_PATH__<directory>/`. Every path the
-skill names is relative to the store; inside a session it goes under that root, so the note `work/a.md` in
-that session is `__WORKTREES_PATH__<directory>/work/a.md` for `Read`, `Edit`, `Write`, `Move`, `Delete`,
-`Grep` and `Glob`. A path without a session root reads the store as it was last approved, and a write to one
-is refused. A change rests uncommitted in its session until `session_submit`.
-
-### Sessions across conversations
-
-The server keeps a session between conversations, but it cannot tell two conversations apart. At the
-start of a conversation, call `session_list` and mention each open session: what it holds uncommitted,
-and any requested changes on its pull request. Work in the session the person names, or start one.
-
-Where the skill hands off to a skill this environment does not carry, such as landing or upgrading, or
-asks you to work inside a store mounted under `shared/`, that step is not yours here: a person lands an approved change from the store's approval page.