Appsilon

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".

Build an interactive, self-contained HTML traceability explorer that links the full clinical-deliverable chain Objective -> Endpoint -> SDTM domain -> ADaM dataset -> TLF, with the Analysis Results Data (ARD) as the connective data layer. Assembles a node/edge graph from the pipeline artifacts (study-model.json, tlf-plan.json, analysis-spec.json, adam-spec.json) and per-table outputs (generated.md, ard.json, generate.R), then emits ONE standalone .html file (vanilla JS + SVG, zero external libraries/CDN/fonts) with an interactive node graph, click-to-highlight lineage, per-node detail panels, status badges, filters and search. Use this skill when the user wants to SEE how outputs trace back to objectives/endpoints and forward to their data — phrases like 'traceability', 'traceability matrix', 'lineage', 'objective-to-TLF', 'end-to-end trace', 'where does this table come from', 'ARD explorer', 'deliverables dashboard', 'traceability explorer', 'link objectives to tables', 'coverage of endpoints', 'which endpoi

Generate ADaM datasets from SDTM data using {admiral} R code, DRIVEN BY the ADaM spec (adam-spec.json) produced upstream by tlf-analysis-spec. The derived ADaM MUST satisfy the spec's datasets/parameters/variables/populations and its MANDATORY derivation rules: (1) day-based analysis-visit windowing that never drops unscheduled/early-termination visits, (2) LOCF records (DTYPE='LOCF', ANL01FL='Y') at the endpoint visit, (3) SITEGR1 pooling on RANDOMIZED (ITTFL='Y') counts. Enforces a data-quality gate on analysis-set N and checks conformance with metacore/metatools. Use this skill whenever the user has an adam-spec.json (or reviewed ADaM spec) plus SDTM datasets and wants ADaM datasets. Also trigger on 'ADaM derivation', 'ADaM generation', 'SDTM to ADaM', 'admiral code', 'derive analysis datasets', 'spec-driven ADaM'. Third step in the Protocol->SAP->TLF-plan->analysis/ADaM-spec->ADaM->TLF pipeline.

Turn a reviewed TLF plan into the analysis specs + ADaM variable spec that drive ADaM derivation and TLF generation. Use this skill when the user has a tlf-plan.json (from tlf-planner / tlf-plan-critic) and asks to 'author the analysis spec', 'build the ADaM spec', 'map the TLF plan to specs', 'create the analysis metadata', 'write the statistical method spec', 'produce ARS-aligned analysis specs', or 'run the bridge before ADaM / generation'. This is Step 2 of the TLF pipeline — the human-review gate between planning and compute: for every producible TLF it authors an ARS-aligned analysis-spec entry (analysisSet, groupingFactor, dataSubset, analysisVariables, methods with operations/model/lsmeans/contrasts, rounding), and aggregates the union of all TLFs' data needs into a reviewable adam-spec.json (datasets, parameters, variables, flags, the mandatory derivation rules, and the data-quality N-gate). It does NOT run R or derive ADaM — it produces specs only. Run before sdtm-to-adam and tlf-generator.

Generate the actual Tables, Listings, and Figures (TLFs) from an ARS-aligned analysis spec + ADaM data, ARD-first: compute every statistic into Analysis Results Data (ARD) with {cards}/{cardx}/emmeans, then render the ARD to the target display shape with {gtsummary} (tables) and {ggsurvfit} (Kaplan-Meier figures), applying SAS rounding at display time. Use this skill when the user has an analysis-spec.json (from tlf-analysis-spec) plus ADaM datasets and wants to produce the numbers and the displays. Also trigger on: 'generate TLFs/tables/figures', 'produce ARD', 'analysis results data', 'cards/cardx tables', 'gtsummary tables from ADaM', 'ANCOVA LS-means table', 'Kaplan-Meier figure', 'ADaM to tables', or 'compute the numbers for the tables'. This is Stage-3 of the Protocol->TLF pipeline and REPLACES/UPGRADES the older adam-to-tlg skill with an ARD-native numbers-then-format approach; prefer this skill over adam-to-tlg when an analysis spec exists.

Derive the exhaustive, traceable list of required TLFs (Tables, Listings, Figures) for a clinical study from its USDM metadata JSON. Use this skill when the user has a USDM / CDISC DDF study definition (or asks 'what TLFs/tables/listings/figures do we need', 'derive the TLF list', 'plan the reporting package from USDM', 'map objectives and endpoints to tables', or 'run the TLF planner'). This is the planning/inventory step that runs before ARD dataset creation and before {cards}/{cardx} TLF generation. It interprets objectives and endpoints, adds the ICH E3 regulatory tables no objective points to, fans out statistical analyses (imputation, subgroups, timepoints, sensitivity models), checks data feasibility, and produces a numbered, human-reviewable TLF index. Pair with the tlf-plan-critic skill, which independently audits the result for coverage and completeness.

