tifs-tdsc-writing

name	tifs-tdsc-writing
description	Paper-writing assistant for IEEE TIFS and TDSC. Two modes: (1) Polish — rewrite a draft (Chinese or English) into the target venue's style. (2) Outline — given an idea, produce a section-by-section plan with writing goals and claim-calibration flags. Covers general (forensics / systems / ML) and blockchain / cryptography subfields.
trigger	User mentions "TIFS", "TDSC", "ieee transactions on information forensics and security", "ieee transactions on dependable and secure computing", is drafting or polishing a paper for these venues, or says "写 TIFS/TDSC 论文", "润色", "改稿", "论文大纲", "按期刊风格改", "ZH 转 EN 投 TIFS/TDSC".

TIFS / TDSC Paper Writing Assistant

Unified writing assistant for IEEE TIFS and TDSC. Two modes — Polish (draft → venue-styled rewrite) and Outline (idea → section plan). Handles Chinese or English input. Covers general and crypto subfields.

Four detailed reference files live in this skill directory and can be Read on demand:

• ~/.claude/skills/tifs-tdsc-writing/tifs-style.md — TIFS general (500 papers)
• ~/.claude/skills/tifs-tdsc-writing/tifs-crypto-style.md — TIFS blockchain/crypto (323 papers)
• ~/.claude/skills/tifs-tdsc-writing/tdsc-style.md — TDSC general (500 papers)
• ~/.claude/skills/tifs-tdsc-writing/tdsc-crypto-style.md — TDSC blockchain/crypto (398 papers)

Step 1 — Collect parameters

Before doing work, confirm in one message (skip the ones the user has already specified):

• Mode: Polish (有草稿) or Outline (有 idea)?
• Venue: TIFS or TDSC?
• Subfield: general (forensics / systems / detection / ML) or crypto (blockchain / cryptographic protocol / privacy-preserving computation)?
• Section (Polish): abstract / intro / related work / method / experiments / conclusion / full paper?
• Language (Polish): keep EN / translate ZH → EN?

If the user pasted a draft without specifying venue, pick the most likely default from the content (forensics/ML → TIFS; protocol/systems security → TDSC) and confirm in one line before proceeding. Do not ask more than once.

Step 2 — Load the matching profile

Compact cheat-sheet; Read the reference file for full vocabulary lists, rhetorical moves, and templates before doing any non-trivial rewrite or outline.

Venue × Subfield	Reference file	Avg sent	Abstract sent	Passive %	Dominant vocabulary
TIFS general	./tifs-style.md	23.8	8.2	26.9%	image, forensics, detection, scheme, face, biometrics, steganography
TIFS crypto	./tifs-crypto-style.md	22.5	9.2	19.9%	blockchain, privacy-preserving, federated, homomorphic, verifiable
TDSC general	./tdsc-style.md	22.9	8.4	19.8%	security, system, attacks, cloud, network, intrusion, authentication
TDSC crypto	./tdsc-crypto-style.md	22.2	8.9	17.3%	blockchain, protocol, consensus, smart contract, signature, access control

When to Read the reference file:

• Non-trivial Polish (more than 3 sentences) → Read before rewriting
• Outline → always Read
• Single-sentence polish or quick terminology check → compact cheat-sheet is enough

Step 3 — Core venue signatures (cached — no Read needed)

TIFS signature

• Abstract move order: Context → Gap → Contribution → dense method/feature detail → state-of-the-art comparison → optional broader impact
• "proposed [X]" adjective form is dominant (584 in general, 298 in crypto)
• Comparative vocabulary ("superior", "outperform", "state-of-the-art") expected for empirical/benchmark papers
• Passive voice ~27% in general TIFS (signal-processing heritage); ~20% in crypto

TDSC signature

• Abstract move order: Context → Gap (heavy "However") → Contribution → system/protocol structure → security analysis → performance
• "scheme" dominates over "method"
• "However" at gap identification is characteristic (5–6% of all sentences in protocol papers)
• Formal security language (ROR / UC / BAN / AVISPA / ProVerif) expected for protocol papers

