startWork-gemini

slash command claude_code

Slash Command Analysis

Re-analyzes command for arguments and references

Original Content

---
allowed-tools: Bash(git:*), FileSystem, Bash(npm:*), Bash(yarn:*), Bash(build:*), Bash(test:*),Bash(gemini:*)
description: Start or continue working on a planned task with proper branch management
---

Start or continue working on a task.

## Arguments provided by user in $ARGUMENTS

- Directory Name: This is the name of the directory or task where
  taskFindings.md file is located. This is used to understand the context of the
  task and where to write the findings.

- Should work in same branch or separate branch

## Context and files

## Context

- Current git status: !`git status --porcelain`
- Current branch: !`git branch --show-current`
- Uncommitted changes: !`git diff --name-only`
- Task findings: @taskNotes/{ArgumentDirectoryName}/taskFindings.md
- Gemini command and the help: !`gemini --help`
- Tools available with Gemini CLI: !`gemini -p "\tools"`

## Steps

- Auto-detect if working directory is clean

- Smart branch naming with ticket prefixes

- Automatic dependency checking: !`npm outdated`.

- If it doesn't exist, ask user to run `/codePlanner` slash command. As of now
  you don't have the ability to run the command yourself.

- Ask the user if they want to work on a separate branch or not.

- If they confirm, make sure to check-out latest version of main, CREATE NEW
  branch with same name as ${ArgumentDirectoryName}.

- If the user doesn't confirm, continue in the current branch. But make sure it
  is the latest version of main.

- Before starting your work, write the current commit hash in
  `taskNotes/{ArgumentDirectoryName}/currentCommitHash` file.

- Guide the Gemini CLI Code agent to complete the development of the task as per
  the findings Task Contents.
  - Note for Gemini CLI Code agent:
    - Understand that the Gemini CLI is using bit inferior Gemini flash, you
      need to be more explicit in your instructions.
    - Each request to Gemini CLI should follow proper checkpointing system we
      can follow for our commits.
    - Strictly tell Gemini CLI about your limitation, it should not do anything
      which you are not allowed to do. It must run within your boundaries.

- Make sure you create proper checkpoints during your work and commit them with
  proper commit messages. Always use single line conventional commit message
  format, like `feat: add new feature`, `fix: fix a bug`, etc.

- IMPORTANT: Commit messages should not include any description.

- Do not push the code yet, only keep the code locally.

Convert to Different Formats

Actions

(Clears cached conversions and forces re-processing)
← Back to List