@rubytech/create-realagent-code 0.1.146 → 0.1.147

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-realagent-code",
-  "version": "0.1.146",
+  "version": "0.1.147",
   "description": "Install Real Agent — Built for agents. By agents.",
   "bin": {
     "create-realagent-code": "./dist/index.js"

package/payload/platform/plugins/admin/PLUGIN.md

@@ -129,7 +129,6 @@ Tools are available via the `admin` MCP server.
 | Plain-English explanation | User asks to explain, define, or pre-empts ("explain in plain English", "what does X mean", "define X", "I don't understand", "what is this"), or admin is about to return a reply containing a term not in the operator's prior turn | `skills/plainly/SKILL.md` |
 | Manage admin users | User asks to add, remove, or list admins on this account, or change an admin PIN | `skills/admin-user-management/SKILL.md` |
 | Session reset / continue / resume | User asks to clear the session, start fresh, continue the last session, or pick up where they left off | `skills/session-management/SKILL.md` |
-| Commitment follow-through | A `<commitment-detected>` block appears in the prompt; the owner has just made a commitment that needs a backing mechanism | `skills/commitment-followthrough/SKILL.md` |
 | Show or download a file | User asks to view, attach, or download a file or document, or the current turn produces a document the owner needs to review | `skills/file-presentation/SKILL.md` |
 | Upgrade Maxy | User asks to upgrade, update, install the latest version, or accepts an upgrade offer | `skills/upgrade/SKILL.md` |
 

package/payload/platform/plugins/admin/hooks/__tests__/session-end-retrospective.test.sh

@@ -294,7 +294,7 @@ write_transcript "$T_RELEASE" \
   "assistant|hello|" \
   "user|/end|" \
   "assistant|running retrospective|" \
-  "assistant||tool_use:session-retrospective-mark-complete"
+  "assistant||tool_use:mcp__admin__session-retrospective-mark-complete"
 ENV_REL=$(envelope_for "$OP_ID" "$T_RELEASE")
 : > "$REQ_LOG"
 run_hook "admin" "" "$ENV_REL"
@@ -325,7 +325,7 @@ fi
 T_OTHER=$(mktemp); TMPFILES+=("$T_OTHER")
 write_transcript "$T_OTHER" \
   "user|/end|" \
-  "assistant||tool_use:session-retrospective-mark-complete"
+  "assistant||tool_use:mcp__admin__session-retrospective-mark-complete"
 # Active gate inspects only T_ACTIVE (no sentinel inside).
 T_ACTIVE=$(mktemp); TMPFILES+=("$T_ACTIVE")
 write_transcript "$T_ACTIVE" "user|/end|"

package/payload/platform/plugins/admin/hooks/session-end-retrospective.sh

@@ -20,7 +20,10 @@
 #
 # Sentinel detection. Completion is recognised by greping the operator's
 # own JSONL (transcript_path on the Stop envelope) for a `tool_use` block
-# whose `name` is exactly `session-retrospective-mark-complete`. The
+# whose `name` is exactly `mcp__admin__session-retrospective-mark-complete`
+# — that is the prefixed form Claude Code writes for MCP tools in the
+# JSONL; the unprefixed name only appears in the operator-facing
+# instruction text below. The
 # sentinel-grep doubles as the re-entry guard: every Stop that fires after
 # the agent's sentinel call sees the sentinel and exits 0 with
 # `gate-released`, so the agent's wrap-up turn never re-blocks.
@@ -128,12 +131,12 @@ fi
 #   1. The latest end-intent token in the most recent real-user message,
 #      or empty if no real user message matches.
 #   2. Whether any `tool_use` block in the transcript names the sentinel
-#      tool `session-retrospective-mark-complete`.
+#      tool `mcp__admin__session-retrospective-mark-complete`.
 # Output one line: <intent-token-or-empty>\t<sentinel-present-yes|no>
 INSPECTION=$(TRANSCRIPT_PATH="$TRANSCRIPT_PATH" python3 - <<'PY'
 import os, json
 
-SENTINEL_TOOL = "session-retrospective-mark-complete"
+SENTINEL_TOOL = "mcp__admin__session-retrospective-mark-complete"
 INTENT_TOKENS = ("/end", "/archive", "end session", "archive this session")
 
 def is_real_user(rec):

package/payload/platform/templates/agents/admin/IDENTITY.md

@@ -71,7 +71,7 @@ When you receive a turn beginning with `[system: <name>-stop-hook]`:
 2. Execute that single `Task` dispatch. Do not paraphrase the prompt, do not respond conversationally, do not ask the operator for clarification, do not surface the dispatch in chat.
 3. When the subagent returns its one-line summary, emit a single space character and stop. The Stop hook's next fire will inspect the transcript, see the dispatch you just performed, and allow the stop.
 
-These directives are never operator-driven. The `database-operator` specialist in particular, when dispatched via `post-turn-graph-pass.sh` (Task 412), runs as a background graph pass that the operator does not see; the dispatch prompt carries `<conversation>` and `<prior-writes>` blocks and you must forward both verbatim.
+These directives are never operator-driven. The `database-operator` specialist in particular, when dispatched via `post-turn-graph-pass.sh` (Task 412), runs as a background graph pass that the operator does not see; the dispatch prompt carries the conversation and prior-writes blocks and you must forward both verbatim.
 
 ## SOUL.md
 

package/payload/platform/plugins/admin/skills/commitment-followthrough/SKILL.md

@@ -1,60 +0,0 @@
----
-name: commitment-followthrough
-description: "Handles the platform-detected commitment signal: offers to track or automate the commitment, waits for owner confirmation, then picks the right backing mechanism (scheduled event, task, or workflow). Loads when the system prompt contains a `<commitment-detected>` block."
----
-
-# Commitment follow-through
-
-This skill activates when the platform identifies that the owner has just made a commitment: something they said they would do. The skill's job is to offer the right backing mechanism, wait for the owner's confirmation, then create it. Without a backing mechanism, a commitment is a broken promise; with one, the agent can hold the owner to their word.
-
-## The trigger
-
-A `<commitment-detected>` block appears in the system prompt. The block names what the platform classifier extracted: the commitment text, the suggested mechanism (scheduled event, task, or workflow), and any time, recipient, or topic the classifier inferred.
-
-## How to offer
-
-Surface a brief, conversational offer. Name the commitment, name the suggested mechanism, and ask the owner to confirm, modify, or dismiss. One or two sentences. Not a form. Not a list of options. Examples:
-
-- "I'll set a reminder for Tuesday morning to chase the Acme invoice. Confirm?"
-- "Want me to create a task for the photo brief so it doesn't slip?"
-- "Shall I schedule the weekly check-in with Daniel on Mondays at 9?"
-
-## Never act without confirmation
-
-The owner must say "yes" or give specifics before any tool call. If they dismiss ("no thanks", "I'll handle it"), acknowledge briefly and continue with whatever they were discussing. Do not re-offer for the same commitment.
-
-If they modify ("make it next Monday instead"), incorporate the changes and confirm before creating.
-
-## The two-rule discipline
-
-This skill is the operator's side of the two-rule contract on commitments.
-
-1. **You never state a future commitment** ("I'll flag", "I'll check", "I'll remind") **without immediately creating the mechanism to fulfil it.** A commitment without a backing mechanism is a broken promise.
-2. **When the owner makes a commitment, offer to back it with a mechanism**, but do not create it without confirmation.
-
-Rule 1 is yours; rule 2 is this skill's job.
-
-## Picking the mechanism
-
-Use the most appropriate tool:
-
-- `schedule-event` for time-bound reminders (every Monday, on Tuesday, by Friday).
-- `work-create` for open-ended obligations (chase X, finish Y, prepare Z).
-- `workflow-create` for multi-step processes that recur (monthly close-out, new-instruction onboarding).
-
-## Verify executor capabilities before promising a workflow
-
-Before committing to build a workflow, check that every step maps to a capability the executor actually has. Tool steps need the named plugin and tool to exist. Agentic LLM steps (steps that browse, click, fill forms, or interact with external systems) need the relevant MCP server command available in `PATH`. If a step requires a capability that does not exist, say so upfront: do not promise a workflow you cannot build. The owner can either narrow the scope or wait for the capability to ship.
-
-## After creation
-
-Tell the owner what was created (task ID, scheduled event time, workflow name) so they have something they can reference, modify, or cancel later. Then resume the conversation.
-
-## Failure modes
-
-- **`<commitment-detected>` block names a mechanism that does not exist** (e.g. `workflow-create` while workflows are not enabled on this account). Surface the gap and offer the next-best mechanism.
-- **Owner approves but the create tool fails.** Surface the error literally. Do not silently substitute a different mechanism.
-
-## What this skill does not do
-
-It does not detect commitments itself; the platform does that and injects the block. It does not act on the owner's behalf without explicit confirmation. It does not create mechanisms for commitments the owner did not actually make; if the platform's classification looks wrong, ignore the block and continue.