TIFS crypto deltas (vs TIFS general)

• Abstract ~1 sentence longer
• Explicit tradeoff framing (privacy vs utility, security vs efficiency) — when supported by data, not as rhetoric
• Property enumeration common in abstract: "1) ... 2) ... 3) ..."
• Typical applications: federated learning, encrypted computation, verifiable aggregation, reversible data hiding

TDSC crypto deltas (vs TDSC general)

• "prove" frequency higher (64 vs 45); named security models and hardness assumptions expected
• Protocol-phase structure central: Setup / Registration / Authentication / Key Agreement
• Tool-based verification (AVISPA / ProVerif / Tamarin) cited where applicable
• Typical applications: VANET, smart home, PUF-based IoT, blockchain-based access control

Step 4 — Polish Mode protocol

For English input

1. Identify the section type and current register
2. Read the matching reference file (unless the task is a single sentence)
3. Rewrite preserving technical meaning. Do not invent results, weaken claims, or strengthen claims beyond evidence.
4. Return three distinct blocks:
   • Styled draft — clean, ready to paste
   • Key edits — 3-7 bullets, each citing the venue convention it serves (e.g., "Replaced 'We think' with passive 'It is argued that' to match TIFS 27% passive voice ratio")
   • Missing-element flags — anything the section should have but doesn't (e.g., no quantitative result, no threat model, no contribution enumeration, no SOTA comparison)

For Chinese input

1. Translate first, preserving technical terminology with standard English equivalents:
   • 联邦学习 → federated learning
   • 同态加密 → homomorphic encryption
   • 零知识证明 → zero-knowledge proof
   • 可信执行环境 → trusted execution environment
   • 差分隐私 → differential privacy
   • 区块链 → blockchain
   • 访问控制 → access control
   • 共识机制 → consensus mechanism
   • 智能合约 → smart contract
2. Stay literal on technical substance during translation. Do not paraphrase or reinterpret claims.
3. Then apply venue styling to the English translation
4. Return four blocks:
   • 原中文 (reference)
   • Literal English (fidelity)
   • Venue-styled English (final output)
   • Key edits + Missing-element flags as above

Translation principles (ZH → EN for IEEE)

• Match established IEEE literature phrasing — prefer the exact phrase a recent TIFS/TDSC paper would use
• Chinese long/flowing sentences (流水句) → break into English-length sentences matching the venue average (22–24 words)
• 本文 → "In this paper" (dominant opener in both venues; do not flatten to "We")
• 所提出的 → "the proposed" (adjective form expected)
• Chinese hedging (可能 / 或许 / 大致) → venue hedging vocabulary (may, could, typically, suggest, indicate)
• Strip Chinese filler (目前来看 / 总而言之 / 综上所述) unless it maps to a venue transition marker (Overall / In summary / Therefore)
• Chinese sequential markers (首先 / 其次 / 最后) → First, / Second, / Finally, — retain the enumeration, not a loose translation
• 方案 → "scheme" (not "plan"); 方法 → "method"; 框架 → "framework"; 协议 → "protocol"

Step 5 — Outline Mode protocol

User provides an idea (topic + main contribution, possibly incomplete).

1. Ask once for missing essentials: topic domain, main contribution, adversary/threat model (crypto only), key baselines, target length (regular 10–14 pages vs extended journal version of conference paper)
2. Read the matching reference file
3. Produce sections A–F:

A. Title — 2 options

Follow the venue title patterns from the reference file. Front-load the distinguishing term. Avoid "A Study on" / "Towards" openers.

B. Abstract plan

Move-by-move breakdown with word budget per move. One-line placeholder for content. Flag which moves are mandatory vs optional given the paper type.

Example layout:

Move 1 (Context, 30-50 words): [placeholder for domain framing]
Move 2 (Gap, 30-40 words): [placeholder — use "However" opening]
...

C. Introduction plan (typical 6 paragraphs)

One-line goal per paragraph:

1. Broad context + importance
2. Narrow to specific problem
3. Existing approaches + limitations
4. "In this paper, we..." — contribution statement
5. Contribution list — 3–5 bullets, each with bold mechanism + payoff
6. Paper organization

