@bompus/house-rules 0.11.0 → 0.14.0

package/skills/hr-what-next/references/reporting.md

@@ -6,26 +6,20 @@ for actions the user must perform.
 
 During long work, give frequent useful progress updates with completed evidence,
 the current action and what remains. Show clock-time forecasts in the user's
-local timezone. Use the timezone provided by the user or session environment;
-ask if neither establishes it.
+local timezone. Use the timezone provided by the user or session environment,
+including the host clock zone (`date +%Z`, or `Get-TimeZone` on Windows). Check
+it before reporting UTC or saying the zone is unknown; ask if neither
+establishes it.
 
-Use a visual when it makes a change, behavior or decision clearer; keep a short
-text explanation beside it. For visible interface changes, prefer actual
-before/after captures with comparable content, viewport and state when available.
-Label mockups and simulated behavior as illustrations, not verification. Use
-interaction when exploring states or alternatives helps the reader, and provide
-an accessible text or static equivalent. Use the host's available tools within
-existing browser and task authorization.
+For routine replies, aim for at most five items per list or group. Rank the
+items by relevance to the current task and retain undisplayed candidates in
+the ledger. When the user requests a full inventory, or needs more items to
+make a decision, show every relevant item. This presentation target does not
+limit investigation, required disclosures or the options required by § Offers.
 
-Use a Markdown table when comparing items on common criteria or reporting
-repeated records with useful shared fields. When asked about benefits,
-tradeoffs or how a proposal differs from current behavior, use a compact
-table for multiple items. Explain one item per row. For changes, show current
-and proposed behavior and why the difference matters. Include relevant
-tradeoffs and evidence or uncertainty; label unknowns rather than inventing
-gains. Keep columns consistent and cells short. Label missing or unverified values and put units in headings. Put
-explanations and caveats beside the table. Split wide tables or use lists when
-long cells obscure the comparison. Preserve § Offers and any enabled offer format.
+Use a visual when it makes a change or decision clearer, with a short text explanation beside it. For interface changes prefer real before/after captures with comparable content, viewport and state; label mockups as illustrations. Give an interactive visual a text or static equivalent.
+
+Use a Markdown table to compare items on shared criteria: one item per row, short cells, units in headings. For proposed changes, show current behavior, proposed behavior and why it matters. Label unknown or unverified values instead of inventing gains, and put caveats beside the table. Numeric before/after tables get a benefit column (percent or times; absolute when a ratio cannot be computed); label changes inside the noise band "no clear change". Keep any enabled offer format.
 
 When asked for a backlog, research list or remaining work, check the current
 session and relevant task records within the requested scope. Reconcile
@@ -50,10 +44,7 @@ Label expected gains and unknowns; do not invent measurements or scores.
 Keep priority separate from readiness, and preserve § Finishing work's
 requirements for continuing authorized work and making offers.
 
-Put the answer, and anything the user must read or act on, in the reply's text
-after its last tool call. Text written between tool calls can be collapsed or
-lost. When the reply ends with a question card, that text goes after every
-other tool call, right before the card.
+Put the answer and anything the user must act on in the text after the reply's last tool call; some hosts hide earlier text behind a summary row. Finish bookkeeping first. If a tool call must follow the answer, repeat the whole answer after it, with any closing lines the rules ask for (such as the parked-item note), unless that call is a question-card tool call. When the reply ends with a question-card tool call, that text goes right before the card.
 
 Verify work with completed checks and their output. Confirm each check's exit status or final
 result before claiming a pass, and do not hide failures by filtering output. Report changes,