القائمة
Analyse source changes since the last release and produce a plan describing what in README.md needs updating. Does not edit any files. Do not invoke automatically.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Determine the latest Kotlin + AGP versions compatible with BOTH the current Android Studio and the current IntelliJ IDEA (the lagging IDE is the cap), compare against this project's pins, and present a dated inline report. Researches live; report-only — proposes a bump but never edits without confirmation. Do not invoke automatically.
Cut a new release — analyse source changes, recommend the next version, confirm it, then bump gradle.properties, write CHANGELOG.md, and commit. Optionally invoke with a version number to pre-fill the recommendation. Do not invoke automatically.
Run BOTH review lenses over the whole project — the eleven rv-* house-rules specialists and the nine bp-* currency specialists — in parallel waves, then synthesize ONE prioritized, cross-deduplicated review document written to docs/full-review-YYYY-MM-DD.md (findings + a phased fix plan). Heavyweight (twenty subagents); for release gates / periodic full audits, not per-diff. Writes only that doc; makes no other code changes. Do not invoke automatically.
Orchestrate a currency audit of the whole project against the latest official upstream best practices, using the nine bp-* specialist subagents dispatched in parallel waves, then synthesize one prioritized, source-cited review document written to docs/currency-review-YYYY-MM-DD.md (findings + a phased fix plan). Writes only that doc; makes no other code changes (each subagent may persist notes to its own project memory). Do not invoke automatically.
Orchestrate a full house-rules review of the entire project from the eleven rv-* review specialists, dispatched in three parallel waves, then synthesize one prioritized review document written to docs/house-review-YYYY-MM-DD.md (findings + a phased fix plan). Writes only that doc; makes no other code changes (each subagent may persist notes to its own project memory). Do not invoke automatically.
Audit this project's `.claude/` subagents, skills, and hooks against the LATEST official Claude Code docs, then present a dated best-practices report inline. Researches current guidance live (does not rely on memory). Read-then-offer — proposes fixes but does not apply them without confirmation. Do not invoke automatically.
| name | readme-plan |
| description | Analyse source changes since the last release and produce a plan describing what in README.md needs updating. Does not edit any files. Do not invoke automatically. |
| disable-model-invocation | true |
| allowed-tools | Bash(git tag*), Bash(git diff*), Read |
!git tag --sort=-version:refname | head -1
Analyse the changes since the previous tag against the current README.md and produce a plan of what needs updating. Do not edit any files.
The previous tag is pre-loaded above. Run the following commands in order and read the output carefully:
git diff <last_tag>..HEAD --name-only — full list of changed filesgit diff <last_tag>..HEAD -- '*.kt' — Kotlin sourcesgit diff <last_tag>..HEAD -- '*.kts' 'gradle/libs.versions.toml' 'gradle.properties' — build and dependency filesgit diff <last_tag>..HEAD -- '.github/' — CI/config filesDo not use git commit messages. Derive everything from the actual diffs.
Read the full contents of README.md.
Compare the diff findings against the README content. For each README section, decide whether it is:
Sections to check:
| README section | What to look for in the diff |
|---|---|
| Badges (top) | Version numbers in gradle/libs.versions.toml or gradle.properties |
| Tech Stack table | Any library version change in libs.versions.toml |
| Architecture diagram / module list | New modules, removed modules, renamed packages |
| Module responsibilities table | New or removed classes/files that change a module's stated role |
| Design Patterns | New patterns introduced, existing patterns significantly changed |
| Testing Strategy | New test utilities, new test layers, changed coverage approach |
| Project Structure tree | New top-level directories or modules |
| Getting Started / prerequisites | Toolchain version changes (JDK, AGP, Xcode notes) |
| Releasing section | Changes to the release workflow |
Present the findings as a numbered list of proposed changes. For each item include:
End with a one-sentence summary of the overall scope (e.g. "3 version bumps in the Tech Stack table and 1 new module to add to the Architecture section").
Do not make any edits. Output the plan only.