diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/validate_user_input.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/validate_user_input.yaml
index 7da4ebf..b505911 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/validate_user_input.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/validate_user_input.yaml
@@ -18,7 +18,7 @@ taskflow:
         ```
         {{ result.result }}
         ```
-        Check that the notes contains a section call "User-Controlled input" or similar.
+        Check that the notes contain a section called "User-Controlled input" or similar.
         If the section is missing, then mark the alert as invalid and update the alert results
         with the reason saying that no user input is found.
       toolboxes:
diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/audit_workflow_users.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/audit_workflow_users.yaml
index 741919d..e7d4ca9 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/audit_workflow_users.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/audit_workflow_users.yaml
@@ -17,7 +17,7 @@ taskflow:
       user_prompt: |
         Fetch the file {{ result.user }} from the repo {{ result.repo }}.
         
-        Get the high privileged triggers for the of the workflow in the file {{ result.user }} and check if it is reusable. 
+        Get the high privileged triggers for the workflow in the file {{ result.user }} and check if it is reusable. 
         If it does not contain any high privileged trigger AND it is not a reusable action, then the task is done.
 
         Otherwise, check that the action specified by {{ result.user }} in repo {{ result.repo }} is active.
@@ -34,7 +34,7 @@ taskflow:
         You must mention the fact that {{ result.user }} uses {{ result.action }} in lines {{ result.lines }}
         in the notes.
         You must also include all the permissions granted to the {{ result.user }} action in the notes, and all the triggers of the action.
-        Finally, update the all the alert result that has {{ result.action }} with the results in your notes using `update_all_alert_results_for_flow_graph` with 
+        Finally, update all the alert results that have {{ result.action }} with the results in your notes using `update_all_alert_results_for_flow_graph` with
         your notes as the `results`, {{ result.action }} as the `next` and {{ result.repo }} as the `repo`.
       toolboxes:
         - seclab_taskflows.toolboxes.gh_file_viewer
diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/trigger_analysis.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/trigger_analysis.yaml
index b4f9aae..850133d 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/trigger_analysis.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/trigger_analysis.yaml
@@ -42,7 +42,7 @@ taskflow:
 
         1. Inspect the workflow file to see if any permission is granted to the action. List all the permissions in your notes
         2. Then check and see if the action is using any secrets.
-           IMPORTANT: Do not consider GITHUB_TOKEN as a secret. Include the name of the all the secrets and their line numbers in the notes.
+           IMPORTANT: Do not consider GITHUB_TOKEN as a secret. Include the name of all the secrets and their line numbers in the notes.
 
 
         Take notes while assessing the alert, including the trigger, permissions, and secrets used by the action.
diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/create_issues_actions.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/create_issues_actions.yaml
index fe3f777..52c98f3 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/create_issues_actions.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/create_issues_actions.yaml
@@ -64,7 +64,7 @@ taskflow:
         - seclab_taskflow_agent.personalities.assistant
       exclude_from_context: true
       user_prompt: |
-        Fetch the all the completed alert results from that has the rule `{{ globals.rule }}`.
+        Fetch all the completed alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -180,6 +180,6 @@ taskflow:
         - seclab_taskflow_agent.personalities.assistant
       exclude_from_context: true
       user_prompt: |
-        Fetch the all the invalid alert results from that has the rule `{{ globals.rule }}`.
+        Fetch all the invalid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/review_actions_injection_issues.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/review_actions_injection_issues.yaml
index a171b6a..9034f90 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/review_actions_injection_issues.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/review_actions_injection_issues.yaml
@@ -55,7 +55,7 @@ taskflow:
         {% include 'seclab_taskflows.prompts.triage_taskflows.actions_common.check_dismiss_reason' %}
 
         IMPORTANT:
-        1. If the dismissal reason does not apply the issue, then you must not dismiss the alert. In particular,
+        1. If the dismissal reason does not apply to the issue, then you must not dismiss the alert. In particular,
         DO NOT try to reason about code injection sanitizer beyond the dismissal reason. 
         
         2. A security check has to restrict the permission or privilege of the user, simple checks that 
diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml
index a87b1ed..89067b6 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml
@@ -137,7 +137,7 @@ taskflow:
           echo "The issue title is: ${{ env.ISSUE_TITLE }}"
         ```
         IMPORTANT:
-        However, if envoirnment variables are not set in the `env` section, but are set in the `run` section, then it is vulnerable to code injection:
+        However, if environment variables are not set in the `env` section, but are set in the `run` section, then it is vulnerable to code injection:
         ```
         run: |
           echo "TITLE=${{ github.event.issue.title }}" >> $GITHUB_ENV
@@ -200,13 +200,13 @@ taskflow:
         only consider whether the code at the alert location {{ result.location }} is affected by a sanitizer or a check that takes 
         place before the code injection vulnerability at {{ result.location }}.
 
