Add research-formatting skills and research dissemination deployment study

[erinepshovel-code]

Problem

Research content currently has no canonical procedural transformation layer for venue-specific academic manuscripts, grant proposals, or social dissemination. The absence is now affecting From Photons to the Macroverse: one research object needs to remain epistemically stable while being rendered differently for reviewers, funders, X, LinkedIn, YouTube, and the public website.

Core invariant:

source claim/evidence/status != audience rendering != deployment side effect

A high-performing social rendering may optimize for views, shares, follows, subscriber conversion, and discovery, but it may not upgrade POSTULATE/HYPOTHESIS/MODEL into ESTABLISHED/SUPPORTED merely because stronger language performs better.

Proposed skill family

1. research-paper-format

Venue-aware academic-paper preparation.

Responsibilities:

• preserve source claims, evidence, citations, figures, limitations, falsifiers, provenance, and unresolved boundaries;
• resolve the actual target venue before formatting and prefer current venue instructions over generic style assumptions;
• separate main claim, minimum mechanism, supplied evidence, and future extensions where scope compression impairs reviewability;
• support journal/conference/preprint profiles without pretending one house style is universal;
• produce manuscript, supplement, cover-letter/checklist metadata where required;
• validate title/abstract/section/figure/reference limits and accessibility requirements where the venue specifies them;
• retain an exact/source view when a transformed submission view is produced.

Current official evidence supports target-specific formatting rather than one universal template: Nature explicitly tells authors to use the destination journal's current requirements and structures its own Articles around a short accessible summary, constrained main text/display items, methods, data/code availability, declarations, and readable cross-disciplinary prose.

2. grant-proposal-format

Funder/opportunity-aware proposal preparation.

Responsibilities:

• resolve the exact funding opportunity and current application instructions before transformation;
• encode instruction precedence and fail closed on conflicts rather than silently choosing a rule;
• preserve project evidence/uncertainty while optimizing reviewer scanability;
• generate opportunity-specific section map, page budget, formatting checks, budget/narrative consistency checks, compliance checklist, and submission package manifest;
• never infer eligibility, allowability, or fit without evidence.

Current official evidence:

• NIH explicitly prioritizes current policy notices, then the specific funding opportunity, then the general application guide; it recommends realistic aims, clear organization, headings, short paragraphs/lists, white space, concise prose, and budget/research-plan consistency.
• NSF requires strict conformance to current PAPPG + solicitation rules, including page/font/margin requirements and proposal-specific sections; nonconformance can return a proposal without review.

3. research-social-format

Research-to-social transformation with platform profiles for X, LinkedIn, and YouTube.

Primary objective for this skill: maximize legitimate views and follower/subscriber growth while preserving epistemic fidelity and source provenance.

Shared responsibilities:

• start from a pinned research object/development version;
• identify audience, platform, format, and objective before writing;
• create native platform artifacts rather than copy-pasting the same text everywhere;
• generate hook/title/opening, body, media plan, CTA, alt text/captions, source link, status label, and experiment metadata;
• preserve source-development-version linkage for infograms and clips;
• produce A/B candidates only when the comparison does not alter claim standing;
• record post identity, publication time, source identity, format variant, and later metrics so iteration is evidence-bearing rather than folklore.

X profile

Current official X guidance supports concise conversational copy, clear CTAs, media that stands out, captions/sound-off video strategy, consistent posting, engagement, and repeated testing. Current X API supports programmatic post creation via POST /2/tweets with user authorization. X automation rules explicitly permit automatically broadcasting helpful information, but the account owner remains responsible for automated behavior.

Research-social policy should therefore optimize first-line novelty + visual salience + clear source path, avoid hashtag stuffing/heavy text images, and treat replies/community participation as a separate engagement action rather than mass automation.

LinkedIn profile

Current LinkedIn guidance favors useful expert/firsthand information, concise mobile-readable thought leadership, consistent publishing, native articles/documents/video, and measuring impressions, out-of-network reach, engagements, profile activity, and follower growth. LinkedIn's 2026 guidance specifically emphasizes original educational content, strong first lines, frequent expert posting, and pairing posts with deeper articles.

