> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsiam-developer-guide/cortex-xsiam-development-guide/contributing-content/pull-request-conventions.md).

# Pull request conventions

If you open a GitHub pull request (PR) against the Cortex XSIAM repository, a reviewer from the content team is assigned to the PR and accompanies you through the process of releasing your contribution.

We recommend you check the PR updates often. If you think the process has stalled, feel free to "ping" the assigned reviewer by adding a new comment to the PR with a [mention](https://github.blog/2011-03-23-mention-somebody-they-re-notified/) or reach out in the #demisto-developers channel in our [Slack Community](https://dfircommunity.slack.com/).

We value your contributions. By following our best practices for pull requests, you can help expedite the contribution process.

#### Pull request best practices

Use the following guidelines when working on changes requested by our reviewers.

* Always create PRs from your own fork using a dedicated branch. Do NOT use the `master/main` branch.
* Use clear and brief messages for your commits. See this [article](https://cbea.ms/git-commit/) for good examples.
* Do NOT use force pushes, for example: `git push --force`). If you need to force push, contact us first via the pull request or Slack.
* During the process our reviewers might ask for multiple changes. Work through the entire list and commit all the changes.
* When you push changes to your fork's branch that was used to open the PR, the PR is automatically updated, you don't need to open a new PR. Do NOT open a new PR unless absolutely necessary (i.e. unless asked by the reviewer), as it will make it hard for the reviewer to track their comments.
* The review usually has a summary and several conversations: make sure you address all the comments, including the ones in the summary:

  ![](/files/0W0qlkPwNgRjf0dF62yx)
* When addressing the review's conversations, do NOT mark them as resolved. Write `done` in a comment, so the reviewer can keep track of them.

  ![](/files/zWEMqM5YSbgDiR9t15Ne)
* Once you have pushed all requested changes, please ask for a new review by navigating to Reviewers section in the right sidebar in GitHub and click the ![xsiam-icon.png](/files/xcP3UnBUHTGTq6anvaw6) icon next to the reviewer's name.
* If the branch you'll be using as the basis for the pull request includes more than 50 commits, squash all commits into a single commit before creating the pull request. This makes the git history cleaner and easier for reviewers. Below is an example of a squash merge after consolidating 122 commits into one:

  ```programlisting
  COMMITS=122

  git reset --hard HEAD~$COMMITS

  git merge --squash HEAD@{1}

  git commit -m "squash last $COMMITS into one"
  ```

  Alternatively, you can use a specific commit to squash from:

  ```programlisting
  COMMIT_HASH=0d1ddfc42

  git reset --hard $COMMIT_HASH

  git merge --squash HEAD@{1}

  git commit -m "squash from $COMMIT_HASH into one"
  ```

#### The build process

The commit hooks of the repository automatically run several commands locally on your system, such as [demisto-sdk validate](/demisto-sdk-development-guide/demisto-sdk-guide/demisto-sdk-commands/validate.md), that verify your content is valid before you commit and push the changes to your pull request.

There are also jobs that run automatically on your pull request after every push that validate the changes and run the same tests to verify the contribution can be merged and become part of the content. You see several GitHub Status Checks that help validate that your pull request is according to our standards.

After you push changes, go back to the pull request and check the status of the build after it's completed. Pay special attention to the checks for unit testing and validations.

If the error is unclear or you are in doubt, add a comment to the PR to ask the reviewer or post a question in the #demisto-developers channel on [Slack](https://dfircommunity.slack.com/).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xsiam-developer-guide/cortex-xsiam-development-guide/contributing-content/pull-request-conventions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.