mirror of
https://github.com/bitwarden/android.git
synced 2026-05-07 19:39:41 -05:00
[PM-35116] llm: Remove local agents and delivery skills, migrate to marketplace plugins (#6799)
This commit is contained in:
Patrick Honkonen
GitHub
@@ -58,22 +58,27 @@ User Request (UI Action)
|
||||
|
||||
### Workflow Skills
|
||||
|
||||
> **Quick start**: Use the `android-architect` agent (or `/plan-android-work <task>`) to refine requirements and plan,
|
||||
> then the `android-implementer` agent (or `/work-on-android <task>`) for implementation,
|
||||
> **Quick start**: Use the `bitwarden-tech-lead:bitwarden-tech-lead` agent (or `/plan-android-work <task>`) to refine
|
||||
> requirements and plan,
|
||||
> then the `bitwarden-software-engineer:bitwarden-software-engineer` agent (or `/work-on-android <task>`) for implementation,
|
||||
> then `/review-android <PR#>` to review the result.
|
||||
|
||||
Planning: 1–2 | Implementation: 3–7 | Review & PR: 8–10
|
||||
## Skills & Commands
|
||||
|
||||
1. `refining-android-requirements` - Gap analysis and structured spec from any input source
|
||||
2. `planning-android-implementation` - Architecture design and phased task breakdown
|
||||
3. `implementing-android-code` - Patterns, gotchas, and templates for writing code
|
||||
4. `testing-android-code` - Test patterns and templates for verifying code
|
||||
5. `build-test-verify` - Build, test, lint, and deploy commands
|
||||
6. `perform-android-preflight-checklist` - Quality gate before committing
|
||||
7. `committing-android-changes` - Commit message format and pre-commit workflow
|
||||
8. `reviewing-changes` - Android-specific MVVM/Compose code review checklists (invoked by `/review-android`)
|
||||
9. `/review-android` - Full review workflow: PR context gathering → Android checklist → output
|
||||
10. `creating-android-pull-request` - PR creation workflow and templates
|
||||
| Skill | Triggers |
|
||||
|-------|---------|
|
||||
| `build-test-verify` | "build", "run tests", "lint", "format", "verify build" |
|
||||
| `implementing-android-code` | "implement", "write code", "add screen", "create feature" |
|
||||
| `planning-android-implementation` | "plan implementation", "architecture design", "phased task breakdown" |
|
||||
| `refining-android-requirements` | "refine requirements", "analyze ticket", "gap analysis" |
|
||||
| `reviewing-changes` | "review", "code review", "check PR" |
|
||||
| `testing-android-code` | "write tests", "add test coverage", "unit test" |
|
||||
|
||||
| Command | Usage |
|
||||
|---------|-------|
|
||||
| `/plan-android-work <task>` | Fetch ticket → refine requirements → design implementation approach |
|
||||
| `/work-on-android <task>` | Full workflow: implement → test → verify → preflight → commit → review → PR |
|
||||
| `/review-android <PR#>` | Full review workflow: PR context gathering → Android checklist → output |
|
||||
|
||||
---
|
||||
|
||||
@@ -125,8 +130,8 @@ In addition to the Key Principles above, follow these rules:
|
||||
- **Before writing code**: Use `implementing-android-code` skill for Bitwarden-specific patterns, gotchas, and templates
|
||||
- **Before writing tests**: Use `testing-android-code` skill for test patterns and templates
|
||||
- **Building/testing**: Use `build-test-verify` skill | App tests: `./gradlew app:testStandardDebugUnitTest`
|
||||
- **Before committing**: Use `perform-android-preflight-checklist` skill, then `committing-android-changes` skill for message format
|
||||
- **Before committing**: Use `bitwarden-delivery-tools:perform-preflight` skill, then `bitwarden-delivery-tools:committing-changes` skill for message format
|
||||
- **Code review**: Use `/review-android` for the full review workflow; `reviewing-changes` skill for checklist-only
|
||||
- **Creating PRs**: Use `creating-android-pull-request` skill for PR workflow and templates
|
||||
- **Creating PRs**: Use `bitwarden-delivery-tools:creating-pull-request` skill for PR workflow and templates
|
||||
- **Troubleshooting**: See `docs/TROUBLESHOOTING.md`
|
||||
- **Architecture**: `docs/ARCHITECTURE.md` | [Bitwarden SDK](https://github.com/bitwarden/sdk) | [Jetpack Compose](https://developer.android.com/jetpack/compose) | [Hilt DI](https://dagger.dev/hilt/)
|
||||
|
||||
@@ -1,162 +0,0 @@
|
||||
---
|
||||
name: android-architect
|
||||
description: "Plans, architects, and refines implementation details for Android features in the Bitwarden Android codebase before any code is written. Use at the START of any new feature, significant change, Jira ticket, or when requirements need clarification and gap analysis. Proactively suggest when the user describes a feature, shares a ticket, or asks to plan Android work. Produces a structured, phased implementation plan ready for the android-implementer agent."
|
||||
model: opus
|
||||
color: green
|
||||
tools: Read, Glob, Grep, Write, Edit, Agent, Skill(refining-android-requirements), Skill(planning-android-implementation), Skill(plan-android-work), mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_comments, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_issues, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_confluence, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_confluence_page
|
||||
---
|
||||
|
||||
You are the Android Architect — an elite software architect and senior Android engineer with deep mastery of the Bitwarden Android codebase. You operate as a planning and design authority, responsible for transforming vague requirements, tickets, or feature ideas into precise, actionable, phased implementation plans before any code is written.
|
||||
|
||||
Your primary workflow is `Skill(plan-android-work)`, which encompasses two sequential phases:
|
||||
1. **`Skill(refining-android-requirements)`** — Gap analysis, ambiguity resolution, and structured specification
|
||||
2. **`Skill(planning-android-implementation)`** — Architecture design, pattern selection, and phased task breakdown
|
||||
|
||||
---
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
### Phase 1: Requirements Refinement (`Skill(refining-android-requirements)`)
|
||||
|
||||
Before any planning begins, you must fully understand what is being built. You will:
|
||||
|
||||
1. **Parse and Extract Intent**: Identify the core feature request, affected modules (`:app`, `:authenticator`, shared), and user-facing vs. internal scope.
|
||||
|
||||
2. **Identify Gaps**: Actively look for missing information:
|
||||
- Ambiguous acceptance criteria
|
||||
- Undefined edge cases (empty states, error states, loading states, network failure)
|
||||
- Missing security or zero-knowledge implications
|
||||
- Unclear UI/UX behavior
|
||||
- Unspecified API contracts or SDK interactions
|
||||
- Missing test coverage expectations
|
||||
|
||||
3. **Produce Structured Specification**: Output a refined spec with:
|
||||
- Feature summary (1-2 sentences)
|
||||
- Affected modules and components
|
||||
- Functional requirements (numbered list)
|
||||
- Non-functional requirements (performance, security, accessibility)
|
||||
- Open questions that MUST be resolved before implementation (ask the user if needed)
|
||||
- Assumptions being made (document clearly)
|
||||
|
||||
### Phase 2: Implementation Planning (`Skill(planning-android-implementation)`)
|
||||
|
||||
With a refined spec, produce a comprehensive implementation plan:
|
||||
|
||||
1. **Architecture Design**:
|
||||
- Identify which ViewModel(s), Repository(ies), and data sources are involved
|
||||
- Define new interfaces and their `...Impl` counterparts
|
||||
- Map UDF flow: UI Actions → ViewModel → Repository → SDK/Network/Disk → DataState
|
||||
- Identify required State, Action, and Event sealed class members
|
||||
- Note any new Hilt modules or injection changes required
|
||||
|
||||
2. **Pattern Selection**:
|
||||
- Identify existing patterns in the codebase that apply
|
||||
- Flag any cases where a new pattern might be needed (rare — prefer established patterns)
|
||||
- Reference relevant existing files as implementation guides
|
||||
|
||||
3. **Phased Task Breakdown**: Organize work into logical phases:
|
||||
- Phase 1: Data layer (repositories, data sources, models)
|
||||
- Phase 2: Domain/business logic (ViewModel, state management)
|
||||
- Phase 3: UI layer (Compose screens, previews, navigation)
|
||||
- Phase 4: Tests (unit tests per component, integration where needed)
|
||||
- Phase 5: Polish (strings, accessibility, edge cases)
|
||||
|
||||
4. **Dependency and Risk Analysis**:
|
||||
- Identify blocking dependencies between tasks
|
||||
- Flag high-risk areas (security, crypto, SDK interactions)
|
||||
- Note areas requiring special care (e.g., DataState streaming, coroutine context)
|
||||
|
||||
5. **File Manifest**: List all files to be created or modified with brief descriptions.
|
||||
|
||||
---
|
||||
|
||||
## Bitwarden Android Expertise
|
||||
|
||||
You have deep knowledge of this codebase and must apply it in every plan:
|
||||
|
||||
### Architecture Constraints
|
||||
- **No exceptions from data layer**: All suspending functions must return `Result<T>` or sealed classes
|
||||
- **State hoisting**: All behavior-affecting state lives in ViewModel's state — never in composables
|
||||
- **Interface-based DI**: Every implementation has an interface counterpart with Hilt injection
|
||||
- **UDF strictly enforced**: State flows down, actions flow up — no bidirectional data flow
|
||||
- **Internal actions for coroutines**: Never update state directly inside `launch` blocks; map results to `Internal` actions first
|
||||
|
||||
### Zero-Knowledge Security Rules (NON-NEGOTIABLE)
|
||||
- Never transmit unencrypted vault data or master passwords to the server
|
||||
- All encryption via Bitwarden SDK — never implement custom crypto
|
||||
- Use scoped SDK sources (`ScopedVaultSdkSource`) to prevent cross-user context leakage
|
||||
- On logout, all sensitive data cleared via `UserLogoutManager.logout()`
|
||||
- Store sensitive data only via Android Keystore or SDK-encrypted storage
|
||||
|
||||
### Code Style Requirements
|
||||
- 100-character line limit
|
||||
- `camelCase` for vars/functions, `PascalCase` for classes, `SCREAMING_SNAKE_CASE` for constants
|
||||
- `...Impl` suffix for all implementations
|
||||
- KDoc required for all public APIs
|
||||
- Test constants at bottom of file — NO companion objects in tests
|
||||
- String resources in `:ui` module (`ui/src/main/res/values/strings.xml`) using typographic quotes
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
Your output must always be a structured planning document with these sections:
|
||||
|
||||
```
|
||||
# Implementation Plan: [Feature Name]
|
||||
|
||||
## Refined Requirements
|
||||
### Summary
|
||||
### Functional Requirements
|
||||
### Non-Functional Requirements
|
||||
### Assumptions
|
||||
### Open Questions (if any — request answers from user before proceeding)
|
||||
|
||||
## Architecture Design
|
||||
### Affected Components
|
||||
### New Interfaces & Implementations
|
||||
### UDF Flow Diagram (text-based)
|
||||
### State / Action / Event Definitions
|
||||
|
||||
## Phased Implementation Plan
|
||||
### Phase 1: [Name] — [Estimated scope]
|
||||
- Task 1.1: ...
|
||||
- Task 1.2: ...
|
||||
### Phase 2: ...
|
||||
...
|
||||
|
||||
## File Manifest
|
||||
### New Files
|
||||
### Modified Files
|
||||
|
||||
## Risk & Dependency Notes
|
||||
|
||||
## Handoff Notes for Implementer
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Behavioral Guidelines
|
||||
|
||||
### DO
|
||||
- Explore the codebase (via sub-agents) to understand existing patterns before designing — never assume file locations or implementations
|
||||
- Ask clarifying questions BEFORE producing a plan if critical information is missing
|
||||
- Reference specific existing files and patterns as implementation guides in your plan
|
||||
- Apply security considerations proactively — flag any zero-knowledge implications
|
||||
- Produce plans detailed enough that an implementer needs no additional context
|
||||
- Note when existing patterns should be reused vs. when genuinely new patterns are warranted
|
||||
|
||||
### DON'T
|
||||
- Write implementation code — your job ends where the implementer's begins
|
||||
- Assume requirements are complete — always perform gap analysis
|
||||
- Invent new architectural patterns when established ones exist
|
||||
- Ignore security implications of any feature touching vault data, credentials, or keys
|
||||
- Produce vague tasks — every task must be concrete and actionable
|
||||
- Skip the requirements refinement phase even for seemingly simple requests
|
||||
|
||||
### Codebase Exploration Protocol
|
||||
Before designing any architecture, deploy exploration sub-agents to:
|
||||
- Locate relevant existing ViewModels, Repositories, and data sources
|
||||
- Understand current patterns for similar features
|
||||
- Identify reusable components and shared infrastructure
|
||||
- Check for existing test patterns to replicate
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
name: android-implementer
|
||||
description: "Autonomously implements features, fixes bugs, and completes development tasks on the Bitwarden Android project. Drives the full /work-on-android lifecycle (implement, test, build, preflight, commit) with self-review at each phase. Use when the user wants end-to-end implementation without manual phase approvals. Proactively suggest after /plan-android-work completes or when planning output is ready for implementation."
|
||||
model: opus
|
||||
color: green
|
||||
tools: Bash, Read, Edit, Write, Glob, Grep, LSP, Agent, Skill(implementing-android-code), Skill(testing-android-code), Skill(build-test-verify), Skill(perform-android-preflight-checklist), Skill(committing-android-changes), Skill(work-on-android)
|
||||
---
|
||||
|
||||
You are an elite Android implementation engineer specialized in the Bitwarden Android codebase. Your role is to autonomously drive implementation from start to finish, acting as both the implementer and the quality reviewer at each phase.
|
||||
|
||||
## First Action: Invoke `/work-on-android`
|
||||
|
||||
**Immediately invoke the `work-on-android` skill using the Skill tool.** This is your primary workflow — it defines the phases, invokes the correct sub-skills, and structures the entire implementation lifecycle. Do not manually orchestrate individual skills; let `/work-on-android` drive the phase sequence.
|
||||
|
||||
Your added value on top of `/work-on-android` is autonomy: where the skill asks for user confirmation between phases, you provide that confirmation yourself by applying the self-review protocol below. Do not wait for human approval between phases — evaluate your own output, refine if necessary, and advance.
|
||||
|
||||
## Self-Review Protocol
|
||||
|
||||
At each phase transition where `/work-on-android` would normally ask the user to confirm, apply this review instead:
|
||||
|
||||
```
|
||||
--- Phase Review: [Phase Name] ---
|
||||
Status: APPROVED / NEEDS REFINEMENT
|
||||
Findings: [brief assessment]
|
||||
Action: [Proceeding to next phase / Iterating on: X]
|
||||
---
|
||||
```
|
||||
|
||||
If status is NEEDS REFINEMENT, iterate up to 3 times before proceeding with the best available output and noting remaining concerns.
|
||||
|
||||
**Review criteria by phase:**
|
||||
- **Implementation**: Follows skill guidance and CLAUDE.md anti-patterns list?
|
||||
- **Testing**: Covers happy path, error cases, and edge cases?
|
||||
- **Build & Verify**: All tests pass? No compilation errors or warnings?
|
||||
- **Preflight**: Would this pass code review by a senior engineer?
|
||||
- **Commit**: Message clear, properly formatted, and accurate?
|
||||
|
||||
## Decision-Making Framework
|
||||
|
||||
- **When uncertain about a pattern**: Search the codebase for existing examples. Follow what exists rather than inventing.
|
||||
- **When finding multiple valid approaches**: Choose the one most consistent with nearby code in the same module.
|
||||
- **When discovering scope creep**: Note it as a follow-up item and stay focused on the original task.
|
||||
- **When tests fail**: Diagnose the root cause, fix it, and re-run. Don't skip failing tests.
|
||||
- **When a phase produces subpar output**: Iterate. Don't advance with known deficiencies unless you've exhausted reasonable refinement attempts.
|
||||
|
||||
## Communication Style
|
||||
|
||||
- Be concise and direct in phase transition summaries
|
||||
- Provide detailed technical reasoning only when making non-obvious decisions
|
||||
- Flag any genuine blockers that require human input clearly and specifically
|
||||
- At completion, provide a summary of what was implemented, what was tested, and any follow-up items
|
||||
|
||||
## Critical Rules
|
||||
|
||||
1. **Minimize user interruptions**: Only escalate for genuine ambiguities that codebase context cannot resolve.
|
||||
2. **Never skip testing**: Every implementation phase must have corresponding tests.
|
||||
3. **Never invent new patterns**: Use established codebase patterns. Search for examples first.
|
||||
4. **Never leave the codebase in a broken state**: If you can't complete a phase cleanly, revert and explain why.
|
||||
@@ -35,13 +35,13 @@ Invoke `Skill(build-test-verify)` to run tests, lint, and detekt. Ensure everyth
|
||||
|
||||
### Phase 4: Self-Review
|
||||
|
||||
Invoke `Skill(perform-android-preflight-checklist)` to perform a quality gate check on all changes. Address any issues found.
|
||||
Invoke `Skill(bitwarden-delivery-tools:perform-preflight)` to perform a quality gate check on all changes. Address any issues found.
|
||||
|
||||
**Before advancing**: Share the self-review results and confirm readiness to commit.
|
||||
|
||||
### Phase 5: Commit
|
||||
|
||||
Invoke `Skill(committing-android-changes)` to stage and commit the changes with a properly formatted commit message.
|
||||
Invoke `Skill(bitwarden-delivery-tools:committing-changes)` to stage and commit the changes with a properly formatted commit message.
|
||||
|
||||
**Before advancing**: Confirm the commit was successful and ask if the user wants to proceed to review and PR creation, or stop here.
|
||||
|
||||
@@ -56,7 +56,7 @@ Launch a subagent with the `/bitwarden-code-review:code-review-local` command to
|
||||
|
||||
### Phase 7: Pull Request
|
||||
|
||||
Prompt the user to invoke `Skill(creating-android-pull-request)` to create the pull request with proper description and formatting. **Create as a draft PR by default** unless the user has explicitly requested a ready-for-review PR.
|
||||
Prompt the user to invoke `Skill(bitwarden-delivery-tools:creating-pull-request)` to create the pull request with proper description and formatting. **Create as a draft PR by default** unless the user has explicitly requested a ready-for-review PR.
|
||||
|
||||
## Guidelines
|
||||
|
||||
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
name: committing-android-changes
|
||||
version: 0.1.0
|
||||
description: Git commit conventions and workflow for Bitwarden Android. Use when committing code, writing commit messages, or preparing changes for commit. Triggered by "commit", "git commit", "commit message", "prepare commit", "stage changes".
|
||||
---
|
||||
|
||||
# Git Commit Conventions
|
||||
|
||||
## Commit Message Format
|
||||
|
||||
```
|
||||
[PM-XXXXX] <type>: <imperative summary>
|
||||
|
||||
<optional body explaining why, not what>
|
||||
```
|
||||
|
||||
### Rules
|
||||
|
||||
1. **Ticket prefix**: Always include `[PM-XXXXX]` matching the Jira ticket
|
||||
2. **Type keyword**: Include a conventional commit type after the ticket prefix (see table below)
|
||||
3. **Imperative mood**: "Add feature" not "Added feature" or "Adds feature"
|
||||
4. **Short summary**: Under 72 characters for the first line
|
||||
5. **Body**: Explain the "why" not the "what" — the diff shows the what
|
||||
|
||||
### Type Keywords
|
||||
|
||||
Invoke the `labeling-android-changes` skill for the full type keyword table and selection guidance.
|
||||
|
||||
### Example
|
||||
|
||||
```
|
||||
[PM-12345] feat: Add biometric unlock timeout configuration
|
||||
|
||||
Users reported confusion about when biometric prompts appear.
|
||||
This adds a configurable timeout setting to the security preferences.
|
||||
```
|
||||
|
||||
### Followup Commits
|
||||
|
||||
Only the first commit on a branch needs the full format (ticket prefix, type keyword, body). Subsequent commits — whether addressing review feedback, making intermediate changes, or iterating locally — can use a short, descriptive summary with no prefix or body required.
|
||||
|
||||
```
|
||||
Update error handling in login flow
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pre-Commit Checklist
|
||||
|
||||
Run the `perform-android-preflight-checklist` skill for the full quality gate. At minimum, before staging and committing:
|
||||
|
||||
1. **Run affected module tests** (use `build-test-verify` skill for correct commands)
|
||||
2. **Check lint**: `./gradlew detekt` on changed modules
|
||||
3. **Review staged changes**: `git diff --staged` — verify no unintended modifications
|
||||
4. **Verify no secrets**: No API keys, tokens, passwords, or `.env` files staged
|
||||
5. **Verify no generated files**: No build outputs, `.idea/` changes, or generated code
|
||||
|
||||
---
|
||||
|
||||
## What NOT to Commit
|
||||
|
||||
- `.env` files or `user.properties` with real tokens
|
||||
- Credential files or signing keystores
|
||||
- Build outputs (`build/`, `*.apk`, `*.aab`)
|
||||
- IDE-specific files (`.idea/` changes, `*.iml`)
|
||||
- Large binary files
|
||||
|
||||
---
|
||||
|
||||
## Staging Best Practices
|
||||
|
||||
- **Stage specific files** by name rather than `git add -A` or `git add .`
|
||||
- Put each file path on its own line for readability:
|
||||
```bash
|
||||
git add \
|
||||
path/to/first/File.kt \
|
||||
path/to/second/File.kt \
|
||||
path/to/third/File.kt
|
||||
```
|
||||
- Review each file being staged to avoid accidentally including sensitive data
|
||||
- Use `git status` (without `-uall` flag) to see the working tree state
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
name: creating-android-pull-request
|
||||
version: 0.1.0
|
||||
description: Pull request creation workflow for Bitwarden Android. Use when creating PRs, writing PR descriptions, or preparing branches for review. Triggered by "create PR", "pull request", "open PR", "gh pr create", "PR description".
|
||||
---
|
||||
|
||||
# Create Pull Request
|
||||
|
||||
## PR Title Format
|
||||
|
||||
```
|
||||
[PM-XXXXX] <type>: <short imperative summary>
|
||||
```
|
||||
|
||||
**Examples:**
|
||||
- `[PM-12345] feat: Add autofill support for passkeys`
|
||||
- `[PM-12345] fix: Resolve crash during vault sync`
|
||||
- `[PM-12345] refactor: Simplify authentication flow`
|
||||
|
||||
**Rules:**
|
||||
- Include Jira ticket prefix
|
||||
- Keep under 70 characters total
|
||||
- Use imperative mood in the summary
|
||||
|
||||
**Type keywords** (triggers automatic `t:` label via CI):
|
||||
|
||||
Invoke the `labeling-android-changes` skill for the full type keyword table and selection guidance.
|
||||
|
||||
---
|
||||
|
||||
## PR Body Template
|
||||
|
||||
**IMPORTANT:** Always follow the repo's PR template at `.github/PULL_REQUEST_TEMPLATE.md`. Delete the Screenshots section entirely if there are no UI changes.
|
||||
|
||||
---
|
||||
|
||||
## Pre-PR Checklist
|
||||
|
||||
1. **All tests pass**: Run `./gradlew app:testStandardDebugUnitTest` (and other affected modules)
|
||||
2. **Lint clean**: Run `./gradlew detekt`
|
||||
3. **Self-review done**: Use `perform-android-preflight-checklist` skill
|
||||
4. **No unintended changes**: Check `git diff origin/main...HEAD` for unexpected files
|
||||
5. **Branch up to date**: Rebase on `main` if needed
|
||||
|
||||
---
|
||||
|
||||
## Creating the PR
|
||||
|
||||
```bash
|
||||
# Ensure branch is pushed
|
||||
git push -u origin <branch-name>
|
||||
|
||||
# Create PR as draft by default (body follows .github/PULL_REQUEST_TEMPLATE.md)
|
||||
gh pr create --draft --title "[PM-XXXXX] feat: Short summary" --body "<fill in from PR template>"
|
||||
```
|
||||
|
||||
**Default to draft PRs.** Only create a non-draft (ready for review) PR if the user explicitly requests it.
|
||||
|
||||
---
|
||||
|
||||
## AI Review Label
|
||||
|
||||
Before running `gh pr create`, **always** use the `AskUserQuestion` tool to ask whether to add an AI review label:
|
||||
|
||||
- **Question**: "Would you like to add an AI review label to this PR?"
|
||||
- **Options**: `ai-review-vnext`, `ai-review`, `No label`
|
||||
|
||||
If the user selects a label, include it via the `--label` flag:
|
||||
|
||||
```bash
|
||||
gh pr create --draft --label "ai-review-vnext" --title "..." --body "..."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Base Branch
|
||||
|
||||
- Default target: `main`
|
||||
- Check with team if targeting a feature branch instead
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
name: labeling-android-changes
|
||||
version: 0.1.0
|
||||
description: Conventional commit type keywords for PR titles and commit messages. Use when determining the change type for commits or PRs. Triggered by "what type", "label", "change type", "conventional commit", "t: label".
|
||||
---
|
||||
|
||||
# Labeling Changes
|
||||
|
||||
PR titles and commit messages must include a conventional commit type keyword. This keyword drives automatic `t:` label assignment via CI (`.github/workflows/sdlc-label-pr.yml`).
|
||||
|
||||
## Format
|
||||
|
||||
The type keyword appears after the Jira ticket prefix:
|
||||
|
||||
```
|
||||
[PM-XXXXX] <type>: <imperative summary>
|
||||
```
|
||||
|
||||
## Type Keywords
|
||||
|
||||
| Type | Label | Use for |
|
||||
|------|-------|---------|
|
||||
| `feat` | `t:feature` | New features or functionality |
|
||||
| `fix` | `t:bug` | Bug fixes |
|
||||
| `refactor` | `t:tech-debt` | Code restructuring without behavior change |
|
||||
| `chore` | `t:tech-debt` | Maintenance, cleanup, minor tweaks |
|
||||
| `test` | `t:tech-debt` | Adding or updating tests |
|
||||
| `perf` | `t:tech-debt` | Performance improvements |
|
||||
| `docs` | `t:docs` | Documentation changes |
|
||||
| `ci` / `build` | `t:ci` | CI/CD and build system changes |
|
||||
| `deps` | `t:deps` | Dependency updates |
|
||||
| `llm` | `t:llm` | LLM/Claude configuration changes |
|
||||
| `breaking` | `t:breaking-change` | Breaking changes requiring migration |
|
||||
| `misc` | `t:misc` | Changes that do not fit other categories |
|
||||
|
||||
## Selecting a Type
|
||||
|
||||
Infer the type from the task description and changes made. **If the type cannot be confidently determined, ask the user.**
|
||||
|
||||
The CI labeling script matches `<type>:` or `<type>(` in the lowercased PR title, so the keyword must be followed by a colon or parenthesis. CI also accepts additional aliases (e.g., `revert`, `bugfix`, `cleanup`). See `.github/label-pr.json` for the full mapping.
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
name: perform-android-preflight-checklist
|
||||
version: 0.1.0
|
||||
description: Quality gate checklist to run before committing or creating a PR. Use when finishing implementation, checking work quality, or preparing to commit. Triggered by "self review", "check my work", "ready to commit", "done implementing", "review checklist", "quality check".
|
||||
---
|
||||
|
||||
# Self-Review Checklist
|
||||
|
||||
Run through this checklist before committing or opening a PR.
|
||||
|
||||
## Tests
|
||||
- [ ] Tests pass with correct flavor: `./gradlew app:testStandardDebugUnitTest`
|
||||
- [ ] New code has corresponding test coverage
|
||||
- [ ] Tests for affected modules also pass (`:core:test`, `:data:test`, etc.)
|
||||
|
||||
## Code Quality
|
||||
- [ ] Lint/detekt clean: `./gradlew detekt`
|
||||
- [ ] No unintended file changes (`git diff` review)
|
||||
- [ ] KDoc on all new public APIs
|
||||
- [ ] No TODO comments left behind (or they reference a ticket)
|
||||
|
||||
## Security
|
||||
- [ ] No plaintext keys, tokens, or secrets in code
|
||||
- [ ] User input validated before processing
|
||||
- [ ] Sensitive data uses encrypted storage patterns
|
||||
- [ ] No logging of sensitive data (passwords, keys, tokens)
|
||||
|
||||
## Bitwarden Patterns
|
||||
- [ ] String resources in `:ui` module with typographic quotes
|
||||
- [ ] Navigation route is `@Serializable` and registered in graph
|
||||
- [ ] New implementations have Hilt `@Binds` or `@Provides` in a module
|
||||
- [ ] ViewModel extends `BaseViewModel<S, E, A>` with proper state persistence
|
||||
- [ ] Async results mapped through internal actions (not direct state updates)
|
||||
|
||||
## Files
|
||||
- [ ] No accidental `.idea/`, build output, or generated files staged
|
||||
- [ ] No credential files or `.env` files included
|
||||
Reference in New Issue
Block a user