mediforce

Design or edit a Mediforce WorkflowDefinition package through a structured interview. Use when authoring a new workflow from an idea, editing an existing workflow folder, or reviewing whether a workflow follows the golden standards. Interviews the user, challenges the design toward the standards, generates the package, and validates the .wd.json against the current checkout. Triggers include "design a workflow", "author a workflow", "create a .wd.json", "build a workflow package", "edit this workflow", "new Mediforce workflow".

Review pull requests, branches, or your own pre-PR diff along three parallel axes — Standards (file-by-file conventions, dead code, DRY/KISS, comments), Spec (does it match the originating issue/PRD), and Big Picture (scope creep, removable features, duplicated mechanisms). Use when asked to review a PR, diff, branch, specific files, or your own changes before shipping.

Write a Discord update for the MediForce community from rough notes. Use when the user asks for a "Discord update", "Discord post", "community update", "weekly digest for Discord", or hands over bullet-point notes to turn into a community announcement. Produces two versions (short and detailed) in engineer-to-peers tone, no marketing language.

Write and run L4 UI E2E journey tests. Use when implementing UI features (TDD red-green), adding tests for existing features, or when E2E tests need updating. Handles the workflow: write test → run → green.

Write a new test for a feature, endpoint, handler, or pure function. Use when adding test coverage for new or changed code, or when starting a feature TDD-style (RED → GREEN). Triggers include "write a test for", "add unit test", "add integration test", "add API E2E", "TDD this", "red-green this", "cover X with a test", "test plan for". Decides the right level (L1 unit / L2 integration / L3 API E2E / L4 UI E2E / L5 external), scaffolds the file, and walks the RED-GREEN loop. Use `/e2e-test` instead for the L4 UI journey workflow.

Keep project documentation in sync with code changes. Detects stale docs in current worktree diff (default), a specific commit, a PR, or across all monitored files (--audit). Auto-fixes Tier 1 executable docs (commands, ports, env vars); proposes Tier 2 narrative doc updates as an editable git diff. Triggers: "sync docs", "update docs", "check docs", "are docs up to date", "docs stale", "documentation outdated".

Final check on your own changes before reporting a task done, opening a PR, or asking for review. Spawns a subagent that runs `/code-review` on the current branch — clean context, no "I just wrote this, it must be good" bias. Returns SHIP / ITERATE verdict. Triggers include "self review", "review my changes", "check my diff", "ready to commit", "ready for PR", "I'm done", "before I ship".

Append a one-line entry for a merged (or about-to-merge) PR under the `[Unreleased]` section in CHANGELOG.md. Use after merging a non-trivial PR, when batching multiple PRs covering one feature, or when updating a Keep-a-Changelog entry. Triggers: "add to changelog", "log this change", "update CHANGELOG", "release notes".

Work with the mediforce CLI, the dev environment, and the platform API. Use when running the app locally, invoking the platform from a script, calling the API from client code, or adding a CLI command that's missing. Triggers include "use the CLI", "run mediforce", "start dev", "start the app", "call the API", "list/get/create via API", "the CLI doesn't have X", "add a CLI command". Enforces the dogfood rule: CLI > REST. Never targets production.

Review and validate Renovate dependency PRs. Assesses risk, runs tests, fixes simple issues, and recommends merge/close/hold. Use when reviewing PRs from Renovate bot.

Render a self-contained HTML report for a CDISC CORE validation delivery. The 5-class classification (clean / minor-fix / recovery / escalate / chaos) is computed deterministically by the prior validate-script step — this skill reads it from the step input and presents it. Use this skill when the prior step has produced findings or has failed and the task is to render the report a human reviewer (or downstream auto-route) will read. Triggers: 'interpret validation', 'render validation report', 'review CDISC CORE output', 'validation report for human review', 'landing zone interpret'. This skill is the agent half of the validate -> human-review handoff.

Propose new study-specific validation rules for the landing-zone workflow based on the findings of a rejected delivery. Append-only — never modify existing rules. Reads /workspace/validation-rules.yaml and /workspace/findings.json, writes proposed additions back, plus a PR title and body to /output/result.json. Triggers: 'propose validation rules', 'codify findings into rules', 'landing zone learn from rejection', 'append validation-rules.yaml'. Used by the propose-rules agent step in the landing-zone workflow after a delivery is rejected — the goal is to capture knowledge gained from broken data so the next CRO submission catches the same problem before a human has to look at it.

