replicas-cli 0.3.169 → 0.3.170
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/index.cjs +2 -2
- package/package.json +1 -1
package/dist/index.cjs
CHANGED
|
@@ -25694,7 +25694,7 @@ var SESSION_HISTORY_ABILITY = {
|
|
|
25694
25694
|
};
|
|
25695
25695
|
|
|
25696
25696
|
// ../shared/src/slack-response-style.ts
|
|
25697
|
-
var SLACK_CONCISE_REPLY_SHAPE = 'short and easy to read. Lead with a concise, easy-to-skim answer; add depth when asked. Each send is a deliberate message, not an automatic split of a long answer. Simple requests need only a short answer or, where the surrounding instructions allow it, a fitting reaction. Use common, everyday words, simple sentences, and contractions where they sound natural. Avoid jargon, corporate language, and formal words when a plain word works. Start with what happened or what works now, then add only the context, limits, or next step people need. Cut repetition and play-by-play, but keep anything important. Put long logs and file-by-file recaps in the pull request or workspace unless the user asks for them. Never use em dashes; use a comma, period, colon, or parentheses. Skip filler openers ("Great question", "Good catch", "Happy to help"), stock AI words ("delve", "leverage", "seamless", "robust"), closing offers ("Let me know if you need anything else"), and a closing line that restates the answer';
|
|
25697
|
+
var SLACK_CONCISE_REPLY_SHAPE = 'short and easy to read. Lead with a concise, easy-to-skim answer; add depth when asked. When the answer is several items compared on the same fields (a ranking, numbers per team or customer, a before and after), send them as a Slack `table` block with a header row, not a numbered or bulleted list. Each send is a deliberate message, not an automatic split of a long answer. Simple requests need only a short answer or, where the surrounding instructions allow it, a fitting reaction. Use common, everyday words, simple sentences, and contractions where they sound natural. Avoid jargon, corporate language, and formal words when a plain word works. Start with what happened or what works now, then add only the context, limits, or next step people need. Cut repetition and play-by-play, but keep anything important. Put long logs and file-by-file recaps in the pull request or workspace unless the user asks for them. Never use em dashes; use a comma, period, colon, or parentheses. Skip filler openers ("Great question", "Good catch", "Happy to help"), stock AI words ("delve", "leverage", "seamless", "robust"), closing offers ("Let me know if you need anything else"), and a closing line that restates the answer';
|
|
25698
25698
|
var SLACK_QUOTE_REPLY_GUIDANCE = "Use a short Slack blockquote (`> quoted text`) only when answering a specific earlier message or when the reply would otherwise have an unclear referent. Quote only the relevant line; do not quote the latest message by default, repeat the full request, or add a blockquote when the reply is already unambiguous. Escape the leading `<` in raw Slack mention and control markup such as `<@U\u2026>` and `<!channel>` as `<` before quoting so it cannot notify anyone.";
|
|
25699
25699
|
var SLACK_BLOCK_KIT_GUIDANCE = "Use Block Kit whenever structure or a link would make the message faster to scan or use. Before composing a structured message, read Slack's live [block catalog](https://docs.slack.dev/reference/block-kit/blocks) and the linked schema for each block you plan to use; do not rely on memory for which blocks exist or their fields. You have broad leeway to use display-only blocks and `actions` with URL buttons, but do not add controls that require an interaction callback. Keep simple replies as plain text, do not add decorative UI or repeat content across blocks, and always keep `text` as a concise, complete fallback for notifications and accessibility.";
|
|
25700
25700
|
var SLACK_PR_BUTTON_GUIDANCE = 'The first time you share a given pull request or merge request link in a thread (the message announcing you opened it), attach a button for it: send `blocks` alongside `text`, with a `section` block holding your message as `mrkdwn`, then an `actions` block with one element per newly shared link, `{"type": "button", "style": "primary", "text": {"type": "plain_text", "text": "View PR"}, "url": "<pr url>", "action_id": "view_pr"}`. Later messages about a pull request you already linked in this thread keep the link in the sentence and get no button, and never re-post a button for a link someone already has. Label it "View MR" for GitLab, and if there are several give each button a unique `action_id` and name its repository in the label ("View PR \xB7 web"). Always keep `text` populated with the same message, since Slack uses it for notifications and fallback, and keep the link in the sentence too.';
|
|
@@ -29094,7 +29094,7 @@ var headlessAgentRequestSchema = external_exports.object({
|
|
|
29094
29094
|
});
|
|
29095
29095
|
|
|
29096
29096
|
// ../shared/src/cli-version.ts
|
|
29097
|
-
var CLI_VERSION = "0.3.
|
|
29097
|
+
var CLI_VERSION = "0.3.170";
|
|
29098
29098
|
|
|
29099
29099
|
// ../shared/src/version.ts
|
|
29100
29100
|
function compareVersions(v1, v2) {
|