AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Ieee Letter

skill-tenwalk-ieee-skills-ieee-letter · by TenWalk

>-

No reviews yet
0 installs
9 views
0.0% view→install

Install

$ agentstack add skill-tenwalk-ieee-skills-ieee-letter

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-tenwalk-ieee-skills-ieee-letter)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
1mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Ieee Letter? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

IEEE Communications Letter (WCL / CL)

A letter is not a short transactions paper. It is a single, sharp contribution presented under a tight page budget (currently a 5-page maximum for both WCL and CL, with page charges beyond the free page budget under ComSoc guidance). The job is to make one result land — fast — and to cut everything that does not serve it. Use this skill to draft a letter from scratch or to compress an over-length draft.

Core stance

  • One contribution, stated once. A letter carries a single advance: one algorithm, one

closed-form expression, one new scheme, or one decisive finding. If the draft has two, it is a transactions paper — say so and use ieee-writing.

  • The free-page budget is a design constraint, not a trim at the end. Plan the budget before

drafting (see page budget below). Treat a paid fifth page as a strategic decision for essential evidence, not as permission to write a small transaction.

  • No standalone Related Work section. Prior work is folded into the Introduction as the gap.
  • Author evidence comes first. Never invent results, numbers, channel models, benchmark

schemes, or limitations. Missing evidence → [PLACEHOLDER: ...] or ask the user.

  • Same IEEE register as a transactions paper: US English, numbered citations [n], bold-vector

/ bold-matrix notation, equations numbered only for the skeleton of the argument.

WCL vs CL — know the target

| | IEEE WCL (Wireless Comms Letters) | IEEE CL (Communications Letters) | |---|---|---| | Page limit | Currently 5 pages maximum; the 5th page incurs an over-length charge | Currently 5 pages maximum; pages beyond 4 incur over-length charges | | Abstract | Short letter abstract, commonly 75–100 words | Short letter abstract, commonly 75–100 words | | EDICS | not required | required at submission | | Scope | wireless / PHY-MAC | all communications | | Anonymity | single-blind (default) | double-anonymous option available | | Figures | submit vector (EPS/PDF) | submit vector (EPS/PDF) |

Always confirm the current page/fee/EDICS rules in the journal's author kit before submitting; these defaults change. If the user has not named WCL vs CL, ask — the EDICS and anonymity rules differ.

Page budget (IEEEtran, two-column, 10pt) — plan this first

Aim for the free 4-page budget by default. Use the paid fifth page only when it protects the one contribution's proof, experiment, or critical validation.

Title + abstract + Index Terms              ~0.25 page
I.  Introduction (gap + contribution)       ~0.75 page
II. System Model (+ problem if needed)      ~1.0 page
III. Proposed Scheme / Analysis (core)      ~1.0 page
IV. Simulation Results (2–4 figures/tables) ~0.75 page
V.  Conclusion (3–4 sentences) + refs       ~0.25 page

This is a starting allocation, not a rule. The core (III) and the result (IV) are the paper; protect their space and compress I–II. Verify how references and appendices count in the target journal's current Author Kit.

When to open extra files

| File | Open when | |---|---| | [references/letter-format.md](references/letter-format.md) | Drafting the letter section by section, or deciding what a letter keeps vs. what only a transactions paper carries | | [references/compression-tactics.md](references/compression-tactics.md) | An existing draft exceeds the free budget or the 5-page maximum and must be cut without losing the argument; or fitting figures/tables/equations into the budget |

For the argument of each section, defer to ieee-writing (its section defaults apply, compressed). For simulation content use ieee-experiments; for figures use ieee-figure; for references and EDICS use ieee-citation; for the cover/response letters use ieee-response.

Intake — establish before drafting

  • target: WCL or CL (they differ on EDICS and anonymity)
  • the one contribution: in a single sentence — the advance the letter exists to deliver
  • type: algorithm/design letter, or closed-form analysis letter (changes Section III)
  • evidence: the algorithm + convergence, or the derivation + a simulation overlay
  • boundary: the CSI/channel assumption and scope where the claim holds
  • starting point: drafting fresh, or compressing an over-length draft (→ compression-tactics.md)

If "the one contribution" is actually two, flag it: a letter cannot carry both well.

Drafting workflow

  1. One-sentence contribution. `We propose/derive [the one advance] for [system], which [benefit],

under [boundary].` Confirm it with the user.

  1. Check it fits a letter. One contribution, one model, one core result. If not, route to

ieee-writing.

  1. Allocate the page budget (above), then draft core-first: Section III, then IV, then the

compressed Introduction, then System Model, then Abstract and Conclusion last.

  1. Draft from evidence outward; keep each claim beside its support. Use ieee-writing section

logic, compressed: Introduction ends with a short contribution statement (often 1–2 sentences, not a numbered list of four).

  1. Fit the figures: 2–4 decisive figures/tables maximum, vector (EPS/PDF), readable at column

width — see ieee-figure. One should validate analysis (line + Monte-Carlo markers) if the letter derives an expression.

  1. Page-fit pass: if over the free budget, decide whether the paid fifth page is justified; if

over the maximum, apply references/compression-tactics.md in order (cut repetition and over-fine detail before touching the core result).

  1. Return the letter (LaTeX if IEEEtran), a page-budget estimate, a claim–evidence map, and a

note on what was cut to fit.

Letter-specific section defaults

  • Abstract: ~75–100 words unless the current Author Kit says otherwise, one quantified headline.
  • Introduction: compress to gap → contribution. Fold prior work into the gap; no separate

Related Work. End with a one- or two-sentence contribution statement, not a 4-item list.

  • System Model: only the symbols the core result needs. Cut generality the result does not use.
  • Proposed Scheme / Analysis (the core): the algorithm box or the theorem/derivation — the one

thing the letter exists for. Label transformations exact vs approximate; state convergence target (KKT/stationary/global) honestly. Long proofs are usually cut or sketched, not appended (letters rarely have appendices — confirm with the author kit).

  • Simulation Results: 2–4 decisive figures/tables, claim-first. Validate the derived expression

first if there is one; then the single most important comparison vs benchmark schemes. A compact measurement/testbed result is worth the space only if it supports the one contribution. State the fairness boundary in one sentence.

  • Conclusion: 3–4 sentences. Contribution → decisive result → boundary/outlook. No new data.

Output format

  1. Draft: the letter prose (or IEEEtran LaTeX).
  2. Page budget: estimated pages per section vs. the free-page budget and the 5-page maximum.
  3. Claim–evidence map: Claim … | Evidence … | Status: supported / needs evidence.
  4. Cut list: what was removed (or must be) to fit, and what was protected.
  5. Assumptions or missing inputs: only material issues.

For Chinese input, give the polished English letter first, then brief Chinese notes on what was compressed or cut and why.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.