-        If the sanitizer is still valid include update the alert results with these information using the alert_id {{ result.alert_id }} and repo {{ result.repo }} in the 
-        `update_alert_result` tool with your notes as the `result`. Remember to include the line numbers of the checks or sanitizers in the notes.
+        If the sanitizer is still valid, update the alert results with this information using the alert_id {{ result.alert_id }} and repo {{ result.repo }} in the
+        `update_alert_result` tool with your notes as the `result`. Remember to include the line numbers of the checks or sanitizers in the notes,
         and then set the `valid` field of the alert result to `false` using alert_id {{ result.alert_id }} and repo {{ result.repo }}.
 
         IMPORTANT:
-        You must only based your decision on the present of sanitizer and check and not any other factors. And do not include 
-        comment on any other factors that may affect the code injection vulnerability.
+        You must only base your decision on the presence of sanitizers and checks and not any other factors. And do not include
+        comments on any other factors that may affect the code injection vulnerability.
       toolboxes:
         - seclab_taskflows.toolboxes.gh_file_viewer
         - seclab_taskflows.toolboxes.report_alert_state
@@ -218,7 +218,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results from that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -249,7 +249,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the all the alert results from that has the rule `{{ globals.rule }}`.
+        Fetch all the alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -259,7 +259,7 @@ taskflow:
         Review the information gathered from the audit notes to determine whether this alert is a FP.
       inputs:
         vuln_specifics: |
-          DO NOT look for sanitizers of user input beyond those mentioned in the notes. If the notes does not 
+          DO NOT look for sanitizers of user input beyond those mentioned in the notes. If the notes do not
           mention any sanitizers used on the user input, then assume that the user input is not sanitized, even if
           you think the code is safe from code injection.
   - task:
@@ -269,7 +269,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid the alert results from that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -309,5 +309,5 @@ taskflow:
       uses: seclab_taskflows.taskflows.alert_triage_examples.triage_taskflows.actions_common.check_report
       inputs:
         vuln_specifics: |
-          You decision must be based only on the criteria above, and not any other factors. 
+          Your decision must be based only on the criteria above, and not any other factors.
           DO NOT mark the alert as invalid if you think the code is safe from code injection.
\ No newline at end of file
diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_client_side_xss.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_client_side_xss.yaml
index 4bda59e..002f347 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_client_side_xss.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_client_side_xss.yaml
@@ -53,8 +53,8 @@ taskflow:
         Exploitable means that a remote attacker would be able to inject a malicious script into the web application that would be executed in the context of a user visiting the page.
         This could include a `javascript:` URL, a `<script>` tag, or any other way to inject JavaScript code into the page.
         It also means that the XSS vulnerability is not mitigated by any other code in the repository, such as sanitization or validation of the input.
-        Check if the code tries to sanitize or validate the input. F.ex. if the output is encoded before being sent back. Or if a Regex is used to validate the input.
-        Also check if the Regex only let's true a subset of the provided input.
+        Check if the code tries to sanitize or validate the input. For example, if the output is encoded before being sent back. Or if a Regex is used to validate the input.
+        Also check if the Regex only lets through a subset of the provided input.
         Take note of relevant regex patterns.
         Analyze all Regex patterns used in the code to see if they are effective against cross-site scripting (XSS) attacks. Let's think step by step and explain how the Regex works.
         If you encounter methods used for validation or sanitization, look them up and check if they are effective against cross-site scripting (XSS) attacks.
@@ -75,7 +75,7 @@ taskflow:
 
         If the vulnerable code sink is part of code that retrieves messages from WebSockets e.g. inside `onMessage`,
         the XSS-vulnerability is likely not exploitable as the attacker would need to be able to send a message to the WebSocket
-        (this might be possible if the WebSocket would be used as some sort of chat notifcation system between users).
+        (this might be possible if the WebSocket would be used as some sort of chat notification system between users).
         Take notes while assessing the alert.
         If prompt token count exceeds the given limit note this in the result and mark the task as complete.
         Update the results field of the alert result with your notes using `update_alert_result` with 
@@ -92,7 +92,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -122,7 +122,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -140,7 +140,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_path_injection.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_path_injection.yaml
index 6ef41c4..73e0633 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_path_injection.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_js_ts_path_injection.yaml
@@ -26,7 +26,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the alert results that has the rule `js/path-injection`.
+        Fetch the alert results that have the rule `js/path-injection`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -69,7 +69,7 @@ taskflow:
       async: true
       user_prompt: |
         Check all results whether they contain next steps that need to be taken. If they do, then take those steps.
