--- name: weekly-tech-brief description: Compress a week of technical news into one scannable page of HTML cards — original titles kept verbatim, explanations in short sentences, and every item ending in something concrete the reader can act on. Use when the user wants a weekly digest, tech brief, news roundup, or research summary rendered as a readable page rather than a wall of Markdown. --- # Weekly tech brief cards **Intent.** The reader is a busy engineer. She opens this page on the train or before bed and has **three minutes** to learn what happened this week and what touches her work. The goal isn't for her to read it — it's for her to scan it and stop on two or three things, knowing what to do next. --- ## 1. The easy mistake: treating "simplify" as "rewrite" **Explanations can be simplified. Facts cannot.** Titles, paper names, project names, metric names, quotes — these are what the reader will later search for, cite in an interview, or put on a résumé. Paraphrase them and they're worthless. ### Original text must survive verbatim - **News headlines, paper titles, and project names appear exactly as published.** Not one word changed. - Put the translation on a **separate line underneath**, in smaller type or a muted color. It is a translation, not a rewrite. - Papers also need: authors (first two + et al.), venue or arXiv ID, date. If you don't have one, write "unconfirmed." - Quotes stay in quotation marks, in the original language. - **Never** describe a title in your own words. `a new paper on time-series forecasting` is noise; `Chronos-Bolt: Fast and Accurate Zero-Shot Forecasting` is usable. Correct shape: ``` Title (original) Chronos-Bolt: Fast and Accurate Zero-Shot Forecasting Title (translated) Source Amazon Science · arXiv:2503.xxxxx · 2026-08-18 ``` --- ## 2. How to write the explanations: short sentences, plain words - **One idea per sentence.** Over 25 words, split it. - **At most one technical term per sentence.** Two or more, split it. - **Lead with verbs.** "It hands the forecast straight to the scheduler," not "it achieves deep coupling between prediction and scheduling decisions." - **Banned**: leverage, paradigm shift, game-changing, and their equivalents in any language. - Plain doesn't mean shallow. Version numbers, metrics, and limitations belong in. - **Keep it short overall.** Three items explained properly beat eight half-sentences. ### Terminology: the original term wins When the reader learned a concept in English, a literal translation is worse than useless — she won't recognize it. - **Use the original term.** Don't translate `conformal prediction` into a local calque. - Follow it with a **plain-language gloss of at most a dozen words**, explaining what it *does* — not what it's called in another language. - Good: `conformal prediction (attaches a trustworthy range to a prediction)` - Bad: `conformal prediction ()` — the parenthesis carries no information - Where the local word is genuinely standard and more natural (cache, throughput, latency, concurrency, scheduling, sampling), just use it. No gloss needed. - **Product, library, and metric names stay as-is**: Airflow, vLLM, Snowflake, CRPS, p99, KV cache, LoRA. Never translated, never annotated. - Gloss each term **once per brief**, then use it bare. --- ## 3. How to write "why this matters to you" This is the only section that genuinely serves the reader. - **Open with the connection in one sentence.** No throat-clearing, no "as the industry evolves." - **If the item is just worth knowing**, stop after that sentence. Don't manufacture an action item. - **If it's worth learning, or could go on a résumé**, give a **concrete, actionable** example — pick one: - **A project to build** — small enough for a weekend; state the input, the output, and the library - **Which direction or which kind of company uses it** — name an industry or company type, never "lots of companies" - **How to write it on a résumé** — a real, usable bullet - **Résumé bullets are bilingual: the original-language bullet first, translation on the line below.** The English bullet follows US résumé convention — starts with a verb, carries a quantified result, fits in two lines. Correct shape: ``` Why this matters to you Same class of problem as the data quality checks you already own. A project you could build Forecast your own Airflow DAG runtimes with Chronos-Bolt; alert when a run exceeds the predicted range. Input is historical task duration, output is a p90 upper bound. One weekend. Résumé bullet EN Built a forecasting-based alerting layer for Airflow pipelines, cutting false-positive runtime alerts by 60% versus static thresholds. ``` --- ## 4. Required structure 1. **Header** — brief name + date range + one line summarizing the week (under 20 words). 2. **Three items of the week** — three large cards, each with: - `Title (original)` — verbatim - `Title (translated)` — secondary styling - `What happened` — two sentences max - `Why this matters to you` — per section 3, set off with a background tint or left border - Source link (clickable, showing the domain) + date - 1–3 tag pills 3. **Projects worth a look** — 3–5 small cards: original project name, one line on what it does, why this week, link. 4. **Papers** — 2–3 cards, each with: - `Title (original)` + `Title (translated)` - Authors, venue / arXiv ID, date - `Method` — one or two sentences - `Why it matters` — one sentence - Link 5. **Hiring signals** — one card listing concrete signals (who's hiring, what requirements shifted, salary bands). If there were none this week, say so. 6. **Something to post** — a title + a ~150-word opening + a copy button. 7. **Footer** — generation time + a line reminding the reader to verify via the links. --- ## 5. Design requirements - Single-file HTML. All CSS and JS inline. No external scripts. - **Card layout** — one item per card, generous whitespace between cards. Not one long article. - Strong hierarchy: original title largest, translation a step down and muted, `Why this matters to you` visually separated by tint or left border. - Wrap résumé bullets in a monospace or tinted block, one line per language, easy to copy. - For mixed-script text, use a CJK-first font stack and line-height of at least 1.7. 8px baseline grid. Body contrast ≥ 4.5:1. - **Theme-aware**: define colors as CSS variables on `:root`, redefine them under `@media (prefers-color-scheme: dark)`, and set an explicit background on `body`. - **Readable on a phone**: card grids use `repeat(auto-fit, minmax(280px, 1fr))`; wide content scrolls inside its own container; the page itself never scrolls sideways. - Restrained palette: one accent plus a neutral ramp. No rainbows. - No charts unless the data genuinely deserves one. This is a brief, not a dashboard. --- ## 6. Hard prohibitions - **Never paraphrase a title.** Not one word. - **Never invent** paper titles, authors, arXiv IDs, version numbers, star counts, or salary figures. Unsure means write "unconfirmed" or drop the item. - Every item needs a real, clickable source link. No link, no item. - If a section has nothing this week, say "nothing this week." Padding is worse than a gap. - Do not output Markdown. The deliverable is an `.html` file. --- *[中文版本 / Chinese version](./SKILL.zh-CN.md)*