Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Research project management for medical manuscripts. Scaffold project structure, track writing progress across phases, maintain project memory files, generate submission checklists and backwards timelines. Commands: init, status, sync-memory, checklist, timeline.
.claude/skills/aperivue-manage-project/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-04 | ✗→✓ | ▲ Improved | 28% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 180% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 69% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 104% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 157% | 0% |
Scaffold new research projects, track manuscript writing progress, maintain lightweight project memory, generate pre-submission checklists, and create backwards submission timelines. Integrates with all other writing skills and the project-manager agent.
/manage-project init {name} --type {type} --journal {journal} [--ssot] [--zotero-collection NAME]Create a complete project scaffold for a new research paper.
Parameters:
{name} -- Project identifier (e.g., nnunet-skull-fracture, rfa-meta-analysis)--type -- Paper type: original | meta | case | animal | technical | ai_validation | letter--journal -- Target journal: RYAI | AJR | Radiology | European_Radiology | KJR | INSI | AJNR | generic--ssot -- Emit SSOT.yaml (schema v1) from templates/SSOT.yaml.template instead of legacy project.yaml. Required for Phase 1C auto-enforce (the PostToolUse verify-refs hook blocks instead of warns). New projects should pass --ssot; legacy in-flight projects stay on project.yaml until /manage-project migrate-ssot is run.--zotero-collection NAME -- Optional. Create a Zotero collection via pyzotero and populate library_id + collection_key in the contract. Requires ZOTERO_API_KEY + ZOTERO_LIBRARY_ID (optionally ZOTERO_LIBRARY_TYPE, default user). Graceful degrade: with pyzotero missing or credentials absent, the contract is scaffolded with library_id: null / collection_key: null and a WARN is printed.SSOT template substitutions: {{PROJECT_ID}} → {name}; {{PROJECT_TYPE}} → the SSOT project_type enum mapped from --type (original → original_research, meta → meta_analysis, case → case_report, ai_validation → ai_validation, else other). Without --zotero-collection, library_id / collection_key stay null until the owner links an existing collection.
Implementation: backed by scripts/init_project.py. Invoke it directly when running outside the skill harness (from the medsci-skills repo root):
bashpython3 scripts/init_project.py \ --name {name} --type {type} --journal {journal} [--ssot] \ --project-root {target_dir}
The helper writes the contract file (SSOT.yaml with --ssot, else legacy project.yaml), the directory scaffold, the minimal stubs scripts/validate_project_contract.py requires (manuscript/index.qmd, artifact_manifest.json, qc/status.json), the memory-file templates, and project_state.json. qc/migration_complete is NOT written by init — that marker belongs to the migrate pipeline.
Do not hand-build the scaffold. The script is the source of truth for the tree and for project_state.json; a hand-built one drifts from what the contract validator expects.
Read on demand:
| File | Read it when | Cost if read blindly | |---|---|---| | references/init_scaffold.md | you need to know where a scaffolded file lands, or what a project_state.json field means | ~1,400 tokens describing output the script already produces for you |
/manage-project migrate-ssot [--no-mark-complete]Thin wrapper over scripts/migrate_project_to_ssot.py that converts a legacy project.yaml project into SSOT.yaml form and, by default, touches qc/migration_complete so Phase 1C auto mode switches from warn to enforce.
bashpython3 scripts/migrate_project_to_ssot.py \ --project-root . --write --mark-complete
--write --mark-complete (enforce-ready).--no-mark-complete flag form: run with --write only. Use when the project still has open QC failures — enforcement is deferred until the migration is validated.qc/migration_complete unless the generated SSOT.yaml passes validate_project_contract.py AND contract_mode=ssot. Do not touch qc/migration_complete manually.Re-run after resolving failures; the script is idempotent.
/manage-project statusReport current progress. Reads project_state.json, scans existing files, and checks whether key project memory files are present and aligned.
Output format:
## Project Status: {name}
Journal: {journal} | Type: {type} | Created: {date}
Target submission: {date or "not set"}
### Phase Progress
[check] Phase 0: Project Init (complete)
[check] Phase 1: Outline (complete)
[check] Phase 2: Tables & Figures (complete)
[work] Phase 3: Methods (IN PROGRESS)
[wait] Phase 4: Results (pending)
[wait] Phase 5: Discussion (pending)
[wait] Phase 6: Introduction & Abstract (pending)
[wait] Phase 7: Polish (pending)
### Word Counts
Abstract: 0 / 250 words
Introduction: 0 / 600 words
Methods: 847 / 1000 words 85%
Results: 0 / 900 words
Discussion: 0 / 800 words
Total: 847 / 3500 words (journal limit)
### Quality Gates
Critic score (Methods): 87/100 PASS
Citations verified: 12/12
Reporting guideline: pending
### Project Memory
PROJECT.md: present
STATUS.md: stale (last updated 12 days ago)
CLAIMS.md: missing
DATA_DICTIONARY.md: present
ANALYSIS_PLAN.md: missing
REVIEW_LOG.md: n/a (not in revision)
### Next Steps
1. Complete Methods draft (150 words remaining)
2. Run /analyze-stats for Table 1 and diagnostic accuracy
3. Begin Results (Phase 4)/manage-project sync-memoryAudit and refresh project memory files so other agents can work with less ambiguity.
What it does:
PROJECT.md, STATUS.md, CLAIMS.md, DATA_DICTIONARY.md, ANALYSIS_PLAN.md, REVIEW_LOG.mdproject_state.json with the current manuscript phaseSuggested use cases:
project-manager/manage-project checklistGenerate a pre-submission checklist covering all quality dimensions.
Output: submission/pre_submission_checklist.md
Read and output the pre-submission checklist from ${CLAUDE_SKILL_DIR}/references/pre_submission_checklist.md.
/manage-project timeline {submission_date}Generate a backwards timeline from submission date.
Example: /manage-project timeline 2026-05-01
Output:
## Backwards Timeline to Submission: 2026-05-01
Week -8 (2026-03-06): Phase 0-2 complete (scaffold, outline, tables)
Week -7 (2026-03-13): Methods draft -> critic pass
Week -6 (2026-03-20): Results draft -> critic pass + /analyze-stats complete
Week -5 (2026-03-27): Discussion draft -> critic pass
Week -4 (2026-04-03): Introduction + Abstract -> critic pass
Week -3 (2026-04-10): AI pattern removal + /check-reporting (reporting guideline)
Week -2 (2026-04-17): /self-review + co-author review
Week -1 (2026-04-24): Final revisions + figures at 300 DPI + /lit verification
SUBMISSION (2026-05-01): Upload to journal portal
Critical path: Statistics must be complete by Week -6.
Run /analyze-stats as soon as data is available.markdown# PROJECT - Title: - Type: - Primary question: - Target journal/venue: - Lead folder: - Collaborators: - Last updated:
markdown# STATUS - Current stage: - Current blocker: - Next actions: 1. 2. 3. - Last updated:
markdown# CLAIMS | Claim | Supporting result | Source table/figure | Citation status | |------|-------------------|---------------------|-----------------| | ... | ... | ... | ... |
markdown# DATA DICTIONARY | Variable | Definition | Timing | Notes | |----------|------------|--------|------| | ... | ... | ... | ... |
markdown# ANALYSIS PLAN - Primary endpoint: - Secondary endpoints: - Main comparator: - Statistical methods: - Validation strategy: - Sensitivity analyses:
markdown# REVIEW LOG | Reviewer comment | Planned action | Status | Location updated | |------------------|----------------|--------|------------------| | ... | ... | ... | ... |
When called from /manage-project init, automatically:
write-paper/references/journal_profiles/{JOURNAL}.mdwrite-paper/references/paper_types/{TYPE}.mdcheck-reporting/references/checklists/After /manage-project checklist, recommend calling:
/self-review for manuscript quality gate/search-lit to verify all citations/write-paper Phase 7)Phase numbers:
Phase status values: pending | in_progress | complete | blocked
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 27,905 | 7,894 | -72% | 1 | 1 | 0% | 5,487 | 3,189 | -42% | 0 | 0 | — |
case-02 | fail→fail | 20,361 | 16,137 | -21% | 1 | 1 | 0% | 3,746 | 5,802 | +55% | 0 | 0 | — |
case-03 | fail→fail | 5,381 | 7,278 | +35% | 1 | 1 | 0% | 268 | 3,087 | +1052% | 0 | 0 | — |
case-04 | fail→pass | 15,193 | 2,873 | -81% | 1 | 1 | 0% | 2,576 | 3,286 | +28% | 0 | 0 | — |
case-05 | fail→pass | 8,497 | 4,899 | -42% | 1 | 1 | 0% | 1,314 | 3,675 | +180% | 0 | 0 | — |
case-06 | fail→pass | 12,359 | 4,161 | -66% | 1 | 1 | 0% | 2,090 | 3,533 | +69% | 0 | 0 | — |
case-07 | fail→pass | 21,927 | 2,877 | -87% | 1 | 1 | 0% | 1,601 | 3,261 | +104% | 0 | 0 | — |
case-08 | pass→pass | 9,368 | 5,009 | -47% | 1 | 1 | 0% | 1,529 | 3,578 | +134% | 0 | 0 | — |
case-09 | pass→pass | 17,470 | 1,999 | -89% | 1 | 1 | 0% | 2,947 | 3,011 | +2% | 0 | 0 | — |
case-10 | fail→pass | 8,443 | 3,831 | -55% | 1 | 1 | 0% | 1,331 | 3,415 | +157% | 0 | 0 | — |
case-11 | pass→pass | 13,363 | 2,232 | -83% | 1 | 1 | 0% | 2,276 | 3,091 | +36% | 0 | 0 | — |
case-12 | fail→pass | 13,918 | 2,091 | -85% | 1 | 1 | 0% | 2,287 | 2,983 | +30% | 0 | 0 | — |
case-13 | fail→pass | 11,581 | 2,132 | -82% | 1 | 1 | 0% | 1,751 | 3,057 | +75% | 0 | 0 | — |
case-14 | pass→pass | 6,157 | 1,749 | -72% | 1 | 1 | 0% | 976 | 2,951 | +202% | 0 | 0 | — |
case-15 | fail→pass | 15,084 | 2,718 | -82% | 1 | 1 | 0% | 2,454 | 3,260 | +33% | 0 | 0 | — |
case-16 | fail→pass | 9,509 | 1,738 | -82% | 1 | 1 | 0% | 1,655 | 2,973 | +80% | 0 | 0 | — |
case-17 | fail→pass | 6,566 | 1,650 | -75% | 1 | 1 | 0% | 1,201 | 2,998 | +150% | 0 | 0 | — |
case-18 | fail→pass | 13,893 | 2,840 | -80% | 1 | 1 | 0% | 2,556 | 3,189 | +25% | 0 | 0 | — |
case-19 | fail→pass | 7,844 | 1,946 | -75% | 1 | 1 | 0% | 1,434 | 3,018 | +110% | 0 | 0 | — |
case-20 | fail→pass | 10,786 | 2,555 | -76% | 1 | 1 | 0% | 2,004 | 3,231 | +61% | 0 | 0 | — |
case-21 | pass→fail | 6,442 | 3,027 | -53% | 1 | 1 | 0% | 1,200 | 3,292 | +174% | 0 | 0 | — |
case-22 | fail→pass | 20,512 | 3,052 | -85% | 1 | 1 | 0% | 3,937 | 3,306 | -16% | 0 | 0 | — |
case-23 | fail→fail | 17,073 | 33,624 | +97% | 1 | 1 | 0% | 2,926 | 7,371 | +152% | 0 | 0 | — |
case-24 | fail→fail | 20,464 | 26,043 | +27% | 1 | 1 | 0% | 3,296 | 7,719 | +134% | 0 | 0 | — |
case-25 | fail→fail | 4,880 | 10,102 | +107% | 1 | 1 | 0% | 181 | 4,541 | +2409% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 25 cases were attempted, and 21 counted toward the lift figure. The other 4 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +52 percentage points is the difference between those two pass rates over the 21 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.