Agent skill

Admiral Adsl

by RConsortium in RConsortium/pharma-skills

Derives an ADaM Subject-Level Analysis Dataset (ADSL) using the {admiral} R package and pharmaverse ecosystem.

MITAuto-check passed

Install Admiral Adsl

skills CLI
$ npx skills add RConsortium/pharma-skills --skill admiral-adsl -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install RConsortium/pharma-skills admiral-adsl --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/RConsortium/pharma-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/admiral/admiral-adsl .claude/skills/admiral-adsl && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
admiral-adsl
GitHub stars
120
Token cost
~4.4k tokens
SKILL.md length
915 words
Files
7 (incl. references)
Skills in repo
13
Repo updated
First seen
Licence
MIT

At a glance

Derives an ADaM Subject-Level Analysis Dataset (ADSL) using the {admiral} R package and pharmaverse ecosystem.

  • Works in 12 steps: Setup and domain loading → Subject spine → Treatment dates (TRTSDTM, TRTSTMF,… → …
  • A user needs to create ADSL from SDTM domains
  • SKILL.md covers Inputs, Workflow, Code quality requirements and Common errors to avoid, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Admiral Adsl is an agent skill from RConsortium/pharma-skills. Derives an ADaM Subject-Level Analysis Dataset (ADSL) using the {admiral} R package and pharmaverse ecosystem. Use when a user needs to create ADSL from SDTM domains, derive standard subject-level variables (treatment dates, disposition, demographics, population flags), or generate QC-ready R code following CDISC ADaM conventions. Requires SDTM input data and an ADaM spec.

Its SKILL.md is about 4.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 8 other files, including reference files (for example `DESIGN.md`, `README.md` and `benchmarks/README.md`). Compatibility notes: Requires R with admiral, dplyr, lubridate, and pharmaversesdtm installed. Designed for use in a GxP-compliant environment with access to SDTM datasets and an…

The repository describes itself as: A collection of agent skills for BioPharma use cases GSDBench Intake https://rconsortium.github.io/pharma-skills/gsdbench-intake/. The licence is MIT.

When your agent uses it

  • A user needs to create ADSL from SDTM domains
  • Derive standard subject-level variables (treatment dates
  • Population flags)
  • Generate QC-ready R code following CDISC ADaM conventions

Example prompts

  • “Use the admiral-adsl skill to derive an ADaM Subject-Level Analysis Dataset (ADSL) using the {admiral} R package and pharmaverse ecosystem”
  • “/admiral-adsl”

Requirements

  • Compatibility (from SKILL.md): Requires R with admiral, dplyr, lubridate, and pharmaversesdtm installed. Designed for use in a GxP-compliant environment with access to SDTM datasets and an ADaM ADSL specification.

Workflow steps

12 steps, taken from the step headings in SKILL.md.

  1. Setup and domain loading
  2. Subject spine
  3. Treatment dates (TRTSDTM, TRTSTMF, TRTEDTM, TRTETMF, TRTSDT, TRTEDT)
  4. Planned and actual treatment (TRT01P, TRT01PN, TRT01A, TRT01AN)
  5. Randomisation and reference dates
  6. Death variables
  7. Study day variables
  8. Treatment duration
  9. Disposition (EOSSTT, DCSREAS, EOSDT)
  10. Baseline demographics
  11. Population flags (SAFFL, ITTFL, PPROTFL)
  12. Dataset attributes and final checks

What it can do on your machine

Read from SKILL.md and the folder at commit ae5d83b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are r).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

  • Compatibility

    Requires R with admiral, dplyr, lubridate, and pharmaversesdtm installed. Designed for use in a GxP-compliant environment with access to SDTM datasets and an ADaM ADSL specification.

    From compatibility in the SKILL.md frontmatter.

Context cost

