Use when revising an ACM CCS paper for a precise threat model, calibrated attack/defense claims, 12-page ACM sigconf compression, double-blind wording, adaptive-evaluation honesty, and the security house style that survives an adversarial SIGSAC program committee.
SkillScore95Maintained
Automatic
◆Writing & Editing pack
Last verified 8/15/2026
What it changes
Passed 21 of 22 test cases with the skill, and 17 of 22 without it.
Without skill77%
With skill95%
Checks it passed that the model alone missed
Recommends stating the threat model on the first page
Defines security goals as specific properties with quantitative parameters
Scopes the claim to the specific deployment configurations and versions evaluated
and 2 more in the full report
5 fixed16 passed either way0 still failing1 broke
Pass-rate lift
+18 pp
Tokens
+2%
Agent turns
0%
Response time
-34%
Model gemini-3.6-flashMeasured 8/15/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
Rewrite the draft sentence 'Our defense is secure and very fast' into a CCS-safe format according to standard paper revision standards, returning your answer in the bracketed format.
What was checked, without and with the skill
Checked
Without skill
With skill
Specifies resistance against an adaptive adversary alongside a concrete percentage overhead
Missed
Passed
case-17 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md61 linessingle file
CCS Writing Style
Use this when revising the main paper. CCS papers must state who the attacker is, what the
contribution defends or breaks, and enough measured evidence that an adversarial reviewer
cannot poke the central claim.
Revision rules
Put the security contribution on the first page: the problem, the attacker, the gap in
existing defenses or attacks, the mechanism, and the evidence that it works.
Make the threat model explicit and early. State attacker capabilities, knowledge, position,
and goal before results; CCS reviewers reject on hidden or shifting adversary assumptions.
Pair every claim with proof, measurement, exploit demonstration, or a cost number. A
security claim without a bound on the adversary or a measured cost reads as marketing.
Use the 12-page body for the core argument; move protocol transcripts, extra measurements,
and formal proofs to appendices without making the body unintelligible.
Do not overstate exploitability beyond the conditions tested; scope every "practical" claim
to the environment, versions, and configuration measured.
Keep double-blind wording in self-citations, tool names, acknowledgements, and artifact
descriptions.
Threat-model discipline
Give the adversary a named model with capabilities enumerated once and referenced by name;
CCS readers audit whether every attack step stays inside those capabilities.
Separate what the attacker knows from what it can do from where it sits in the system; a
conflated model is the most common source of "the attack assumes too much" reviews.
State the security goal as a property (confidentiality, integrity, availability,
unlinkability) and say what "broken" means quantitatively.
When a defense is evaluated, name the adaptive attacker it was tested against; a defense
measured only against the attack it was designed to stop is a standing CCS complaint.
Label conjecture, heuristic argument, and proved result distinctly; mixing them near a
security claim is a credibility leak at this venue.
Sentence-level rewrites
Draft pattern
CCS-safe rewrite
"Our attack is highly effective..."
"recovers the key in N queries against library X vY on platform Z"
"Under realistic assumptions..."
"Under threat model T (network MITM, no host access)..."