Draft a professional, factual markdown rejection note that the operator forwards to the CRO after a delivery is rejected at human review. Use this skill in the landing-zone workflow only when the human reviewer has rejected a delivery — the note explains what was wrong with the data and what the CRO needs to fix before resending. The note is NOT auto-sent. Triggers: 'draft rejection note', 'compose CRO email', 'rejection draft', 'landing zone reject path'.

Ingest sources into the LLM-maintained wiki, query it, and lint it. Use when adding new docs, answering architecture/domain questions, filing a synthesis answer back, or before pushing a PR that touched wiki pages.

Write Teal app code from cowork artifact to files and push to GitHub.

Build a complete Teal Shiny app from ADaM datasets using TealFlowMCP tools, validate it, and push to GitHub. Autonomous workflow — no user interaction during execution.

Generate a Marp pitch deck (docs/pitch/deck.md) from the product vision and structure definition. Reads PRODUCT_VISION.md, STRUCTURE.md, and theme CSS, then produces a presentation and exports to PDF.

Write Discord posts from ranked GitHub changes

Evaluate GitHub changes for community interest and produce a ranked list

Generate production-quality Tables, Listings, and Figures (TLGs) from ADaM datasets using R code with gtsummary, gt, and ggplot2, guided by mock TLG shells. Use this skill whenever the user has ADaM datasets and mock TLG shells and wants to produce the actual TLG outputs. Also trigger when the user mentions 'generate TLGs', 'create tables from ADaM', 'produce clinical study report outputs', 'TLG programming', 'table programming', 'figure programming', or wants to implement the statistical analyses defined in mock shells. This skill is the fourth step in a Protocol->SAP->Metadata->TLG Shells->ADaM->TLG pipeline.

Generate mock TLG (Table, Listing, and Figure) shells from structured clinical trial metadata JSON. Use this skill whenever the user has trial metadata (output from the trial-metadata-extractor skill) and wants to create mock shells, TLG shells, display shells, output shells, or mock-ups for clinical study reports. Also trigger when the user mentions 'TLG generation', 'mock shells', 'display shells', 'CSR tables', 'clinical study report outputs', 'table shells', 'listing shells', 'figure shells', or wants to plan the reporting package for a clinical trial. This skill is the second step in a Protocol->SAP->Metadata->TLG pipeline and requires metadata JSON as input -- if the user provides a Protocol/SAP instead, redirect them to the trial-metadata-extractor skill first.

Generate ADaM datasets from SDTM data using {admiral} R code, driven by mock TLG shells. Use this skill whenever the user has SDTM datasets and mock TLG shells (output from mock-tlg-generator) and wants to create ADaM datasets. Also trigger when the user mentions 'ADaM derivation', 'ADaM generation', 'SDTM to ADaM', 'admiral code', 'ADaM programming', 'ADaM spec', 'create ADaM datasets', 'generate ADaM', or wants to derive analysis datasets from SDTM. This skill is the third step in a Protocol->SAP->Metadata->TLG->ADaM pipeline. It requires mock TLG shells as primary input and SDTM datasets as data input.

Extract structured metadata from clinical trial Protocol and Statistical Analysis Plan (SAP) documents into a standardized JSON format. Use this skill whenever the user provides a Protocol, SAP, or both (as file paths or uploaded files) and wants to extract study design, endpoints, populations, visit schedules, analysis plans, or any structured trial metadata. Also trigger when the user mentions 'protocol review', 'SAP review', 'trial metadata', 'study design extraction', 'endpoint extraction', 'ADaM planning', 'TLG planning', or wants to prepare inputs for mock TLG shell generation. This skill is the first step in a Protocol->SAP->Metadata->TLG pipeline. Even if the user only provides one document (Protocol OR SAP), use this skill -- it handles partial inputs gracefully and flags what's missing.

Generate an interactive Shiny-based clinical trial exploration app using the R teal framework from ADaM datasets and mock TLG shells. Use this skill whenever the user has ADaM datasets and wants to create an interactive teal app for data exploration, review, or QC. Also trigger when the user mentions 'teal app', 'interactive exploration', 'Shiny clinical app', 'teal modules', 'interactive TLGs', 'clinical data explorer', 'teal dashboard', or wants an interactive review tool for their ADaM data. This skill is an alternative/complement to the static TLG generation (adam-to-tlg) — it produces a live, filterable Shiny app instead of static outputs.