full-implement

name	full-implement
description	Do a full implementation, iteratively start to finish

Instructions

You are tasked to do a full implementation start to finish, iteratively. You are the main agent and should delegate tasks to subagents as needed. You will be responsible for the overall implementation and ensuring that all tasks are completed correctly, while subagents should focus on implementing the changes in their respective areas. You will also be responsible for reviewing the code and testing the changes.

Input

You will be either given:

• A Jira task number like "WA-123" or "ABC-123".

If so, first fetch all ticket information using the Atlassian MCP integration. This includes the title, description, and any other relevant information. If the ticket is not found, ask me for clarification. If there are connected parent tickets or Epics, also fetch their information to get the full context.

The user may also gave you some other info about the task (e.g. where the relevant code sits). The JIRA task number may be given as its full URL (e.g. "https://companyname.atlassian.net/browse/AB-123" -> "AB-123").

• A task description without Jira Ticket number If you don't get a Jira Ticket but instead just a raw task description, no need to connect to Jira and instead work from there.

Steps

Our goal is to implement this ticket fully, iteratively, and in a way that is easy to understand. Follow these steps exactly. You may need to do iteration steps to complete the implementation, so after each iteration, review the changes and make any necessary adjustments.

1. Before starting the implementation

• create a separate branch. e.g. for task "AB-123 Migrate to MUI v9", this is "AB-123/MUI-v9". We may still be in some other feature branch, in that case stash the current changes and switch to the new branch. Make sure to always base your branch on the main/master branch, not on any other feature branch!
• Read the AGENTS.md file to understand the project.
• You can read some of the code to understand the code style in more detail, but you should not read the entire codebase. You will be able to read the code as needed during the implementation.

2. Read the task description and requirements carefully

• Perform a validation check of the task. Tasks can contain issues - e.g. they outline to use an API or table that doesn't actually exist, or they are missing some requirements. If you find any issues, ask me questions to clarify the requirements and constraints.
• If helpful, create yourself a short summary of the task and requirements to refer back to during the implementation.
• If this is a big task that needs planning, you may switch to plan mode and ask me questions to clarify the requirements and constraints.

3. Main implementation

Break down the task into smaller sub-tasks or components - if applicable. For each subtask:

• Identify the section of code affected (e.g. the folder or file).
• create a separate subagent with the "ponytail" skill and task it to implement the changes fully. Also instruct the subagent to read the AGENTS.md file first

You may be working on multiple projects at once (e.g. a fullstack ticket that has a separate backend and frontend). In that case, create separate subagents for each project and task them to implement the changes fully.

You may need to do multiple iterations of the implementation, so after each iteration, review the changes and make any necessary adjustments.

4. Code review

For this create separate subagents for:

• the "picky-code-reviewer" skill to review the code for correctness, style, and best practices.
• the "ponytail-review" skill to review the code for unnecessary complexity
• a "reimplementation checker" to see if we are reimplementing something that already exists in the codebase and can be reused instead.

For python projects, use black, isort and flake8 for code formatting and linting. For JavaScript/TypeScript projects, use prettier and eslint (or whatever the current project uses).

5. Testing

Test everything thoroughly, including edge cases. If you find any issues, create a new subagent to fix them.

You may use your browser integration to test the changes in a real environment, or you may use a testing framework if applicable. I have the dev server running, so please never start your own. If the prompt doesn't say different, the frontend will be on port 3000.

Finally, make sure we are fully implementing the original ticket and fulfill all the acceptance criteria outlined.

If need be, you can also write a short "manual testing steps" instruction for me - 1-3 quick things I should test to verify the changes are working correctly.

6. Git submission

After everything is done, create a new commit for these changes. e.g. for task "AB-123 Migrate to MUI v9", this is "[AB-123] Upgrade to MUI v9". This should follow git commit message conventions. The commit message should be clear and concise, describing the changes made in the implementation.

We only want a single commit for the whole ticket, not several ones. If there are changes that need to be done, ammend the original commit.

NEVER manually merge the changes into the main branch. We'll instead create a PR on GitHub. For this, we often have a ".github/pull_request_template.md", otherwise we'll follow this template:

---

What changes does this introduce?

Link to any corresponding tickets

What kind of change is this?

• New feature
• Bug fix
• Chore
• Tech debt/refactoring existing code

How can this be tested?

Checklist

• I have tested the app for visual regressions
• I have tested affected journeys for functional regressions, or I will ask the code owners for a review
• Unit tests have been added for new or heavily modified code
• Any code/feature that is not production ready is behind a feature flag

Screenshots

---

Generally keep the texts here super short, nobody wants to read a long PR description. Just a few bulletpoints and short sentences are enough.

Fill in the PR template. Use the GitHub integration to create the PR as a draft PR. Don't assign reviewers. Finally, give me the link to the PR and ask me to review it. I will then review the PR and approve it if everything is correct. If there are any issues, I will ask you to fix them.

Code style

Follow the code guidelines lined out in the respective AGENTS.md. Additionally follow my own code style guidelines:

• Use tests sparingly. In frontend code we don't test at all, in backend projects we only test the absolute base functionality.
• Don't do "smoke tests"
• Use comments sparingly if at all. Good code comments itself - if you're putting a long comment on something it shows me your code is bad and needs to be refactored, or you comment something that is trivial to see from the code itself which is unnecessary.
• Focus on writing short, maintainable, clean code. Often the shorter the better! Because of this, always use the "ponytail" skill for the implementation agents.
• Prefer using bun wherever possible to run tests, run lint etc.
• Religously prefer existing utils and functions. If we can use some component, util, helper etc. that already exists instead of writing our own, we should always use the existing one. This is a big part of keeping the codebase maintainable and clean.