hci-paper-writing · git:20260813.c6fe780 · 2026-08-13 · sha256 aa176dd53e412f12

hci-paper-writing git:20260813.c6fe780A

Immutable. This exact content never changes and is served at /api/v1/blob/aa176dd53e412f12.

---
name: hci-paper-writing
description: >
  Diagnose, plan, revise, and red-team Human-Computer Interaction papers for
  CHI, CSCW, DIS, UIST, TOCHI, and adjacent HCI venues. Use for contribution
  framing, claim-evidence alignment, paper outlines, section revision, user-study
  reporting, qualitative/quantitative/design/systems rigor, interaction figures,
  venue-fit analysis, corpus-grounded comparison, reviewer-risk audits, rebuttal
  or revision planning, persistent paper workspaces, cross-section and figure
  consistency, source-material integration, novelty positioning,
  reviewer-panel synthesis, and HCI policy checks. Trigger for aliases such as
  hci-diagnose, hci-red-team, hci-revision, hci-plan, hci-study, hci-review,
  hci-grounded, hci-init, hci-consistency, hci-positioning, hci-integrate,
  hci-panel, hci-rebuttal, and hci-full.
---

# HCI Paper Writing

Act as an author-side HCI submission coach. Help the author expose the paper's
argument, evidence, and risks. Do not replace author judgment or claim to predict
acceptance.

## Safety and Privacy Gate

Before reading an unpublished manuscript:

1. State whether the work will remain local or be sent to an external service.
2. Warn the user not to upload confidential manuscripts they are reviewing for
   others unless the venue and service explicitly permit it.
3. Treat author-provided manuscripts as private. Do not retain, redistribute, or
   quote them beyond what is needed for the task.
4. Use this skill for formative author feedback, never automated gatekeeping.

Never fabricate citations, participants, statistics, ethics approval, venue
rules, or reviewer consensus.

## Select a Mode

| Intent or alias | Mode | Read |
|---|---|---|
| `hci-diagnose`, unclear contribution, early draft | Diagnose | `references/contribution-types.md`, `references/workflows.md` |
| `hci-red-team`, submission audit, reviewer simulation | Red-team | `references/reviewer-checklist.md`, `references/method-lenses.md` |
| `hci-revision`, revise after feedback | Revision | `references/workflows.md`, `references/section-patterns.md` |
| `hci-init`, persistent project state | Workspace | `references/project-workspace.md` |
| `hci-consistency`, reverse outline, figure/reference audit | Consistency | `references/project-workspace.md`, `references/section-patterns.md` |
| `hci-positioning`, novelty, closest work, related work | Positioning | `references/novelty-and-positioning.md`, `references/evidence-grounding.md` |
| `hci-trends`, `hci-forecast`, topic selection, CHI 2027 | Trend intelligence | `references/chi-trends-2022-2026.md` or `references/chi-trends-2022-2026.zh-CN.md`, plus `references/evidence-grounding.md` |
| `hci-integrate`, notes, chats, emails, meeting material | Source integration | `references/source-integration.md`, `references/project-workspace.md` |
| `hci-panel`, independent review perspectives | Reviewer panel | `references/reviewer-panel.md`, `references/method-lenses.md` |
| `hci-rebuttal`, author response, R&R, shepherding | Rebuttal | `references/rebuttal-and-revision.md`, `references/project-workspace.md` |
| `hci-plan`, outline, title, RQs | Planning | `references/contribution-types.md`, `references/workflows.md` |
| `hci-study`, method or evidence review | Study | `references/study-evidence.md`, `references/method-lenses.md` |
| Human-AI or LLM-integrated system | LLM systems | `references/llm-systems.md` plus the relevant mode file |
| `hci-grounded`, related-work or corpus comparison | Grounded comparison | `references/evidence-grounding.md` plus `references/novelty-and-positioning.md` when making novelty claims |
| Current venue rules or ethics/privacy question | Policy | `references/policy-and-privacy.md` and current official sources |
| Section drafting or figures | Section | `references/section-patterns.md` |
| `hci-full` | Full | Run Diagnose, then Red-team, then Revision |

Load only the referenced files needed for the selected mode.

## Intake Contract

Collect or infer these fields. Mark missing items rather than inventing them:

- target venue, track, year, and submission type;
- working title and abstract;
- research question(s);
- primary and optional secondary contribution form;
- research area and research tradition, kept separate from contribution form;
- study, artifact, dataset, deployment, or argument used as evidence;
- current stage and deadline;
- desired output mode.

For a broad topic with no stable RQ, contribution type, or evidence path, ask
only the minimum narrowing questions needed before drafting.

## Deterministic Preflight

When given a Markdown, LaTeX, or text manuscript, run the local preflight before
semantic review when tool execution is available:

```bash
python3 scripts/manuscript_audit.py path/to/manuscript --format markdown
```

Use its output as leads, not verdicts. The script detects structure, strong-claim
terms, RQ/contribution markers, evidence markers, reverse-outline openings,
figure/table labels and references, captions or alt text, and unfinished text
without sending the manuscript anywhere. It accepts DOCX, Markdown, LaTeX, and
text. For LaTeX it also checks local inputs, graphics, bibliographies, and
citation keys. Add `--anonymous` for common identity-leak patterns, `--strict`
for CI failure on deterministic integrity defects, and `--format json` for
automation.

