Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› uist-writing-style
uist-writing-style
GitHub针对UIST论文写作与修订的指导技能。涵盖系统论文结构（先演示后机制）、具备技术深度的实现章节撰写、能力声明与图表/数据的严格对应，以及符合10页或5页双栏格式限制的论证优化。
Trigger Scenarios
起草或修改UIST会议论文
优化系统论文的实现部分细节
检查论文是否符合特定页数限制
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill uist-writing-style -g -y
SKILL.md
Frontmatter
{
"name": "uist-writing-style",
"description": "Use when drafting or revising a UIST paper — structuring the systems-paper arc (walkthrough before mechanism), writing an implementation section with real technical depth, pairing every capability claim with a figure or measurement, and fitting the argument inside the 10-page or 5-page two-column limit."
}
UIST Writing Style
A UIST paper is a guided tour of a working thing. The reader should experience the
system before dissecting it, believe the engineering because it is specified, and
finish knowing exactly which piece they could reuse. This is a different rhetoric
from an empirical HCI paper (argument from study design) and from an ML paper
(argument from benchmark deltas). Format facts below are the 2026 cycle's
(two-column acmart, 10-page standard / 5-page short, references and appendices
excluded); verify against the current Author Guide.
The UIST arc
| Section | Job | Failure smell |
|---|---|---|
| Abstract + teaser figure | Name the artifact, the enabling idea, one number | No artifact named; "we explore..." |
| Introduction | What becomes possible that wasn't; contribution list | Motivation essay with the system in ¶5 |
| Walkthrough / scenario | Reader operates the system vicariously, figure-driven | Mechanism dumped before experience |
| Design rationale | The 2-4 decisions that define the system, with rejected alternatives | A feature inventory |
| Implementation | Enough specificity to re-implement: architecture, algorithms, parts, timings | "Built in Unity" as the whole section |
| Evaluation | Evidence matched to claims (see uist-experiments) |
A ritual usability study proving nothing claimed |
| Applications | Breadth: 3-5 demonstrations the technique enables | Repeats of the walkthrough |
| Limitations | Engineering honesty: where it breaks, at what scale | Generic "future work will explore" |
The teaser figure under the title is load-bearing at UIST: many reviewers form their contribution hypothesis from it before reading a sentence. Design it to show the interaction, not the hardware on a bench.
Implementation prose that earns trust
Vague implementation writing is the most common style failure in UIST rejections. Specificity is cheap and convincing:
WEAK: "The system tracks the user's hand and updates the display with low latency."
STRONG: "A wrist-mounted IMU streams at 200 Hz over BLE; orientation is fused with
a complementary filter (α = 0.98) and mapped to cursor space in 1.8 ms
median (95th percentile 3.1 ms) on the target tablet, measured over
10,000 events with the harness in the supplement."
Rules of thumb:
- Every latency, accuracy, weight, or cost figure carries its measurement condition.
- Name the algorithm, then say what is non-obvious about applying it here — the novelty is usually in the adaptation, and reviewers who know the algorithm will check.
- Fabrication and hardware papers: include the parts, materials, and process details
a motivated lab needs; put the full bill of materials in the appendix (see
uist-reproducibility).
Claim discipline
- Claim capabilities, not superlatives: "supports freehand annotation on curved surfaces up to 40 cm" survives review; "the first system to enable natural annotation" invites a counterexample hunt.
- Every "the system can X" needs a figure, measurement, or application section
pointing at X. Reviewers at a demo-culture venue mentally run your video against
your claims (see
uist-supplementaryfor keeping the two synchronized). - Write your own prior work in the third person with full citations — UIST's anonymization rule, and also a useful humility device.
Fitting the page budget
The 10-page limit (5 for short papers) excludes references and appendices, so the compression targets are figures and mechanism prose:
- Merge walkthrough and rationale figures: one annotated sequence beats three screenshots.
- Move parameter tables, extended benchmark grids, and study instruments to the appendix — but keep the body self-contained; the 2026 guide is explicit that the body must be readable without the appendix.
- Cut applications last: breadth of demonstration is UIST evidence, not decoration.
- Never buy space with
\vspaceor margin tricks; over-limit and modified templates are desk-reject territory (seeuist-submission).
Figures do half the arguing
UIST papers are read figure-first, and the figure budget deserves design effort equal to the prose:
- The teaser (figure 1, under the title): the interaction at its most legible moment, ideally input and output in one frame, with a caption that states the capability rather than naming the parts.
- Sequence figures for the walkthrough: numbered frames with annotation arrows; readers should follow the interaction without the body text.
- Mechanism diagrams for the implementation: signal paths, layer stacks, state machines — one honest diagram replaces four paragraphs of prose and is what re-implementers screenshot.
- Results figures follow
uist-experimentsrules: distributions visible, conditions labeled, no truncated axes performing significance. - Captions are self-contained at this venue: many reviewers' first pass is figures-plus-captions only. Every caption should survive being read alone.
Language habits of accepted systems papers
- Present tense for the system ("the controller re-fits the model"), past tense for what you did ("we measured latency over 10,000 events").
- Active voice for design decisions — "we chose capacitive sensing because..." — since rationale is a claimed contribution, not a confession.
- Name the system early and use the name consistently; "our system/our approach" prose reads as unnamed and unfinished.
- Kill the throat-clearing openers ("In recent years...", "With the advent of..."); UIST introductions start inside the problem.
- Define each term of art once, then trust the reader — the audience builds interfaces for a living.
Revision passes
- Artifact-first pass — can a reader say what you built after page 1?
- Specificity pass — highlight every number without a measurement condition.
- Claim-evidence pass — table every "can/enables/supports" against its proof.
- Video-consistency pass — nothing in the paper that the video contradicts.
- Cold read — a labmate outside the project reads the walkthrough and narrates the system back; misnarrations mark the unclear paragraphs.
Output format
[Arc audit] weakest section of the eight + why
[Implementation depth] re-implementable / partially / opaque
[Unbacked claims] <list of capability claims lacking figure/measurement/app>
[Page budget] body pages vs limit, with the two cheapest cuts
[Rewrite order] <top three passes to run first>
Version History
- 9f86f09 Current 2026-07-19 17:52
