83 lines
4.1 KiB
Plaintext
83 lines
4.1 KiB
Plaintext
---
|
|
alwaysApply: true
|
|
---
|
|
|
|
# System Directives
|
|
|
|
|
|
Unless the user explicitly says otherwise, these rules apply to all projects and technology stacks.
|
|
|
|
## Basic Rules
|
|
|
|
- Always reply in Chinese unless the user explicitly requests another language.
|
|
- The current development environment is Windows.
|
|
- Follow YAGNI and KISS. Solve the current problem with the simplest correct approach.
|
|
- Prefer existing project capabilities, conventions, utilities, and standard tooling.
|
|
- Do not over-engineer, and do not add abstractions, dependencies, frameworks, services, or parallel implementations for hypothetical needs.
|
|
|
|
## Project Directory
|
|
|
|
- If an existing project directory matches the task, work in that directory.
|
|
- If no project directory exists, first check `E:\code\TempCode`.
|
|
- If it exists, create a new working directory there with a name that matches the task purpose, and use it as the current project directory.
|
|
- If it does not exist, ask the user where files should be stored before creating anything.
|
|
- Do not scatter project files across unrelated directories, and do not write directly to the user's home directory unless explicitly asked.
|
|
|
|
## Changes And Cleanup
|
|
|
|
After implementation, clean up before reporting completion:
|
|
|
|
- Delete temporary files, test artifacts, fake data, temporary scripts, debug logs, and unused configuration.
|
|
- Remove commented-out old code, unused imports, variables, functions, assets, and unreachable code.
|
|
- Keep only files, code, and necessary logs that are required for real use.
|
|
|
|
## Project Memory
|
|
|
|
After every feature, modification, or bug fix, update the project memory:
|
|
|
|
- Use `aidocs/project_context.md` by default.
|
|
- Add `aidocs/` to `.gitignore` by default. Project memory is local only and must not be committed to Git.
|
|
- Create the memory file if it does not exist.
|
|
- Record architecture changes, new dependencies, new conventions, key logic, and important lessons.
|
|
- Do not scatter project memory across multiple files unless clearly necessary.
|
|
- Keep the document description at the top of the memory file. Add each new memory entry after the description and before older entries.
|
|
- Keep memory history in reverse chronological order, with the newest entry first, like a timeline.
|
|
|
|
## Git
|
|
|
|
Before finishing a project task, handle version control:
|
|
|
|
- Initialize Git if `.git` does not exist.
|
|
- Ensure `.gitignore` exists and matches the real project structure.
|
|
- Commit only real, meaningful changes. Do not create empty commits.
|
|
- Commit message format: `<type>: <Chinese description>`.
|
|
- Allowed types: `feat`, `fix`, `refactor`, `style`, `docs`, `chore`, `revert`.
|
|
- Before committing, inspect all working tree changes.
|
|
- If there are changes not made in the current session, check whether they break code or introduce obvious problems.
|
|
- If those changes are reasonable user edits, such as copy changes or feature improvements, and they do not break code, include them in the commit instead of leaving them unstaged.
|
|
- If non-current-session changes appear to break code, contain sensitive information, or conflict with the current goal, ask the user before committing.
|
|
|
|
## Execution Order
|
|
|
|
Unless the user explicitly asks to skip steps, follow this order:
|
|
|
|
1. Implement.
|
|
2. Clean up.
|
|
3. Update `aidocs/project_context.md`.
|
|
4. Update other documentation if needed.
|
|
5. Initialize or check Git.
|
|
6. Check `.gitignore`.
|
|
7. Commit meaningful changes.
|
|
8. Report the result or ask for next steps.
|
|
|
|
## Non-Project Task Exception
|
|
|
|
- Pure consulting, explanations, remote troubleshooting, server configuration, device debugging, command guidance, and one-off diagnostics do not require creating a project directory.
|
|
- These tasks do not require project memory updates, Git initialization, `.gitignore` checks, or commits.
|
|
- If the task later becomes code creation, file generation, or a reusable deliverable, handle it as a project task from that point onward.
|
|
|
|
## No Silent Skipping
|
|
|
|
- Do not silently skip cleanup, project memory, Git, `.gitignore`, or commits during project tasks.
|
|
- If steps are skipped because the task is non-project work or because the user explicitly requested it, briefly explain the reason when relevant.
|