When writing or reviewing in CursorMulti-platformcode, uniformly followeach platform's official documentationand project conventions. Save as SKILL.md and place it in ~/.cursor/skills/coding-assistant/ or the project's .cursor/skills/ to take effect.
Reference documentation (prioritize official websites):
- Android: Follow Android official standards. Android Developers (Chinese)https://developer.android.com/?hl=zh-cn；Jetpack Compose https://developer.android.com/develop/ui?hl=zh-cn。
- iOS: Follow iOS official documentation standards. Apple Developer (developer documentation, Swift, UIKit/SwiftUI)https://developer.apple.com/documentation/；Swift https://swift.org/documentation/。
- Other languages / frameworks: Prefer theofficial website documentationof that language or framework (e.g., Rust, Python, Go, React, Vue, etc., based on their respective official websites and official styles).
II. Coding Standards and References
- Usethe official documentation of the platform/language used by the current projectas the primary reference; when there is no clear standard, stay consistent with the project's existing style.
- File header: The top of a new file must include a feature summary, author, date, and version (format according to the language's conventions, such as JSDoc, KDoc, Swift comments, etc.).
- Naming and comments: Related to the responsibilities of the class/module; important functions should note "what it does" and "why it is implemented this way"; separate responsibilities and extract unrelated logic into independent modules.
III. New File Header
According to the current language's conventions, include at the top of the file: feature summary, author, date, and version. Example (C/Java-like style):
/**
* 功能：xxx 模块的 ViewModel，负责 UI 状态与业务逻辑。
* 作者：Your Name
* 日期：2025-03-12
* 版本：1.0.0
*/
Swift / other languages may use the corresponding comment style.
IV. Class and Function Standards
- Naming: Related to the responsibilities of the class/module; prefer abbreviations of the class name or agreed prefixes.
- Comments and rationale: Important functions should explain "what it does" and "why it is implemented this way".
- Separation of responsibilities: Extract logic unrelated to the current class/module into an independent Util, Handler, Repository, or equivalent module.
V. Single File/Single Class Length
The length of a single file or single class must not exceed 3000 lines (or follow project conventions). When exceeded, split it by splitting classes, extracting modules, extension functions, or other methods.
VI. Checks After Development Is Complete
- Android: Run
./gradlew assembleDebug(or the project's agreed task),./gradlew lint; if it fails, modify according to the error and retry. - iOS: Use Xcode build and static analysis (or
xcodebuild, SwiftLint, etc., according to project conventions); if it fails, modify according to the error and retry. - Other: Execute the compilation, lint, and formatting commands agreed by the project until they pass.
VII. Unit Testing During Development
- Write unit tests for newly added or modified classes/functions (JUnit, XCTest, pytest, or the project's existing framework).
- Run tests (such as
./gradlew test、xcodebuild test、pytest, etc.) to ensure the relevant tests pass. - Persistence strategy: Only after the unit tests pass, write this change to disk; if they fail, fix first and then save.
X. Core Technical Documentation and Notes
During coding, assist in organizing core technologies, and call the create_note capability to write technical notes into WPS Notes. For the complete workflow (including check-before-edit, mermaid call chain, core code sources, waiting for user instructions for direct assistance, etc.), see the sub-skill review-notes and reference/reference.md. When collaborating with WPS: prefer get_current_note; before editing, get_note_outline get the latest block_id, and after editing, sync_note; if BLOCK_NOT_FOUND occurs, refresh the outline and retry; for multi-step edits, use batch_editas much as possible. See reference §7 for details. The following is a summary of key points.
When to start WPS Notes technical documentation(start reading and writing WPS Notes and generating technical documentation if any one is met):
- Coding tool + keywords: when the user uses Cursor、Codex、Claude Code、AS code and other coding tools towrite, review, or optimize code, and the user mentions "architecture」「design diagram」「core methods」「key technologies" or "technical documentation", "record in notes", etc., automatically read the current file/project context and write to WPS Notes, generating or updating technical documentation.
- Phrases/scenarios: reviewing code, technical documentation, summarizing key code, recording key technical points, recording in notes, generating technical documentation; or when "generate technical documentation" appears in class/function comments; or when the code involves complex scenarios (multithreading/coroutines, JNI/NDK, complex state and navigation, performance optimization, security and encryption, etc.), include as appropriate.
Complete note structure: the generated WPS Notesmust be complete, andmust includethe following 7 second-level headings:Core Technologies(must include images),Core Code、Key Technical Points、Core Classes and Responsibilities、Call Chain(mermaid, and may include images),Architecture Overview(must include images),Precautions. See reference §0.2 for details.
Architecture / core technologies / call chain images: prefer using WPS Notes' generate_image to generate images based on the call chain description, architecture description, and core technology description, then use insert_image to insert them into the notes; if generate_image is unavailable, use mermaid or insert_image from the official website/Juejin/Wikipedia. See reference §2.1 for details.
Before saving: first list_notes to view existing technical documentation; then create_note(or check before editing, and if matched, edit directly without creating a new one) and write the content into that note.
Call chain: the "call chain" in the notes must use the mermaid format (flowchart or sequenceDiagram); you may also use generate_image to generate a schematic diagram based on the call chain description and insert it with insert_image.
Core code(include in the notes if any one is met): (1) keywords in comments: When "core code", "key implementation", "technical points", "generate technical documentation", etc. appear in comments, read the corresponding line/block or function body. (2) User-copied code block: The user notifies after selecting and copying (e.g. "copied", "this section is core code"). (3) Code block in the clipboard: The user notifies that code has been pasted to the clipboard; if the clipboard cannot be read, extract the most relevant function/block from the current file as a fallback. (4) Code selected in this file。(5) Specified function: Take the complete function body of that function. When writing notes, prefer using edit_block(op="insert") / edit_block(op="replace") to write in code block form.
User-added heading: When the user adds a new second-level heading or other subheading in the note,based on the user's requestadd the corresponding content under that heading (edit_block(op="insert")）。proactive update: While the user has not closed the current note,after about 1 minuteor at an appropriate timeproactively refresh and updatethe note (e.g. supplement subsections, update the call chain/core code, etc.),until the user actively closes the current note. See reference §0.3, §0.4, §7 for details.
Tags: After the note is completed, call find_tags to view existing tags, then generate core tags or output suggested tags according to the user's style.
8. Metadata and Structure Reference
The Skill metadata and directory structure can be referenced at:https://github.com/Drjacky/claude-android-ninja/tree/master(including SKILL.md, references, templates).
9. When to Use This Skill
When the user is doing Android / iOS / other languages development, code review, adding new files, refactoring, or asking about the official specifications of various platforms, automatically apply this Skill.WPS Note technical documentation: When the user uses coding tools such as Cursor, Codex, Claude Code, AS code, etc. to write, review, or optimize code, and the user mentions "architecture", "design diagram", "core method", "key technology", or "technical documentation", "record in notes", etc., automatically start reading and writing WPS notes, and generating or updating technical documentation (first use list_notes to check existing notes, and edit if matched rather than creating new ones); the core code involved can be obtained from keywords in comments, code blocks copied by the user, code blocks in the clipboard, selected code, or a specified function body. During development, only write to disk after unit tests pass; after development ends, assist in executing that platform's compilation and lint. When collaborating with WPS, follow rules such as get_current_note, get_note_outline, sync_note, and batch_edit.