LinkedIn Posts API currently supports organic text, images, videos, documents, articles, multi-image, polls, etc. w_member_social / w_organization_social govern writes; Community Management access and analytics permissions remain access-tier dependent and must be checked at execution time.

For research papers, native PDF/document posts, short insight posts, longer articles, and researcher-authored video should be generated as distinct variants rather than one universal LinkedIn output.

YouTube profile

Current YouTube guidance makes title/thumbnail expectation matching and audience retention central. The first 30 seconds should deliver what title/thumbnail promised; top moments should be surfaced earlier when possible. Shorts ranking uses viewer choice-to-watch, average view duration, average percentage viewed, likes, surveys, personalization, topic interest, competition, and seasonality. Audience analytics distinguishes new/casual/regular viewers; consistent topic/format and community interaction help grow regular viewers.

A research-paper YouTube renderer should therefore generate at least:

• Short/vertical hook version;
• concise visual explainer;
• full research walkthrough when warranted;
• title + custom thumbnail specification;
• chapter/description/source metadata;
• caption track;
• CTA oriented to next related research object / subscribe only after value delivery.

Separate research track: research-distribution-automation

Do not bury platform writes inside the formatting skill. Deployment is a side-effecting operational capability and needs its own research/permission boundary.

Current feasibility established from official APIs

• X: API can create posts, threads/replies/media-linked posts with authenticated user context; automation rules constrain acceptable behavior.
• LinkedIn: Posts API can create organic text/image/video/document/article posts with appropriate member/org scopes; API versions are time-versioned and Community Management access/analytics permissions can be restricted.
• YouTube: Data API can upload videos, set thumbnails, upload captions, and schedule metadata; unverified API projects uploading videos are private by default until compliance audit. YouTube Analytics/Reporting APIs can retrieve performance metrics programmatically.

Research still required before implementation

1. exact current account/API access available to The Interdependency for each platform;
2. current pricing/quota/rate-limit behavior and whether automation is economically sensible;
3. media-upload flows and resumability for each platform;
4. whether personal-account vs organization/page publishing requires different applications or review;
5. analytics retrieval available for each account type and metric latency;
6. safe credential storage on the VM and least-privilege OAuth refresh flow;
7. publish approval policy: auto-publish vs staged draft vs human gate by claim standing;
8. rollback/deletion/update behavior and immutable publication receipts;
9. platform-specific AI-generated media disclosure requirements;
10. experiment design for reach/follower optimization without engagement bait, spam, or epistemic distortion;
11. failure behavior when one platform publishes and another fails;
12. source-development-version linkage so old social artifacts remain traceable after research evolves.

Composition with existing skills

• distributed-publication: source identity, exact/transformed view separation, provenance, fallback, public reading surface.
• data-visualization: visual grammar/accessibility/status encoding for infograms and figures.
• action-calibration: choose minimal decisive dissemination experiment before scaling.
• risk-boundary-build: own runtime permissions/side-effect boundaries for deployment.
• interdependent-work-graph: preserve repo ownership and cross-repository source identities.

Do not duplicate those contracts inside the new skills.

Validation expectations

For each formatting skill, tests should show:

• source claims/status are preserved across transformations;
• venue/platform constraints are explicit and current-source bound;
• missing target rules become hmmm, not invented conventions;
• transformed text cannot silently erase limitations/falsifiers;
• output contains source/version provenance;
• social optimization variables are separable from scientific claim variables.

For deployment research, no production write implementation should be called complete until current official API docs, authentication/access, sandbox/private publication, receipts, delete/update behavior, and metrics retrieval have been tested with the actual accounts.

hmmm

• whether the three formatters remain separate skills or share a research-transform substrate after field use;
• whether platform profiles inside research-social-format eventually deserve separate skills as API/format divergence increases;
• which metrics best represent durable audience growth rather than transient impressions;
• how much automated experimentation is acceptable before human review becomes required for research reputation/claim-risk reasons;
• whether deployment belongs in skill-lib as one cross-platform skill or as platform-specific adapters under a common contract.