chore: add plugins settings + remove git instructions

core/instructions/commits.md

@@ -1,78 +0,0 @@
-<!--
-<type>(<scope>): <concise summary>
-Required.
-
-Purpose:
-- Quickly communicates the intent when scanning `git log`.
-- Follow Conventional Commits for consistency and tooling.
-- Describe the intended outcome, not the implementation.
-
-Examples:
-feat(auth): support OAuth device flow
-fix(cache): prevent stale session reuse
-refactor(api): simplify request validation
--->
-
-## Why
-<!--
-Explain why this change exists.
-
-This is the most valuable part of the commit because the code diff
-already shows WHAT changed. Future maintainers (human or AI) often
-need to understand WHY the change was made.
-
-Include, where applicable:
-- Problem being solved
-- User or business need
-- Bug or root cause
-- Important context that is not visible in the code
-
-Omit if the reason is immediately obvious.
--->
-
-## Implementation Notes
-<!--
-Capture decisions that are difficult to infer from the code.
-
-Useful information includes:
-- Why this approach was chosen
-- Important assumptions or invariants
-- Constraints imposed by external systems
-- Tradeoffs or intentional compromises
-- Non-obvious implementation details
-- Workarounds or temporary solutions
-
-Do NOT describe the diff ("renamed X", "added Y", etc.).
-The code already documents that.
-Omit if there is nothing worth preserving.
--->
-
-## Impact
-<!--
-Document effects that future developers should know.
-
-Examples:
-- Behavior changes
-- Breaking changes
-- Performance implications
-- Security considerations
-- Migration or deployment requirements
-- Compatibility concerns
-- Follow-up work or known limitations
-
-Omit if there are no noteworthy impacts.
--->
-
----
-# References
-<!-- Git Trailers:  Structured metadata for traceability and tooling. Use only the trailers that apply. -->
-
-Fixes:
-Refs:
-ADR:
-RFC:
-Design:
-Co-authored-by:
-Reviewed-by:
-Signed-off-by:
-BREAKING CHANGE:

core/instructions/git.md

@@ -1,16 +0,0 @@
-# Git conventions
-
-- Never skip hooks with `--no-verify`. Hooks are the automated QA gate; bypassing them breaks the pipeline.
-- Never force-push `main` or `master`.
-- Keep commits atomic. Each commit should represent one logical, independently reviewable and reversible change.
-- Ensure every commit leaves the repository in a working state (buildable/testable where practical).
-- Commit messages explain **why**, not **what**. The diff already documents what changed.
-- Never commit secrets, credentials, or environment-specific config.
-- Use Conventional Commits (`feat:`, `fix:`, `docs:`, `chore:`, `refactor:`, `test:`, etc.).
-- Reference related issues, ADRs or design documents using Git trailers when applicable.
-
-## Submodules
-
-- When working with submodules: commit and push the submodule first, then update and push the parent repo. Pushing the parent while the submodule commit doesn't exist on the remote breaks `git submodule update` for anyone who pulls.
-- Always use `rtk git` for parent repo operations; drop into the submodule directory for submodule-specific git commands.
-- After adding a submodule, check `git status` in both the parent and the submodule — a `-dirty` flag means the submodule has uncommitted local changes that need to be committed before the parent pointer is updated.