Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

render-workspace-html

Étoiles14

Forks9

Mis à jour21 juin 2026 à 08:23

Renders the paper-workspace (outputs + lifecycle progress) into a single self-contained HTML dashboard the author can open in a browser, and refreshes it on request. Use when a researcher says "show me an HTML view", "give me a dashboard", "can I see my progress in a browser", "visualize what's been done", "make an HTML report", or "update the dashboard". Offered as an option whenever a visual overview would help (it is opt-in, not generated unprompted), and re-run after each significant change so the page stays current. The output is one local dashboard.html with inline CSS — no network, no external assets, light/dark aware — listing every generated artifact by stage with clickable links and a recent-activity timeline. Trigger words - html, dashboard, browser view, visualize progress, html report, update the html.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

ShaishavMaisuria

ShaishavMaisuria/research-paper-lifecycle-skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Enseignants postsecondaires, autresEnseignement et bibliothèques·SOC 25-1199

Explorateur de fichiers

2 fichiers

SKILL.md

readonly

name

render-workspace-html

description

Render Workspace HTML

Turns the paper-workspace/ directory into a dashboard the author can open in a browser — lifecycle progress, every generated artifact grouped by stage with clickable links, and a recent-activity timeline. It's the visual "where am I / what's been done" view on top of the files the other skills produce.

This is opt-in: offer it when a visual overview would genuinely help (after a batch of work, or when the author asks), not on every turn. When the author wants it kept live, refresh it after each significant change so it never goes stale.

When to use

The author asks for an HTML view / dashboard / browser-readable summary of progress.
After several skills have run and the workspace has enough in it to be worth a glance.
The author says "keep the HTML updated" — then regenerate it at the end of each request that changed the workspace.

Process

Offer, don't impose. If the author hasn't asked, ask once: "Want an HTML dashboard of your progress? I can refresh it after each change." Generate only on yes.
Generate (deterministic):
```
python3 scripts/build_dashboard.py --workspace paper-workspace
```
It reads paper-workspace/INDEX.md and the stage folders (and .paper-memory/profile.yml for the title/venue if present) and writes paper-workspace/dashboard.html — one self-contained file, inline CSS, no network or external assets, light/dark aware. Exit 1 only if there is no workspace yet.
Point the author to it (open paper-workspace/dashboard.html). Summarize what it shows.
Refresh on request. If the author asked to keep it live, re-run step 2 at the end of any request that wrote new artifacts, and say you refreshed it. Otherwise regenerate only when asked again.

Output

paper-workspace/dashboard.html — a stage-by-stage progress bar, artifact cards with links to each output, and a recent-activity timeline from INDEX.md. Opens offline in any browser.

Richer reports

This skill is built for speed and zero dependencies: one self-contained dashboard.html that works offline and can be refreshed repeatedly. If the author asks for a more designed or interactive report, and the current agent runtime has a separate web artifact, frontend, or report-building skill installed, offer to hand the workspace summary to that tool. Keep this dashboard as the default status view; use richer builders only when the author asks for presentation-grade HTML.

Guardrails

