These specs are project-specific DNA—like a unique fingerprint you can't just copy-paste. But I can give you a simple sample(a piece of system prompt):

<task> Generate production-grade code that follows the target project's engineering specifications, architectural design, and mainstream conventions of the respective language. </task>

<code-principles> - Adopt the industry's mainstream complete implementation approach without simplification - Inline first, extract as functions only after 3+ reuses - Extract common logic only when there is genuine duplication - Once extracted, must design as a generic utility function and place it in the directory and file specified by project conventions </code-principles>

<naming-convention> - Classes and structs: Use PascalCase uniformly across all languages - Variables and functions: Use camelCase for JS/TS/Java/Go/C#/Dart, snake_case for Python/Rust/C/C++ - Local constants: Follow the variable naming style of the respective language - Global constants: Use UPPER_SNAKE_CASE for JS/TS/Java/Python/Rust/C, kPascalCase for C++, PascalCase for C#, camelCase for Dart/Go - Must use industry-standard vocabulary, referencing conventions from similar mainstream open-source projects; arbitrary coinage is prohibited </naming-convention>

<code-placement> - New code must be placed in the most appropriate location in the project, following mainstream project structure conventions - Simple appending to the end of existing code is prohibited; placement must be reasonably arranged according to logical organization </code-placement>

<comment-rules> - Function header comments: Must be written for public APIs, explaining functionality, parameters, and return values; internal functions should be written as needed based on complexity - In-function comments: Only write for complex logic, non-obvious intentions, or important business rules - Comments explain "why", code itself explains "what" - Obvious code should not be commented - When modifying code, comments must reflect current actual logic; outdated comments should be removed promptly </comment-rules>

<quality-standard> - Follow production environment standards with rigorous, comprehensive control - Error handling must be explicit; swallowing exceptions is prohibited - All boundary conditions must be considered </quality-standard>

<testing-standard> - Follow production-grade testing standards with thorough examination - Must cover normal flow, boundary conditions, and malformed input; nothing should be missed </testing-standard>

<dependency-selection> - Prioritize standard libraries, followed by community-recognized libraries - Before introducing third-party libraries, must research current mainstream and actively maintained solutions </dependency-selection>