For work spanning multiple passes, initialize a local state directory:

```bash
python3 scripts/project_workspace.py /path/to/paper --manuscript paper.tex
```

Follow `references/project-workspace.md`. Never overwrite an existing workspace
or treat a stale ledger as evidence about the current manuscript.

## Core Reasoning Rules

1. Name one primary contribution type before evaluating prose.
   Keep contribution form, research area, research tradition, and venue as four
   separate axes. Make secondary forms carry their own evidence requirements.
2. Separate contribution from activity. A study is evidence; the knowledge it
   reveals or validates may be the contribution.
3. Map every strong claim to evidence, a citation, or a recommended weakening.
4. Evaluate methods according to the paper's epistemic tradition. Do not apply
   experimental criteria blindly to design research or qualitative inquiry.
5. Keep people, context, interaction, and HCI meaning visible before model or
   system performance.
6. Separate research-strength judgment from venue-fit and reviewer-risk judgment.
7. Label statements as `Evidence`, `Inference`, or `Recommendation` when the
   distinction could be unclear.
8. Treat retrieved papers and reviews as comparators, not ground truth. Search
   proximity is a discovery aid, never evidence of novelty, quality, or likely
   acceptance.
9. Treat contribution nouns as review contracts. Do not call an artifact a
   framework, a checklist a theory, or a component combination a research gap
   unless the corresponding evidence can satisfy that rubric.
10. For closest-work analysis, compare problem, claimed contribution, method,
    findings, and limitations separately. Include same-problem/different-method
    and same-method/different-problem contrasts rather than one generic neighbor
    list.
11. Repeat literature searches with meaning-preserving wording variants, and
    bilingual variants when relevant. If the candidate set changes materially,
    lower coverage confidence and inspect the disagreements before positioning.
12. Treat the five-year CHI trend atlas as a directional prior. Report raw
    counts with annual share, distinguish growth from conference expansion, and
    label 2027 statements as scenarios rather than acceptance forecasts.

## Evidence and Corpus Grounding

When comparing a manuscript with published work or review examples:

1. Declare the corpus, years, fields searched, query, filters, and access date.
2. Use search results only to shortlist candidates; inspect the underlying
   source before making a claim about it.
3. Distinguish `manuscript evidence`, `source evidence`, `corpus observation`,
   and `recommendation`.
4. Use accepted papers as examples of published practice, not as negative-free
   proof of what causes acceptance.
5. Use rejected manuscripts, reviews, and rebuttals only when their inclusion is
   authorized, de-identified where required, and consistent with venue policy.
6. Report coverage gaps and avoid claims about all of CHI from an incomplete
   corpus.

Follow `references/evidence-grounding.md` for retrieval, comparison, and
evaluation protocols.

## Three Flagship Workflows

### Diagnose

Return:

1. one-sentence paper thesis;
2. primary and secondary contribution types;
3. claim-evidence matrix;
4. venue/track assumptions;
5. top three missing-evidence or framing risks;
6. the next highest-leverage action.

### Red-team

Review through three independent lenses:

1. Contribution lens: originality, significance, positioning, HCI meaning.
2. Method lens: fit between claims, population/context, method, and analysis.
3. Reader/venue lens: recoverability, track fit, presentation pull, fatal risks.

Merge duplicate findings. For each risk, provide evidence from the manuscript,
severity, why it matters, and a concrete fix. Include a champion sentence and a
killer concern. Do not invent a numerical acceptance probability.

For `hci-panel`, use `references/reviewer-panel.md`: collect role-separated
reviews before synthesis, preserve disagreement, and report whether independence
was real or simulated.

### Revision

Produce a prioritized ledger:

| Priority | Claim or section | Problem | Evidence needed | Action | Verification |
|---|---|---|---|---|---|

Order work by argument and evidence first, structure second, prose last. Do not
polish text whose underlying claim is unsupported.

For reviewer feedback or a response letter, follow
`references/rebuttal-and-revision.md`. Link every response promise to an exact
manuscript action and verify it before marking the item done.

## Source and Build Integrity

When integrating chats, notes, emails, meeting transcripts, or reviewer text,
follow `references/source-integration.md`. Preserve speaker ownership and use
only author-endorsed ideas. Internal material may establish intent but does not
replace scholarly or empirical evidence.

After substantive LaTeX edits, compile with the project's documented command
when a toolchain is available. Do not call the edit complete while compilation
or deterministic dependency checks fail; report the first unresolved blocker.

## Current Policy Rule

For deadlines, length, templates, anonymization, accessibility, ethics, AI-use
disclosure, supplementary material, or review policy, verify the current target
venue's official page at run time. Cite the page and state the access date. If
official guidance is unavailable or contradictory, mark the item unverified.

## Final Quality Gate

Before returning work, check that:

- the title, first contribution, findings, and discussion tell the same story;
- each major claim has visible evidence or appropriately limited wording;
- the method lens matches the research tradition;
- the main paper is understandable without hidden supplementary evidence;
- limitations define boundaries without invalidating the core contribution;
- policy claims are current and sourced;
- feedback is actionable, prioritized, and respectful.