2 changed files with 16 additions and 0 deletions
@@ -28,3 +28,6 @@ When conducting or receiving a code review for NexusReader, ensure the implement
 ## 5. Standard Nexus Guidelines
 - [ ] **Result Pattern**: Ensure all application logic returns `Result` or `Result<T>` via FluentResults. No exceptions for control flow.
 - [ ] **AI Prompts**: Ensure changes to AI logic do not bypass the `PromptRegistry` or token estimation limits defined in `AiSettings`.
+
+## 6. Code Review Comments
+- [ ] **Specific Linking**: Comments should be linked to specific code. Try to avoid general comments about the entire pull request.
@@ -0,0 +1,13 @@
+---
+name: nexus-git-workflow
+description: Guidelines and standards for Git workflow, commits, and PRs in NexusReader
+---
+# NexusReader Git Workflow Standards
+
+When working with Git and remote repositories for NexusReader, adhere to the following standards:
+
+- **System Prompts in Tasks**: Tasks in the tracker *usually include* a system prompt that you should use directly for implementation.
+- **Pull Request Traceability**: When you create a pull request, it must include a reference to at least one task from the tracker (e.g., "Fixes #123" or "Resolves #456").
+- **Gitea MCP Server**: Use the **Gitea MCP server** whenever possible when exchanging data with a remote repository.
+- **Atomic Commits**: Create *atomic commits* that represent a single logical change. This makes reviewing, reverting, and bisecting easier.
+- **Addressing Comments**: When addressing comments on a pull request, always refer to specific comments and try to resolve them within the conversation.