-        In case code parts (such as methods) were not found previosuly, look them up and change the notes accordingly.
+        In case code parts (such as methods) were not found previously, look them up and change the notes accordingly.
         Update the results field of the alert result with your notes using `update_alert_result` using the updated notes. 
       toolboxes:
         - seclab_taskflows.toolboxes.gh_file_viewer
diff --git a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_untrusted_checkout_critical.yaml b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_untrusted_checkout_critical.yaml
index 85f1f97..7611ebe 100644
--- a/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_untrusted_checkout_critical.yaml
+++ b/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_untrusted_checkout_critical.yaml
@@ -30,7 +30,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the alert results that has the rule `{{ globals.rule }}`.
+        Fetch the alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -45,7 +45,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -99,7 +99,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid alert results from that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -130,7 +130,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the all the alert results from that has the rule `{{ globals.rule }}`.
+        Fetch all the alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
@@ -157,7 +157,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the valid the alert results from that has the rule `{{ globals.rule }}`.
+        Fetch the valid alert results that have the rule `{{ globals.rule }}`.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state
   - task:
diff --git a/src/seclab_taskflows/taskflows/audit/acl_check.yaml b/src/seclab_taskflows/taskflows/audit/acl_check.yaml
index 8af2694..2cf42c1 100644
--- a/src/seclab_taskflows/taskflows/audit/acl_check.yaml
+++ b/src/seclab_taskflows/taskflows/audit/acl_check.yaml
@@ -20,23 +20,23 @@ taskflow:
         Fetch the list of issues for component {{ globals.id }} in repo {{ globals.repo }}. Check if there is any issue 
         that involves access control or authentication. If there isn't any, then your task is finished.
 
-        If there are any authentication or access control that are crucial in determining whether issue is vulnerable or not,
-        then go through these measures and look carefully to see if there is any way to bypass these checks. Also look for 
-        inconsistencies in access controls. The goal of this task is to scrutinize the access control, authentication
-        relevent to the issue. You should limit your audit to those that are involved in the in issue. 
+        If there are any authentication or access controls that are crucial in determining whether the issue is vulnerable or not,
+        then go through these measures and look carefully to see if there is any way to bypass these checks. Also look for
+        inconsistencies in access controls. The goal of this task is to scrutinize the access control and authentication
+        relevant to the issue. You should limit your audit to those that are involved in the issue. 
 
-        Look at the authentication and access control mechanism used in this component. Note that the implementation of 
-        the authentication and access control may well be defined outside of this component. In which case, you need to 
-        look at files in the repo outside of the component. For each end point, take note of 
-        its intended functionality and any access control/authetnication that is applied. When looking at access control,
+        Look at the authentication and access control mechanisms used in this component. Note that the implementation of
+        the authentication and access control may well be defined outside of this component. In which case, you need to
+        look at files in the repo outside of the component. For each endpoint, take note of
+        its intended functionality and any access control/authentication that is applied. When looking at access control,
         do not just check if access control is applied, but note down the exact role/authority that is required.
 
-        Go through the list of access control and authentication that you made earlier, and consider the followings:
-        - Look through end points functionalities and identify those that should require similar level of privilege. For example, 
-        endpoint that modifies data should require similar privilege to endpoints that write to data, but endpoints that only 
-        read data allows lower privilege. Within the group of endpoint, do access control ensure that they have the same privilege?
-        Or do some endpoint required higher privilege than others? Take a note of such inconsistencies stating clearly 
-        which endpoints should require similar privilege but doesn't. Then decide whether it is 
+        Go through the list of access control and authentication that you made earlier, and consider the following:
+        - Look through endpoint functionalities and identify those that should require similar levels of privilege. For example,
+        endpoints that modify data should require similar privilege to endpoints that write to data, but endpoints that only
+        read data allow lower privilege. Within the group of endpoints, does access control ensure that they have the same privilege?
+        Or do some endpoints require higher privilege than others? Take note of such inconsistencies stating clearly
+        which endpoints should require similar privilege but don't. Then decide whether it is
         a security issue or not.
 
         - Are there other ways to bypass ownership/access control checks via IDOR etc.?
diff --git a/src/seclab_taskflows/taskflows/audit/audit_issue.yaml b/src/seclab_taskflows/taskflows/audit/audit_issue.yaml
index d1fb7ff..52706fe 100644
--- a/src/seclab_taskflows/taskflows/audit/audit_issue.yaml
+++ b/src/seclab_taskflows/taskflows/audit/audit_issue.yaml
@@ -19,19 +19,19 @@ taskflow:
       user_prompt: |
         Fetch the issues in component with id {{ globals.id }} in the repo {{ globals.repo }}. Audit the second issue that was suggested.
 
-        The issues suggested are have not been probably verified and are only suggested because they are common issues in these types of 
-        application. You task is to audit the source code to check if this type of issues is present.
+        The issues suggested have not been properly verified and are only suggested because they are common issues in these types of
+        applications. Your task is to audit the source code to check if this type of issue is present.
 
