Agent Config Adapter

Original Content

---
allowed-tools: Bash(git:*), Bash(tree:*), Bash(ls:*), Bash(grep:*), Bash(cat:*), Bash(find:*), Bash(gh:*), mcp__memory-server_*, FileSystem
description: Plan and analyze code tasks with comprehensive project understanding
argument-hint: github ticket id | task description
---

# Purpose

Understand the code and requirements we are working on.

## Arguments

- Task and/or Github Ticket ID: This can be mix and match, user may provide both
  task description and github ticket ID or just one of them.

## Context and commands for project analysis

- Current directory: `pwd`
- Project structure: `tree -L 3 -I 'node_modules|.git'`

### Additional commands for git repositories (if applicable)

- Git status: `git status 2>/dev/null || echo "Not a git repository"`
- Current branch:
  `git branch --show-current 2>/dev/null || echo "Not a git repository"`
- Recent commits:
  `git log --oneline -5 2>/dev/null || echo "Not a git repository"`
- Remote info: `git remote -v 2>/dev/null || echo "Not a git repository"`
- Git files: `git ls-files 2>/dev/null || echo "Not a git repository"`

## Steps to follow

**Step 1: Understand the project structure**

- Understand the project structure first. What the project looks like in high
  level, what is the tech and framework used and the dependencies of the
  proeject.

**Step 2: Understand the requirements**

- Check how the task details are provided to you, it can be a github ticket ID,
  additional task details or both.

- If Github Ticket ID is provided in $ARGUMENT, the **GitHub Project Work
  Planner** skill can help fetch and format the ticket details automatically.
  Alternatively, run `git remote -v` to understand the remote and owner of the
  git repo, and then use the `gh` CLI tool to fetch the ticket details.

- If $ARGUMENT mentions about any additional task, COMBINE it with ticket
  details and consider this as a task to do.

- Read the relevant code carefully and get the clear understanding of the task
  and code context. If you are creating new files, understand adjacent files and
  their structure and style.

- If the requirement contains any bugs,use **triage** agent carefully to triage
  the bug and understand what's happening. Pass the path of taskFindings file to
  triage agent so that it can write the triage report there.

- IMPORTANT: Use triage report as additional context for planning.

**Step 3: Intelligence Gathering**

- Use following tools appropriately while planning.

  - Developer Memory: memory-server (check if there is any memory relevant to
    the task)
  - Any online search: Use **web-search-specialist** agent for reading web pages
    or searching online.

**Step 4: Planning**

**Step 4.1: Creating the hub**

- Decide the directory name, where you will write the taskFindings
  - Rule for naming: Consider the appropriate short name, Max 3 words in
    kebab-case
  - Consider if it's a new functionality or upgraded on top of an existing
    functionality
    - For Upgrades:
      - Consider existing documents as previous version
      - IMPORTANT: MOVE existing documents to appropriate versioned directory
        -e.g. taskNotes/existing-directory-name-in-kebab-case/v1
      - Write new documents in the
        taskNotes/existing-directory-name-in-kebab-case/v2

  - With all the information, enter into plan mode. Think about the solution.

  - Keep following format for your plan.
    <PlanFormat>

  # Purpose

  A one liner high level purpose of the task

  ## Original Ask
  Exact original requirements AS IS

  ## Complexity and the reason behind it
  Complexity score out of 5 and reason to chose this score

  ## Architectural changes required

  If none required, simply state that, otherwise write architectural plan

  ## Backend changes required

  If none required, simply state that, otherwise write backend implementation
  plan

  ## Frontend changes required

  If none required, simply state that, otherwise write frontend implementation
  plan

  ## Acceptance Criteria

  Only applicable for tasks with complexity score >= 3

  ## Validation

  Write the high level description of what to test and how to test it,

  Including commands to run and verify the changes. For frontend, user steps.
  For backend: API Flows with cases

</PlanFormat>

- IMPORTANT FOR COMPLEXITY SCORES:
  - Follow these rules along with your own intelligence
    - Do not consider a simple fullstack task as complex just because it
      involves both frontend and backend.
    - Take your capabilities into account, if you are good at something (Like
      greenfield scaffolding, CRUD etc...), lower the complexity score.
    - Consider the complexity of verification into account. If something seems
      easy to develop but hard to verify, increase the complexity score, and
      vice versa.

  - For dependency upgrades, determine following factors for complexity score
    - Breaking changes from new version
    - New changes/features that gives us advantages over current implementation
    - Total changes required.

- Write the plan in
  `taskNotes/{relevant-directory-name-in-kebab-case}/taskFindings.md` before
  presenting it to the user

**Optional Step 5: Specs**

- THIS STEP IS VERY IMPORTANT FOR HIGH COMPLEXITY TASKS

**Variables**:

- Main TaskFindings file:
  taskNotes/{relevant-directory-name-in-kebab-case}/taskFindings.md
- Specs directory: taskNotes/{relevant-directory-name-in-kebab-case}/specs
- Specs File: taskNotes/{relevant-directory-name-in-kebab-case}/specs/specs.md
- Task Breakdown: A bullet point mention of task that can be done independently
  and has complexity score 1 or 2.

- For tasks having complexity score 3 or more, decide if the plan contains exact
  breakdown of the task or not.

- Write the breakdown in specs file and refer the specs file in main
  taskFindings

- Create the taskFindings.md for each bullet point in the specs.md file, and
  write each taskFindings in specs directory, appropriately move section of main
  taskfindings to spec taskFindings

- update main taskFindings.md file to refer those specs taskFindings and
  strictly ask the agent to update an h2 section at start mentions current task
  status in 20 words or less. (i.e. Currently starting spec1 or Validating Spec
  4 etc..)

**Optional Step 6: Iteration**

- If user asks you to change the plan, read relevant taskFindings file, and
  consider this as an additional context when you are thinking about the plan.

- IMPORTANT: For user next step is always `/startWork`, any messages from user
  before start work is iteration of plan.

- IMPORTANT: The absense of taskFinding should always be considered as fresh
  plan even though user meant iteration.

**EXIT**

- AS SOON AS YOU WRITE THE TASKFINDINGS FILE, Ask the user to review and provide
  feedback.

- When user confirms the plan, take up a funny personality and present a funny,
  made-up and relevant star wars quote.

- IMPORTANT: AVOID CREATING ANY TODO LIST, ASK USER TO INVOKE `/startWork`
  COMMAND TO START WORK.

Convert to Different Formats

Actions