docs(skill): guide a descriptive publish message + bump 0.6.4 -> 0.6.5

.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
     {
       "name": "outsystems",
       "description": "Edit, publish, deploy, and search OutSystems apps from your AI assistant.",
-      "version": "0.6.4",
+      "version": "0.6.5",
       "author": {
         "name": "OutSystems AI Platform"
       },

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "outsystems",
   "description": "Edit, publish, deploy, and search OutSystems apps from your AI assistant.",
-  "version": "0.6.4",
+  "version": "0.6.5",
   "author": {
     "name": "OutSystems AI Platform"
   },

SKILL.md

@@ -101,7 +101,7 @@ The context lookups index by **visibility**, not ownership: app-scoped queries r
 **Edit an existing app and ship it:**
 1. First turn: start a mentor run with the `app_key` and your prompt (e.g. "Add a due date field to Task"). It returns a `runId`; poll the run with its `cursor` until terminal, then pull `mentor_session_id` + `mentor_session_token` out of the result.
 2. Optional follow-up turns: start another run passing `mentor_session_id` + `mentor_session_token` and your next prompt, and poll the same way. Each terminal result returns a fresh token; use the newest one next.
-3. Publish the edited OML with `mentor_session_id` + `mentor_session_token` + `env_key`; it returns a publication id. An optional `message` (max 500 chars) attaches a publish note to the created revision — the same note ODC Studio's "1-Click Publish with message" sets; over-length is rejected up front, and attaching the note is best-effort so a failure to attach it doesn't fail the publish.
+3. Publish the edited OML with `mentor_session_id` + `mentor_session_token` + `env_key`; it returns a publication id. An optional `message` (max 500 chars) attaches a publish note to the created revision — the same note ODC Studio's "1-Click Publish with message" sets; over-length is rejected up front, and attaching the note is best-effort so a failure to attach it doesn't fail the publish. Make good use of it: pass a `message` that summarizes what this publish changed (and why) — a useful revision note up to the 500-char limit, not empty or a single word.
 4. Poll the publication status until terminal. Pull the publication logs for messages on failure.
 
 **Promote a build across environments:**

kiro/outsystems/POWER.md

@@ -105,7 +105,7 @@ Workflows below show MCP tool form. Identity (tenant + user) is derived from the
 
 1. `mentor_start { app_key: "<key>", prompt: "Add a due date field to Task" }` → returns `runId`. Poll `mentor_get_run { runId, cursor }` until terminal; pull `mentor_session_id` + `mentor_session_token` out of `result`. On a failed/cancelled terminal the `error` carries `mentor_session_id` + `mentor_session_token` (and a `hint` on `OS-AISA-40001`) — resume the same session with those rather than starting fresh, unless the error `code` is `session_not_found` or this first `app_key` turn failed to initialize (a bare error with no credentials, e.g. `oml_download_failed`); in either case start a fresh `app_key` session.
 2. (Optional) Follow-up turns: `mentor_start { mentor_session_id, mentor_session_token, prompt: "..." }` and poll the same way. Each terminal result returns a fresh token; use the newest one next. If the conversation hits its max length (`OS-AISA-40001`) or mentor starts hallucinating, add `fresh_context: true` to the resume call — it starts a new conversation over the session's *current* OML while keeping the session slot and any unpublished edits (boolean, JSON `true`; ignored on a first `app_key` turn; a server that predates the flag rejects the call). Start a run *without* `mentor_session_*` only to reset the OML to pristine or move to an unrelated app.
-3. `publish_start { mentor_session_id, mentor_session_token, env_key: "<env>", message: "<publish note>" }` → returns `publication_id`. The `message` is optional — it attaches a publish note to the created revision (ODC Studio's "1-Click Publish with message"; max 500 chars — over-length is rejected up front; attaching the note is best-effort, so a failure to attach it does not fail the publish).
+3. `publish_start { mentor_session_id, mentor_session_token, env_key: "<env>", message: "<publish note>" }` → returns `publication_id`. The `message` is optional — it attaches a publish note to the created revision (ODC Studio's "1-Click Publish with message"; max 500 chars — over-length is rejected up front; attaching the note is best-effort, so a failure to attach it does not fail the publish). Make good use of it: pass a `message` summarizing what this publish changed (and why) — a useful revision note up to the 500-char cap, not empty or terse.
 4. Poll `publish_status { publication_id }` until terminal. On failure, `publish_logs { pub_key: publication_id }`.
 
 ### Workflow 3: Promote a build across environments

kiro/outsystems/steering/skill.md

@@ -130,7 +130,7 @@ The context lookups index by **visibility**, not ownership: app-scoped queries r
 **Edit an existing app and ship it:**
 1. First turn: start a mentor run with the `app_key` and your prompt (e.g. "Add a due date field to Task"). It returns a `runId`; poll the run with its `cursor` until terminal, then pull `mentor_session_id` + `mentor_session_token` out of the result.
 2. Optional follow-up turns: start another run passing `mentor_session_id` + `mentor_session_token` and your next prompt, and poll the same way. Each terminal result returns a fresh token; use the newest one next.
-3. Publish the edited OML with `mentor_session_id` + `mentor_session_token` + `env_key`; it returns a publication id. An optional `message` (max 500 chars) attaches a publish note to the created revision — the same note ODC Studio's "1-Click Publish with message" sets; over-length is rejected up front, and attaching the note is best-effort so a failure to attach it doesn't fail the publish.
+3. Publish the edited OML with `mentor_session_id` + `mentor_session_token` + `env_key`; it returns a publication id. An optional `message` (max 500 chars) attaches a publish note to the created revision — the same note ODC Studio's "1-Click Publish with message" sets; over-length is rejected up front, and attaching the note is best-effort so a failure to attach it doesn't fail the publish. Make good use of it: pass a `message` that summarizes what this publish changed (and why) — a useful revision note up to the 500-char limit, not empty or a single word.
 4. Poll the publication status until terminal. Pull the publication logs for messages on failure.
 
 **Promote a build across environments:**

skills/outsystems/SKILL.md

@@ -128,7 +128,7 @@ The context lookups index by **visibility**, not ownership: app-scoped queries r
 **Edit an existing app and ship it:**
 1. First turn: start a mentor run with the `app_key` and your prompt (e.g. "Add a due date field to Task"). It returns a `runId`; poll the run with its `cursor` until terminal, then pull `mentor_session_id` + `mentor_session_token` out of the result.
 2. Optional follow-up turns: start another run passing `mentor_session_id` + `mentor_session_token` and your next prompt, and poll the same way. Each terminal result returns a fresh token; use the newest one next.
-3. Publish the edited OML with `mentor_session_id` + `mentor_session_token` + `env_key`; it returns a publication id. An optional `message` (max 500 chars) attaches a publish note to the created revision — the same note ODC Studio's "1-Click Publish with message" sets; over-length is rejected up front, and attaching the note is best-effort so a failure to attach it doesn't fail the publish.
+3. Publish the edited OML with `mentor_session_id` + `mentor_session_token` + `env_key`; it returns a publication id. An optional `message` (max 500 chars) attaches a publish note to the created revision — the same note ODC Studio's "1-Click Publish with message" sets; over-length is rejected up front, and attaching the note is best-effort so a failure to attach it doesn't fail the publish. Make good use of it: pass a `message` that summarizes what this publish changed (and why) — a useful revision note up to the 500-char limit, not empty or a single word.
 4. Poll the publication status until terminal. Pull the publication logs for messages on failure.
 
 **Promote a build across environments:**