feat: add linkage from dev workflow to static analysis (#1734)

content/en/contribute/code/static-analysis.md

@@ -10,6 +10,8 @@ description: >
 
 All code must pass an eslint check which runs early in the CI cycle and uses the [standard medic eslint configuration](https://github.com/medic/eslint-config).
 
+ESLint has [plugins/integrations](https://eslint.org/docs/latest/use/integrations) for many IDEs that will report linting issues in real-time.
+
 ## Sonar
 
 [Sonar](https://www.sonarsource.com/) static analysis supports development by providing feedback on code quality and security issues. Sonar analysis must pass on all _new code_.

content/en/contribute/code/workflow.md

@@ -12,6 +12,12 @@ Where possible, follow the [coding style guide]({{< ref "contribute/code/style-g
 
 Aim for self-documenting code. Where code cannot be made self-documenting add commenting. Usually comments are useful when they explain why some code exists, and should not be explaining what some code is doing. 
 
+### Code Quality
+
+Several [static analysis tools]({{< ref "contribute/code/static-analysis" >}}) are used to support code quality. These tools are run automatically on every pull request and will fail the build if they find any issues.
+
+For a more efficient feedback loop, developers should run linting scripts locally before pushing code to the repository. Additionally, both [ESLint]({{< ref "contribute/code/static-analysis#eslint" >}}) and [Sonar]({{< ref "contribute/code/static-analysis#during-development" >}}) have IDE plugins that show code issues in real-time. 
+
 ## Issues
 
 Issues are managed in GitHub. Issues should be created in the repository where the changes need to be made. If it is not clear in which repo to open an issue the default should be the `cht-core` repository. If it is a security or sensitive issue it should be opened in the private `medic-projects` repository.