ctxr-cli 0.10.0 → 0.11.1

package/templates/notes/People.md

@@ -0,0 +1,19 @@
+---
+date_created: "{{date}}"
+title: "{{title}}"
+tags:
+  - People
+---
+# {{title}}
+
+## Bio
+<!-- Who they are: current role, organization, relevant history. -->
+
+## Relationship
+<!-- How you know them, and in what context. -->
+
+## Communication Log
+<!-- Dated entries, one per exchange: ### YYYY-MM-DD — context -->
+
+## Follow-ups
+<!-- - [ ] Task text (added YYYY-MM-DD, due YYYY-MM-DD) -->

package/templates/notes/Project.md

@@ -0,0 +1,19 @@
+---
+date_created: "{{date}}"
+title: "{{title}}"
+tags:
+  - Project
+---
+# {{title}}
+
+## Goal
+<!-- What done looks like. Work with no end state is an area, not a project. -->
+
+## Open threads
+<!-- Unresolved decisions and blockers; each links where it was raised. -->
+
+## Follow-ups
+<!-- - [ ] Task text (added YYYY-MM-DD, due YYYY-MM-DD) -->
+
+## Related
+<!-- Links out to related notes. -->

package/templates/skills/ctxr-ingest-orchestration.md

@@ -38,7 +38,10 @@ to put the file — "create a new note" is one option among several, never the d
    - Source discipline: a field the source does not confirm is "not reported" — never inferred from
      silence in either direction.
 5. Write the note the decision calls for — create it, expand it, merge, restructure, or add a section —
-   preserving prior content in every case but the deliberate rewrite.
+   preserving prior content in every case but the deliberate rewrite. A NEW note starts from a template
+   under `__TEMPLATES_PATH__`, with `{{title}}` and `{{date}}` substituted as you write (`ctxr-placement`
+   picks which). An EXISTING note is extended in place — never re-cut from a template, which would throw
+   away the content that made it worth expanding.
 6. Register the source against whatever note you just wrote:
    `ctxr ingest <path> --into <note> --source-type <type> --source-id <id>`. Every row of the table above
    ends here, not just the first: the command retains the capture under the capture tier's month, freezes

package/templates/skills/ctxr-placement.md

@@ -9,8 +9,20 @@ __LAYER_STEP__
 - Match on what the content IS. When two sibling locations both seem to fit, name the distinction between
   them (abstract vs concrete; outward-facing vs inward-facing; who-we-are vs how-it-runs) and pick by
   altitude and audience, not by keyword.
-- Read one or two sibling notes in the chosen location and match their shape — frontmatter keys, heading
-  style, bullets vs prose — before writing.
+- If the chosen location has a `README.md`, read it first: a folder with one answer about what its notes
+  look like states it there, and that answer wins over anything you would infer.
+
+## 2b. Which template?
+
+Start a new note from a template under `__TEMPLATES_PATH__` — never a blank file, and never by copying a
+sibling wholesale. List that directory and pick the kind the content actually is; `Note` is the base when
+nothing more specific fits, and it is also the file to copy when this store needs a kind it does not have.
+Substitute `{{title}}` and `{{date}}` as you write — no command expands them, and `ctxr lint` reports a
+note that lands with one still in it.
+
+The template is the starting shape, not a cage: delete a section that does not apply rather than leaving
+it empty, and add one the note needs. Read a sibling note only for what the template leaves open — house
+phrasing, bullets vs prose, which tags this location uses.
 
 ## 3. Sub-item under an existing location, or a new top-level one?
 
@@ -37,6 +49,13 @@ manufactures an artifact for the graveyard; capture the durable slice by hand in
 Add a one-line wikilink from the relevant hub note so the new note is not an orphan; `ctxr lint` flags
 orphans and notes without a catalog entry.
 
+## An existing note
+
+A note that already exists is EXTENDED, never restarted from a template: add the section it now needs,
+preserve what is there, and leave its frontmatter alone. Re-cutting a note from a template to "bring it up
+to standard" destroys the content that made it worth keeping — a note that has outgrown its starting shape
+is doing the right thing.
+
 ## Relocating an existing note
 
 `ctxr archive <path>` to retire it; a plain tracked `git mv` for an ordinary re-placement. Either way the

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

@@ -84,7 +84,11 @@ notes:
     path: <layer>/<location>/<Title>.md
     mode: create            # or: append
     body: |