-        You need to take into account of the intention and threat model of the component in component notes to determine if an issue 
-        is a valid security issue or if it is an intended functionality. You can fetch entry points, web entry points and user actions 
+        You need to take into account the intention and threat model of the component in the component notes to determine if an issue
+        is a valid security issue or if it is an intended functionality. You can fetch entry points, web entry points and user actions
         to help you determine the intended usage of the component.
 
         For example, the application may be a dashboard frontend that allow user to query various databases, in this case, being able 
         to query these databases is not considered a security issue or info leak.
 
-        Or an application may be an Admin UI intended for an admin user to perform high privilege actions. In this case, the absense of
-        authentication or bypasses would be a security issue. However, issues that are reachable only after authentication are not 
-        generally considered security issue, unless it has unintended consequences or are XSS, CSRF type issues.
+        Or an application may be an Admin UI intended for an admin user to perform high privilege actions. In this case, the absence of
+        authentication or bypasses would be a security issue. However, issues that are reachable only after authentication are not
+        generally considered security issues, unless they have unintended consequences or are XSS, CSRF type issues.
 
         Do not consider scenarios where authentication is bypassed via stolen credential etc. We only consider situations that are 
         achievable from within the source code itself.
diff --git a/src/seclab_taskflows/taskflows/audit/audit_sanitizers.yaml b/src/seclab_taskflows/taskflows/audit/audit_sanitizers.yaml
index d3d1867..68f8d90 100644
--- a/src/seclab_taskflows/taskflows/audit/audit_sanitizers.yaml
+++ b/src/seclab_taskflows/taskflows/audit/audit_sanitizers.yaml
@@ -35,7 +35,7 @@ taskflow:
         Also do not include issues that require system to be already compromised, such as issues that rely on malicious 
         configurations etc.
 
-        For each scenario, consider what privilege and access does the attacker need to gain and do not include issues that 
+        For each scenario, consider what privilege and access the attacker needs to gain and do not include issues that
         require high privilege or access to the system.
 
         Store a component issue entry for each type of issue identified.
diff --git a/src/seclab_taskflows/taskflows/audit/classify_application.yaml b/src/seclab_taskflows/taskflows/audit/classify_application.yaml
index 563786d..9ba4949 100644
--- a/src/seclab_taskflows/taskflows/audit/classify_application.yaml
+++ b/src/seclab_taskflows/taskflows/audit/classify_application.yaml
@@ -24,19 +24,19 @@ taskflow:
         can you tell me what type of application this repo is and what kind of security boundary it has.
         Based on this, identify the components that are most likely to have security problems. For each component, 
         state the precise component id, and the location. (You can group multiple components that serves a single functionalities together)
-        State the most likely security problems in these components. For example, an Admin UI/dashboard may be susceptible to client side 
-        Javascript vulnerabilities such as XSS, CSRF. 
-        An authentication/authorization component may be susceptible to IDOL, bypasses etc.
-        Components that grants user accesses to data may require access control or authentication.
+        State the most likely security problems in these components. For example, an Admin UI/dashboard may be susceptible to client side
+        Javascript vulnerabilities such as XSS, CSRF.
+        An authentication/authorization component may be susceptible to IDOR, bypasses etc.
+        Components that grant user access to data may require access control or authentication.
 
         We're looking for more concrete and serious security issues that affects system integrity or 
         lead to information leak, so please do not include issues like brute force, Dos, log injection etc.
 
-        Also do not include issues that requires system to be already compromised, such as issues that relies on maliciious 
+        Also do not include issues that require the system to be already compromised, such as issues that rely on malicious
         configurations etc.
 
-        For each scenario, consider what privilege and access does the attacker needs to gain and do not include issues that 
-        requires high privilege or access to the system.
+        For each scenario, consider what privilege and access the attacker needs to gain and do not include issues that
+        require high privilege or access to the system.
 
         Store a component issue entry for each type of issue identified.
       toolboxes:
diff --git a/src/seclab_taskflows/taskflows/audit/classify_application_local.yaml b/src/seclab_taskflows/taskflows/audit/classify_application_local.yaml
index d6423c4..545244b 100644
--- a/src/seclab_taskflows/taskflows/audit/classify_application_local.yaml
+++ b/src/seclab_taskflows/taskflows/audit/classify_application_local.yaml
@@ -33,53 +33,53 @@ taskflow:
 
         {{ result.notes }}
 
-        Fetch the entry points and web entry points the component, then the user actions of this component.
+        Fetch the entry points and web entry points of the component, then the user actions of this component.
         Based on the entry points, web entry points, components, user actions and README.md and if available, SECURITY.md in the {{ globals.repo }},
         can you tell me what type of application this repo is and what kind of security boundary it has.
