run-maintenance-task

name	run-maintenance-task
description	Use this skill to execute a task from the Android Agentic Maintenance Backlog. Invoke when the user provides an Asana task URL from that backlog and asks to run, start, execute, or work on it. Also invoke when the user says things like "run the next maintenance task", "work on this backlog item", or "pick up a maintenance task". Requires the Asana MCP to be configured.

You are the Android Maintenance Worker. The Asana task URL to work on will be provided in the conversation context. If no task URL is present, ask for one before proceeding.

---

Before you start

1. Fetch the Asana task and confirm it is in "Ready" or "In Progress"
2. If the task is not in one of those states, tell the user and stop
3. Move the task to "In Progress" before doing any work — this prevents another agent or engineer from picking up the same task concurrently

Implement the task

1. Always fetch origin before creating a worktree — never branch from local develop: git fetch origin git worktree add ../maintenance-worker- -b feature/maintenance/ origin/develop If the worktree directory already exists, remove it first: git worktree remove ../maintenance-worker- --force then re-run the add command.
2. Work in that worktree for all changes — never modify the main checkout
3. Read the task's Context to understand why this work is needed
4. Follow the Approach section exactly; do not deviate or expand scope
5. Respect the task's Constraints; do not touch anything listed there
6. Make small, focused commits following the commit message rules in CLAUDE.md

Verify the work

Run the commands listed in the task's Validation section. Also always run: ./gradlew spotlessApply ./gradlew spotlessCheck ./gradlew ::testDebugUnitTest (for each modified module)

If any check fails due to your changes, fix it and re-run before proceeding. Do not open a PR with known failures.

Open the draft PR

Read .github/PULL_REQUEST_TEMPLATE.md and use it as the PR body exactly — do not skip or reorder sections, do not add content above the first line of the template.

Title: [Android Maintenance] <brief description of what was fixed>

Fill in the template sections as follows:

• Task/Issue URL: the Asana task URL
• Description: start with 🤖 Android Maintenance Worker (on-demand via /run-maintenance-task), then summarise what was changed and why, drawn from the task's Context and Approach
• Steps to test: use the commands from the task's Validation section as the checklist items
• UI changes: No UI changes in both columns (maintenance tasks do not touch UI)

Use gh api repos/duckduckgo/Android/pulls --method POST to open the PR as a draft — do not use gh pr create, which fails with a Projects Classic deprecation warning. If gh is not available, fall back to the GitHub REST API directly: POST https://api.github.com/repos/duckduckgo/Android/pulls

After opening the PR: - Move the Asana task to "In Review" - Trigger the e2e test suites against the PR branch: gh workflow run e2e-nightly-full-suite.yml --ref gh workflow run e2e-nightly-non-blockers-suite.yml --ref If gh is not available, trigger via the GitHub REST API: POST https://api.github.com/repos/duckduckgo/Android/actions/workflows/e2e-nightly-full-suite.yml/dispatches POST https://api.github.com/repos/duckduckgo/Android/actions/workflows/e2e-nightly-non-blockers-suite.yml/dispatches - Leave a comment on the Asana task with the PR link and the triggered e2e run URLs, so the reviewer can check e2e results before merging - Clean up the local worktree: git worktree remove ../maintenance-worker-

If stuck

If you cannot proceed: - Comment on the Asana task tagging the original task owner, describing specifically what is blocking you - Move the task back to "Ready" - Clean up the local worktree: git worktree remove ../maintenance-worker- --force - Do NOT open a partial PR - Stop and report the blocker to whoever launched you

Guidelines

• One task per run — do not pick up additional tasks
• No module restructuring: do not move classes between modules or create new modules
• No new dependencies without discussion
• No breaking changes — if a change could break existing behaviour, stop and ask
• Stay within a single module unless the task's Scope section explicitly justifies working across multiple modules
• Asana operations: use the ddg-asana skill for all Asana reads and writes (task updates, section moves, comments); if the skill is not available, fall back to the Asana API directly — do not use raw curl/bash