chore: refresh kendex renders

.agents/skills/communication/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: communication
+description: "Load before writing a message to a person: a reply, report, briefing, decision request, or issue or comment addressed to the user."
+summary: "Plain-language messages, reader modes, decision questions, reports, threads and spoken replies."
+license: MIT
+user-invocable: true
+metadata:
+  author: vanillagreen
+  source: kendex
+  repository: "https://github.com/vanillagreencom/kendex"
+  bugs: "https://github.com/vanillagreencom/kendex/issues"
+tags: [communication]
+---
+
+# Communication
+
+## Scope
+
+Use this package for messages to a person. Agent-to-agent messages, literal return formats, tool prompts, documentation and text sent as the user follow their own owners. The caller owns authority, delivery and report schedules.
+
+## Reading routes
+
+Read [messages](references/messages.md) before every message. Add only the reference the task needs:
+
+| Task | Read |
+|---|---|
+| Request a decision or action | [questions](references/questions.md) |
+| Write a report or briefing | [reports](references/reports.md) |
+| Answer a voice request | [voice](references/voice.md) |
+
+## User instruction
+
+The supported installed path is `.agents/skills/communication/SKILL.md`, relative to the consumer project or assistant home. Its user instruction file carries this writing reference:
+
+```text
+Before writing a message to a person, read `.agents/skills/communication/SKILL.md`.
+```

.agents/skills/communication/references/messages.md

@@ -0,0 +1,80 @@
+# Messages to a person
+
+Read before writing any message to a person.
+
+## Reader modes
+
+Use the reader mode the caller supplies. The default prose is for a CEO with moderate technical knowledge.
+
+| Mode | Prose |
+|---|---|
+| `ceo` | Say what the thing does and why it matters. Report the outcome and its cost. Name a tool, file, command or mechanism only when the person must act on it. Expand unfamiliar jargon. Keep common terms such as AI, CPU and API. |
+| `engineer` | Use the session's technical vocabulary for the same outcomes and costs. |
+
+## Plain language
+
+- Write in ASD-STE100 Simplified Technical English.
+- Start with the answer itself, stated as a fact. Give no summary, preamble, verdict or unrelated opening fact.
+- Say what happened and what it means for the work. Name no generation, pane, token count, seat, mailbox id or internal rule unless the person must act on it.
+- Stop after the last fact. Write no closing sentence.
+- Put one idea in each short sentence. Use active voice.
+- Cut generic sentences. Keep specific facts the reader needs: numbers, names and mechanisms.
+- Never say that a fact is worth noticing.
+- Do the work, then report it. Never narrate what you are about to do.
+- Use no long dash, including after a bold label. Use a colon.
+- Use short bullets as the default.
+- Never mention these writing rules or say what you will not do.
+- Never rate, rank, praise or sell, even when asked. This includes superlative framing. A heading names a topic, not a verdict.
+- Name the real thing. Do not stack clauses or use insider shorthand. Replace abstract words such as signal, surface, shape, posture, residue, substrate and predicate with the real noun.
+- Avoid: delve, landscape, testament, interplay, serves as, robust, seamless, and leverage as a verb.
+- Give full detail on request. Never trade correctness for brevity.
+
+## Evidence and costs
+
+- Use a number only when you saw it in this session's output. Otherwise name the thing without the number. Never estimate or run an extra command only to fill that gap.
+- Give every number its yardstick and verdict in the same bullet: the earlier value, target or normal range; good, bad or not known; and what is done about it. If the yardstick is unread, say so and name the reading that settles it.
+- Give a measure that depends on load with that load: session length beside the work handled, or machine use beside what ran. Length or use alone never claims an improvement.
+- Before posting, read each topic as the person and ask "so what for me?". Add that answer or cut the topic.
+- State a cost as its figure and source. Compare added CI time against the plan's 50,000 private-repository minutes each month.
+
+The yardstick, load and so-what rules come from the owner's Slack messages 1792172820, 1792172887 and 1792172957, relayed in Jarvis note 1792173119.
+
+## Impact and odds
+
+When describing a mechanism, give its effect on the person and the likelihood of that effect.
+
+## Message purpose
+
+- Omit acknowledgements, unneeded mechanisms and history that do not affect the person's action.
+- A critical notice states the failure, its effect and the action the person must take.
+- When introducing a rule or setting, name the file or service that will hold it.
+
+## Medium and threads
+
+- Use the medium where the person started the conversation. Chat and voice connectors are the person's choice. Voice replies go to the call only.
+- Keep one topic per post and per thread. Reply in the thread of the message answered, or its containing thread. Continue that topic there until the person changes topic. Keep thread replies in their threads.
+- Answer each message in its own thread. If a fact answers two messages, give a short answer in each thread.
+- A new topic, decision request, critical notice or progress report starts at the top level.
+- Read only the thread of the message answered. Read its history when needed, not unrelated channel history.
+- Follow the person's reporting cadence and quiet hours. The person defines which critical notices can interrupt them.
+
+## Times
+
+Write times in the person's time zone with am or pm. Do not use a `Z` stamp.
+
+## References and markup
+
+- Link each pull request, commit, issue and tracker item with its short name. Use `[REPO#N](https://github.com/OWNER/REPO/pull/N)`, `[SHORT_SHA](https://github.com/OWNER/REPO/commit/SHORT_SHA)` or `[KEY-N](TRACKER_ISSUE_URL)` as the form. Never put a tracker id in a code span.
+- For standard Markdown, put blank lines between paragraphs, around lists and before labels. Use numbered lists for steps or options and bullets for parallel facts.
+- Use headings and bold labels or decisions for structure. Never use bold for emphasis or on a whole sentence. Use sentence case. Use italics seldom.
+- Use inline code for a command or path. Use a code block for output longer than one line. Keep paragraphs to a few sentences.
+- Put text the person must send in a code block. Name the recipient above it.
+- Beside a file, including a Slack file comment, use Slack mrkdwn: `*Label*` for bold, `<URL|LABEL>` for a link and plain lines for a list. The other markup rules still hold.
+
+## Corrections
+
+Own a mistake in one line, with its repair.
+
+## Attachments
+
+Attach a screenshot or image when it explains the point better than words.

