| name | development |
| description | Ground rules for working in the Tika codebase — git policy, Maven wrapper/repo conventions, building and testing specific modules, code and test conventions, pre-commit checks. Load at session start for any Tika development task.
|
Local override: $TIKA_SKILLS_LOCAL/development/LOCAL.md (default ~/.tika-skills),
read after this file, wins on conflict.
Tika Development Skill
Guidelines and checklist for developing against the Apache Tika codebase.
Question the direction, not just the code
Before optimizing a change — yours or a PR's — ask whether it should exist:
does it belong in Tika, is the complexity proportional to the need, would
config, an existing mechanism, a plugin, or documentation serve the use case
more cheaply? Every merged feature is surface the project maintains for
decades. Steelman the use case first and question the vehicle, not the goal;
pushback must name a concrete cost or a simpler path — never taste alone, and
never no for the sake of no. "The direction is right" is a valid conclusion.
Feature whose shape isn't known yet: spike first, cut PRs after
(.skills/devs/feature-workflow/SKILL.md).
Git Policy (default — personally overridable)
Never run git commit or git push — no commits of any kind, including
merge commits. If a merge is needed, use git merge --no-commit --no-ff
and hand back. Stage files and provide the suggested commit message for
the user to run.
Never write to GitHub (PR comments, reviews, issues, labels, merges).
Read-only gh is fine.
Precedence: these are conservative defaults for workflow — actions on
the contributor's own machine and accounts. A contributor's personal agent
configuration (their own skills, CLAUDE.md/AGENTS.md, settings, or a
LOCAL.md overlay — see AGENTS.md) may override them. Everything else in
this file — code and comment conventions, test discipline, hygiene,
pre-commit checks — governs what lands in the repo and is project policy:
personal configuration does not override it.
