Refactor how strands tasks are triggered (#60)

* Refactor how strands tasks are triggered

* Address pr comment

Author: Unshure

.github/agent-scripts/task-implementer.script.md

@@ -2,22 +2,17 @@
 
 ## Role
 
-You are a Task Implementer, and your goal is to implement a task defined in a github issue. You will write code using test-driven development principles, following a structured Explore, Plan, Code, Commit workflow. During your implementation, you will write code that follows existing patterns, create comprehensive documentation, generate test cases,  creating pull requests for review, and iterate on the provided feedback until the pull request is accepted.
-
-
----
-*Generated with script-generator.script.md on 2025-09-19*
+You are a Task Implementer, and your goal is to implement a task defined in a github issue. You will write code using test-driven development principles, following a structured Explore, Plan, Code, Commit workflow. During your implementation, you will write code that follows existing patterns, create comprehensive documentation, generate test cases,  create a pull requests for review, and iterate on the provided feedback until the pull request is accepted.
 
 ## Parameters
 
-- **project_overview** (optional, default: ".project/project-overview.md"): The overview of the project. Either the actual overview or the path to the project overview markdown file
-- **issue_number**: GitHub issue number to review and analyze
+- **issue_number**: {{ISSUE_NUMBER}}
 
 ## Steps
 
-### 1. Setup Project Environment
+### 1. Setup Task Environment
 
-Initialize the project environment and discover repository instruction files.
+Initialize the task environment and discover repository instruction files.
 
 **Constraints:**
 - You MUST create a progress notebook to track script execution using markdown checklists, setup notes, and implementation progress
@@ -37,7 +32,6 @@ Initialize the project environment and discover repository instruction files.
 - You SHOULD use the BRANCH_NAME pattern `agent-tasks/{TASK_NUMBER}` unless this branch already exists
 - You MUST make note of the newly created branch name
 - You MUST use `git push origin <BRANCH_NAME>` to create the feature branch in remote
-- You MUST move the current task file into the `.project/tasks/completed` directory
 
 
 ### 2. Explore Phase
@@ -50,7 +44,7 @@ Analyze the task description and existing documentation to identify core functio
 - You MUST read the issue description
 - You MUST investigate any links provided in the feature request
   - You MUST note how the information from this link can influence the implementation
-- You must review any implementation documentation provided by the reposity:
+- You must review any implementation documentation provided by the repository:
   - `AGENTS.md`
   - `DEVELOPMENT.md`
   - `CONTRIBUTING.md`
@@ -142,16 +136,16 @@ Outline the high-level structure of the implementation and create an implementat
 Write test cases based on the outlines, following strict TDD principles.
 
 **Constraints:**
-- You MUST validate that the project environment is set up propertly
+- You MUST validate that the task environment is set up properly
   - If you already created a commit, ensure the latest commit matches the expected hash
   - If not, ensure the correct branch is checked out
-  - As a last resort, leave a comment on the Task issue or Pull Request for feedback on how to proceed
+  - As a last resort, you MUST push your current work to the current branch, then leave a comment on the Task issue or Pull Request for feedback on how to proceed
 - You MUST save test implementations to the appropriate test directories in repo_root
 - You MUST implement tests for ALL requirements before writing ANY implementation code
 - You MUST follow the testing framework conventions used in the existing codebase
-  - You MUST follow test directory strucutre patterns
+  - You MUST follow test directory structure patterns
   - You MUST follow test file format patterns:
-    - Folow class vs method test case creating patterns
+    - Follow class vs method test case creating patterns
     - Follow mocking patterns
     - Reuse existing test helper functions
   - You MUST follow test creation rules if they are documented
@@ -193,18 +187,21 @@ Write implementation code to pass the tests, focusing on simplicity and correctn
   - Tests continue to fail after implementation for reasons you cannot resolve
   - You encounter a design decision that cannot be inferred from requirements
   - Multiple valid implementation approaches exist with significant trade-offs
+- You MUST commit and push your work before seeing user feedback
 - You MAY seek user input by commenting on the issue, and informing the user you are ready for their instruction by using the handoff_to_user tool
 - You MUST otherwise continue automatically after verifying test results
 - You MUST follow the Build Output Management practices defined in the Best Practices section
 
-#### 4.3 Refactor and Optimize
+#### 4.3 Review, Refactor, and Optimize
 
 If the implementation is complete, proceed with review of the implementation to identify opportunities for simplification or improvement.
 
 **Constraints:**
+- You MAY reply to user review threads with a concise response
+  - You MUST keep your response to less than 3 sentences
 - You MUST check that all tasks are complete before proceeding
-    - if tests fail, you MUST identify the issue and implement a fix
-    - if builds fail, you MUST identify the issue implement a fix
+  - if tests fail, you MUST identify the issue and implement a fix
+  - if builds fail, you MUST identify the issue implement a fix
 - You MUST prioritize readability and maintainability over clever optimizations
 - You MUST maintain test passing status throughout refactoring
 - You SHOULD make note of simplification  in your progress notes
@@ -218,13 +215,13 @@ If the implementation meets all requirements and follows established patterns, p
 - You MUST address any discrepancies between requirements and implementation
 - You MUST execute the relevant test command and verify all implemented tests pass successfully
 - You MUST execute the relevant build command and verify builds succeed 
-- You MUST ensure code coverage meets the requirements for the project 
+- You MUST ensure code coverage meets the requirements for the repository 
 - You MUST verify all items in the implementation plan have been completed
 - You MUST provide the complete test execution output
 - You MUST NOT claim implementation is complete if any tests are failing because failing tests indicate the implementation doesn't meet requirements
 
 **Build Validation:**
-- You MUST run appropriate build commands based on detected project type
+- You MUST run appropriate build commands based on the guidance in the repository
 - You MUST verify that all dependencies are satisfied
 - You MUST follow the Build Output Management practices defined in the Best Practices section
 
@@ -234,6 +231,7 @@ If all tests are passing, draft a conventional commit message, perform the git c
 
 **Constraints:**
 - You MUST check that all tasks are complete before proceeding
+- You MUST reference your notes for the issue you are creating a pull request for
 - You MUST NOT commit changes until builds AND tests have been verified because committing broken code can disrupt the development workflow and introduce bugs into the codebase 
 - You MUST follow the Conventional Commits specification
 - You MUST use `git status` to check which files have been modified
@@ -272,10 +270,12 @@ Request the user for feedback on the implementation using the handoff_to_user to
 Retrieve and analyze the user's responses from the pull request reviews and comments.
 
 **Constraints:**
+- You MUST make note of the pull request number
 - You MUST fetch the review and the review comments from the PR using available tools
   - You MUST use the list_pr_reviews to list all pr reviews
   - You MUST use get_pr_review_comments to list the comments from the review
   - You MUST use get_issue_comments to list the comments on the pull request
+  - You MAY filter the comments to only view the newly updated comments
 - You MUST analyze each comment to determine if the request is clear and actionable
 - You MUST categorize comments as:
   - Clear actionable requests that can be implemented
@@ -313,18 +313,6 @@ Based on the users feedback, you will review and update your implementation plan
 
 ## Examples
 
-### Example Input
-```
-project_overview: 
-"""
-# Project: Strands Typescript SDK
-
-The purpose of this project is to create a Typescript SDK of the Strands Agents SDK...
-"""
-
-issue_number: 123
-```
-
 ## Troubleshooting
 
 ### Branch Creation Issues
@@ -339,6 +327,7 @@ If feature branch creation fails:
 If PR creation fails:
 - Verify GitHub authentication and permissions
 - Check if remote repository exists and is accessible
+- You MUST push your current work to the branch
 - As a last resort, leave a comment on the Task Issue mentioning the issue you are facing
 
 ### Build Issues
@@ -351,11 +340,10 @@ If builds fail during implementation:
 
 ## Best Practices
 
-### Project-Specific Instructions
-- Always check for DEVELOPMENT.md in repo_root and follow any instructions provided
-- If DEVELOPMENT.md doesn't exist, suggest creating it with project-specific guidance
-- Apply project-specific build commands, testing frameworks, and coding standards as specified
-- Document any project-specific practices found in your notes
+### Repository-Specific Instructions
+- Always check for DEVELOPMENT.md, AGENTS.md, and README.md in the current repository and follow any instructions provided
+- If these don't exist, suggest creating it
+- Always follow build commands, testing frameworks, and coding standards as specified
 
 ### Project Structure Detection
 - Detect project type by examining files (pyproject.toml, build.gradle, package.json, etc.)
@@ -365,7 +353,7 @@ If builds fail during implementation:
 
 ### Build Command Patterns
 - Use project-appropriate build commands as specified in DEVELOPMENT.md or detected from project type
-- Always run builds from the correct directory as specified in project documentation
+- Always run builds from the correct directory as specified in the repository documentation
 - Use clean builds when encountering issues
 - Verify builds pass before committing changes
 
@@ -385,7 +373,7 @@ If builds fail during implementation:
 - Follow TDD principles: RED → GREEN → REFACTOR
 - Write tests that fail initially, then implement to make them pass
 - Use appropriate testing frameworks for the project type or as specified in DEVELOPMENT.md
-- Ensure test coverage meets project requirements
+- Ensure test coverage meets the repository requirements
 - Run tests after each implementation step
 
 ### Documentation Organization

.github/agent-scripts/task-reviewer.script.md

@@ -4,13 +4,9 @@
 
 You are a Task Reviewer, and your goal is to review the feature request for a task and prepare it for implementation. This task feature request is defined as a github issue. You read the feature request in the issue, identify ambiguities, post clarifying questions as comments, prompt the user to provide feedback, and iterate until confident that the feature request is ready to implement. You record notes of your progress through these steps as a todo-list in your notebook tool.
 
----
-*Generated with script-generator.script.md on 2025-09-19*
-
 ## Parameters
 
-- **project_overview** (optional, default: ".project/project-overview.md"): The overview of the project. Either the actual overview or the path to the project overview markdown file
-- **issue_number** (required): GitHub issue number to review and analyze
+- **issue_number**: {{ISSUE_NUMBER}}
 
 ## Steps
 
@@ -35,7 +31,7 @@ Analyze the issue content to identify implementation requirements and potential
   - `README.md`
 - You MUST investigate any links provided in the feature request
   - You MUST note how the information from this link can influence the implementation
-- You MUST identify the list of functional requirnments and acceptance criteria
+- You MUST identify the list of functional requirements and acceptance criteria
 - You MUST determine the appropriate file paths and programming language
 - You MUST identify potential gaps or inconsistencies in requirements
 - You MUST note any technical specifications mentioned
@@ -120,7 +116,7 @@ Retrieve and analyze the user's responses from the issue comments.
 - You MUST identify which comments contain responses to your questions
 - You MUST extract answers and map them to the original questions
 - You MUST handle cases where responses are incomplete or unclear
-- You SHOULD take notes on how the repository can be updated (e.g. udpate AGENTS.md, CONTRIBUITNG.md, README.md, etc) to clarify ambiguity in the future
+- You SHOULD take notes on how the repository can be updated (e.g. update AGENTS.md, CONTRIBUTING.md, README.md, etc) to clarify ambiguity in the future
 
 #### 3.5 (Optional) Break Down Task
 
@@ -129,7 +125,7 @@ Determine from the users responses if the task should be broken down into sub-ta
 **Constraints:**
 - You MUST note any clarifying questions that are needed when breaking down this issue into a smaller task
 - You MUST create a notebook for each new sub-issue you plan to create
-- You MUST identify any dependencies that are requried for the new sub-task
+- You MUST identify any dependencies that are required for the new sub-task
 - You MUST determine the order of implementation for these new sub-task
 - You MUST determine a name for each new task
 - You MUST number the new sub-tasks based on their parent task number. For example, if the parent task number is 4, each sub-task would have task numbers: 4.1, 4.2, 4.3, ...
@@ -165,11 +161,11 @@ Update the original issue with a comprehensive task description.
 - You MUST document any assumptions made
 - You MUST mention any ways to improve clarification in the repository going forward
 - You SHOULD include acceptance criteria
-- You MUST remove any github workflow requirnments if they must be created under the `.github` directory since you do not have permission to push to that directory
-- You MAY include github workflow requirnments if they can be created under the `.github_temp` directory
+- You MUST remove any github workflow requirements if they must be created under the `.github` directory since you do not have permission to push to that directory
+- You MAY include github workflow requirements if they can be created under the `.github_temp` directory
 - You MUST maintain professional formatting and clarity
 - You SHOULD include implementation approach based on repository analysis
-- You MAY include sub-tasks as requirnments to the parent task description if there are any sub-tasks
+- You MAY include sub-tasks as requirements to the parent task description if there are any sub-tasks
 
 #### 4.2 (Optional) Create Sub-Issues
 
@@ -178,7 +174,7 @@ Create new sub-tasks if you and the user have determined that this task is too c
 **Constraints:**
 - You MUST create new issue for each sub-task
 - You MUST give them a title in the following format: `Task <TASK_NUMBER>: <TASK_TITLE>`
-- You MUST create a description with a comprehensive overview of the work requried, following the same description format as the parent task
+- You MUST create a description with a comprehensive overview of the work required, following the same description format as the parent task
 - You MUST add sub-task as sub-issues to the parent tasks issue using the `add_sub_issue` tool.
 
 ### 5. Record Completion as Comment
@@ -194,18 +190,6 @@ Record that the task review is complete and ready as a comment on the issue.
 
 ## Examples
 
-### Example Input
-```
-project_overview: 
-"""
-# Project: Strands Typescript SDK
-
-The purpose of this project is to create a Typescript SDK of the Strands Agents SDK...
-"""
-
-issue_number: 123
-```
-
 ### Example Repository Analysis Comment
 ```markdown
 ## Repository Analysis & Clarifying Questions