Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →brycewang-stanford/chi-topic-selection
Use when deciding whether a project belongs at ACM CHI, which of CHI's contribution types it makes, and which reviewing subcommittee should judge it — or whether the work is better routed to UIST, CSCW, DIS, IUI, ASSETS, IMWUT, or TOCHI before any drafting starts.
Passed 17 of 23 test cases with the skill, and 11 of 23 without it.
and 7 more in the full report
7 fixed10 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
We developed a C++ graphics rendering engine for spatial audio in WebXR. To satisfy CHI expectations, we added a brief 5-minute usability survey with 4 lab colleagues rating audio quality. Evaluate this submission strategy with human stake, contribution types, subcommittee designations, venue verdict, length plan, and blocking gap.
| Checked | Without skill | With skill |
|---|---|---|
| The blocking gap or human stake critique highlights that a superficial user study added to decorate an engineering result will lead to rejection. | Passed | Passed |
| The response structures the output using the required bracketed section format. | Missed | Passed |
The instructions your model reads when the skill loads.
CHI accepts almost every topic that touches people and computing, so "is this in scope?" is rarely the real question. The decisions that actually shape the outcome are: which contribution type is this paper, and which subcommittee should read it. Both are declared at submission time in PCS, and both are strategy, not paperwork — CHI 2026 rejected roughly three quarters of 6,730 completed submissions, and a large share of early rejections trace to papers pitched at the wrong reviewer community inside CHI itself.
Ask: who changes what they do because this paper exists? A designer picks a different pattern, a researcher runs a study differently, a developer builds an interface differently, a policy team understands a user population differently. If no answer survives scrutiny, the project is an engineering result wearing an HCI costume, and reviewers will say exactly that. A system with no study can still be CHI-worthy — but only when the system itself embodies a claim about interaction that others can build on.
CHI's own guidance enumerates the contribution types the conference publishes. Force the project into exactly one primary type; hybrids are fine but one must lead:
| Contribution type (CHI's list) | Typical evidence | Failure mode when mismatched |
|---|---|---|
| Interface artifacts or techniques | Prototype + comparative or usability study | Demo praised, knowledge contribution doubted |
| Understanding users (empirical) | Interviews, surveys, logs, field data | "Interesting but so what for design?" |
| Systems, tools, architectures | Working system + evaluation of enabled tasks | Judged as engineering, not research |
| Methodology | New method + validation against practice | "Who has actually used this method?" |
| Theory | Concepts/models grounded in literature | Read as an essay without operational value |
| Innovation, creativity, and vision | Provocations, envisionments | Dismissed unless framing is explicit |
| Argument | Well-supported position essay | Torn apart if evidence is thin anywhere |
| Validation and replication | Careful reproduction of prior findings | Undervalued unless framed as such |
Source: the "Contributions to CHI" pages carried across recent cycles (chi2026.acm.org/contributions-to-chi/, checked 2026-07-08).
test cases passed, vs 11 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.