Ccfddl PR Review

ccfddl PR Review

Review open pull requests in ccfddl/ccf-deadlines against the latest repository state, official conference sources, and CI results.

Apply the same review rules to every PR regardless of author identity, repository role, or permissions.

Scope

Use this skill when asked to:

• review one or more pull requests
• continue reviewing open PRs
• check whether a PR is correct
• approve eligible PRs
• request changes on incorrect PRs
• re-review a PR after new commits

Skip closed PRs and draft PRs.

Do not proactively search the repository for new conference editions. Use the ccfddl-conference-update skill for that.

Do not manually merge a PR unless the current user request explicitly asks for a merge operation.

Review invariants

A review decision is valid only for the exact PR head SHA that was inspected.

Never approve from:

• an older head SHA
• an earlier conversation
• cached PR state
• a previous CI result
• the PR description alone

For every review attempt, re-read the current PR state.

Treat the review identity as:

repository + PR number + head SHA

Required state

Before making a decision, retrieve and inspect:

• PR number, title, author, state, and draft status
• base branch
• latest head SHA
• complete changed-file list
• complete diff
• existing reviews
• review comments and discussion
• unresolved review threads when available
• latest CI/check status for the current head SHA
• relevant repository conventions

Review procedure

1. Capture the current head SHA

Read the head SHA before reviewing anything else.

If the head SHA changes during review, discard the old decision and restart against the new SHA.

2. Read the complete diff

Inspect the entire diff, not only lines mentioned by previous reviewers.

Check for:

• incorrect conference information
• wrong year, edition, track, or submission round
• abstract/submission deadline confusion
• timezone errors
• wrong conference dates or location
• outdated or incorrect URLs
• malformed YAML or metadata
• formatting inconsistent with nearby entries
• duplicate entries
• accidental deletion
• unrelated changes
• stale values copied from older editions

3. Read existing review context

Inspect:

• submitted reviews
• review comments
• unresolved threads
• author replies
• previous requested changes

Confirm that previously reported issues are actually fixed in the current head SHA.

A resolved GitHub conversation does not by itself prove that the underlying issue was fixed.

Do not repeat an equivalent review or comment for the same head SHA unless materially new information changes the conclusion.

Official conference verification

For every conference-related factual change, independently verify the relevant fields using current primary sources.

Preferred source order:

1. official conference website
2. official Call for Papers
3. official Important Dates page
4. official submission-system page linked by the conference
5. official ACM / IEEE / USENIX / AAAI / organizer page
6. official sponsoring-organization page

Secondary sources may be used only to locate primary sources.

Do not use deadline aggregators, blogs, Reddit, social posts, search snippets, AI summaries, cached third-party pages, or previous-year repository values as final evidence when a primary source is available.

Fields to verify

Verify every changed field that is relevant to the PR, including when applicable:

• conference name
• year and edition
• track
• submission round
• abstract deadline
• paper submission deadline
• timezone / AoE
• notification date
• rebuttal period
• camera-ready date
• conference start/end dates
• location
• official conference URL
• CFP URL
• submission URL
• notes or round-specific metadata

Do not verify only the field mentioned in the PR title.

Edition, track, and round disambiguation

Before accepting an official source, confirm that it refers to the exact conference, year, track, and round.

Be especially careful not to confuse:

• main conference vs workshop
• research track vs demo/poster/industry track
• journal-first track
• artifact evaluation
• previous-year archived pages
• Round 1 vs later rounds
• abstract deadline vs full-paper deadline

If the source cannot be tied confidently to the changed repository entry, do not approve.

Deadline and timezone rules

A deadline is correct only when all relevant dimensions match:

• date
• time
• timezone
• track
• round

Treat timezone as part of the deadline.

Pay particular attention to AoE, UTC, UTC offsets, local timezones, daylight-saving transitions, 11:59 PM, and midnight boundaries.

Do not infer a timezone from previous editions.

Do not silently reinterpret an official deadline unless repository conventions explicitly require a representation conversion.

TBD and unpublished information

Never infer an unpublished deadline.

If the official source says TBD, TBA, To be announced, Coming soon, or equivalent, preserve the repository's established representation of unknown information.

Do not fill an unknown field using last year's date, historical cadence, another deadline site, or an inferred annual pattern.

Conflicting official sources

If official sources disagree:

1. identify exactly which values conflict
2. determine whether the pages refer to different rounds, tracks, or editions
3. check whether one page is clearly archived or stale
4. prefer a more specific/current official page only when that conclusion is well supported

If the conflict cannot be resolved confidently, hold the PR.