ShiroiKuma0

Build the signed release APK with the buildFork Gradle task, then deliver it automatically — wireless adb connect, adb install -r, push to /sdcard/tmp (latest only), am start (fall back to /after-build's scp path if the phone is unreachable). Always build first without asking for permission to build. Use whenever 白い熊 asks to build the app, build the APK, make a release build, or build and send to the phone.

HARD RULE for every OpenTasker JSON bundle (or any JSON) produced for 白い熊 — it must arrive already documented as a "literate programming" artifact: useful per-action labels, a per-task note, and full variable docs at the point of definition. Apply whenever generating/editing an importable bundle (tasks/profiles/variables) or any JSON 白い熊 will read. NOT an opt-in formatting pass — bundles are wrong if shipped uncommented.

Publish the latest local build as a GitHub release of this fork — refresh the README (fork-style, major features), write a very specific CHANGELOG entry, tag the bare versionName, ensure the default branch is `custom`, and create the release with the ~/tmp APK attached. Use when 白い熊 says publish / release / cut a version / ship it to GitHub.

Format an OpenTasker task for 白い熊 to build by hand, as a clear tabular spec — each action given by its picker fold-path (Category => Action Name) followed by its fields in the editor's display order. Use whenever handing 白い熊 a task / sub-task to enter in 白い熊 自由作業盤 (e.g. test tasks, examples, repro steps), or when 白い熊 asks for a task "in the spec format".

Rebase this fork onto a new upstream release of SysAdminDoc/OpenTasker. Use when 白い熊 says a new upstream version is out, asks to update/sync to upstream, bump to the new OpenTasker release, or rebase custom onto the latest upstream — then build the new +1.

Build, deploy, and release the shiroikumanojisho Flutter Android app. Use this skill any time you are about to run `flutter build`, `gradle`, `adb push`, `adb install`, bump a version in pubspec.yaml, generate a release commit, tag a release, or upload to GitHub releases. Also use when reasoning about why a build is failing in confusing ways (the JDK pin and Gradle-daemon hygiene rules here cover the most common cause). Trigger words include "build", "release", "deploy", "APK", "tag", "version bump", "publish", "gradle", "JDK", "Zulu", "split-per-abi". The non-obvious rules — Zulu 11 JDK pin, archive-to-~/tmp + /after-build delivery, release filename without datetime, bare-semver tag, pubspec clean for release — are easy to get wrong from defaults and are encoded here precisely so Claude does not have to re-derive them every session.

How and when to update `CHANGELOG.md` for shiroikumanojisho. Use this skill any time you add or modify a user-facing feature, fix a user-visible bug, change behaviour that someone outside the codebase might notice, or are about to cut a release. Trigger words include "changelog", "release notes", "what's new", "release", "what changed", or any feature/fix PR that touches public app behaviour. Skip the skill (and the changelog) for purely internal work — refactors, test changes, build infrastructure, dependency bumps that have no user impact, documentation edits. The skill defines what counts as user-facing, the entry format, and how the changelog connects to the GitHub release notes at publish time.

How to bring changes from the original upstream project (`arianneorpilla/jidoujisho`) into this fork (`ShiroiKuma0/shiroikumanojisho`). Use this skill whenever the user asks "what's new upstream", "did upstream change anything", "sync upstream", "port upstream", "is there a new jidoujisho release", or wants to compare this fork against the parent project. Also use when the user mentions cherry-picking from upstream, looking at upstream tags or commits, or wants to know whether a specific bug they hit has been fixed upstream. Defines: adding the upstream remote, the comparison commands to find what's new since the last sync, the manual-port vs `cherry-pick` decision, the `upstream-sync-X.Y.Z` tracking tag convention, and the changelog-entry annotation that records provenance.

Check whether Felicity Music Player upstream (Hamza417/Felicity) has a newer release tag and, if so, sync the shiroikuma.ongaku fork to it — present 白い熊 a proceed-gated table of what the new upstream version introduces, then (on go-ahead) fast-forward `master`, rebase the `custom` commit stack onto the new tag, and build the new signed APK per the ongaku-build skill. Use this skill whenever 白い熊 runs /upstream-new-version, or asks to "check for a new Felicity version", "sync to the latest Felicity release", "update to the new upstream", "rebase onto the new tag", or otherwise wants the ongaku fork brought up to a newer upstream release. This is the orchestration layer on top of ongaku-build; read that skill for all the build/rebase/version detail this one references.

Publish 白い熊's shiroikuma-ongaku fork (customized Felicity Music Player, app id shiroikuma.ongaku, label "白い熊 音楽") as a GitHub release — tag the newest already-built APK, refresh the fork README + CHANGELOG, switch the GitHub default branch to `custom`, and create the release with the APK attached. Use whenever 白い熊 says /publish-version, "publish a version", "publish to github", "make/cut a release", or "release the latest build" in the ongaku fork. Never rebuilds — it publishes the newest APK already in ~/tmp/; if there is none, tell 白い熊 to build first (ongaku-build).

Cross-compile the gcfs Termux/arm64 binary via build-termux.sh, then auto-deliver it — run `adb devices` UNSANDBOXED and, if a device is present, `adb push` it to /sdcard/tmp without asking. Use whenever 白い熊 asks to build gcfs, build the binary, make a Termux build, or build and send to the phone.

Merge new upstream commits from hardcore-sushi/libgocryptfs into our custom branch. Use when 白い熊 says upstream libgocryptfs has changes, asks to sync/update to upstream, or to rebase custom onto upstream.