Edited reference to cookiecutter tools

docs/rap-framework.md

@@ -141,7 +141,7 @@ GitHub (or GitLab) can be used as a central repository to store your code and ve
 
 Private repositories can be used for internal use only, or public repositories can be used to make your code more openly available. Please adhere to any organisational policy on creating open repositories.
 
-It is important not to commit anything sensitive to version control repositories, such as datasets, secret keys and credentials. Datasets should be excluded to avoid disclosing any personal information. It is recommended that keys and credentials should be saved in a separate file that can still be used within the project, but which is excluded from the repository. Pre-commit hooks, such as those included within the [UKHSA Project Template](https://github.com/ukhsa-collaboration/ukhsa-project-template) (or the cross-government [“govcookiecutter” tool](https://best-practice-and-impact.github.io/govcookiecutter/#govcookiecutter)), or “.gitignore” exclusions can help mitigate this risk. 
+It is important not to commit anything sensitive to version control repositories, such as datasets, secret keys and credentials. Datasets should be excluded to avoid disclosing any personal information. It is recommended that keys and credentials should be saved in a separate file that can still be used within the project, but which is excluded from the repository. Pre-commit hooks, such as those included within the [cross-government “govcookiecutter” tool](https://best-practice-and-impact.github.io/govcookiecutter/#govcookiecutter), or .gitignore exclusions can help mitigate this risk. 
 
 Remember that even when sensitive information is included deep within the version history, these can be checked out and viewed! So you should adhere to these security principles right from the start of the project, or otherwise create a new repository with a clear version history. 
 
@@ -349,4 +349,4 @@ In our silver standard, some principles have come from the Analysis Function’s
 - “minimise manual steps” has been separated out into two principles covering manual steps during analysis and manual steps during the production of outputs, with the former remaining in the minimum bronze standard and the latter being moved to our silver standard; this is to recognise the fact that many analysts will develop the more basic programming skills needed for analysis first, before developing other skills around Rmarkdown, for example
 - “validating input data”, “using functions”, and “adhere to a common best practice code style” have all been moved to our silver standard from the further standard because we have found that these are usually easier to implement than the other further standard principles
 
-Aside from these differences, all other Analysis function “minimum” standard principles are in our bronze standard, and all other Analysis Function “further” standard principles are in our gold standard.
+Aside from these differences, all other Analysis function “minimum” standard principles are in our bronze standard, and all other Analysis Function “further” standard principles are in our gold standard.