Generalized self-learning loop for the CDISC Case 3 pipeline. Distil durable, per-skill lessons from the reviewer feedback captured during a run across ALL THREE review gates (plan / specs / TLFs). Reads /workspace/review_feedback.jsonl — one object per revise, each tagged with the skill it targets (tlf-planner, tlf-analysis-spec, tlf-generator) — plus the approved artifacts and each target skill's current references/lessons-learned.md; proposes an append-only markdown block per revised skill that would have produced an approvable result first pass. Writes { hasLessons, lessons: [ { skill, lessonAppendMarkdown } ], prTitle, prBody, summary } to /output/result.json. Append-only — never rewrites existing lessons. Triggers: 'learn from review feedback', 'propose skill lessons', 'codify reviewer comments into the skills', 'self-learning loop'. Used by the propose-skill-update agent step after the pipeline's reviews.

Independently audit a TLF plan (produced by the tlf-planner skill) for traceability and completeness before human review. Use this skill after tlf-planner, or whenever the user asks to 'audit/review/QC the TLF plan', 'check TLF coverage', 'verify every endpoint has a table', 'find missing or orphan TLFs', or 'run the coverage/traceability check'. It performs a two-way audit — forward (every objective and every resolved endpoint maps to at least one planned TLF) and backward (every TLF traces to an objective/endpoint or a regulatory rule) — plus conventional-completeness heuristics, then emits a coverage report with a verdict and, on gaps, a bounded re-run plan. It reads only the plan and the study model, never the planner's reasoning, so the check is genuinely independent.

Discover available plugins and generate 1-N execution proposals for a workflow structure. Each proposal is a complete WorkflowDefinition. Produces a visual comparison of proposals for reviewer selection.

Generate workflow structure (steps, transitions, triggers) from a natural language description. Produces both a YAML structure file and an HTML flow diagram for visual review.

Discover available plugins and generate 1-N execution proposals for a workflow structure. Each proposal is a complete WorkflowDefinition with executor config on every step.

Generate or modify workflow structure (steps, transitions, triggers) from a baseline and natural language instructions. Outputs partial WorkflowDefinition YAML — structural elements only, without execution config (executor, agent, plugin are added later).

Build a USDM v3.0 study representation from a ClinicalTrials.gov record (Stage 1 output) and, when present, the protocol PDF Schedule of Activities. Use this skill for Stage 2 of the protocol-to-synthetic-SDTM pipeline: when 00_raw/<NCT>.json exists and you need 01_usdm/usdm.json + soa.json. Deterministically maps the structured, enumerated CT.gov fields (arms, interventions, eligibility flags, phase, design) and uses the LLM ONLY for the free-text fragments that have no clean schema field — parsing eligibility criteria into discrete criterion objects, normalising objectives/endpoints, and reading the protocol Schedule of Activities into a visit grid + activity list. Triggers: 'extract USDM', 'build USDM', 'Stage 2', 'USDM from study record', 'SoA extraction'.

Match each USDM activity/assessment to a CDISC Biomedical Concept (BC). Use this skill for Stage 3 of the protocol-to-synthetic-SDTM pipeline: when 01_usdm/usdm.json exists and you need 02_bc_matches.json. Deterministically retrieve candidate BCs from the CDISC Library (keyword / NCIt search via the cdisclib MCP server), then use the LLM ONLY to select the best-matching BC from the retrieved candidate set and assign a confidence score. The LLM never invents a BC id — it only chooses from candidates. Unmatched activities are flagged, not dropped. Triggers: 'match biomedical concepts', 'BC matching', 'Stage 3', 'map activities to BCs', 'find biomedical concept for activity'.

Look up SDTMIG v3.4 domain/variable information (Core status, Role, Type, allowed values) from the authoritative CSV reference file. Use this whenever you need to verify whether a variable is Required, Expected, or Permissible in a domain — do NOT assume or guess. Trigger when authoring or reviewing rules and you need to confirm variable constraints.

Author, edit, and review CDISC SDTM/SDTMIG conformance rules in the core-contributor repo. Use this skill whenever the user asks to work on a CG rule, CORE rule, or conformance rule - including phrases like "author CG0057", "edit CORE-000084", "fix rule CG0085", "work on CG rule", "migrate rule", "verify rule", "add test data for rule", "fix validation for CORE-000XXX", or any mention of CG/CORE rule IDs. Also trigger when user mentions SDTM rule authoring, rule migration, or conformance rule testing.