-      matching the frontmatter and style of the sibling notes (`ctxr-placement` decides the location)
+      for create: started from a template under `__TEMPLATES_PATH__`, with {{title}} and {{date}}
+      substituted, sections that do not apply deleted rather than left empty
+      for append: only the new material, extending the note rather than restarting it — the
+      command appends your body verbatim and never rewrites what is already there
+      (`ctxr-placement` decides both the location and the template)
 ```
 
 Then run `ctxr session capture --proposal <file>`. It validates and writes every item independently —

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

@@ -29,6 +29,16 @@ deferring is a normal answer, and the session is unaffected by it. A `cli.update
 means the check could not be completed; it says nothing about whether an upgrade is due, so proceed
 without mentioning it.
 
+## Between turns
+
+A session is not a turn. The worktree persists across as many exchanges as the work takes, and ending a
+turn with uncommitted changes on the branch is the session's normal resting state — not an obligation to
+discharge before replying. Say in one line what is uncommitted and which worktree holds it, then stop.
+
+Nothing about a finished piece of work ends the session. `ctxr-submit` is what ends it, and it waits to
+be asked — see its own entry condition. An agent that treats delivering the thing it was asked for as the
+signal to wrap up will submit into the middle of a conversation that had more coming.
+
 ## Re-scan before any plan
 
 Re-scan whenever state may have moved under you — before presenting a plan, before running `ctxr-submit`,

package/templates/skills/ctxr-submit.md

@@ -2,6 +2,29 @@ The submit half of the session lifecycle — everything up to and including open
 `ctxr-land` is the other half, after review; `ctxr-session-lifecycle` covers what surrounds both (starting
 a session, the conflict playbook, sequencing several pull requests) and is not repeated here.
 
+## When
+
+Fires on an explicit request to wrap up — "submit", "open the PR", "push it", "ship it" — or on the
+operator's own closing utterance ("done", "that's all", a sign-off). That request is the whole reason step 8
+needs no further confirmation: it is the consent for the push and the pull-request open. Enter without
+one and there is nothing behind those steps.
+
+Anti-triggers — do not enter this skill when: you have merely finished the task you were given (a
+delivered piece of work is not a closing signal, and the next message is as likely to extend it as to
+end it); a question, an error, or a requested follow-up is still outstanding; the operator's last message
+asked for more work. Your own judgment that the work looks complete is never the signal, and neither is
+your own summary saying so.
+
+Two tells that you are here uninvited. Reaching for `ctxr doctor`, `ctxr lint`, or `ctxr catalog check`
+to decide *whether* to submit — those live at step 5 and after, inside a submit already asked for, and
+running them ahead of one is a rehearsal, not a check. And composing a question like "shall I open the
+pull request?" — needing to ask is itself the answer: leave, and let the work continue.
+
+Ending a turn without that signal is normal and is not this skill. Say in one line what is uncommitted
+and which worktree holds it, then stop. The work is safe on the branch and the next message picks it up.
+
+## Steps
+
 1. Re-scan (mandatory — never replay a plan from an earlier snapshot): `git fetch origin`,
    `git status --short`, `git diff --stat`, `git diff --cached --stat`,
    `git ls-files --others --exclude-standard`, `git log --oneline origin/__DEFAULT_BRANCH__..HEAD`. State moves
@@ -26,5 +49,7 @@ a session, the conflict playbook, sequencing several pull requests) and is not r
 9. Verify before any retry: a transport error can arrive AFTER the push or the pull-request open already
    succeeded. Before retrying anything, `git ls-remote origin <branch>` and `gh pr list --head <branch>` —
    never replay a push or a pull-request open blindly.
-10. Hand off: report the pull request, then point at `ctxr-land` for after review — landing is a separate
-    decision and keeps its own explicit confirmation.
+10. Hand off: report the pull request's number and its url, and name what landing it takes —
+    `ctxr-land`, targeting that number — so the next step is one word away instead of something to
+    reconstruct later. Landing stays a separate decision and keeps its own explicit confirmation; never
+    run it from here.

package/templates/skills/ctxr-upgrade.md

@@ -37,7 +37,8 @@ step 3 gates on the operator rather than proceeding from the fact that a newer r
 
 6. Land the re-render as its own pull request. `ctxr update` produces generated-file churn — AGENTS.md
    sections, skill copies, hooks, adapter outputs — and mixing it into unrelated work makes both
-   harder to review. Follow `ctxr-submit`, then `ctxr-land`.
+   harder to review. Submit it with `ctxr-submit` when the re-render is ready to go out; landing it is a
+   separate decision afterwards, and `ctxr-land` keeps its own confirmation.
 
 If step 4 or 5 fails, say which step and what the command reported. A partial upgrade — new executable,
 un-re-rendered store — is a real state worth naming: the store still works, and step 5 can be re-run on