-        Based on this, determine whether the components that is likely to have security problems. 
+        Based on this, determine whether the component is likely to have security problems. 
         
-        Identify the most likely security problems in the component. You task is is not to carry out a full audit, but to 
-        identify the main risk in the component so that further analysis can be carried out. 
-        Do not be too specific about an issue, but rather craft your report based on the general functionality and type of 
+        Identify the most likely security problems in the component. Your task is not to carry out a full audit, but to
+        identify the main risk in the component so that further analysis can be carried out.
+        Do not be too specific about an issue, but rather craft your report based on the general functionality and type of
         the component and state the most likely risk, instead of risk specific to the implementation of the component.
-        However, you should still 
-        take care not to include issues that are of low severity or requires unrealistic attack scenario such as misconfiguration
+        However, you should still
+        take care not to include issues that are of low severity or require unrealistic attack scenarios such as misconfiguration
         or an already compromised system.
 
         Base your decision on:
-        - Is this component likely to take untrusted user input? For example, remote web request or IPC, RPC calls?
-        - What is the intended purpose of this component and its functionality? Does it allow high privileged action?
-        Is it intended to provide such functionalities for all user? Or is there complex access control logic involved?
+        - Is this component likely to take untrusted user input? For example, remote web requests or IPC, RPC calls?
+        - What is the intended purpose of this component and its functionality? Does it allow high privileged actions?
+        Is it intended to provide such functionalities for all users? Or is there complex access control logic involved?
         - The component itself may also have its own `README.md` (or a subdirectory of it may have a `README.md`). Take 
         a look at those files to help understand the functionality of the component.
 
-        For example, an Admin UI/dashboard may be susceptible to client side Javascript vulnerabilities such as XSS, CSRF. 
-        An authentication/authorization component may be susceptible to IDOL, bypasses etc.
-        Components that grants user accesses to data may require access control or authentication. It may also require 
-        ownership check. For example, 
-        a web frontend may allow users to access their own content and admin to access all content, but users should not 
+        For example, an Admin UI/dashboard may be susceptible to client side Javascript vulnerabilities such as XSS, CSRF.
+        An authentication/authorization component may be susceptible to IDOR, bypasses etc.
+        Components that grant user access to data may require access control or authentication. It may also require
+        ownership checks. For example,
+        a web frontend may allow users to access their own content and admins to access all content, but users should not
         be able to access another users' content in general.
 
         We're looking for more concrete and serious security issues that affects system integrity or 
         lead to information leak, so please do not include issues like brute force, Dos, log injection etc.
 
-        Also do not include issues that requires system to be already compromised, such as issues that relies on maliciious 
+        Also do not include issues that require the system to be already compromised, such as issues that rely on malicious
         configurations, stolen credentials, misconfiguration etc.
 
-        For each scenario, consider what privilege and access does the attacker needs to gain and do not include issues that 
-        requires high privilege or access to the system.
+        For each scenario, consider what privilege and access the attacker needs to gain and do not include issues that
+        require high privilege or access to the system.
 
-        Your task is to identify risk rather than properly audit and find security issue. Do not based look too much into 
-        the implementation or scrutinize the security measures such as access control and sanitizers at this stage. 
-        Instead, report more general risk that are associated with the type of component 
+        Your task is to identify risk rather than properly audit and find security issues. Do not look too much into
+        the implementation or scrutinize the security measures such as access control and sanitizers at this stage.
+        Instead, report more general risks that are associated with the type of component
         that you are looking at. 
 
         It is not your task to audit the security measures, but rather just to identify the risks and suggest some issues 
         that is worth auditing.
 
-        Reflect on your notes and check that the attack scenario meets the above requirements. Exclude low severity or 
-        issues that requires unrealistic circumstances such as misconfiguration or stolen credentials etc. 
-        It is ok to conclude that the component is not likely to have security issue.
+        Reflect on your notes and check that the attack scenario meets the above requirements. Exclude low severity issues or
+        issues that require unrealistic circumstances such as misconfiguration or stolen credentials etc.
+        It is ok to conclude that the component is not likely to have security issues.
 
         If you think the issues satisfy the criteria, store a component issue entry for each type of issue identified.
       toolboxes:
diff --git a/src/seclab_taskflows/taskflows/audit/filter_severity.yaml b/src/seclab_taskflows/taskflows/audit/filter_severity.yaml
index 50d0655..ac91465 100644
--- a/src/seclab_taskflows/taskflows/audit/filter_severity.yaml
+++ b/src/seclab_taskflows/taskflows/audit/filter_severity.yaml
@@ -38,29 +38,29 @@ taskflow:
         {{ result.notes }}
 
         Determine the low severity results based on the following criteria:
