/by-display

id: "skill_927c0230b96941e0ada299a50ccee03c"
name: "by-display"
display-name: "BY Display"
short-description: "Canonical display formats and conversational patterns for BY terminal output — banners, score bars, status tables, progress, errors, and checkpoints. Use when rendering any user-facing output so every skill speaks with the same voice."
category: "display"
keywords: "display, formatting, output, terminal, banner, progress bar, score bar, status table, screening report, error message, checkpoint, conversational pattern, ANSI, unicode, box drawing"
version: "1.0"
last-updated: "2026-05-20"

BY Display Patterns

Standard display formats for **all** campaign output. They use Unicode box-drawing characters and markdown that render natively in Claude Code's terminal. **Never use ANSI escape codes in response text** — they render as literal characters.

Every other BY skill (research, screening, scoring, campaign-manager, ...) calls into these templates when it is time to talk to the user. This file is the canonical source; the literal templates live in [`references/output-format-spec.md`](references/output-format-spec.md) so other skills can copy them verbatim.

---

When to Use This Skill

Use this skill when you are:

• ✅ **Rendering campaign status** for `/by:status`, `/by:watch`, or phase transitions
• ✅ **Formatting screening reports** (liabilities, developability, structure scores)
• ✅ **Showing ranked results** for `/by:results` or any final campaign output
• ✅ **Displaying errors or quota warnings** that need user attention
• ✅ **Presenting a checkpoint or safety gate** that requires explicit user approval
• ✅ **Streaming progress** during long-running design/fold jobs
• ✅ **Closing a phase** — every major phase ends with a "Next Up" block

Do NOT use this skill when:

• ❌ **You need to compute scores** — that is `by-scoring`; this skill only renders them
• ❌ **You need to run a screening battery** — that is `by-screening`
• ❌ **You need to decide what to do next** — that is `by-campaign-manager` / `by-design-workflow`
• ❌ **You need raw machine-readable JSON output** for another tool — emit JSON directly, not the human-facing templates here
• ❌ **You want to invent a new visual style** — extend the templates here instead of forking them

---

Inputs

This skill is consumed by other skills. Inputs are the data objects to be rendered:

**Required (one of):**

• **Campaign checkpoint object** — `{ campaign_id, target, phases: [{name, status, time, details}, ...], current_phase }`. Source: `by-campaign-manager` (campaign_state.json).
• **Ranked design list** — `[{ design_id, composite, ipSAE, ipTM, pLDDT, liabilities, verdict }, ...]`. Source: `by-scoring` / `by-screening`.
• **Screening report object** — `{ design_id, liabilities: {...}, developability: {...}, structure: {...}, verdict }`. Source: `by-screening`.
• **Progress event** — `{ phase, status (◆/✓/✗), message, elapsed }`. Source: any long-running skill.
• **Error object** — `{ title, details, suggested_next }`.

**Optional:**

• **Score scale overrides** — non-default thresholds for the `EXCELLENT/STRONG/...` labels on score bars (see `references/output-format-spec.md` §Score Bars).
• **Provider context** — `{ provider, tool, protocol, scaffold, budget }` shown in design-launch banners.

---

Outputs

Markdown strings printed to the terminal. No files written by this skill itself.

| Output | When | Template ID | |--------|------|-------------| | Campaign status banner | `/by:status`, phase transitions | `banner.campaign-status` | | Progress-during-design line | `/by:watch`, mid-pipeline | `progress.design` | | Ranked results table | `/by:results`, campaign close | `table.ranked-results` | | Screening battery report | `/by:screen`, per-design report | `report.screening` | | Score bar | Any 0-1 metric display | `bar.score` | | Error box | Quota / failure / warning | `box.error` | | Checkpoint box | Lab gate, approval gate | `box.checkpoint` | | Next-Up block | End of every major phase | `block.next-up` | | Long-running job submission | SSH / Tamarind dispatch | `block.job-submitted` | | Batch progress | Multi-job tracking | `block.batch-progress` | | Pipeline summary table | Campaign complete | `table.pipeline-summary` | | Inline progress (✓/◆/✗) | Between phases | `inline.progress` |

For the literal Unicode/ASCII templates, see [`references/output-format-spec.md`](references/output-format-spec.md).

---

Clarification Questions

⚠️ **CRITICAL: ASK THIS FIRST** — confirm there is something to render before invoking this skill.

1. **What are you trying to render? (ASK THIS FIRST)** — A campaign status, a ranked results table, a screening report, an error, or a checkpoint? Each maps to a different template. Without this, do not generate any output. 2. **Which data object do you have?** — Pass the campaign checkpoint, the ranked design list, or the screening report object. The skill cannot make up values; if a field is missing, leave it blank or mark `—` (em-dash). 3. **What is the audience?** — User-facing terminal output (this skill) vs. machine-readable JSON for another tool (do NOT use this skill). 4. **Is this an end-of-phase rendering?** — If yes, append the Next-Up block. If mid-phase, use the inline `◆/✓` progress format instead. 5. **Are there units to clarify?** — pLDDT is 0-100 (divide by 100 for the score bar); ipSAE and ipTM are 0-1 (use directly). RMSD is in Å, lower is better. 6. **Is a safety gate involved?** — If lab submission or any irreversible action is next, use the checkpoint box and require explicit user approval. Never auto-proceed past a checkpoint. 7. **Provider context available?** — Local GPU / HPC / Tamarind affects what shows in the design-launch banner. If unknown, fall back to "compute provider: see `.by/config.json`".

---

Standard Workflow

🚨 **MANDATORY: COPY TEMPLATES FROM `references/output-format-spec.md` VERBATIM — DO NOT IMPROVISE LAYOUT** 🚨

1. **Identify