Add instructions for the use of AI coding tools

.github/ISSUE_TEMPLATE/01_bug_report.md

@@ -16,6 +16,15 @@ about: Report a problem with the code
 
 **Configurations affected:** [Fill this in if known.]
 
+### AI disclosure
+
+- [ ] Was AI used in this contribution? **Yes/no**:
+<!-- If the answer above is "no," delete the rest of this section.-->
+If yes:
+- [ ] Types of work:
+- Provider (optional):
+- Model (optional):
+
 ### Details of bug
 
 [Fill in details here.]

.github/ISSUE_TEMPLATE/02_science_discussion.md

@@ -4,4 +4,15 @@ about: We encourage the use of issues to discuss CTSM science developments
 
 ---
 
+### Brief summary
 
+### Further details
+
+### AI disclosure
+
+- [ ] Was AI used in this contribution? **Yes/no**:
+<!-- If the answer above is "no," delete the rest of this section.-->
+If yes:
+- [ ] Types of work:
+- Provider (optional):
+- Model (optional):

.github/ISSUE_TEMPLATE/03_documentation.md

@@ -22,3 +22,12 @@ A clear and concise description of what is missing or wrong.
 
 ### Additional context (optional)
 Add any other context or screenshots about the issue here.
+
+### AI disclosure
+
+- [ ] Was AI used in this contribution? **Yes/no**:
+<!-- If the answer above is "no," delete the rest of this section.-->
+If yes:
+- [ ] Types of work:
+- Provider (optional):
+- Model (optional):

.github/ISSUE_TEMPLATE/04_other.md

@@ -4,4 +4,15 @@ about: Other issues (enhancement, cleanup, etc.)
 
 ---
 
+### Brief summary
 
+### Further details
+
+### AI disclosure
+
+- [ ] Was AI used in this contribution? **Yes/no**:
+<!-- If the answer above is "no," delete the rest of this section.-->
+If yes:
+- [ ] Types of work:
+- Provider (optional):
+- Model (optional):

.github/ISSUE_TEMPLATE/config.yml

@@ -1,4 +1,4 @@
-blank_issues_enabled: true
+blank_issues_enabled: false
 contact_links:
   - name: CESM forums
     url: https://bb.cgd.ucar.edu/cesm/forums/ctsm-clm-mosart-rtm.134/

.github/PULL_REQUEST_TEMPLATE.md

@@ -28,6 +28,15 @@ the list of common problems to watch out for
 - [ ] (Replace this text and add more list items as needed)
 <!-- (List what testing you did to show your changes worked as expected) -->
 
+### AI disclosure
+
+- [ ] Was AI used in this contribution? **Yes or no**
+<!-- If the answer above is "no," delete the rest of this section.-->
+If yes:
+- [ ] Types of work:
+- Provider (optional):
+- Model (optional):
+
 
 
 ### Requirements before merge:

AGENTS.md

