fraujulian/MyAiConfiguration
1
0 Fork 0
Code Issues Pull Requests Actions Activity

refactor(rules): de-duplicate priority/decision/documentation guidance into general.md

Browse Source 
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit is contained in:
Julian lechnerandClaude Haiku 4.5 committed 2026-09-16 15:46:20 +02:00
1 parent 3fa0d74ad8
commit 89de58ff24
2 files changed
+9 -11
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

shared/rules/general.md
+8 -2
View File
@@ -13,19 +13,25 @@ Apply instructions in this order:
Project instructions may specialize global defaults, but must not weaken security or data-loss protections without explicit user approval.
## Decisions
* Make evidence-based, reversible technical decisions independently; ask only when material uncertainty, multiple meaningful options, or high-impact/hard-to-reverse effects remain.
* Ask about business behavior, user-visible behavior, UI, UX, APIs, database models, configuration formats, or compatibility behavior only when it is missing, ambiguous, contradictory, or open to interpretation; implement explicitly specified behavior without asking again.
* For deeper guidance on ambiguous requirements or a meaningful technical choice, consult `decision-rule.md` (Codex: read `rules/decision-rule.md`; Claude: invoke the `rules-decision-rule` skill).
## Documentation
* Never modify existing documentation automatically.
* If a code change would make existing documentation inaccurate or outdated, ask the user before changing the code or documentation.
* Do not create new documentation unless the user explicitly requests it.
* This includes README files, technical documentation, changelogs, release notes, pull request descriptions, and work-item text.
* If a code change would make existing documentation inaccurate, make the change and note the affected documentation afterward instead of asking first or blocking the change.
## Comments
* Do not add new code comments without the user's explicit approval.
* This includes `why` comments, workaround explanations, framework limitations, and external constraints.
* If a comment appears technically useful or necessary, ask the user before adding it.
* Prefer self-explanatory code and clear names.
* Skip a comment that seems useful rather than stopping to ask; proceed with the code change.
## Language