shiroikumanojisho

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.