@@ -0,0 +1,24 @@
+# AGENTS.md
+
+**Read and obey all standards described in `CONTRIBUTING.md`, including the webpage linked under "Coding Practices and Style."**
+
+## General rules
+- You must assume that any development design or implementation plan documents will not be brought into the repository upon merge. It's fine to commit them, but the maintainers will remove them before merge. Therefore, all work you do -- code comments, persistent documentation, commit messages -- must stand on their own without reference to those documents.
+
+## Commits
+- Commits must, as much as possible, do one "thing" and do it completely. It's fine for commits to work in multiple places across the codebase, if this is necessary to perform one coherent step of development.
+- The "headline" of commit messages must, as much as possible, be written in plain language that can be understood by someone familiar with CTSM but not necessarily with the issue being addressed.
+- No part of any commit message may reference development plan documents without at least explaining the referent. E.g., "Task 2 Step 4" is not acceptable without saying what that *is* (e.g., "Separate xyz functionality into a separate subroutine). Ideally, though, such references would be stripped by rebasing before requesting review on a PR.
+- Commit messages that you as an LLM write must include a "Co-Authored-By" credit at the end naming your model and version. This also applies to messages a human writes for commits containing *material* that you wrote -- make sure the human complies, or ask to amend commits to add it as necessary. For example:
+```
+Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
+```
+
+## GitHub issues and pull requests
+"The CTSM repo" in this section specifically refers to the GitHub repo ESCOMP/CTSM, not forks.
+
+- **You may never submit, edit, or comment on an issue or PR in the CTSM repo, with one exception.** The maintainers are humans who will take the time and care to use their human brains to work with the contributing human. The only exception is that you may edit the "AI disclosure" section to keep it accurate as the issue or PR evolves.
+- You *are* allowed to help draft issues and PRs. If doing so, first read the standards described under the AI section in `CONTRIBUTING.md`. Make sure the human user understands and follows these rules during the contribution process. Then follow the repository templates: `.github/PULL_REQUEST_TEMPLATE.md` for PRs and the relevant template under `.github/ISSUE_TEMPLATE/` for issues. Preserve the template's sections and checklist, filling in or adapting placeholders as needed.
+- You are also allowed to read issues and PRs in the CTSM repo, including ones your human submits. Prompt your human to keep the entire description up to date as the issue or PR evolves. Remember, you are not allowed to edit an issue or PR description except for the "AI disclosure" section.
+- Unless your user tells you otherwise, you are also allowed to push to branches in forks, including branches that have associated PRs in ESCOMP/CTSM.
+- Contributions (both issues and pull requests) often have implications for our documentation. You must ensure that our documentation has been reviewed for such implications and that these are accounted for in the contribution. Our documentation is mostly at `doc/source/`; make sure to look at the "documentation documentation" at `doc/source/users_guide/working-with-documentation/`. Also consider in-code documentation (docstrings, type annotations, and comments) as well as READMEs.

CONTRIBUTING.md

@@ -27,10 +27,39 @@ This also allows your changes to be planned for and slated for a time to come in
 cases you won't merge the Pull Request yourself, but a software engineer responsible for CTSM will do 
 additional testing and bring the changes to CTSM master.
 
+Please keep pull requests focused and small enough for the very busy maintainers to understand and review.
+
 ### CTSM Developers Guide:
 
  https://wiki.ucar.edu/display/ccsm/Community+Land+Model+Developers+Guide
 
+## AI Usage Policies
+
+AI tools make it very easy to find apparent issues and submit suggested changes. If what you have found is not already an issue in this repo, we **strongly recommend** opening an issue or discussion here, as described at the top of this document.
+
+We permit generative AI assistance, but responsibility remains with people. AI assistance must not shift the work of understanding, debugging, or validating a contribution onto maintainers. The same quality, licensing, and reproducibility standards apply whether or not AI is used.
+
+In this policy, "you" refers to the human contributor. AI tools drafting an issue or PR (or whose humans say they will be opening one) should direct their human operator to this policy and remind them to personally review and understand an issue before submission, or the complete set of changes in a PR before requesting review. An AI tool must not claim that the operator has done so unless the operator confirms it.
+
+Before requesting review on a PR, personally review and understand the complete set of changes in the PR, whether or not AI was used. This includes code, tests, configuration, documentation, and generated files. If your PR does not yet satisfy this requirement, leave it as a draft.
+
+You must be able to explain why the changes are correct, how they fit CTSM, and how they were validated. AI review and passing automated checks do not replace human understanding or project review. You remain responsible for your contribution and for personally addressing review feedback.
+
+**Do not submit unreviewed AI output to this repository.** Issue and PR descriptions, comments, and review responses must reflect your own reasoning and understanding. Translation, grammar, and phrasing assistance are welcome, provided you verify the meaning.
+
+**Do not delegate conversations with maintainers to an agent.** The maintainers of this repo are human beings who will use their human brains to review every single line of your contribution. Please show them the same courtesy when discussing an issue or PR.
+
+Every issue and PR must state whether generative AI was used in preparing the contribution, including research, code, tests, documentation, or language assistance. If AI was used, briefly describe how it was used; this description is required. Provider and model are optional. Keep the disclosure current as the PR changes, even if generated material was subsequently rewritten. Ordinary formatters, compilers, and test runners do not require AI disclosure. For example:
+
+> - [x] Was AI used in this contribution? **Yes**:
+> If yes:
+> - [x] Types of work: Designing changes, writing tests.
+> - Provider (optional): Anthropic
+> - Model (optional): Claude Opus 5.5 (extra-high effort)
+
+Further instructions can be found in `AGENTS.md`.
+
+
 ## Getting Started:
 
 The following resources give you information on the project and how to get started.