Agent skill

Packaging For Flathub

by TriliumNext in TriliumNext/Trilium

A skill your agent uses when working on Trilium's Flathub packaging — the from-source flatpak recipe vendored in apps/desktop/flatpak/ (manifest, trilium.sh, flathub.json, .desktop, metainfo), the…

AGPL-3.0Auto-check passedDevelopment

Install Packaging For Flathub

skills CLI
$ npx skills add TriliumNext/Trilium --skill packaging-for-flathub -a claude-code

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

GitHub CLI
$ gh skill install TriliumNext/Trilium packaging-for-flathub --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/TriliumNext/Trilium.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/packaging-for-flathub .claude/skills/packaging-for-flathub && 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
packaging-for-flathub
GitHub stars
38k
Token cost
~4.4k tokens
SKILL.md length
2,026 words
Files
1
Skills in repo
23
Repo updated
First seen
Licence
AGPL-3.0

At a glance

A skill your agent uses when working on Trilium's Flathub packaging — the from-source flatpak recipe vendored in apps/desktop/flatpak/ (manifest, trilium.sh, flathub.json, .desktop, metainfo), the…

  • Works in 4 steps: The packaging repo's README, which still… → The data migration for existing users,… → EOL-rebase the old app: PR flathub.json… → …
  • Working on Triliums Flathub packaging — the from-source flatpak recipe vendored in apps/desktop/flatpak/ (manifest
  • SKILL.md covers The two working locations, Settled decisions and why (do…, The offline-build machinery… and Toolchain rule:…, plus 3 more sections
  • Calls pnpm and node; reaches github.com

What it does

Packaging For Flathub is an agent skill from TriliumNext/Trilium. Use when working on Trilium's Flathub packaging — the from-source flatpak recipe vendored in apps/desktop/flatpak/ (manifest, trilium.sh, flathub.json, .desktop, metainfo), the scripts/flatpak/ generators (update-repo.mts, generate-sources.mts), .github/workflows/release-flathub.yml, or the published packaging repo at ../org.triliumnotes.Trilium. Covers the settled architecture decisions (no electron-forge, no asar, sandboxed data dir, per-arch pnpm sources, build-time scripts shared with the forge build), the…

Its SKILL.md is about 4.4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Pull requests. It works with GitHub Actions and pnpm. The repository describes itself as: Build your personal knowledge base with Trilium Notes. The licence is AGPL-3.0.

When your agent uses it

  • Working on Triliums Flathub packaging — the from-source flatpak recipe vendored in apps/desktop/flatpak/ (manifest
  • The scripts/flatpak/ generators (update-repo.mts
  • Generate-sources.mts)
  • .github/workflows/release-flathub.yml

Example prompts

  • “/packaging-for-flathub”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. The packaging repo's README, which still describes staged scripts and the old
  2. The data migration for existing users, which the EOL-rebase does not perform and
  3. EOL-rebase the old app: PR flathub.json with
  4. Parked polish: carousel-spec screenshots (window ≤1000×700 or 2× at ≤2000×1400, shadow

What it can do on your machine

Read from SKILL.md and the folder at commit 80be026. 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

    Shell commands in SKILL.md call:

    • pnpm
    • node

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

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • github.com

    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.

Context cost

Packaging For Flathub loads about 4.4k tokens when it runs. Until then it costs about 243 tokens; SKILL.md has 2,026 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~243
When it runs · the whole SKILL.md, loaded when a task matches
~4.4k

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 TriliumNext/Trilium at commit 80be026, republished under its AGPL-3.0 licence (© TriliumNext). 2,026 words, ~4,424 tokens.

Download SKILL.mdSave it as .claude/skills/packaging-for-flathub/SKILL.md (or your agent's skills folder).
name
packaging-for-flathub
description
Use when working on Trilium's Flathub packaging — the from-source flatpak recipe vendored in apps/desktop/flatpak/ (manifest, trilium.sh, flathub.json, .desktop, metainfo), the scripts/flatpak/ generators (update-repo.mts, generate-sources.mts), .github/workflows/release-flathub.yml, or the published packaging repo at ../org.triliumnotes.Trilium. Covers the settled architecture decisions (no electron-forge, no asar, sandboxed data dir, per-arch pnpm sources, build-time scripts shared with the forge build), the offline-build machinery (flatpak-node-generator, requiresBuild:false, the Electron ≥43 unzip, the armv7l crash), the org.flatpak.Builder-only toolchain rule, how Flathub test-builds pull requests (drafts included, one misleading status), and what remains (the data migration, EOL-rebase of the old app ID). Do NOT use for the electron-forge .flatpak release asset (see forge.config.ts) or for cutting releases (see cutting-a-release).

Packaging Trilium for Flathub

A from-source flatpak of Trilium Desktop, built offline inside the flatpak-builder sandbox with no Electron Forge involvement. The app is published: the submission (flathub/flathub#10014) merged and flathub/org.triliumnotes.Trilium exists. The recipe now lives in this repo and the packaging repo is generated from it.

The generated recipe builds on Flathub's own infrastructure. FLATHUB_PAT is in place and the workflow's first unattended run opened org.triliumnotes.Trilium#1: validate-manifest passed, build-x86_64 took 8m07s and build-aarch64 10m40s, both green. That run also carried the first prune, removing the three leftover .mts scripts. Flathub ships the latest release and CI keeps it current, so it is the Flatpak that apps/website/src/download-helper.ts recommends on the Linux download card; the Forge .flatpak asset is no longer linked from the website.

Flathub bans AI-generated submissions (policy May 2026). Everything addressed to Flathub — pull request descriptions, review replies, linter-exception requests — is Elian's to author personally. Draft packaging code and manifests freely; do not write the words that go to Flathub reviewers.

The two working locations

  • This repo owns the recipe. apps/desktop/flatpak/ holds the manifest (org.triliumnotes.Trilium.yml), trilium.sh, flathub.json, the .desktop file and the metainfo. scripts/flatpak/ holds update-repo.mts (writes the manifest with the ref and pnpm pins, copies trilium.sh + flathub.json) and generate-sources.mts (regenerates generated-sources.json). .github/workflows/release-flathub.yml runs both and opens the pull request, on every published non-prerelease and on a dispatched ref. Also here: apps/website/public/.well-known/org.flathub.VerifiedApps.txt (empty, serving 200; the dev-portal token fills it — post-publication flow, keep the file forever).
  • The packaging repo: /home/elian/Projects/TriliumNext/org.triliumnotes.Trilium, a clone of the real Flathub repo (default branch master, Elian has push). It holds only the manifest, trilium.sh, flathub.json, generated-sources.json and a README. Never hand-edit it — update-repo.mts overwrites everything but the sources file, which generate-sources.mts overwrites, and deletes every other tracked file. A file the recipe should keep but not write belongs in KEPT_FILES; master carried flip-fuses.mts, stamp-build-info.mts and trim-locales.mts long after the manifest moved to running the checkout's own copies, which is what that prune clears.

Local flow, from this repo, in this order:

sh
pnpm exec tsx scripts/flatpak/update-repo.mts ../org.triliumnotes.Trilium [ref]
pnpm exec tsx scripts/flatpak/generate-sources.mts ../org.triliumnotes.Trilium

ref defaults to HEAD; a tag pins tag: + commit:, anything else pins a bare commit. The pinned commit must be pushed — Flathub clones TriliumNext/Trilium at that SHA.

Settled decisions and why (do not relitigate without new facts)

  • From source, not repackaged. The AppImage-extract fallback (Zettlr-style) exists if reviewers ever balk at build cost.

  • App ID org.triliumnotes.Trilium, CamelCase last element. The old com.github.zadam.trilium gets an end-of-life-rebase to the new ID — still pending, Elian can merge it himself; <provides>/<replaces> are already in the metainfo. The rebase renames ~/.var/app/<id>, which the old app never used, so it moves no notes — see "What remains" for the migration that does.

  • No asar, no Forge. Payload proven byte-identical to the Forge flatpak; the +11 MB is compression granularity (ostree per file vs. one asar stream). Tamper-sealing comes from content-addressed ostree, so asar integrity fuses buy nothing.

  • The build-time scripts are shared with the forge build, not copies. The manifest runs the checkout's own code:

    • pnpm chore:update-build-info --from-commit — commit date, not wall clock, so a rebuild of the same source stamps the same bytes. The default (no flag) is what the seven CI callers use; do not change it.
    • apps/desktop/electron-forge/flip-fuses.ts — FUSES is the shared baseline; the forge config spreads it and adds OnlyLoadAppFromAsar + EnableEmbeddedAsarIntegrityValidation at the use site, because only Forge packages an asar. RunAsNode is OFF, so ELECTRON_RUN_AS_NODE smoke tests do not work.
    • apps/desktop/electron-forge/trim-locales.ts — one keep-list derived from LOCALES, one walk, one completeness check (a keep-list locale missing from the package fails the build). 55 → 21 .paks on Linux.

    Each has a run-as-script guard (process.argv[1] === import.meta.filename) and takes its target as an argument. Editing them touches both the Flathub build and the .deb/.rpm/Forge artifacts.

  • The desktop file and metainfo install from the pinned checkout, not from packaging-repo copies and not from raw.githubusercontent pins. The review wanted them in this repo; the URL-pin variant is also how the published build missed the StartupWMClass fix for weeks. There is no separate metadata module any more — nothing is left for it to cache-isolate. trilium.sh is the one exception, copied into the packaging repo so a reviewer reads the sandbox behavior without opening the checkout.

    That is also why the metainfo's <releases> — the version Flathub displays — has to be right in the commit that gets tagged. pnpm chore:update-version regenerates it from the newest five vX.Y.Z tags, so it is never hand-edited and never accumulates drift; the version being prepared is dated today until its own tag supplies the date.

  • Sandboxed data dir, narrow filesystem access. trilium.sh sets TRILIUM_DATA_DIR to $XDG_DATA_HOME/trilium-data (i.e. inside ~/.var/app), falling back to host ~/.local/share/trilium-data when that exists; a flatpak override wins. --filesystem=home is gone — four read-only XDG dirs cover drag-&-drop import (electron#30650), so the linter exception that was pending at submission is moot.

    Do not grant the legacy path back, in any form. The reviewer struck --filesystem=home (#10014), then struck the narrowed --filesystem=~/.local/share/trilium-data:create as well (here) — "you have your sandboxed folder" — when told it would blank out the old app's users: migration is upstream's job, the permission set is Flathub's. Re-adding either gets the next packaging PR rejected. A review bot that reads trilium.sh alone flags this as a data-loss bug (PR #11629); it is a known deferred cost, not a defect.

    $HOME inside the sandbox is the real path (/home/user) whatever is mounted, so the fallback branch turns purely on what the manifest or an override exposes. Verify with flatpak run --nofilesystem=home --command=sh <id> -c '…' against an installed build. Since the guard is [ ! -d "$XDG_DATA_HOME/trilium-data" ], an override added after the first launch no longer reaches the legacy notes — the sandbox dir already exists.

  • pnpm 12 ships as a native binary per platform. The manifest stages @pnpm/exe.linux-x64 / -arm64 tarballs with only-arches, because the pnpm wrapper package's postinstall (which picks one) cannot run offline. append-path points at flatpak-node/pnpm; the archive root holds an executable pnpm, so no chmod/symlink step. Refs older than pnpm 12 are rejected by checkPnpmSupported — pnpm 11 had a single wrapper tarball and the per-arch URL would 404.

    The vendored manifest holds no pins of its own — __TAG__, __COMMIT__, __PNPM_VERSION__, __PNPM_SHA256_X64__ and __PNPM_SHA256_ARM64__ are placeholders update-repo.mts fills in from the packaged ref, fetching the two tarballs for their hashes every run. So there is nothing to keep in step and nothing to gate: a check that compared a vendored pin with package.json was tried and reverted, because on a pull_request run it sees main's package.json against the branch's manifest and one Renovate bump reddens every open pull request, none of which can fix it.

    Consequences: the vendored manifest is a template, not a buildable one (it also references a generated-sources.json that lives only in the packaging repo), and checkPlaceholdersFilled fails the run when a new __NAME__ appears that nothing fills — including one written inside a comment. Verify a change to the templating by rendering into an empty directory and diffing against the packaging repo: node --experimental-strip-types scripts/flatpak/update-repo.mts /tmp/out [ref]. Never cp -r the packaging repo to do it — its .flatpak-builder/ holds a multi-gigabyte build tree.

  • flathub.json carries disable-external-data-checker: true (the checker probes broken URLs without x-checker-data, so it would poll ~2400 generated npm sources) and automerge-flathubbot-prs: false — the linter errors on true (flathub-json-automerge-enabled). It only takes effect on the default branch.

  • No only-arches at app level: x86_64 + aarch64 both build (better-sqlite3 13 ships arm64 prebuilds).

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

The offline-build machinery (how it works, where it bites)

  • flatpak-node-generator pnpm <lockfile> --pnpm-store-version v11 — the flag is mandatory. pnpm 12 still reads the v11 store layout (SQLite index.db); the generator defaults to v10 (per-package JSON index). Verify with pnpm store path before assuming a bump changed it. checkPnpm in generate-sources.mts guards the major (currently 12).
  • The generator crashes on Electron ≥44 unless it is recent: KeyError: electron-v44.4.1-linux-armv7l.zip, because Electron stopped publishing armv7l and only newer generator revisions skip that arch. CI pins a master commit (41c20aa10819cdb2a4f3ca171758a96d1955c018 or later) via pipx. The copy bundled in org.flatpak.Builder is too old — locally, extract it and patch the guard in flatpak_node_generator/electron.py, keeping the copy under $HOME (the sandbox cannot see /tmp) and pointing PYTHONPATH at it through a flatpak-node-generator shim on PATH. Drop that crutch once the Builder flatpak updates.
  • The generated store marks every package requiresBuild: false ⇒ no dependency lifecycle script runs. The workspace's OWN postinstall DOES run. Nothing in the graph needs a native build.
  • Electron ≥43 has no install script — it lazy-downloads on first require, which offline forbids. The manifest unzips flatpak-node/cache/electron/electron-v*-linux-*.zip itself, renames the binary to trilium, deletes chrome-sandbox (zypak replaces the setuid sandbox), and the wrapper runs zypak-wrapper.
  • Playwright's ~511 MB of browser archives are filtered out by filterSources, which also fails loudly if the count collapses or the Electron zip disappears. --no-devel is unsupported for lockfile v9 and would break the build (Vite/esbuild/tsx are devDeps).
  • Generator output is deterministic across runs and machines.

Toolchain rule: org.flatpak.Builder ONLY

Build and lint exclusively through the org.flatpak.Builder flatpak (bundles flatpak-builder, flatpak-builder-lint, appstreamcli, ostree, jq). The host's flatpak-builder cost two wasted investigations: NixOS ships it without appstreamcli, and version skew produced phantom lint errors.

sh
flatpak run org.flatpak.Builder --user --install --force-clean builddir org.triliumnotes.Trilium.yml
flatpak run --command=flatpak-builder-lint org.flatpak.Builder manifest org.triliumnotes.Trilium.yml
# Repo lint as Flathub's test pipeline judges it:
flatpak run org.flatpak.Builder --user --force-clean --default-branch=test --repo=repo builddir org.triliumnotes.Trilium.yml
flatpak run --env=REPO=https://github.com/flathub/org.triliumnotes.Trilium --command=flatpak-builder-lint org.flatpak.Builder repo repo
# Metainfo alone, no build needed (what CI does):
flatpak run --command=appstreamcli org.flatpak.Builder validate --explain apps/desktop/flatpak/org.triliumnotes.Trilium.metainfo.xml

Expected findings — do not re-investigate: runtime-update-available-… (a runtime bump is a deliberate decision) and, on local repo lint, appstream-remote-icon-not-mirrored (the mirroring checks string-match dl.flathub.org/media URLs that appstreamcli never emits locally; only Flathub's own build adjudicates it).

How Flathub builds pull requests (verified 2026-09-21)

  • Draft PRs are test-built — flathub/org.kde.kolourpaint#128 (draft: true) produced a vorarbeiter run. Drafting costs no coverage.
  • Only one status is ever posted: builds/x86_64 — an aggregate, on every app, whether or not aarch64 built. The aarch64 result is a build-aarch64 job inside the run the status links to (alongside validate-manifest). Never read a green check as proof aarch64 built; open the run.
  • The arch matrix is fail-fast, both directions — one arch failing cancels the other. Failures do post (builds/x86_64=failure); bot, build re-triggers and the newer run overwrites the status.
  • What triggers a build: refs/pull/*/head (test, publishes nothing), master (stable publish), beta (beta channel). A push to any other branch builds nothing — so a pull request is the only way to get a build without publishing.
  • Therefore untagged commits go out as draft PRs to master (shared update/beta branch, superseded per run) purely for the two-arch verdict. A real beta branch is for -rc tags with actual testers, and publishing there has no review gate.

Runtime behaviors (verified — trust these)

  • flatpak-builder --run CANNOT test zypak apps (portal Spawn needs a registered instance). Always --install + flatpak run.
  • GNOME matches the window to the desktop file without any desktopName / CHROME_DESKTOP fix — but only in a session started after flatpak enablement. If integration looks broken, check XDG_DATA_DIRS of the running gnome-shell before touching code: a re-login fixes it. Two "fixes" were nearly shipped for this non-bug.
  • The app runs Wayland-native. The system-bus dbus error at startup is benign Chromium probing.
  • Quarantine tests with --env=TRILIUM_DATA_DIR=/tmp/....
  • --talk-name=org.freedesktop.Notifications is NOT needed (libnotify ≥0.8 uses the portal). The tray's org.kde.StatusNotifierWatcher has no portal equivalent and stays. Audit a finish-arg with flatpak run --no-talk-name=… <id> and dbus-monitor.

What remains

  1. The packaging repo's README, which still describes staged scripts and the old pnpm/ASAR reasoning.
  2. The data migration for existing users, which the EOL-rebase does not perform and which no permission can substitute for (see "Sandboxed data dir"). The old Flathub app, the Forge .flatpak and every .deb/AppImage keep notes at host ~/.local/share/trilium-data; the new app starts on an empty $XDG_DATA_HOME/trilium-data and says nothing about why. Until then, the User Guide's Desktop Installation page documents copying the directory into ~/.var/app/org.triliumnotes.Trilium/data by hand. Options not yet weighed: a first-run prompt that asks for the directory through the file portal, a documented flatpak override --filesystem=… in the release notes, or exposing the legacy database read-only for a one-time import. Settle it before the rebase — after it, the old app is gone and the surprise is the user's.
  3. EOL-rebase the old app: PR flathub.json with end-of-life-rebase: org.triliumnotes.Trilium to flathub/com.github.zadam.trilium (needs end-of-life too, or the linter errors). Old app ships 0.63.7/2024 on EOL 23.08 to ~71k installs.
  4. Parked polish: carousel-spec screenshots (window ≤1000×700 or 2× at ≤2000×1400, shadow
    • rounded corners), <branding> colors (leaf-green #cfe8c0 light / #254d18 dark; compare peers via flathub.org/api/v2/appstream/<id> → .branding), metainfo description refresh, and the --no-playwright-browsers flag worth filing upstream. License stays AGPL-3.0-only until the repo reconciles package.json with the README's v3+ grant.

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

Files

Just SKILL.md in .claude/skills/packaging-for-flathub of TriliumNext/Trilium.

Open the folder on GitHubat commit 80be026

Compare with similar skills

Packaging For Flathub 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.

Packaging For Flathub compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Packaging For Flathub this skillTriliumNext/Trilium38k—~4.4kAutomated safety check: PassAGPL-3.0
ZCF Release AutomationUfoMiao/zcf6.1k—~3.4kAutomated safety check: PassMIT
Babysit PR To Pass CIsgl-project/sglang37k2 repos~3kAutomated safety check: PassApache-2.0
Releasemicrosoft/agent-lightning19k—~2.8kAutomated safety check: PassMIT
Pull Requestspnpm/pnpm37k—~2.2kAutomated safety check: PassMIT
Verdaccio Pull Request Workflowverdaccio/verdaccio18k—~1.9kAutomated safety check: PassMIT

Similar skills

  • Automates a version release with changesets: analyzes code changes, writes a bilingual CHANGELOG, bumps the version and commits through a release branch and pull request.

    6.1k GitHub stars~3.4k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed
  • Babysit PR To Pass CI

    sgl-project/sglang

    Start and persistently pursue a goal to babysit an SGLang pull request until selected GitHub Actions workflows pass on the latest PR head.

    37k GitHub starsUsed in 2 repos~3k tokens
    DevelopmentAuto-check passed
  • Release

    microsoft/agent-lightning

    Official

    Prepare and publish stable Agent Lightning releases through the repository's version bump, pull-request checks, merge, tag, PyPI trusted-publishing, and versioned-documentation workflows.

    19k GitHub stars~2.8k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Pull Requests

    pnpm/pnpm

    Take a change through a pull request in the pnpm repository — opening it, then staying with it after every push until CI is green and the review round is quiet.

    37k GitHub stars~2.2k tokensUpdated today
    DevelopmentAuto-check passed
  • Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines.

    18k GitHub stars~1.9k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Verdaccio PR Review

    verdaccio/verdaccio

    Reviews an existing verdaccio/verdaccio pull request end to end, verifies each finding and reports whether it is mergeable, optionally fixing it on the PR branch.

    18k GitHub stars~1.7k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from TriliumNext/Trilium

All 23 skills in this repo
  • Cutting A Release

    TriliumNext/Trilium

    A skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.

    38k GitHub stars~3.2k tokensUpdated today
    Auto-check passed
  • Developing Electron Desktop

    TriliumNext/Trilium

    A skill your agent uses when working on the Trilium Electron desktop app (apps/desktop) — adding or changing an electronApi method / IPC channel, touching preload.ts, main.ts, services/window.ts or…

    38k GitHub stars~5.7k tokensUpdated today
    Auto-check passed
  • Evolving The Data Model

    TriliumNext/Trilium

    A skill your agent uses when adding a DB migration or a new column/field to a Becca entity in Trilium ("add a migration", "new column on notes/attributes", "ALTER TABLE", "add a field to…

    38k GitHub stars~2.1k tokensUpdated today
    Auto-check passed
  • Adding Internal API Route

    TriliumNext/Trilium

    A skill your agent uses when adding, moving, or wiring an internal REST endpoint in Trilium (a new /api/ route) — choosing between a core-shared handler (packages/trilium-core/src/routes/index.ts…

    38k GitHub stars~3.3k tokensUpdated today
    Auto-check passed
  • Adding LLM MCP Tools

    TriliumNext/Trilium

    A skill your agent uses when adding, changing, or reviewing an LLM/MCP tool in Trilium (the defineTools definitions under packages/trilium-core/src/services/llm/tools/ —…

    38k GitHub stars~2.5k tokensUpdated today
    Auto-check passed
  • Ckeditor5 Plugin Development

    TriliumNext/Trilium

    Write, extend, and review CKEditor 5 plugins in the Trilium (TriliumNext Notes) monorepo — the rich-text-note editor under packages/ckeditor5, whose plugins live in src/plugins/.

    38k GitHub stars~4.9k tokensUpdated today
    Auto-check passed

Categories

Questions about Packaging For Flathub

What does Packaging For Flathub do?

A skill your agent uses when working on Trilium's Flathub packaging — the from-source flatpak recipe vendored in apps/desktop/flatpak/ (manifest, trilium.sh, flathub.json, .desktop, metainfo), the…. Packaging For Flathub is an agent skill from TriliumNext/Trilium.Trilium.

When should I use Packaging For Flathub?

Packaging For Flathub fits situations like: working on Triliums Flathub packaging — the from-source flatpak recipe vendored in apps/desktop/flatpak/ (manifest; the scripts/flatpak/ generators (update-repo.mts; generate-sources.mts); .github/workflows/release-flathub.yml.

How do I install Packaging For Flathub in Claude Code?

Run `npx skills add TriliumNext/Trilium --skill packaging-for-flathub -a claude-code`. Or copy the skill folder (.claude/skills/packaging-for-flathub in TriliumNext/Trilium) into .claude/skills/packaging-for-flathub in your project. Claude Code loads it when a task matches its description.

How do I install Packaging For Flathub in Codex?

Run `npx skills add TriliumNext/Trilium --skill packaging-for-flathub -a codex`. Or copy the skill folder (.claude/skills/packaging-for-flathub in TriliumNext/Trilium) into .agents/skills/packaging-for-flathub in your project. Codex loads it when a task matches its description.

Can I use Packaging For Flathub 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 TriliumNext/Trilium --skill packaging-for-flathub -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/packaging-for-flathub, .gemini/skills/packaging-for-flathub, .github/skills/packaging-for-flathub and .opencode/skills/packaging-for-flathub in your project.

What does Packaging For Flathub need to run?

Going by SKILL.md and its folder, Packaging For Flathub needs the command-line tools its instructions call (pnpm and node).

Does Packaging For Flathub access the network?

SKILL.md names 1 domain. In commands or code: github.com; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Packaging For Flathub 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 Packaging For Flathub use?

Packaging For Flathub is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Packaging For Flathub 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.

What are the alternatives to Packaging For Flathub?

Skills that share tags, products or a category with Packaging For Flathub: ZCF Release Automation (UfoMiao/zcf, 6.1k stars), Babysit PR To Pass CI (sgl-project/sglang, 37k stars), Release (microsoft/agent-lightning, 19k stars) and Pull Requests (pnpm/pnpm, 37k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Packaging For Flathub?

TriliumNext (a GitHub organization) maintains it in TriliumNext/Trilium, which has 38,265 GitHub stars. The repository holds 23 skills in this directory. The repository was last updated on October 10, 2026.

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