菜单
MADR (Markdown Any Decision Records) workflow. Use when recording an architecture or significant technical decision. Trigger phrases: "new adr", "architecture decision", "record decision", "write adr", "/madr".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Patterns and conventions for the Android (Jetpack Compose + Kotlin) app. Use when implementing or reviewing any screen, composable, ViewModel, repository, or service. Trigger phrases: "android pattern", "jetpack compose", "new screen", "new composable", "viewmodel", "/android".
arXiv Atom/XML API integration patterns. Use when implementing or reviewing any code in data/remote/ArxivApiService.kt or any file that calls the arXiv API. Trigger phrases: "arxiv api", "fetch papers", "query arxiv", "/arxiv-api", or when editing ArxivApiService.kt.
Debugging workflow for the Android (Kotlin + Jetpack Compose) app. Use when tracking down runtime errors, unexpected behavior, network issues, or state problems. Trigger phrases: "debug", "não está funcionando", "erro em runtime", "por que isso falha", "breakpoint", "/debug".
Unit testing patterns and conventions using JUnit5 + MockK + Turbine. Use when writing, reviewing, or debugging unit tests in this project. Trigger phrases: "write test", "unit test", "test this viewmodel", "test this repository", "/unit-test".
Spec-Driven Development workflow. Use when user asks to "create spec", "new spec", "approve spec", "implement spec", "/spec", or when starting work on any non-trivial change in a repository that uses docs/specs/. Enforces immutable numbering, status lifecycle (Draft → Approved → In Progress → Implemented → Deprecated), and index synchronization.
Product Requirements Document (PRD) writing workflow. Use when the user wants to define a new feature, product area, or user journey before writing specs. Trigger phrases: "write prd", "product requirements", "new feature brief", "define feature", "/write-prd".
| name | madr |
| description | MADR (Markdown Any Decision Records) workflow. Use when recording an architecture or significant technical decision. Trigger phrases: "new adr", "architecture decision", "record decision", "write adr", "/madr". |
ADRs record significant technical decisions and the reasoning behind them. They are not specs (which define features) — they answer: "Why did we choose X over Y?"
Reference: MADR
ALWAYS load this skill when:
DO NOT use for:
/spec/write-prddocs/adrs/NNNN-slug/adr.mddocs/adrs/README.md to find the next available numberProposed ──review──▶ Accepted ──supersede──▶ Deprecated
│
└─── Rejected
# [Short title of the decision]
* Status: Proposed | Accepted | Rejected | Deprecated | Superseded by [ADR-NNNN](../NNNN-slug/adr.md)
* Date: YYYY-MM-DD
* Deciders: [names or roles]
## Context and Problem Statement
[Describe the context and the problem in 2–4 sentences. Frame as a question if helpful.]
## Decision Drivers
* [Driver 1 — a force or concern]
* [Driver 2]
## Considered Options
* Option A — [one-line description]
* Option B — [one-line description]
* Option C — [one-line description]
## Decision Outcome
Chosen option: **Option A**, because [brief justification — which driver it satisfies].
### Positive Consequences
* [consequence 1]
### Negative Consequences
* [consequence 1]
## Pros and Cons of the Options
### Option A
* Good, because [argument]
* Bad, because [argument]
### Option B
* Good, because [argument]
* Bad, because [argument]
docs/adrs/README.md to find the next numberdocs/adrs/NNNN-slug/adr.md from the templatedocs/adrs/README.md with status ProposedAcceptedAGENTS.md if the decision changes a project-wide conventiondocs/adrs/README.mddocs/adrs/_template/adr.md