メニュー
Build Koha frontend assets (CSS, JS, OpenAPI spec) inside the KTD container. Use after editing SCSS, Vue components, or api/v1/swagger/*.yaml. After swagger changes you must also run restart_all to reload services — yarn build alone is not enough.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
File a Koha bug on bugs.koha-community.org and attach commits non-interactively via git bz. Use when the user wants to submit a patch, file a bug, or open a bz/Bugzilla ticket for Koha. Arguments (optional, free-form): summary or component hints. Without args, derive details from the current branch and HEAD commits.
Run Koha Cypress end-to-end tests. Cypress runs from the HOST (not the KTD container) — KTD exposes the staff/OPAC interfaces on localhost and Cypress drives a real browser. Pass a spec path or directory under t/cypress/integration/.
Run Koha Perl tests inside the KTD container. Pass a test file or directory path (relative to the Koha repo root, or absolute). Handles both t/ and t/db_dependent/ automatically.
Run the Koha QA script (koha-qa.pl) inside KTD before submitting patches. Surfaces critic, POD, file_permissions, tinyint_has_boolean_flag, and other QA failures the community reviewers will check. Run after every commit; fix flagged issues before pushing.
Apply a Koha DB schema change end-to-end after editing kohastructure.sql and the atomicupdate file. Runs updatedatabase.pl in KTD, regenerates DBIC schema with dbic --force, and reminds about the manual is_boolean / relationship edits below the marker line. Use this after the atomicupdate skill has scaffolded the file and the SQL is filled in.
QA review a Koha patchset for regressions, security, code quality, and Koha-specific conventions. Use when the user says "QA this", "review this patchset/branch/PR", "review my work", or "review N commits". Auto-detects patchset scope, runs specialist review agents in parallel based on file types touched, and synthesises findings into Critical/Important/Suggestion buckets with file:line citations.
| name | koha-build |
| description | Build Koha frontend assets (CSS, JS, OpenAPI spec) inside the KTD container. Use after editing SCSS, Vue components, or api/v1/swagger/*.yaml. After swagger changes you must also run restart_all to reload services — yarn build alone is not enough. |
Build Koha assets inside KTD.
Arguments: $ARGUMENTS (optional — css, js, prod, or omit for full build)
| Changed | Command |
|---|---|
*.scss only | yarn css:build (faster) |
*.vue / *.js only | yarn js:build (faster) |
api/v1/swagger/*.yaml (OpenAPI) | yarn build then restart_all (mandatory — see below) |
| Mixed or unsure | yarn build |
| Production / packaging | yarn build:prod |
If the user didn't specify and edited several file types, default to
yarn build.
ktd --name "${KTD_INSTANCE:-kohadev}" --shell --run 'yarn build'
Substitute yarn css:build, yarn js:build, or yarn build:prod as needed.
Edits to api/v1/swagger/*.yaml are not picked up by yarn build alone —
the running Mojolicious workers cache the compiled spec. Restart services
after the build:
ktd --name "${KTD_INSTANCE:-kohadev}" --shell --run 'yarn build && restart_all'
Without restart_all the API will still serve the old spec and your tests
will fail with confusing schema-mismatch errors. This is the single most
common "build looks fine but tests fail" trap.
For tight feedback loops while editing SCSS or JS, run in the background:
ktd --name "${KTD_INSTANCE:-kohadev}" --shell --run 'yarn css:watch' # or yarn js:watch
The user should run watch mode in a separate terminal — don't background it from a skill invocation.
Report: which target ran, build duration if surfaced, and whether
restart_all was triggered. If the build failed, surface the first error
(usually a missing import, syntax error, or YAML parse error in swagger).