keiyoushi/extensions-source: Kotlin source for the Keiyoushi extension repository

What keiyoushi/extensions-source actually is, and who it is for

The repository is the source code of the extensions published in the separate keiyoushi/extensions repository. The README describes it as source code of extensions in that repository, and the topics list ties it to android, kotlin, mihon and tachiyomi. So the audience is narrow: developers who write Kotlin extension modules for a Mihon or Tachiyomi style reader, and anyone who wants to read how a particular source is put together before trusting it.

It is not a consumer download. The README's usage section does not tell you to clone this repository. It points new users at the Keiyoushi Getting Started guide, then offers two ways to add the extension repository: through the Keiyoushi website, or by pasting a URL that ends in index.pb. That index is the artifact the reader app consumes. The source tree here is what produces it.

The README also carries a disclaimer worth reading before anything else: the project has no affiliation with the content providers, and it is not affiliated with Mihon or Tachiyomi. It asks that you not bring extension problems to those projects' official support channels. That single paragraph defines the support boundary better than most project READMEs do.

The Gradle layout: common, core, lib, lib-multisrc, compiler, src

The top-level entries tell you how the code is organised. build.gradle.kts and settings.gradle.kts are the Gradle entry points, with gradlew and gradlew.bat as the wrappers and gradle.properties for build settings. The interesting part is the module split: common/, core/, lib/, lib-multisrc/, compiler/ and src/.

The presence of a multisrc module is the design decision worth noting. Many extensions in an index like this share the same site template, differing only in domain, language and a few selectors. lib-multisrc exists to hold that shared code so individual sources stay thin. The trade-off is real: a change in a multisrc module fans out across every source that depends on it, which is efficient when the template is stable and unpleasant when one site drifts away from it. A source that no longer fits the shared template has to be pulled out into its own module.

common/, core/ and lib/ hold the pieces that are neither a specific source nor a shared template. compiler/ suggests a build-time component rather than runtime code, consistent with the idea that sources are compiled and packaged rather than interpreted. src/ is where the individual extensions live. The repository also carries AGENTS.md and CLAUDE.md at the top level, which indicates the maintainers have written instructions for automated coding assistants working in the tree, alongside CONTRIBUTING.md and .editorconfig for humans.

Adding the Keiyoushi repository to your reader (the end-user path)

If your goal is to read, you never touch this repository. The README says to read the Getting Started guide first, and then gives the fallback: copy and paste this URL into the reader's extension repository field.

https://github.com/keiyoushi/extensions/raw/repo/index.pb

That URL points at index.pb on the repo branch of the extensions repository, not at anything in extensions-source. After adding it, the reader should list the available extensions and let you install them individually. The website path at keiyoushi.github.io/add-repo does the same thing with fewer keystrokes.

There are no install steps for extensions-source itself in the README, because it is not an installed artifact. If you want to build from source, the README does not document a build command; the repository provides gradlew and a CI workflow named build_push.yml under .github/workflows/, and the badge at the top of the README points at that workflow. Reading that workflow file is the reliable way to learn the exact build invocation, since the README leaves it out.

Contributing a source: what the README commits to and what it refuses to promise

The requests section is unusually candid. New sources and bug fixes go through the issue templates linked from the README. But it states plainly that creating an issue does not mean the source will be added or fixed in a timely fashion, because the work is volunteer-based. It goes further: some sources may be impossible to do or prohibitively difficult to maintain.

That last sentence is the honest limitation of the whole project. An extension is a moving target. When a site changes its markup, the extension breaks, and someone has to notice and fix it. The README does not describe any automated detection of broken sources, so the practical failure mode is silent: an extension keeps installing but stops returning results until a user files a bug.

The README does offer a path for people who want a request fulfilled: issues are up-for-grabs for any developer if no assigned user is already on them. That is the contribution model in one line. Check the backlog, check for an assignee, then write the Kotlin. CONTRIBUTING.md is the file to read before you start, and the repository's ktlintCodeStyle.xml plus .editorconfig mean formatting is enforced rather than advisory.

Mihon, Tachiyomi and the alternatives you should weigh against this

The closest alternative is not another extension index. It is the upstream Tachiyomi extension repository that this project descends from. The README credits the original contributors and states no affiliation with Mihon or Tachiyomi, which is the whole point of the split: after Tachiyomi was discontinued, the extension work continued under the Keiyoushi name, and this repository is where that continuation lives. Adopting it means accepting that the index is maintained by a separate group with its own Discord, not by the reader app's maintainers.

A second alternative is writing your own extension outside any index. That is viable if you want one source for personal use, but you lose the shared lib-multisrc code, the CI workflow that validates builds, and the packaging that produces the index your reader consumes. For a single source, the overhead of matching the repository's conventions may exceed the value.

A third option is a different reader that ships its own extension mechanism. The README does not compare readers and I will not invent a comparison. What it does say is where not to ask for help: not at Mihon's or Tachiyomi's official support channels. That constraint alone should shape which project you file against.

Licence, maintenance and the cost of keeping a source alive

The repository is Apache-2.0. The README reproduces the full Apache License 2.0 header, with the copyright line Copyright 2015 Javier Tomás, and includes the standard warranty disclaimer: the software is distributed on an as-is basis, without warranties or conditions of any kind. That is a permissive licence, so redistributing or modifying the code carries attribution and notice obligations rather than copyleft ones. I am not a lawyer and this is not legal advice; if you plan to ship a derivative, read the LICENSE file in the repository root rather than the README excerpt.

Maintenance is the part to think hardest about. The last push to the default branch was on 2026-09-22, so the repository is receiving changes. There are no releases listed, which fits a project whose output is a branch-hosted index rather than versioned artifacts. But activity at the repository level does not mean any individual extension is healthy. A source can sit untouched for months while the site it targets has changed twice.

The upgrade cost falls on whoever depends on a given source. If you fork this repository to run your own index, you inherit the entire multisrc surface and every source that depends on it. If you only contribute a fix, your cost is a build through the Gradle wrapper and a review cycle in the issue tracker. Those are very different commitments, and the README does not pretend otherwise.

Editorial conclusion

Adopt this repository if you write Kotlin and want to add or repair a source in the Keiyoushi index, or if you need to read how an existing source is implemented. Do not adopt it if you want an installable reader: the README sends end users to the Keiyoushi website to add the repository URL instead. Before opening a pull request, verify three things: that the source you plan to touch is not already assigned to someone in the issue backlog, that your build passes through the Gradle wrapper at the repository root, and that the extension metadata follows the conventions in the existing directories, because the README states some sources may be impossible to do or prohibitively difficult to maintain and a submission that ignores that will not be merged.

Frequently asked questions

Official sources

1. Issues
2. keiyoushi/extensions-source on GitHub
3. License: Apache-2.0
4. Project website
5. README