A rule for creating or updating a Markdown document in the docs directory after a completed coding task. The document records database changes, configuration, API details, and the implementation flow in Chinese.
A rule for coordinating multiple software agents when a request contains specific development or testing phrases in Chinese. It selects a scenario such as a new feature, bug fix, refactoring, or test-only work and assigns suitable agent roles.
A rule requiring Chinese OpenAPI 3 documentation annotations on backend controllers and data-transfer objects. OpenAPI is a standard way to describe web APIs so their endpoints, parameters, and responses can be read by people and tools.
A database table standard that requires every table to include identity, ownership, deletion, and change-history fields. A tenant is a customer or organization sharing the system, and an OEM is the product maker or vendor associated with the data.
Rules for organising software into four layers—interface, application, domain, and infrastructure—and for modelling business concepts using domain-driven design.
A set of SOLID design and defensive-programming rules for Java and Spring code. SOLID is a group of principles for keeping software responsibilities, interfaces, inheritance, and dependencies manageable.
A set of Chinese-language rules for improving Java Virtual Machine performance and designing the data-access layer, the code that reads and writes databases.
A set of enterprise security rules based on OWASP Top 10, a list of common web-application security risks. It covers input validation, secrets, logging, encryption, permissions, and tenant data separation.
A set of rules for designing code that is easy to test and for writing unit, integration, and end-to-end tests. Unit tests check small pieces, integration tests check connected parts, and end-to-end tests check complete user flows.
Rules for structured logs, monitoring measurements, and request tracing. These practices help you understand what a running application is doing and where failures or delays occur.
A set of rules for generating Java code with detailed Chinese comments and execution logs. It requires the Lombok Slf4j logging framework and defines when to use information, debug, warning, and error logs.
A set of rules for MyBatis-Plus, a Java library that maps database queries to application code. It covers query building, SQL placement, pagination, logical deletion, and multi-tenant data handling.
A set of coding rules for REST APIs built with Spring Boot, a Java framework for web services. It covers response formats, URL paths, authentication, dependency injection, and error handling.
Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes.
A step-by-step process for fixing software bugs, including errors, failed requests, and features that used to work. It requires investigating the underlying cause, writing a test that first fails, then applying and checking the fix.
Use when tests have race conditions, timing dependencies, or inconsistent pass/fail behavior - replaces arbitrary timeouts with condition polling to wait for actual state changes, eliminating flaky tests from timing guesses.
Use when invalid data causes failures deep in execution, requiring validation at multiple system layers - validates at every layer data passes through to make bugs structurally impossible.
A backend development workflow driven by a product requirements document, with the frontend or a test substitute consuming the result. It defines the API contract before implementation and covers authentication, database changes, transactions, regression checks, and security review.
A structured workflow for building frontend features from a product requirements document (PRD), while the backend API is already available or being built by someone else. It covers clarification, project review, implementation, testing, release, and follow-up.
A full-stack development workflow for building both the front end and back end from a PRD, a document describing product requirements. It defines the API contract first, proves one real end-to-end path, then expands the implementation and tests.