---
name: docs-engineering
description: Writing/updating project documentation (README, PRIVACY-POLICY, NOTICES, changelogs) and maintaining F-Droid metadata. Use when the user asks to update docs, write changelogs, or modify F-Droid store listings.
argument-hint: task description
---

# Document Engineering

You are performing documentation tasks for Guileless Bopomofo.

## Bilingual Convention

This project maintains documentation in both **English (en-US)** and **Traditional Chinese (zh-TW)**. When creating or updating user-facing text, always produce both language versions unless instructed otherwise.

- README.md uses interleaved bilingual sections (English heading/paragraph followed by Chinese equivalent).
- F-Droid metadata keeps separate locale directories.

## Project Documentation Files

| File | Purpose |
|------|---------|
| `README.md` | Project overview, usage guide, build instructions (bilingual) |
| `PRIVACY-POLICY.md` | Privacy policy |
| `NOTICES.md` | Third-party license notices |
| `CLAUDE.md` | Guidance for Claude Code |

When updating `NOTICES.md`, check `gradle/libs.versions.toml` and `app/build.gradle.kts` for current dependencies and their licenses.

## F-Droid Metadata

Metadata lives under `fastlane/metadata/android/` with two locales:

```
fastlane/metadata/android/
  en-US/
    title.txt              # App name (max 50 chars)
    short_description.txt  # Store tagline (max 80 chars)
    full_description.txt   # Full store listing (max 4000 chars)
    changelogs/<versionCode>.txt  # Per-version changelog
    images/                # Screenshots and graphics
  zh-TW/
    (same structure)
```

### Changelogs

- Changelog filenames use **versionCode** (integer), not versionName. Find the current versionCode in `app/build.gradle.kts` (`versionCode = ...`).
- Write changelogs in a friendly, first-person tone consistent with existing entries (see `fastlane/metadata/android/en-US/changelogs/` for examples).
- Always create both `en-US` and `zh-TW` versions.
- Max 500 characters per changelog file.

### Store Descriptions

- `full_description.txt` is written in first person from the app's perspective ("Hello, it's me, Guileless Bopomofo Keyboard.").
- Use `*` for bullet points in en-US, `＊` (fullwidth asterisk) in zh-TW.

## Writing Style

- Keep language clear and approachable.
- For zh-TW text, use Traditional Chinese characters only. Do not use Simplified Chinese.
- Preserve the existing tone: the app "speaks" in first person in store listings and changelogs; README and other docs use standard third-person technical writing.
- When referencing keyboard layouts, use their established names: Dachen (大千), Hsu (許氏), E-Ten (倚天), Dachen CP26 (大千26鍵).
- **Respect external resource providers' efforts.** When describing problems in upstream projects, dependencies, or third-party services (e.g., libchewing, libraries, platforms), use softened wording. Prefer "issue", "behavior", or "limitation" over "bug"; prefer "resolved" or "addressed" over "fixed the bug". Frame workarounds as collaborative rather than corrective. This applies to both en-US and zh-TW text (e.g., use 「問題」 rather than 「錯誤」 or 「bug」 when referring to upstream).

## Task: $ARGUMENTS