# Development

Ground rules for working in the Tika codebase, git policy, Maven wrapper/repo...

- Repository: https://github.com/apache/tika (4119 stars)
- Category: Testing
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add apache/tika --skill development -g -a claude-code -y`
Codex: `npx skills add apache/tika --skill development -g -a codex -y`
Cursor: `npx skills add apache/tika --skill development -g -a cursor -y`
Gemini CLI: `npx skills add apache/tika --skill development -g -a gemini-cli -y`

## 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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->

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.

The rest: https://github.com/apache/tika/blob/HEAD/.skills/devs/development/SKILL.md