Admiral Adsl loads about 4.4k tokens when it runs, and up to ~11k if it reads all its reference files. Until then it costs about 97 tokens; SKILL.md has 915 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~97
When it runs · the whole SKILL.md, loaded when a task matches
~4.4k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~11k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from RConsortium/pharma-skills at commit ae5d83b, republished under its MIT licence (© RConsortium). 915 words, ~4,423 tokens.

Download SKILL.mdSave it as .claude/skills/admiral-adsl/SKILL.md (or your agent's skills folder). This skill also uses 6 other files; get the full folder from GitHub.
name
admiral-adsl
description
Derives an ADaM Subject-Level Analysis Dataset (ADSL) using the {admiral} R package and pharmaverse ecosystem. Use when a user needs to create ADSL from SDTM domains, derive standard subject-level variables (treatment dates, disposition, demographics, population flags), or generate QC-ready R code following CDISC ADaM conventions. Requires SDTM input data and an ADaM spec.
compatibility
Requires R with admiral, dplyr, lubridate, and pharmaversesdtm installed. Designed for use in a GxP-compliant environment with access to SDTM datasets and an ADaM ADSL specification.
license
MIT
metadata.author
Navitas Data Sciences
metadata.version
0.2
metadata.pharmaverse
true
metadata.parent
admiral

admiral-adsl

Shared conventions (library setup, pipe style, date rules, flag convention, # REVIEW: annotations, stopifnot() patterns) are defined in the parent ../SKILL.md. The workflow below is ADSL-specific.

Derives a CDISC-conformant ADSL dataset using {admiral}. Outputs executable, QC-ready R code with derivation logic traceable to the ADaM specification.

See admiral-functions reference for function selection guidance. See adsl-conventions reference for CDISC variable conventions.


Inputs

Before generating code, confirm the following are available or explicitly noted as absent:

InputRequiredNotes
DMYesSubject spine; one record per USUBJID
EXYesExposure; needed for treatment dates and SAFFL
DSYesDisposition; needed for EOSSTT, DCSREAS
DVNoProtocol deviations; needed for PPROTFL
MHNoMedical history flags if protocol requires
VSNoHEIGHTBL, WEIGHTBL, BMIBL if in scope
ADaM ADSL specYesVariable list, derivation rules, grouping cut-points
Study contextYesTreatment arm names, population flag definitions

If required domains are absent, stop and request them. If optional domains are absent, omit the corresponding derivations and note this in code comments.


Workflow

Follow these steps in order. Generate code section by section, not as a single block.

Step 1 — Setup and domain loading
r
library(admiral)
library(dplyr)
library(lubridate)
library(pharmaversesdtm)

# Load SDTM domains
dm  <- pharmaversesdtm::dm
ex  <- pharmaversesdtm::ex
ds  <- pharmaversesdtm::ds
# mh <- pharmaversesdtm::mh  # uncomment if in scope

# Confirm one record per USUBJID in DM before proceeding
stopifnot(nrow(dm) == n_distinct(dm$USUBJID))
Step 2 — Subject spine

Start from DM. One record per USUBJID is mandatory at this step and must be preserved throughout. Select only variables needed downstream.

r
adsl <- dm |>
  select(
    STUDYID, USUBJID, SUBJID, SITEID,
    AGE, AGEU, SEX, RACE, ETHNIC, COUNTRY,
    ARM, ARMCD, ACTARM, ACTARMCD,
    DMDTC, RFSTDTC, RFENDTC,
    DTHFL, DTHDTC
  )
Step 3 — Treatment dates (TRTSDTM, TRTSTMF, TRTEDTM, TRTETMF, TRTSDT, TRTEDT)

Derive datetimes first, then extract date-only variables. Always include time_imputation arguments and always retain imputation flags (TRTSTMF, TRTETMF) in new_vars — setting flag_imputation = "auto" without capturing the flag variables provides no traceability benefit.

Remove DOMAIN from EX before merging to avoid variable conflicts.

r
ex_dtm <- ex |>
  select(-DOMAIN) |>
  derive_vars_dtm(
    dtc             = EXSTDTC,
    new_vars_prefix = "EXST",
    date_imputation = "first",
    time_imputation = "first",
    flag_imputation = "auto"
  ) |>
  derive_vars_dtm(
    dtc             = EXENDTC,
    new_vars_prefix = "EXEN",
    date_imputation = "last",
    time_imputation = "last",
    flag_imputation = "auto"
  )

# TRTSDTM / TRTSTMF: first dose datetime and imputation flag
# REVIEW: The placebo filter (EXTRT == "PLACEBO") must be confirmed against the
#   protocol. In some studies EXDOSE > 0 is sufficient; in others EXDOSE = 0
#   for placebo and EXTRT must be used. Adjust condition per protocol definition.
adsl <- adsl |>
  derive_vars_merged(
    dataset_add = ex_dtm,
    by_vars     = exprs(STUDYID, USUBJID),
    new_vars    = exprs(TRTSDTM = EXSTDTM, TRTSTMF = EXSTTMF),
    order       = exprs(EXSTDTM),
    mode        = "first",
    filter_add  = (EXDOSE > 0 | EXTRT == "PLACEBO") & !is.na(EXSTDTM)
  ) |>
  # TRTEDTM / TRTETMF: last dose datetime and imputation flag
  # REVIEW: If subjects have non-contiguous EX records, TRTEDTM reflects the
  #   last administration date only. Flag for QC if exposure gaps exist.
  derive_vars_merged(
    dataset_add = ex_dtm,
    by_vars     = exprs(STUDYID, USUBJID),
    new_vars    = exprs(TRTEDTM = EXENDTM, TRTETMF = EXENTMF),
    order       = exprs(EXENDTM),
    mode        = "last",
    filter_add  = (EXDOSE > 0 | EXTRT == "PLACEBO") & !is.na(EXENDTM)
  ) |>
  mutate(
    TRTSDT = as.Date(TRTSDTM),
    TRTEDT = as.Date(TRTEDTM)
  )
Step 4 — Planned and actual treatment (TRT01P, TRT01PN, TRT01A, TRT01AN)

Use derive_vars_merged_lookup() with a treatment lookup tibble — this is the idiomatic admiral approach for controlled terminology mapping and is preferred over case_when() or mutate() for treatment arm coding.

TRT01P/TRT01PN: from DM.ARMCD (planned). TRT01A/TRT01AN: from DM.ACTARMCD (actual). These are distinct — derive independently.

r
# REVIEW: Confirm ARMCD values, treatment labels, and numeric codes against
#   the randomisation schedule and ADaM spec before use.
arm_lookup <- tibble::tribble(
  ~ARMCD,    ~TRT01P,                   ~TRT01PN,
  "Pbo",     "Placebo",                 1L,
  "Xan_Lo",  "Xanomeline Low Dose",     2L,
  "Xan_Hi",  "Xanomeline High Dose",    3L
  # Screen failure subjects (Scrnfail) are not in the lookup — they receive NA
)

adsl <- adsl |>
  derive_vars_merged_lookup(
    dataset_add = arm_lookup,
    by_vars     = exprs(ARMCD),
    new_vars    = exprs(TRT01P, TRT01PN)
  ) |>
  derive_vars_merged_lookup(
    dataset_add = arm_lookup |>
      rename(ACTARMCD = ARMCD, TRT01A = TRT01P, TRT01AN = TRT01PN),
    by_vars     = exprs(ACTARMCD),
    new_vars    = exprs(TRT01A, TRT01AN)
  )
Step 5 — Randomisation and reference dates

Use derive_vars_dt() for all date conversions from DM — never use as.Date() directly on --DTC variables as this bypasses partial date imputation handling.

r
adsl <- adsl |>
  # RANDDT: date of randomisation from DM.DMDTC
  # REVIEW: Confirm DMDTC is the randomisation date in this study. In some
  #   studies randomisation date comes from a separate SDTM domain (e.g. RS).
  derive_vars_dt(
    dtc             = DMDTC,
    new_vars_prefix = "RAND",
    date_imputation = "first",
    flag_imputation = "auto"
  ) |>
  derive_vars_dt(
    dtc             = RFSTDTC,
    new_vars_prefix = "RFST",
    date_imputation = "first",
    flag_imputation = "auto"
  ) |>
  derive_vars_dt(
    dtc             = RFENDTC,
    new_vars_prefix = "RFEND",
    date_imputation = "last",
    flag_imputation = "auto"
  )
Step 6 — Death variables
r
adsl <- adsl |>
  derive_vars_dt(
    dtc             = DTHDTC,
    new_vars_prefix = "DTH",
    date_imputation = "first",
    flag_imputation = "auto"
  ) |>
  mutate(
    # Ensure CDISC flag convention: "Y" or NA — never "N"
    DTHFL = if_else(DTHFL == "Y", "Y", NA_character_)
  )
Step 7 — Study day variables

Use derive_vars_dy() — do not compute manually with date subtraction.

r
adsl <- adsl |>
  derive_vars_dy(
    reference_date = TRTSDT,
    source_vars    = exprs(RANDDT)
  )
Step 8 — Treatment duration
r
adsl <- adsl |>
  derive_var_trtdurd()
  # Requires TRTSDT and TRTEDT to be present. NA for untreated subjects.
Step 9 — Disposition (EOSSTT, DCSREAS, EOSDT)

Filter DS to DSCAT == "DISPOSITION EVENT". Verify uniqueness before merging. Categorise EOSSTT within the source dataset before the merge — never pass DSDECOD through directly to EOSSTT, as DSDECOD contains reason values ("ADVERSE EVENT", "SCREEN FAILURE") not status values.

Derive DCSREAS in a separate derive_vars_merged() call filtered to discontinued subjects only — this avoids a post-merge mutate() cleanup step.

r
ds_eos <- ds |>
  select(-DOMAIN) |>
  filter(DSCAT == "DISPOSITION EVENT") |>
  derive_vars_dt(
    dtc             = DSDTC,
    new_vars_prefix = "DS",
    date_imputation = "last",
    flag_imputation = "auto"
  )

# Confirm one DISPOSITION EVENT record per subject
stopifnot(n_distinct(ds_eos$USUBJID) == nrow(ds_eos))

# EOSSTT: end of study status — "COMPLETED" or "DISCONTINUED" only
# REVIEW: Verify the COMPLETED/DISCONTINUED mapping covers all DSDECOD values
#   in this study's DS domain. Some protocols require a third category for
#   "STUDY TERMINATED BY SPONSOR". Confirm with the statistician.
adsl <- adsl |>
  derive_vars_merged(
    dataset_add = ds_eos |>
      mutate(
        EOSSTT = if_else(DSDECOD == "COMPLETED", "COMPLETED", "DISCONTINUED")
      ),
    by_vars  = exprs(STUDYID, USUBJID),
    new_vars = exprs(EOSSTT, EOSDT = DSDT)
  ) |>
  # DCSREAS: decoded discontinuation reason — NA for completers per CDISC convention
  # REVIEW: DCSREAS is sourced from DS.DSDECOD (decoded value). DS.DSTERM
  #   (verbatim text) belongs in DCSREASP. Do not swap these.
  derive_vars_merged(
    dataset_add = ds_eos |>
      filter(DSDECOD != "COMPLETED"),
    by_vars  = exprs(STUDYID, USUBJID),
    new_vars = exprs(DCSREAS = DSDECOD, DCSREASP = DSTERM)
  )
Step 10 — Baseline demographics

Derive AGE groupings per the ADaM spec. The example cut-points below are placeholders only — always replace with the study-specific values from the ADaM spec. Do not use these defaults without explicit confirmation.

r
# REVIEW: Age cut-points must come from the ADaM spec — they are study-specific.
#   The values below are placeholders. Replace before use.
adsl <- adsl |>
  mutate(
    AGEGR1 = case_when(
      AGE < 65              ~ "<65",     # PLACEHOLDER — confirm from spec
      AGE >= 65 & AGE <= 80 ~ "65-80",  # PLACEHOLDER — confirm from spec
      AGE > 80              ~ ">80"      # PLACEHOLDER — confirm from spec
    ),
    AGEGR1N = case_when(
      AGEGR1 == "<65"   ~ 1L,
      AGEGR1 == "65-80" ~ 2L,
      AGEGR1 == ">80"   ~ 3L
    )
  )

If VS is in scope, derive HEIGHTBL, WEIGHTBL, BMIBL using derive_vars_merged() from the baseline VS records (VSBLFL == "Y").

Step 11 — Population flags (SAFFL, ITTFL, PPROTFL)

Critical: population flag definitions are protocol-specific. The derivations below implement standard logic but must be reviewed against the protocol and SAP before use. Flag is "Y" or NA only — never "N".

r
# SAFFL: received at least one dose
# REVIEW: SAFFL definition is protocol-specific. The condition below includes
#   placebo subjects (EXTRT == "PLACEBO") who have EXDOSE = 0 in some studies.
#   Verify EXTRT values in EX exhaustively and confirm with the statistician.
adsl <- adsl |>
  derive_var_merged_exist_flag(
    dataset_add   = ex,
    by_vars       = exprs(STUDYID, USUBJID),
    new_var       = SAFFL,
    condition     = (EXDOSE > 0 | EXTRT == "PLACEBO") & !is.na(EXSTDTC),
    true_value    = "Y",
    false_value   = NA_character_,
    missing_value = NA_character_
  ) |>
  # ITTFL: randomised subjects — ARMCD != "Scrnfail" AND ARM != "Screen Failure"
  # REVIEW: Confirm ITTFL exclusion criteria with the statistician. The ARMCD
  #   condition is more reliable than ARM text matching — use both as a safeguard.
  mutate(
    ITTFL = if_else(
      ARMCD != "Scrnfail" & ARM != "Screen Failure",
      "Y",
      NA_character_
    )
  )
# ITTFL pipe chain ends here; PPROTFL is derived separately below.

# PPROTFL: per-protocol — ITT subjects with no major protocol deviations.
# Uses derive_vars_merged() + filter_add (not derive_var_merged_exist_flag) because
# the exclusion criterion belongs in filter_add, and NA absence of a match is the
# natural signal that no major deviation record was found for the subject.
#
# Guard: DV-absent and DV-present-but-no-major-deviations are different states
# and must not produce the same PPROTFL output. If DV is not loaded, halt so the
# analyst can decide explicitly — do not silently set NA.
# REVIEW: DVCAT values must match the protocol deviation management plan (PDMP).
#   Some studies categorise by DVCAT == "MAJOR"; others use DVSCAT or a study-
#   specific flag. Confirm the filter_add condition with the statistician before use.
if (!exists("dv")) {
  stop(
    "DV domain is required for PPROTFL derivation but is not loaded. ",
    "Load DV, or set adsl$PPROTFL <- NA_character_ explicitly if the study ",
    "has no protocol deviation records and this has been confirmed with the statistician."
  )
}

dv_major <- dv |>
  select(-DOMAIN) |>
  mutate(MAJDVFL = "Y")

adsl <- adsl |>
  derive_vars_merged(
    dataset_add = dv_major,
    by_vars     = exprs(STUDYID, USUBJID),
    new_vars    = exprs(MAJDVFL),
    filter_add  = DVCAT == "MAJOR",
    mode        = "first"   # subjects may have >1 major deviation record; any match suffices
  ) |>
  mutate(
    PPROTFL = if_else(ITTFL == "Y" & is.na(MAJDVFL), "Y", NA_character_)
  ) |>
  select(-MAJDVFL)  # intermediate exclusion flag; not an ADSL output variable
Step 12 — Dataset attributes and final checks
r
# One record per USUBJID — non-negotiable per ADaMIG; FDA will reject if violated
stopifnot(nrow(adsl) == n_distinct(adsl$USUBJID))

# Check required variables are present
required_vars <- c(
  "STUDYID", "USUBJID", "TRTSDT", "TRTEDT",
  "TRT01P", "TRT01PN", "TRT01A", "TRT01AN",
  "TRTSDTM", "TRTSTMF", "TRTEDTM", "TRTETMF",
  "EOSSTT", "SAFFL", "ITTFL"
)
missing_vars <- setdiff(required_vars, names(adsl))
if (length(missing_vars) > 0) {
  stop("Missing required ADSL variables: ", paste(missing_vars, collapse = ", "))
}

# Apply variable labels — use xportr for submission context
# adsl <- adsl |>
#   xportr_label(metacore_obj, domain = "ADSL") |>
#   xportr_type(metacore_obj, domain = "ADSL") |>
#   xportr_length(metacore_obj, domain = "ADSL") |>
#   xportr_order(metacore_obj, domain = "ADSL")
# xportr_write(adsl, "adsl.xpt", label = "Subject-Level Analysis Dataset")
#
# For non-submission contexts:
# Hmisc::label(adsl$TRTSDT) <- "Date of First Study Treatment"
# Hmisc::label(adsl$SAFFL)  <- "Safety Population Flag"

Show full SKILL.md (385 more words)Show less

Code quality requirements

Generated code must meet these standards for QC-readiness:

  • Comments: Each derivation block must have a comment referencing the source variable (e.g. # TRTSDT: first dose date from EX.EXSTDTC per ADaM spec §4.2)
  • Human review flags: Use # REVIEW: comments where protocol-specific decisions are required (population flags, disposition record selection, cut-points, treatment arm coding)
  • No silent failures: Use stopifnot() for critical assertions (one record per subject at DM load, DS uniqueness before merge, required variables present)
  • Pipe style: Use the native pipe |> and exprs() for admiral verb arguments
  • No manual date arithmetic: Always use admiral date derivation functions

Common errors to avoid

  • Using slice(), slice_min(), slice_max(), or manual group_by/summarise instead of derive_vars_merged() with mode
  • Using as.Date(), as.POSIXct(), convert_dtc_to_date(), or convert_dtc_to_datetime() directly on --DTC variables — always use derive_vars_dt() or derive_vars_dtm()
  • Setting flag_imputation = "date" instead of "auto" — "date" only generates a date imputation flag and silently drops the time imputation flag
  • Setting flag_imputation = "auto" without including the generated flag variables (e.g. TRTSTMF, TRTETMF) in new_vars — the flags must be explicitly requested to appear in the output
  • Setting date_imputation = "none" for reference or death dates — partial dates will return NA silently; use "first" for start dates and "last" for end dates
  • Passing DSDECOD directly to EOSSTT without categorisation — DSDECOD contains reason values ("ADVERSE EVENT", "SCREEN FAILURE") not status values; EOSSTT must be "COMPLETED" or "DISCONTINUED" only
  • Mapping DCSREAS from DSTERM (verbatim) instead of DSDECOD (decoded) — DCSREAS = decoded value, DCSREASP = verbatim text
  • Using case_when() for treatment arm coding when derive_vars_merged_lookup() is available — the lookup function is more idiomatic and spec-driven
  • Not removing DOMAIN from source datasets before derive_vars_merged() calls
  • Using "N" for flag variables — CDISC convention is "Y" or NA, never "N"
  • Hardcoding AGEGR1 cut-points without a # REVIEW: annotation — these are always study-specific and must come from the ADaM spec

Output checklist

Before returning code, verify:

  • DM uniqueness confirmed with stopifnot() at load
  • DS uniqueness confirmed with stopifnot() before disposition merge
  • One record per USUBJID confirmed with stopifnot() at end
  • All required variables present
  • TRTSTMF and TRTETMF present in output and captured in new_vars
  • All # REVIEW: comments placed at protocol-specific decision points
  • date_imputation and time_imputation arguments explicitly set
  • flag_imputation = "auto" used — not "date" or "none"
  • EOSSTT contains only "COMPLETED" or "DISCONTINUED"
  • DCSREAS is NA for all completers
  • Population flag derivations annotated with protocol reference
  • Dataset and variable labels applied

© RConsortium, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 6 other files (references) in admiral/admiral-adsl of RConsortium/pharma-skills.

  • SKILL.md
  • DESIGN.md
  • LICENSE
  • README.md
  • benchmarks/README.md
  • references/admiral-functions.md
  • references/adsl-conventions.md

Open the folder on GitHubat commit ae5d83b

Compare with similar skills

Admiral Adsl next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Admiral Adsl compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Admiral Adsl this skillRConsortium/pharma-skills120—~4.4kAutomated safety check: PassMIT
DatasetsArize-ai/phoenix12k—~1.6kAutomated safety check: PassCustom licence
Longbridge Derivativessickn33/agentic-awesome-skills47k1 repos~1.1kAutomated safety check: PassMIT
Dataset Curationwshobson/agents40k—~2kAutomated safety check: PassMIT
Arize Datasetgithub/awesome-copilot40k1 repos~3.9kAutomated safety check: NotesMIT
Crypto Derivatives StrategiesHKUDS/Vibe-Trading35k—~2.4kAutomated safety check: PassMIT

Similar skills

  • Datasets

    Arize-ai/phoenix

    Understand what a Phoenix dataset is and reason well about its examples, outputs, splits, and how it feeds evaluators and experiments.

    12k GitHub stars~1.6k tokensUpdated yesterday
    AI & LLM EngineeringAuto-check passed
  • Longbridge Derivatives

    sickn33/agentic-awesome-skills

    Curated upstream guidance for Longbridge Derivatives; use when the workflow matches the user goal.

    47k GitHub starsUsed in 1 repo~1.1k tokens
    Business, Finance & HRAuto-check passed
  • Dataset Curation

    wshobson/agents

    Prepare, format, and validate datasets for supervised fine-tuning and preference training.

    40k GitHub stars~2k tokensUpdated 6 days ago
    AI & LLM EngineeringAuto-check passed
  • Arize Dataset

    github/awesome-copilot

    Official

    Creates, manages, and queries Arize datasets and examples. An agent skill from github/awesome-copilot.

    40k GitHub starsUsed in 1 repo~3.9k tokens
    Testing & QAAuto-check: notes
  • Covers three crypto-derivatives approaches: perpetual funding-rate arbitrage, futures term-structure trading in contango and backwardation, and options volatility and Greeks analysis.

    35k GitHub stars~2.4k tokensUpdated today
    Business, Finance & HRAuto-check passed
  • Create Test Datasets

    ClickHouse/ClickHouse

    Create test datasets (hits, visits, tpcds, tpch) from standard scripts.

    50k GitHub stars~1k tokensUpdated today
    DatabasesAuto-check passed

More from RConsortium/pharma-skills

All 13 skills in this repo
  • Rounding

    RConsortium/pharma-skills

    Audit R code that prepares CSR/TLF statistics for SAS-compatible rounding compliance (ties away from zero, round-once-at-display, fixed trailing-zero precision).

    120 GitHub stars~3.8k tokensUpdated 7 days ago
    Auto-check passed
  • Issue To Eval

    RConsortium/pharma-skills

    Converts one or more GitHub Issues into standardized benchmark data using automated scripts.

    120 GitHub stars~463 tokensUpdated 7 days ago
    Auto-check passed
  • Weekly Summary

    RConsortium/pharma-skills

    Generate a concise weekly progress summary for the pharmaskills repository.

    120 GitHub stars~546 tokensUpdated 7 days ago
    Auto-check passed
  • Admiral Adae

    RConsortium/pharma-skills

    Derives an ADaM Adverse Events Analysis Dataset (ADAE) using the {admiral} R package and pharmaverse ecosystem.

    120 GitHub stars~3.9k tokensUpdated 7 days ago
    Auto-check passed
  • Admiral Bds

    RConsortium/pharma-skills

    Derives ADaM Basic Data Structure (BDS) datasets using the {admiral} R package.

    120 GitHub stars~3.6k tokensUpdated 7 days ago
    Auto-check passed
  • Sdtm Oak

    RConsortium/pharma-skills

    Derives CDISC SDTM domains from raw clinical (EDC/eCRF) data using the {sdtm.oak} R package.

    120 GitHub stars~3.9k tokensUpdated 7 days ago
    Auto-check passed

Questions about Admiral Adsl

What does Admiral Adsl do?

Derives an ADaM Subject-Level Analysis Dataset (ADSL) using the {admiral} R package and pharmaverse ecosystem. Admiral Adsl is an agent skill from RConsortium/pharma-skills. Derives an ADaM Subject-Level Analysis Dataset (ADSL) using the {admiral} R package and pharmaverse ecosystem.

When should I use Admiral Adsl?

Admiral Adsl fits situations like: A user needs to create ADSL from SDTM domains; derive standard subject-level variables (treatment dates; population flags); generate QC-ready R code following CDISC ADaM conventions.

How do I install Admiral Adsl in Claude Code?

Run `npx skills add RConsortium/pharma-skills --skill admiral-adsl -a claude-code`. Or copy the skill folder (admiral/admiral-adsl in RConsortium/pharma-skills) into .claude/skills/admiral-adsl in your project. Claude Code loads it when a task matches its description.

How do I install Admiral Adsl in Codex?

Run `npx skills add RConsortium/pharma-skills --skill admiral-adsl -a codex`. Or copy the skill folder (admiral/admiral-adsl in RConsortium/pharma-skills) into .agents/skills/admiral-adsl in your project. Codex loads it when a task matches its description.

Can I use Admiral Adsl in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add RConsortium/pharma-skills --skill admiral-adsl -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/admiral-adsl, .gemini/skills/admiral-adsl, .github/skills/admiral-adsl and .opencode/skills/admiral-adsl in your project.

What does Admiral Adsl need to run?

SKILL.md names no scripts, command-line tools or credentials: Admiral Adsl is instructions for the agent only. Compatibility (from SKILL.md): Requires R with admiral, dplyr, lubridate, and pharmaversesdtm installed. Designed for use in a GxP-compliant environment with access to SDTM datasets and an ADaM ADSL specification. .

Does Admiral Adsl access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Admiral Adsl safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Admiral Adsl use?

Admiral Adsl is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Admiral Adsl use?

About 4.4k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 6.5k tokens, read only when the agent opens those files.

What are the alternatives to Admiral Adsl?

Skills that share tags, products or a category with Admiral Adsl: Datasets (Arize-ai/phoenix, 12k stars), Longbridge Derivatives (sickn33/agentic-awesome-skills, 47k stars), Dataset Curation (wshobson/agents, 40k stars) and Arize Dataset (github/awesome-copilot, 40k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Admiral Adsl?

RConsortium (a GitHub organization) maintains it in RConsortium/pharma-skills, which has 120 GitHub stars. The repository holds 13 skills in this directory. The repository was last updated on October 4, 2026.

Source: RConsortium/pharma-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.