| 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
- Identify the section type and current register
Read the matching reference file (unless the task is a single sentence)- Rewrite preserving technical meaning. Do not invent results, weaken claims, or strengthen claims beyond evidence.
- 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
- 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
- Stay literal on technical substance during translation. Do not paraphrase or reinterpret claims.
- Then apply venue styling to the English translation
- 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).
- 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)
Read the matching reference file- 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:
- Broad context + importance
- Narrow to specific problem
- Existing approaches + limitations
- "In this paper, we..." — contribution statement
- Contribution list — 3–5 bullets, each with bold mechanism + payoff
- 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.