-        - blind SSRF that has limited on the information it discloses. For example, an SSRF that only gives a different 
+        - blind SSRF that has limited information it discloses. For example, an SSRF that only gives a different
         HTTP status for a specific type of endpoint and rejects all other endpoints (e.g. the endpoint must respond with a certain type of payload), and does not disclose any information other than the HTTP status code.
-        - Path traversal or partial path traversal that can only read access to a specific directory with limited types of files (e.g. it can only access log files, or it can only access files with a specific extension).
+        - Path traversal or partial path traversal that can only provide read access to a specific directory with limited types of files (e.g. it can only access log files, or it can only access files with a specific extension).
         - Path traversal or partial path traversal that only discloses the existence of files or directories, and does not disclose any additional information about the file or directory.
         - Information disclosure that only discloses whether a specific condition is true, or some 
         id number, publicly available resources, such as source code files or documentation,
         and does not disclose any additional information. For example, an information disclosure that only discloses whether a specific user exists, 
         or an information disclosure that only discloses whether a specific issue id exists in the system.
-        - Issues that requires a malicious admin users to exploit during installation, configuration or other 
-        set up process. 
-        - When running CLI tools or installers, we assume the user already has control on the device. 
-        Any issues that only allows a local user to gain access of the device with running these tools or during installation 
-        is considered low severity.
+        - Issues that require malicious admin users to exploit during installation, configuration or other
+        setup processes.
+        - When running CLI tools or installers, we assume the user already has control of the device.
+        Any issues that only allow a local user to gain access to the device when running these tools or during installation
+        are considered low severity.
         However, do not exclude issues in installation or configuration that can be exploited by non-admin users.
         - CSRF or XSS issues that can only be exploited during a very specific time window. For example, 
         CSRF or XSS that can only be exploited during the installation process.
         - Stored XSS that requires an admin user to upload malicious contents.
-        - Issue with very limited impact, such as 
+        - Issues with very limited impact, such as
         forcing a user to log out, rate limiting, DoS issues.
-        - Misclassified issues that does not have a valid attack scenario or impact.
-        - Issues that requires knowledge of the victim's private information (e.g. secret tokens, private keys, credentials)
+        - Misclassified issues that do not have a valid attack scenario or impact.
+        - Issues that require knowledge of the victim's private information (e.g. secret tokens, private keys, credentials)
         in order to exploit.
-        - Issues that requires physical access to the device or system, or sharing a device with the victim.
+        - Issues that require physical access to the device or system, or sharing a device with the victim.
         - Blind SQL injection that does not return any data, and only returns a different HTTP status code for a specific type of endpoint, and does not disclose any information other than the HTTP status code.
 
         If you decided to reject an issue, provide the reason, and then 
diff --git a/src/seclab_taskflows/taskflows/audit/gather_web_entry_point_info.yaml b/src/seclab_taskflows/taskflows/audit/gather_web_entry_point_info.yaml
index 04c84f5..3bca059 100644
--- a/src/seclab_taskflows/taskflows/audit/gather_web_entry_point_info.yaml
+++ b/src/seclab_taskflows/taskflows/audit/gather_web_entry_point_info.yaml
@@ -18,10 +18,10 @@ taskflow:
       agents:
         - seclab_taskflows.personalities.web_application_security_expert
       user_prompt: |
-        For the repo {{ globals.repo }} iterate over all entry points and and check if they are
+        For the repo {{ globals.repo }} iterate over all entry points and check if they are
         reachable as a server endpoint.
-        For this check the noted `file` and it's line using the file viewer.
-        Then note it's path, HTTP method and note any middlewares used. Also note which roles are
+        For this check the noted `file` and its line using the file viewer.
+        Then note its path, HTTP method and note any middlewares used. Also note which roles are
         allowed to call it. Note which kind of authentication is required for that endpoint.
         For each entry point identified as a web endpoint create a new web entry point using
         the information gathered.
diff --git a/src/seclab_taskflows/taskflows/audit/gather_web_entry_point_info_local.yaml b/src/seclab_taskflows/taskflows/audit/gather_web_entry_point_info_local.yaml
index 6475d2b..6f75b71 100644
--- a/src/seclab_taskflows/taskflows/audit/gather_web_entry_point_info_local.yaml
+++ b/src/seclab_taskflows/taskflows/audit/gather_web_entry_point_info_local.yaml
@@ -32,12 +32,12 @@ taskflow:
       user_prompt: |
         The component has component_id {{ result.app_id }} and location {{ result.location }} in the repo {{ result.repo }}.
         Fetch the entry points of the component and for each entry point, check if this entry point is a server endpoint.