Local only. The dashboard is a local file built from local artifacts; never upload it, host it, or copy it into this skills repo. No third-party paper content is rendered (only the author's own outputs).
Self-contained, no tracking. Inline CSS only — no external scripts, fonts, images, or analytics.
Opt-in. Don't generate the dashboard unprompted on every turn; offer it, then refresh per the author's preference.
It only displays what other skills produced; it never edits artifacts, scores, or the paper.

Memory

Uses the shared .paper-memory/ convention (paper-memory-convention.md).

At start: read profile.yml for the paper title/venue to label the dashboard; check whether the author opted into auto-refresh.
At end: record the auto-refresh preference (date · render-workspace-html · auto-refresh on/off) so later runs honor it without re-asking.
Create .paper-memory/ on demand; local-only, never uploaded.

Plus depuis ce dépôt

même dépôt

assess-paper

ShaishavMaisuria/research-paper-lifecycle-skills

One consolidated read on how good a paper is right now — top strengths, biggest risks, scores, and what to do next — by running the compliance, integrity, citation, conformance, and mock-review skills and summarizing them in one Paper Health Report. Use when a researcher asks "how good is my paper", "is my paper ready", "what are the strengths and weaknesses of my paper", "give me an overall assessment", "review my whole paper", "what should I improve first", or "what's the state of my paper". Orchestrates preflight-check, verify-citations, check-originality, benchmark-paper, and simulate-reviewers, then summarizes them in plain language with strengths first, a prioritized fix list, and an honest readiness read — never a prediction of acceptance. Trigger words - how good is my paper, paper health, overall assessment, is it ready, strengths and weaknesses, what to improve, paper report, assess my paper.

2026-06-2214

draft-related-work

ShaishavMaisuria/research-paper-lifecycle-skills

Drafts or rewrites a Related Work / prior work section positioned against actually-retrieved papers — derives the REQUIRED clusters from the paper's own claimed scope (not just whatever was retrieved), clusters prior work into themes, articulates the delta (what this paper adds) per cluster, enforces a per-cluster citation floor and routes empty expected clusters back to find-papers, follows the target community's placement and citation conventions (numeric ACM/IEEE vs natbib author-year, single- vs double-blind self-citation, where the section sits at NeurIPS/CHI/SIGMOD-style venues), and admits only verified citations. Use when the user says "related work", "prior work", "position my paper against the literature", "how do we differ from X", "reviewers said related work is thin/missing/a laundry list", or asks to add citations to a draft. Works from papers found via find-papers and/or an existing .bib — it never invents references.

2026-06-2214

draft-survey

ShaishavMaisuria/research-paper-lifecycle-skills

Turns a topic into a ranked reading list of the best papers plus a two-column, arXiv-ready literature-review/survey draft grounded in verified citations. Use when a researcher says "write a survey on X", "do a literature review of X", "give me a ranked reading list on X", "what should I read on X first", "draft a survey paper for arXiv", or "two-column related-work survey on X". Searches across DBLP/Crossref/Semantic Scholar/arXiv, ranks candidates by citation impact, venue strength, recency, and citation-graph centrality, clusters them into a taxonomy, verifies every reference, and writes an original-prose survey (intro, taxonomy, per-theme synthesis, open problems) where each claim cites a real, resolved paper. Never fabricates citations, never copies source text — original synthesis only; the author stays the author. Trigger words - survey, literature review, reading list, ranked papers, what to read, arxiv survey, two-column review.

2026-06-2214

find-papers

ShaishavMaisuria/research-paper-lifecycle-skills

Searches scholarly literature with zero API keys across DBLP, Crossref, Semantic Scholar, and arXiv. Use when the user wants to find papers, search the literature, list a conference's proceedings (e.g. "all SIGSPATIAL 2025 papers"), survey related work on a topic, look up papers by author/venue/year, get DOIs or citation counts, or check recent arXiv preprints. Ships a venue-alias table that solves cross-API venue naming (DBLP "conf/gis" vs Semantic Scholar "SIGSPATIAL/GIS" vs Crossref proceedings titles) plus polite, cached, 429-resilient search scripts. Trigger words - find papers, literature search, related work, proceedings, DBLP, Crossref, Semantic Scholar, arXiv, citation count, DOI lookup, venue search.

2026-06-2214

literature-review

ShaishavMaisuria/research-paper-lifecycle-skills

Builds a structured literature review — survey of prior work, state of the art, related-work landscape — where every claim cites a verified reference. Use when the user says "literature review", "lit review", "survey the papers on X", "what's the state of the art", "synthesize prior work", or "organize these papers by theme". Composes sibling skills, search via find-papers (key-free DBLP/Crossref/Semantic Scholar/arXiv), full text via fetch-paper (legal open-access only), and citation checking via verify-citations. Tracks a screening corpus, extracts claims with section-level anchors, organizes by theme, and gates the final document with a deterministic checker so no claim ships uncited, unverified, or resting on a fabricated reference.

2026-06-2214

orchestrate-paper

ShaishavMaisuria/research-paper-lifecycle-skills

Goal-driven conductor for the whole idea-to-published-paper lifecycle. Takes a research idea plus experiments and a target ("submit to NeurIPS 2026", or "help me pick a venue") and runs a goal->plan->execute->verify->reflect loop. It plans the stages, invokes the right lifecycle skills in order (literature-review, write-abstract, preflight-check, simulate-reviewers, and the rest), checkpoints with the author before each stage, and re-verifies the live CFP via parse-cfp rather than trusting a cached profile. Use when a researcher says "take my idea to a submitted paper", "run the whole pipeline", "orchestrate the paper for venue X", "what's the plan from here", or "what's done and what's next". Copilot, not autonomous author. It stops to ask at every stage gate, never fabricates results or citations, and never submits. Trigger words - orchestrate, pipeline, end to end, whole paper, idea to submission.

2026-06-2214

name

render-workspace-html

description

Render Workspace HTML

When to use

The author asks for an HTML view / dashboard / browser-readable summary of progress.
After several skills have run and the workspace has enough in it to be worth a glance.
The author says "keep the HTML updated" — then regenerate it at the end of each request that changed the workspace.

Process

Offer, don't impose. If the author hasn't asked, ask once: "Want an HTML dashboard of your progress? I can refresh it after each change." Generate only on yes.
Generate (deterministic):
```
python3 scripts/build_dashboard.py --workspace paper-workspace
```
It reads paper-workspace/INDEX.md and the stage folders (and .paper-memory/profile.yml for the title/venue if present) and writes paper-workspace/dashboard.html — one self-contained file, inline CSS, no network or external assets, light/dark aware. Exit 1 only if there is no workspace yet.
Point the author to it (open paper-workspace/dashboard.html). Summarize what it shows.
Refresh on request. If the author asked to keep it live, re-run step 2 at the end of any request that wrote new artifacts, and say you refreshed it. Otherwise regenerate only when asked again.

Output

paper-workspace/dashboard.html — a stage-by-stage progress bar, artifact cards with links to each output, and a recent-activity timeline from INDEX.md. Opens offline in any browser.

Richer reports

Guardrails

Local only. The dashboard is a local file built from local artifacts; never upload it, host it, or copy it into this skills repo. No third-party paper content is rendered (only the author's own outputs).
Self-contained, no tracking. Inline CSS only — no external scripts, fonts, images, or analytics.
Opt-in. Don't generate the dashboard unprompted on every turn; offer it, then refresh per the author's preference.
It only displays what other skills produced; it never edits artifacts, scores, or the paper.

Memory

Uses the shared .paper-memory/ convention (paper-memory-convention.md).

At start: read profile.yml for the paper title/venue to label the dashboard; check whether the author opted into auto-refresh.
At end: record the auto-refresh preference (date · render-workspace-html · auto-refresh on/off) so later runs honor it without re-asking.
Create .paper-memory/ on demand; local-only, never uploaded.