@rudderhq/agent-runtime-cursor-local 0.1.0-canary.70 → 0.1.0-canary.72

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rudderhq/agent-runtime-cursor-local",
-  "version": "0.1.0-canary.70",
+  "version": "0.1.0-canary.72",
   "license": "SEE LICENSE IN LICENSE",
   "homepage": "https://github.com/Undertone0809/rudder",
   "bugs": {
@@ -51,7 +51,7 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@rudderhq/agent-runtime-utils": "0.1.0-canary.70",
+    "@rudderhq/agent-runtime-utils": "0.1.0-canary.72",
     "picocolors": "^1.1.1"
   },
   "devDependencies": {

package/skills/rudder-create-agent/SKILL.md

@@ -88,11 +88,21 @@ Required thinking:
 - optional `desiredSkills` from the organization skill library
 - adapter and runtime config aligned to this environment
 - capabilities
-- role/persona instructions for the new agent (`promptTemplate` when the CLI payload is the available surface; Rudder materializes this as `SOUL.md`)
+- structured role/persona instructions for the new agent (`promptTemplate` when the CLI payload is the available surface; Rudder materializes this as `SOUL.md`)
 - source issue linkage (`sourceIssueId` or `sourceIssueIds`) when this hire came from an issue
 
 Do not copy Rudder's shared filesystem, memory, language, or safety contract into the hire prompt. Rudder injects that operating contract from runtime code for supported local runtimes. The hire-specific prompt should only define the new agent's role, identity, scope, tone, and durable responsibilities.
 
+Draft `promptTemplate` as a durable SOUL document, not a one-line command. Use these sections when the role is not trivial:
+
+- Opening: one sentence that captures who the agent is
+- Mission: the outcome this agent owns
+- Responsibilities: durable duties and ownership boundaries
+- Boundaries: what the agent should not do or should escalate
+- Decision Principles: role-specific judgment rules
+- Voice: how the agent should communicate
+- Continuity: what should become memory or explicit instruction updates over time
+
 8. Submit the canonical hire request.
 
 ```sh
@@ -107,7 +117,7 @@ rudder agent hire --org-id "$RUDDER_ORG_ID" --payload '{
   "agentRuntimeConfig": {
     "cwd": "/abs/path/to/repo",
     "model": "o4-mini",
-    "promptTemplate": "You are the CTO. Own technical strategy, architecture, engineering execution, and quality bars."
+    "promptTemplate": "# SOUL.md -- CTO Persona\n\nYou are the CTO.\n\n## Mission\nOwn technical strategy, architecture, engineering execution, and quality bars.\n\n## Responsibilities\n- Set technical direction and execution standards.\n- Review architecture and staffing trade-offs.\n- Keep delivery risks visible and actionable.\n\n## Boundaries\n- Do not approve risky shortcuts without naming the trade-off.\n- Escalate product or budget ambiguity instead of guessing.\n\n## Decision Principles\n- Prefer simple architectures with explicit trade-offs.\n- Treat reliability, developer velocity, and product learning as linked constraints.\n\n## Voice\nDirect, specific, and evidence-led.\n\n## Continuity\nPreserve durable technical standards, repeated failure patterns, and long-running architecture decisions in memory or explicit instructions."
   },
   "runtimeConfig": {"heartbeat": {"enabled": true, "intervalSec": 300, "wakeOnDemand": true, "maxConcurrentRuns": 3}},
   "sourceIssueId": "<issue-id>"
@@ -159,7 +169,8 @@ Before sending a hire request:
 - set a concrete `icon` from `rudder agent icons` so the new hire is identifiable in org and task views
 - avoid secrets in plain text unless required by adapter behavior
 - ensure the reporting line is correct and in-org
-- ensure the prompt is role-specific and operationally scoped; it should become the agent's `SOUL.md`, not a copy of Rudder's shared operating contract
+- ensure the prompt is role-specific, operationally scoped, and structured enough to become the agent's durable `SOUL.md`
+- include mission, responsibilities, boundaries, decision principles, voice, and continuity when the role has ongoing authority
 - prefer `sourceIssueId` or `sourceIssueIds` in the hire payload instead of manual approval linking
 - if board requests revision, update the payload and resubmit through the approval flow
 - do not report success unless `rudder agent hire` itself succeeded and you can cite the returned `agent.id` or `approval.id`

package/skills/rudder-create-agent/references/api-reference.md

@@ -90,7 +90,7 @@ Request body:
   "agentRuntimeConfig": {
     "cwd": "/absolute/path",
     "model": "o4-mini",
-    "promptTemplate": "You are the CTO. Own technical strategy, architecture, engineering execution, and quality bars."
+    "promptTemplate": "# SOUL.md -- CTO Persona\n\nYou are the CTO.\n\n## Mission\nOwn technical strategy, architecture, engineering execution, and quality bars.\n\n## Responsibilities\n- Set technical direction and execution standards.\n- Review architecture and staffing trade-offs.\n- Keep delivery risks visible and actionable.\n\n## Boundaries\n- Do not approve risky shortcuts without naming the trade-off.\n- Escalate product or budget ambiguity instead of guessing.\n\n## Decision Principles\n- Prefer simple architectures with explicit trade-offs.\n- Treat reliability, developer velocity, and product learning as linked constraints.\n\n## Voice\nDirect, specific, and evidence-led.\n\n## Continuity\nPreserve durable technical standards, repeated failure patterns, and long-running architecture decisions in memory or explicit instructions."
   },
   "runtimeConfig": {
     "heartbeat": {
@@ -141,7 +141,8 @@ Important notes:
 
 - `name` is optional; if omitted or blank, Rudder assigns a distinct first name automatically
 - `desiredSkills` accepts organization skill ids, canonical keys, or a unique slug; the server resolves and stores canonical organization skill keys
-- `agentRuntimeConfig.promptTemplate`, when present for local runtimes, is role/persona content that Rudder materializes as managed `SOUL.md`
+- `agentRuntimeConfig.promptTemplate`, when present for local runtimes during hire, is role/persona content that Rudder materializes as managed `SOUL.md`
+- write hire-time `promptTemplate` as a durable SOUL document with mission, responsibilities, boundaries, decision principles, voice, and continuity when the role has ongoing authority
 - do not put Rudder's shared operating contract in `promptTemplate`; supported local runtimes inject that contract from code
 - `sourceIssueId` and `sourceIssueIds` are the canonical way to link the hire back to originating issues
 - this route is preferred over creating `hire_agent` approvals manually because it preserves the organization's approval policy

package/skills/rudder-create-agent/references/cli-reference.md

@@ -65,7 +65,7 @@ rudder agent hire --org-id "$RUDDER_ORG_ID" --payload '{
   "agentRuntimeConfig": {
     "cwd": "/abs/path/to/repo",
     "model": "o4-mini",
-    "promptTemplate": "You are the CTO. Own technical strategy, architecture, engineering execution, and quality bars."
+    "promptTemplate": "# SOUL.md -- CTO Persona\n\nYou are the CTO.\n\n## Mission\nOwn technical strategy, architecture, engineering execution, and quality bars.\n\n## Responsibilities\n- Set technical direction and execution standards.\n- Review architecture and staffing trade-offs.\n- Keep delivery risks visible and actionable.\n\n## Boundaries\n- Do not approve risky shortcuts without naming the trade-off.\n- Escalate product or budget ambiguity instead of guessing.\n\n## Decision Principles\n- Prefer simple architectures with explicit trade-offs.\n- Treat reliability, developer velocity, and product learning as linked constraints.\n\n## Voice\nDirect, specific, and evidence-led.\n\n## Continuity\nPreserve durable technical standards, repeated failure patterns, and long-running architecture decisions in memory or explicit instructions."
   },
   "runtimeConfig": {"heartbeat": {"enabled": true, "intervalSec": 300, "wakeOnDemand": true, "maxConcurrentRuns": 3}},
   "sourceIssueId": "<issue-id>"
@@ -80,7 +80,7 @@ Canonical semantics:
 
 Do not use `rudder approval create --type hire_agent` as a replacement for `agent hire` during normal skill execution. That is a lower-level compatibility surface and does not preserve the canonical direct-create behavior.
 
-`agentRuntimeConfig.promptTemplate`, when used, is for role/persona content. Rudder materializes it as the managed instruction bundle's `SOUL.md`. Do not include Rudder's shared operating contract in this field; supported local runtimes inject that contract from code.
+`agentRuntimeConfig.promptTemplate`, when used during hire, is for role/persona content. Rudder materializes it as the managed instruction bundle's `SOUL.md`. Write it as a durable SOUL document with mission, responsibilities, boundaries, decision principles, voice, and continuity when the role has ongoing authority. Do not include Rudder's shared operating contract in this field; supported local runtimes inject that contract from code.
 
 ### Approval follow-up