-        If it is reachble as a server endpoint, then you need to find the following by looking through the relevant files:
-        - The routing path that reaches this entry point 
+        If it is reachable as a server endpoint, then you need to find the following by looking through the relevant files:
+        - The routing path that reaches this entry point
         - HTTP method
-        - Note any middlewares used. 
-        - Also note which roles are allowed to call it. Note which kind of authentication is required for that endpoint. It is possible 
-        that the entry point does not have require any authentication. In which case, you can leave both roles and auth fields empty.
+        - Note any middlewares used.
+        - Also note which roles are allowed to call it. Note which kind of authentication is required for that endpoint. It is possible
+        that the entry point does not require any authentication. In which case, you can leave both roles and auth fields empty.
 
         For each entry point identified as a web endpoint create a new web entry point using
         the information gathered.
diff --git a/src/seclab_taskflows/taskflows/audit/identify_applications.yaml b/src/seclab_taskflows/taskflows/audit/identify_applications.yaml
index 0fd765f..93709d4 100644
--- a/src/seclab_taskflows/taskflows/audit/identify_applications.yaml
+++ b/src/seclab_taskflows/taskflows/audit/identify_applications.yaml
@@ -30,8 +30,8 @@ taskflow:
         - seclab_taskflows.personalities.web_application_security_expert
       user_prompt: |
         Inspect {{ globals.repo }} and determine its function. Determine whether the repo is a framework library,
-        or a web application etc. For repo that may contain multiple applications, determine the purpose of each 
-        application and the directories of each application. Repo can also be a library but contains actual applications, for 
+        or a web application etc. For repos that may contain multiple applications, determine the purpose of each
+        application and the directories of each application. Repos can also be libraries but contain actual applications, for
         example, a web server and admin UI etc. that are not for testing or examples.
         
         Apart from source code, it is also useful to look at the README.md and documentations in 
@@ -65,7 +65,7 @@ taskflow:
       async: true
       max_steps: 100
       name: entry point analysis
-      description: Identify entry points that allows untrusted users to interact with the component.
+      description: Identify entry points that allow untrusted users to interact with the component.
       agents:
         - seclab_taskflows.personalities.web_application_security_expert
       user_prompt: |
@@ -84,9 +84,9 @@ taskflow:
 
         For application components, you should consider the following:
 
-        Does this application consumes untrusted input, for example, web request? Or does it interact with 
-        other applications and can take input from them? User supplied arguments, 
-        configuration files, web request from hardcoded url or environment variables are not considered untrusted 
+        Does this application consume untrusted input, for example, web requests? Or does it interact with
+        other applications and can take input from them? User supplied arguments,
+        configuration files, web requests from hardcoded URLs or environment variables are not considered untrusted
         input. 
         
         However, if user arguments are pointing to some untrusted resources, then they can be considered as 
@@ -95,8 +95,8 @@ taskflow:
 
         ## Library
 
-        For library code, identify the functions that are exposed to a library user. Consider the library user 
-        as trusted and instead focus on functionalities that consumes untrusted input when they are used for 
+        For library code, identify the functions that are exposed to a library user. Consider the library user
+        as trusted and instead focus on functionalities that consume untrusted input when they are used for 
         building applications. 
         
         Ignore applications within the library such as default UI, etc. as these are going 
diff --git a/src/seclab_taskflows/taskflows/audit/identify_applications_local.yaml b/src/seclab_taskflows/taskflows/audit/identify_applications_local.yaml
index 1953886..9476318 100644
--- a/src/seclab_taskflows/taskflows/audit/identify_applications_local.yaml
+++ b/src/seclab_taskflows/taskflows/audit/identify_applications_local.yaml
@@ -33,8 +33,8 @@ taskflow:
         - seclab_taskflows.personalities.web_application_security_expert
       user_prompt: |
         Inspect {{ globals.repo }} and determine its function. Determine whether the repo is a framework library,
-        or a web application etc. For repo that may contain multiple applications, determine the purpose of each 
-        application and the directories of each application. Repo can also be a library but contains actual applications, for 
+        or a web application etc. For repos that may contain multiple applications, determine the purpose of each
+        application and the directories of each application. Repos can also be libraries but contain actual applications, for
         example, a web server and admin UI etc. that are not for testing or examples.
 
         Be granular when identifying components. Even if the repo is a library, do not store it as a single component.
@@ -43,7 +43,7 @@ taskflow:
         often more granular components that represents different functionalities. Inspect file content if necessary 
         to get an idea of the functionality of the component.
 
-        For web application, each component should consists of a single web service/server.
+        For web applications, each component should consist of a single web service/server.
         
         Apart from source code, it is also useful to look at the README.md and documentations in 
         the repo.
@@ -95,9 +95,9 @@ taskflow:
 
         For application components, you should consider the following:
 