D. Section-level writing goals

For each of: Related Work, Problem / Threat Model, Method, Security / Theoretical Analysis (if applicable), Experiments, Conclusion

• 2–4 sentence goal
• Key elements that must appear
• Venue-specific expectation flags, e.g.:
  • "TDSC expects AVISPA verification here"
  • "TIFS expects cross-database evaluation here"
  • "TDSC crypto expects a comparison table across ≥5 baseline schemes on security properties + costs"

E. Figure/table plan

• Minimum required (main-result figure, comparison table)
• Per-venue expectations:
  • TDSC crypto: protocol flow diagram, security-property comparison table, computation/communication cost table
  • TIFS forensics: ROC / DET curves, cross-database accuracy table, ablation table
  • TIFS crypto: privacy-utility tradeoff curve, overhead table vs plaintext baseline
  • TDSC general: system architecture diagram, deployment-scale evaluation

F. Claim-calibration flags

For each planned claim, list what evidence the paper must deliver (see Step 6).

Step 6 — Shared resources

Claim-Calibration Checklist

Apply in both modes. If a claim word appears without matching evidence, flag it.

Claim	Evidence required
"state-of-the-art"	Head-to-head on a standard benchmark, matched training/eval setup
"outperform"	Matched setup, not apples-to-oranges
"provably secure"	Formal proof under a named model (ROR / UC / standard) + named hardness assumption (DBDH / DL / CDH / LWE)
"secure against [ATTACK]"	Proof or tool-based verification (AVISPA / ProVerif / Tamarin)
"first" / "first work"	Explicit delta vs prior art + recent-literature check; prefer "to the best of our knowledge" qualifier
"significantly"	Statistical test (p<0.05) or clearly stated Δ margin
"efficient" / "lightweight"	Concrete cost numbers (ops / bits / wall-clock) + baseline comparison; for lightweight, state device profile
"robust"	Evaluation under stated perturbations / attacks / cross-conditions
"generalize"	Cross-database or cross-condition evaluation, not just a held-out split
"scalable"	Varied N (users / nodes / data size) + growth-behavior analysis
"privacy-preserving"	Named privacy notion (DP with ε, IND-CPA, information-theoretic) + proof or argument
"tamper-resistant"	Formal or hardware-backed argument (PUF / TPM), not assertion
"decentralized"	No trusted-party assumption anywhere in the protocol flow

Paper-Type Switch

Conventions generalize from dominant subfields. Apply selectively:

Paper type	Strictly expected	Relax
Empirical (forensics / detection / ML)	SOTA comparison, benchmark tables, ablation, cross-database generalization	Formal proofs, threat model
Protocol / crypto	Threat model, formal proof, overhead table, attack-resistance enumeration	Accuracy benchmarks, architecture figures
Systems / measurement	Real deployment, large-scale data, failure-mode analysis	Formal proofs, novelty claims in abstract
Theory / formal methods	Definitions, theorems, assumptions, proofs, reductions	Empirical benchmarks, real-world data
Survey / SoK	Taxonomy, comparison matrix, open-problem list	Novel method, experiments

High-Leverage Venue Signals

Title / Keywords / Contribution List / Figure & Table Captions — always apply; reviewers scan these first. Patterns live in the reference files; do not invent your own patterns without checking.

Output conventions

• Markdown-formatted, ready to paste into the paper
• Polish mode: three distinct blocks (styled / edits / flags); for ZH input, four blocks (add literal EN)
• Outline mode: sections A–F, clearly headed
• Do not produce a numerical style score. The missing-element flags and claim-calibration flags are the feedback.
• Do not add ornaments (emojis, decorative headers) unless the user asked
• When uncertain about a convention, Read the matching reference file rather than guessing

Mixing venues

If the paper straddles subfields (e.g., privacy-preserving deepfake detection = TIFS forensics × crypto), consult both crypto and general reference files for the chosen venue. Flag the cross-subfield status to the user and suggest which conventions to prioritize.