.agents/skills/communication/references/questions.md

@@ -0,0 +1,43 @@
+# Questions
+
+Read when requesting a decision or action. The caller decides whether to ask and which options it can offer.
+
+## Decision requests
+
+Ask one question per message. Give the options and a recommendation. Each option states its gain, its cost and the likelihood of that cost. Use the reader mode from [messages](messages.md#reader-modes).
+
+## CEO questions
+
+```text
+[WHAT THIS CHANGES FOR THE USER, ONE SENTENCE]
+
+**A. [OUTCOME OF THE FIRST PATH]**
+
+[ONE OR TWO PLAIN SENTENCES SAYING WHAT THE USER GETS, WHAT IT COSTS THEM AND HOW LIKELY THAT COST IS]
+
+**B. [OUTCOME OF THE SECOND PATH]**
+
+[ONE OR TWO PLAIN SENTENCES SAYING WHAT THE USER GETS, WHAT IT COSTS THEM AND HOW LIKELY THAT COST IS]
+
+**Recommended:** [A OR B], because [ONE SENTENCE IN OUTCOME TERMS].
+```
+
+Use outcomes only. Name no mechanism the person does not act on and no option by its internal name.
+
+## Engineer questions
+
+```text
+[QUESTION]: [OPTION_A] | [OPTION_B], with [RECOMMENDED_OPTION] recommended.
+```
+
+## Action requests
+
+Use plain words to say what the person does and what evidence closes the request. State what the deadline does. Omit the recommendation when the caller's ask form records none.
+
+## Opening question
+
+When the caller offers `idle` and `tracker` for an empty work queue, use:
+
+```text
+What do you want to work on? Reply with issue ids or describe it, or answer tracker to take work from the tracker. With no answer by the deadline I wait for your reply.
+```

.agents/skills/communication/references/reports.md

@@ -0,0 +1,58 @@
+# Reports and briefings
+
+Read when writing a report or briefing. Use the wording and markup in [messages](messages.md).
+
+## Reports
+
+Say the outcome for the person or fleet, not the issue title. Link each work item to its owning tracker issue: the Linear issue for a Linear item or the GitHub issue for an `issue-N` item. Do not use its pull request or commit as the work-item link. The tracker issue links to its pull request.
+
+Put detail in the report file. Send one post per report, not a thread of fragments. Give each blocked item its cause and next action.
+
+## Report opening
+
+Open with the repository's outcome readings, each with its date and source. Reuse existing evidence comments and rulings. Do not open with a Landed count.
+
+## Evidence
+
+List completed work only after its acceptance check passes. Put a merge under Landed only after reading it from the source service in this session. An agent's notice that it is merging, or an approval, is not a landing.
+
+## Waiting on you
+
+End with **Waiting on you**, with `Nothing` when empty. Read current open requests and the person's replies since the last report when writing it. Do not copy this section from a handoff. Keep a step here only when no available tool can do it.
+
+Name each open ask by its question, so the person can find its thread. Link each unanswered decision. State what its deadline does and when, using the [person's time zone](messages.md#times). This section is never empty while an ask is open.
+
+## Account headroom
+
+Report account headroom for every harness the fleet runs, including Claude, Codex and Copilot, side by side.
+
+## Summary shape
+
+- Put one item per line, at most 20 words. A line may carry two links.
+- Put a blank line before each label. Each label stands alone: **Landed**, **Running**, **Blocked**, **Waiting on you**.
+- Put each figure on its own line. Group account headroom after the opening outcome readings.
+- Use at most `ORCH_REPORT_SUMMARY_LINES` item lines for an orch report, default 20. Blank lines, labels and the first opening line do not count. Leave excess items in the report file. Never pack a line to fit the cap.
+- Use no table in an owner message.
+
+## Owner summary template
+
+Use this mrkdwn template for the report file's comment. For a post without a file, use standard Markdown under [References and markup](messages.md#references-and-markup).
+
+```text
+[DATE]: [REPOSITORY OUTCOME READING] (<SOURCE URL|SOURCE>)
+[DATE]: [REPOSITORY OUTCOME READING] (<SOURCE URL|SOURCE>)
+
+[ACCOUNT HEADROOM FIGURE]
+
+*Landed*
+- [OUTCOME] (<https://linear.app/vanillagreen/issue/KEY-N|KEY-N>)
+
+*Running*
+- [OUTCOME IN PROGRESS] (<https://linear.app/vanillagreen/issue/KEY-N|KEY-N>)
+
+*Blocked*
+- Nothing
+
+*Waiting on you*
+- Nothing
+```

.agents/skills/communication/references/voice.md

@@ -0,0 +1,13 @@
+# Voice replies
+
+Read when answering a voice request.
+
+## Spoken reply
+
+- Answer a voice request before resuming other work. If the answer needs work, say what is needed in the spoken reply.
+- Start with the answer in one or two spoken sentences. Use plain spoken words, no Markdown and no links. Say numbers as a person says them. Name an id only when the caller must act on it.
+- Include the spoken answer only. End the spoken paragraph with one question or next step.
+
+## Action acknowledgement
+
+Before an approved action, say the exact action back in one sentence. The caller's authority and confirmation rules decide whether approval permits that action.

.agents/skills/linear/scripts/lib/formatters.sh

@@ -11,6 +11,7 @@ readonly ISSUE_BLOCKED_BY_FIELDS="inverseRelations { pageInfo { hasNextPage endC
 readonly ISSUE_RELATION_FIELDS="$ISSUE_BLOCKS_FIELDS $ISSUE_BLOCKED_BY_FIELDS"
 readonly ISSUE_RELATION_JQ='
 def issue_is_open: (.state.type | IN("completed", "canceled") | not);
+def issue_blocks_launch: issue_is_open and .state.name != "Verifying";
 def issue_blocks_relations($relations): [($relations // [])[] | select(.type == "blocks")];
 def issue_blocks_ids($relations): issue_blocks_relations($relations) | map(.relatedIssue.identifier);
 def issue_blocks_open_ids($relations): issue_blocks_relations($relations) | map(select(.relatedIssue | issue_is_open) | .relatedIssue.identifier);
@@ -21,6 +22,7 @@ def issue_blocked_by_open_relations($relations): issue_blocked_by_relations($rel
 def issue_blocker_row: {id: .issue.identifier, title: .issue.title, state: .issue.state.name};
 def issue_blocked_by_ids($relations): issue_blocked_by_relations($relations) | map(.issue.identifier);
 def issue_blocked_by_open_ids($relations): issue_blocked_by_open_relations($relations) | map(.issue.identifier);
+def issue_blocked_by_launch_ids($relations): issue_blocked_by_relations($relations) | map(select(.issue | issue_blocks_launch) | .issue.identifier);
 def issue_blocked_by_rows($relations; $with_relation_id): issue_blocked_by_relations($relations) | map(issue_blocker_row + if $with_relation_id then {relation_id: .id} else {} end);
 def issue_blocked_by_open_rows($relations; $with_relation_id): issue_blocked_by_open_relations($relations) | map(issue_blocker_row + if $with_relation_id then {relation_id: .id} else {} end);
 # A related relation is one record Linear shows on both issues: the side that
@@ -135,6 +137,7 @@ format_issue_single() {
         blocks: issue_blocks_ids(.issue.relations.nodes),
         blocked_by: issue_blocked_by_ids(.issue.inverseRelations.nodes),
         blocked_by_open: issue_blocked_by_open_ids(.issue.inverseRelations.nodes),
+        blocked_by_launch: issue_blocked_by_launch_ids(.issue.inverseRelations.nodes),
         related: issue_related_ids(.issue.relations.nodes; .issue.inverseRelations.nodes),
         url: (.issue.url // "")
     } + (if (.issue | has("syncedWith")) then {

.agents/skills/orch/README.md

@@ -50,7 +50,7 @@ Until KEN-2466 lands, the Claude Code agent renderer maps `haiku` to `sonnet` an
 | `REVIEW_MAX_CYCLES` | Re-review cycles per issue. `0`: one blockers-only fix round, accepted on its validation without re-review; `1`: one fix round and one re-review of its diff | `1` |
 | `REVIEW_MAX_EXTERNAL_ROUNDS` | External comment-triage passes and automatic review-wait restarts on one PR head | `4` |
 | `REVIEWER_SLOT_BUDGET` | Concurrent agent-session budget counting the primary; `0` is unlimited; reviews run in waves past it. On Codex, the cap `spawn-adapter slots` reports | `0` |
-| `ORCH_USER_MODE` | `ceo` or `engineer`, and what each asks: [communication-modes.md](references/communication-modes.md) | `ceo` |
+| `ORCH_USER_MODE` | `ceo` or `engineer`: [ask set and composition](references/communication-modes.md), [prose](../communication/references/messages.md#reader-modes) | `ceo` |
 | `ORCH_DECISION_MODE` | `ask` presents decision points; `auto-recommended` takes the recommended one | `auto-recommended` |
 | `ORCH_MERGE_AUTONOMY` | `auto` merges once every gate is green on authorization already given; `ask` requires it per merge | `auto` |
 | `PM_CREATE_AUTONOMY` | Audit creation and cancellation: [project-management settings](../project-management/README.md#setup) | `ask`; `auto` under `ceo` |