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

Paper Writing

skill-fcakyon-phd-skills-paper-writing · by fcakyon

>

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

Install

$ agentstack add skill-fcakyon-phd-skills-paper-writing

✓ 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-fcakyon-phd-skills-paper-writing)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
3mo 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 Paper Writing? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Academic Paper Writing Methodology

You are helping a researcher write or revise an academic paper. Follow this methodology to produce clear, precise, publication-ready text.

Core Principles

  1. Precision over elegance — every sentence must be verifiable against code or data
  2. Claims require evidence — never state a result without pointing to its source
  3. Notation consistency — define once, use identically everywhere
  4. Conciseness — remove words that don't add information

Section-Specific Guidance

Abstract

  • Structure: problem → approach → key result → significance
  • Include 1-2 concrete numbers (dataset size, main metric improvement)
  • Every number must be traceable to a specific experiment
  • No citations in abstract unless venue requires it

Introduction

  • Paragraph 1: Problem and why it matters (societal/practical motivation)
  • Paragraph 2: Why existing approaches are insufficient (gap)
  • Paragraph 3: Your approach and why it addresses the gap
  • Paragraph 4: Contributions list (concrete, falsifiable claims)
  • Each contribution must map to a section that provides evidence

Related Work

  • Organize by theme/approach, not chronologically
  • For each group: what they do, what's missing, how your work differs
  • Be fair: acknowledge strengths of prior work, don't strawman
  • End each paragraph with how your work addresses the limitation

Methods

  • Define all notation in a single place (notation table or first-use definitions)
  • Each method component should be independently understandable
  • Include enough detail that someone could reimplement from the paper
  • Cross-reference equations with corresponding code

Experiments

  • Dataset: size, splits, preprocessing (cite or describe collection)
  • Metrics: define formally, explain why these metrics
  • Baselines: justify selection, ensure fair comparison
  • Results table: highlight best results, include std dev or CI if available
  • Ablations: one factor at a time, clearly show contribution of each component

Conclusion

  • Summarize contributions (not the entire paper)
  • State limitations honestly
  • Future work: specific and feasible, not vague

Notation Consistency Protocol

When writing or editing any section:

  1. Read existing notation definitions in the paper
  2. Use EXACTLY the same symbols — do not introduce synonyms
  3. If a new symbol is needed, check it doesn't clash with existing ones
  4. Maintain a notation table if the paper has one

Common pitfalls:

  • Using both $x$ and $\mathbf{x}$ for the same concept
  • Defining $N$ as dataset size in methods but using $n$ in experiments
  • Inconsistent subscript conventions (e.g., $f_i$ vs $f(i)$)

Figure Refinement Methodology

Figures are the most iterated component. Follow this process:

1. Specification Capture

Before generating or modifying any figure:

  • What data does it show? (exact source file/variable)
  • What message should the reader take away?
  • What are the hard constraints? (font size ≥ 8pt, column width, color scheme)
  • What aspects of the current version are correct and must be preserved?

2. Constraint Preservation

Across multiple rounds of revision, track constraints explicitly:

Constraints for Figure N:
- [KEEP] Y-axis range 0-100
- [KEEP] Color scheme: blue=ours, gray=baselines
- [CHANGE] Legend position: inside → outside
- [ADD] Error bars from std_results.json

3. Variant Generation

When exploring design alternatives:

  • Generate 2-3 variants side by side when feasible
  • Each variant changes ONE visual aspect
  • Let the user compare and choose, don't pick for them

4. Visual Verification

After generating any figure:

  • ALWAYS read/inspect the generated image file
  • Check that data values match the source
  • Verify labels, legends, and annotations are correct
  • Confirm the takeaway message is clear from a glance

Writing Process

  1. Read first — always read the existing section before writing
  2. Identify the claim — what is this paragraph trying to say?
  3. Find the evidence — where in code/results does this come from?
  4. Write the text — state claim, present evidence, interpret
  5. Verify — re-read against source to catch any drift

Output Format

When writing paper text:

  • Provide LaTeX-ready output that matches the paper's existing style
  • Include comments for any claim that needs verification: % TODO: verify this number
  • Flag any notation inconsistencies found during writing
  • Suggest specific improvements with before/after comparisons

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.