Document the GitHub-native contribution workflow

.github/CODEOWNERS

@@ -0,0 +1,28 @@
+# CODEOWNERS requests review from verified write-access owners for core changes.
+# Repository rules determine whether an approval is enforced.
+
+/CSharpMath/ @Happypig375 @charlesroddie @FoggyFinder
+/CSharpMath.Core.Tests/ @Happypig375 @charlesroddie @FoggyFinder
+/CSharpMath.Rendering/ @Happypig375 @charlesroddie @FoggyFinder
+/CSharpMath.Rendering.Tests/ @Happypig375 @charlesroddie @FoggyFinder
+/CSharpMath.Rendering.Tests.FSharp/ @Happypig375 @charlesroddie @FoggyFinder
+/CSharpMath.Rendering.Text.Tests/ @Happypig375 @charlesroddie @FoggyFinder
+/CSharpMath.SkiaSharp/ @Happypig375 @charlesroddie @FoggyFinder
+
+# Cross-cutting solution, build, workflow, review, and security policy files.
+/CSharpMath.slnx @Happypig375 @charlesroddie @FoggyFinder
+/global.json @Happypig375 @charlesroddie @FoggyFinder
+/.editorconfig @Happypig375 @charlesroddie @FoggyFinder
+/NuGet.Config @Happypig375 @charlesroddie @FoggyFinder
+/.gitmodules @Happypig375 @charlesroddie @FoggyFinder
+/.gitattributes @Happypig375 @charlesroddie @FoggyFinder
+/Directory.Build.props @Happypig375 @charlesroddie @FoggyFinder
+/Directory.Build.targets @Happypig375 @charlesroddie @FoggyFinder
+/.github/release-drafter.yml @Happypig375 @charlesroddie @FoggyFinder
+/.github/workflows/ @Happypig375 @charlesroddie @FoggyFinder
+/.github/CODEOWNERS @Happypig375 @charlesroddie @FoggyFinder
+/.github/PULL_REQUEST_TEMPLATE.md @Happypig375 @charlesroddie @FoggyFinder
+/AGENTS.md @Happypig375 @charlesroddie @FoggyFinder
+/Contributing.md @Happypig375 @charlesroddie @FoggyFinder
+/SECURITY.md @Happypig375 @charlesroddie @FoggyFinder
+/ReleaseProcedure.txt @Happypig375 @charlesroddie @FoggyFinder

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,23 @@
+## Summary
+
+<!-- Use a concise title and give a simple description of what changes and why. Keep this focused on behavior a reviewer can verify. -->
+
+## Related issue
+
+<!-- Use "Fixes #123" for complete fixes, or link the tracking issue without a closing keyword for partial work. -->
+
+## Validation
+
+<!-- List the focused tests and broader checks you ran. Include new or updated rendering baselines when applicable. -->
+
+## Added code and maintenance
+
+<!-- Disclose added code, complexity, and ongoing maintenance. Note public API, rendering, serialization, platform, or migration effects. Write "None" when there are none. -->
+
+## Review
+
+<!-- Name the automated or AI review actually used (do not assume GitHub Copilot is available), and summarize findings and fixes. Write "None" when none was used. -->
+
+## Human judgment
+
+<!-- Flag whether human judgment is needed for feature fit, security, public API, or maintainability. Explain briefly, or write "No". -->

AGENTS.md

@@ -0,0 +1,20 @@
+# Coding-agent guidance
+
+Follow [Contributing.md](Contributing.md) and [SECURITY.md](SECURITY.md), including
+their review policy. Keep pull-request titles concise and descriptions simple. Run
+focused validation relevant to the change, inspect the diff and repository for
+accidentally exposed secrets without reproducing suspected secrets, and disclose the
+actual automated or AI review used and its findings and fixes. Do not assume GitHub
+Copilot is available.
+
+Changes to CSharpMath core/editor, CSharpMath.Rendering, CSharpMath.SkiaSharp, their
+corresponding tests, or cross-cutting build, release, review, or security
+infrastructure require human review. Humans also decide significant feature-fit and
+maintainability questions and should check obvious and security mistakes.
+
+Periphery changes (Evaluation/symbolic algebra, other platform frontends or adapters,
+examples, benchmarks, and isolated tests) are ready without human GitHub review only
+when relevant CI is green, a satisfactory independent LLM review has no unresolved
+findings, and no core, public-API, security, release, or cross-cutting concern is
+involved. Never claim that any model can never leak secrets; use safe handling and
+escalation instead.

Contributing.md

@@ -14,6 +14,26 @@ Never get slowed down by dying platforms (e.g. Silverlight).
 Transparency
 ------------
 New issues and pull requests should be responded in a short time.
-Use appropriate status labels when needed.
-Avoid having stale open issues without status labels.
-Always label resolutions to closed issues so future readers can know what happened.
+Keep issues for reproducible bugs and concrete, actionable work. Use Discussions for
+questions, ideas, and ongoing conversations that do not yet have an implementation
+scope.
+
+Use labels to classify the type, area, and impact of work, rather than to duplicate
+workflow state. Use draft pull requests for work in progress, milestones for release
+commitments, and native sub-issues and dependencies for larger efforts. When closing
+an issue without a merged change, choose the appropriate GitHub state reason so
+future readers can distinguish completed work from work that is not planned.
+
+Review policy
+-------------
+Core changes are changes to CSharpMath core/editor, CSharpMath.Rendering,
+CSharpMath.SkiaSharp, their corresponding tests, or cross-cutting build, release,
+review, or security infrastructure. Core changes require human review.
+
+Periphery includes symbolic algebra/Evaluation, other platform frontends and adapters,
+examples, benchmarks, and isolated tests for those areas. A periphery change may
+proceed without human GitHub review only when relevant CI is green, a satisfactory
+independent LLM review has no unresolved findings, and it does not involve core code,
+a public API, security, release, or another cross-cutting concern. Humans decide
+significant feature-fit and maintainability questions and remain important for obvious
+or security mistakes.