-        Does this application consumes untrusted input, for example, web request? Or does it interact with 
-        other applications and can take input from them? User supplied arguments, 
-        configuration files, web request from hardcoded url or environment variables are not considered untrusted 
+        Does this application consume untrusted input, for example, web requests? Or does it interact with
+        other applications and can take input from them? User supplied arguments,
+        configuration files, web requests from hardcoded URLs or environment variables are not considered untrusted
         input. 
         
         However, if user arguments are pointing to some untrusted resources, then they can be considered as 
@@ -159,7 +159,7 @@ taskflow:
       async: true
       max_steps: 100
       name: user actions analysis
-      description: Identify actions that untrusted users are allowed performed the component.
+      description: Identify actions that untrusted users are allowed to perform on the component.
       agents:
         - seclab_taskflows.personalities.web_application_security_expert
       user_prompt: |
@@ -168,16 +168,16 @@ taskflow:
 
         {{ result.notes }}
 
-        Analyze the actions that an untrusted user is allowed to perform. The purpose of this task is not 
-        about the security of the source code, but rather get an understanding of the purpose of the component and 
+        Analyze the actions that an untrusted user is allowed to perform. The purpose of this task is not
+        about the security of the source code, but rather to get an understanding of the purpose of the component and
         what an untrusted user should be allowed to do under the intention of the component.
-        For example, the component may have an api that allows an untrusted user to run aribitrary command. In this 
-        case, the intention and purpose of the component is for user to run arbitrary command, and so the user action in 
+        For example, the component may have an API that allows an untrusted user to run arbitrary commands. In this
+        case, the intention and purpose of the component is for users to run arbitrary commands, and so the user action in
         this case is arbitrary code execution. 
 
-        Similarly, an api may allow a user to read and write files to a specific directory. In this case the intention and 
-        the user action is to read and write to restricted directory. This is different to allowing a user read and write 
-        to any directories. Be precise in these details when looking at user action.
+        Similarly, an API may allow a user to read and write files to a specific directory. In this case the intention and
+        the user action is to read and write to a restricted directory. This is different from allowing a user to read and write
+        to any directories. Be precise in these details when looking at user actions.
 
         Do not consider security risk or potential bypasses or any potential privilege escalations that is outside of the 
         intended use. Focus only on the intended use here.
@@ -192,8 +192,8 @@ taskflow:
         
         For application components, you should consider the following:
 
-        What actions can a user perform using the application? Can they exectue arbitrary code? Can they 
-        make arbitrary web request? Can they read any local file? Consider restrictions that are placed on the actions 
+        What actions can a user perform using the application? Can they execute arbitrary code? Can they
+        make arbitrary web requests? Can they read any local file? Consider restrictions that are placed on the actions
         that a user can perform using the application, and what actions the user should not be allowed to do
         when using the application.
 
@@ -207,14 +207,14 @@ taskflow:
         application library may provide functionalities for the library user to run arbitrary script to configure 
         the application. These are not considered "allowed actions" from an untrusted user point of view.
 
-        However, if a library exposes a REST api that allows arbitrary files to be read by unauthenticated users, 
-        then it reading arbitrary files is consider an "allowed" activity. Note any "allow" activity and how 
+        However, if a library exposes a REST API that allows arbitrary files to be read by unauthenticated users,
+        then reading arbitrary files is considered an "allowed" activity. Note any "allow" activity and how
         they are exposed to untrusted users, referencing the file and function in detail.
 
-        Ignore applications within the library such as default UI, etc. as these are going 
+        Ignore applications within the library such as default UI, etc. as these are going
         to be analyzed separately. Focus on the library code.
 
-        Store an user_action entry stating precising the file and line number where the allowed action is performed, and
+        Store a user_action entry stating precisely the file and line number where the allowed action is performed, and
         provide notes about the action.
 
         Note that line number has to be integer. If an user action spans multiple lines, then use the first line as the line 
diff --git a/src/seclab_taskflows/taskflows/audit/inspect_issue.yaml b/src/seclab_taskflows/taskflows/audit/inspect_issue.yaml
index 0461c74..ea1b917 100644
--- a/src/seclab_taskflows/taskflows/audit/inspect_issue.yaml
+++ b/src/seclab_taskflows/taskflows/audit/inspect_issue.yaml
@@ -17,7 +17,7 @@ taskflow:
       model: code_analysis
       user_prompt: |
         Fetch the components in {{ globals.repo }} and then identify the one where {{ globals.location }}
-        belong. Give me the id of this component, then. Fetch the issues in this component in the repo {{ globals.repo }}. Give a summary of each type of issue in this
+        belongs. Give me the ID of this component. Fetch the issues in this component in the repo {{ globals.repo }}. Give a summary of each type of issue in this
         component.
       toolboxes:
         - seclab_taskflows.toolboxes.repo_context