Skip to content

Commit 963a54c

Browse files
TechNickAITechNickAI
authored
Merge pull request #3 from TechNickAI/feature/implement-autotask-command
Add adaptive review workflow and XML naming standards
2 parents c46f923 + a0d4733 commit 963a54c

File tree

7 files changed

+928
-139
lines changed

7 files changed

+928
-139
lines changed

‎.claude/commands/autotask.md‎

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
---
2+
description: Execute complete development task autonomously from description to PR-ready state
3+
---
4+
5+
# /autotask - Autonomous Task Execution
6+
7+
Execute a complete development task autonomously from description to PR-ready state.
8+
9+
## Usage
10+
11+
```
12+
/autotask "task description"
13+
```
14+
15+
## What This Command Does
16+
17+
Takes your task description and autonomously delivers a pull request ready for your review. The command analyzes task complexity, sets up an isolated worktree environment, implements the solution using appropriate agents, performs adaptive validation scaled to risk level, and handles bot feedback intelligently.
18+
19+
You only need to provide the task description and review the final PR.
20+
21+
## Execution Flow
22+
23+
Read @rules/git-worktree-task.mdc for comprehensive autonomous workflow guidance.
24+
25+
<task-preparation>
26+
Ensure you have clear, unambiguous requirements before starting implementation. If the task description is unclear or has multiple valid interpretations, use @commands/create-prompt.md to ask clarifying questions and create a structured prompt. For tasks with clear requirements and single valid interpretation, proceed directly to implementation.
27+
</task-preparation>
28+
29+
<worktree-setup>
30+
Create a fully functional, isolated development environment in .gitworktrees/ where all tests pass and the project is ready for development work. Ensure the environment is secure (prevent shell injection), handle any conflicts, and set up all necessary dependencies and configurations using /setup-environment.
31+
</worktree-setup>
32+
33+
<autonomous-execution>
34+
Implement the solution following project patterns and standards. Build a plan for which agents or approaches to use based on the task type. Available specialized agents:
35+
36+
- Dixon (.claude/agents/dev-agents/debugger.md): Root cause analysis, reproduces issues, identifies underlying problems
37+
- Ada (.claude/agents/dev-agents/autonomous-developer.md): Implementation work, writes tests
38+
- Phil (.claude/agents/dev-agents/ux-designer.md): Reviews user-facing text, validates accessibility, ensures UX consistency
39+
- Rivera (.claude/agents/code-review/code-reviewer.md): Architecture review, validates design patterns, checks security
40+
- Petra (.claude/agents/dev-agents/prompt-engineer.md): Prompt optimization and refinement
41+
- Explore (general-purpose): Investigation, research, evaluates trade-offs
42+
43+
Create your execution plan, then implement the solution. Use /load-cursor-rules to load relevant project standards for the task. Execute agents in parallel when possible, sequentially when they depend on each other.
44+
45+
When launching agents, provide targeted context for effectiveness: task context (original requirements and any clarifications), implementation context (what's been built, decisions made, constraints), project context (relevant standards from /load-cursor-rules), and specific focus area. Tailor context to agent type - debuggers need error details and reproduction steps, reviewers need change rationale and risk areas, implementers need full requirements and constraints.
46+
47+
Maintain context throughout workflow phases. Decisions and clarifications from earlier phases inform later ones - don't re-decide or re-ask. Carry forward user clarifications, implementation decisions, constraint discoveries, and why choices were made.
48+
</autonomous-execution>
49+
50+
<validation-and-review>
51+
Ensure code quality through adaptive validation that scales with complexity and risk. Match review intensity to the changes: simple changes need only automated checks, medium complexity benefits from targeted agent review, high-risk or security-sensitive changes warrant comprehensive review. Use your judgment to determine what level of validation the changes require.
52+
</validation-and-review>
53+
54+
<create-pr>
55+
Deliver a well-documented pull request ready for review, with commits following .cursor/rules/git-commit-message.mdc. Provide reviewers with decision context: why this approach over alternatives, what trade-offs were made, how this fits the larger system, and what testing validates the changes.
56+
</create-pr>
57+
58+
<bot-feedback-loop>
59+
Autonomously address valuable bot feedback, reject what's not applicable, and deliver a PR ready for human review with all critical issues resolved.
60+
61+
After creating the PR, wait 3 minutes for AI code review bots to complete their initial analysis. Check for bot comments using GitHub API. You have context bots lack: project standards, why implementation choices were made, trade-offs considered, and user requirements. Evaluate feedback against this context - bots may suggest changes that contradict project patterns or misunderstand requirements.
62+
63+
Fix what's valuable (security issues, real bugs, good suggestions). Reject what's not (use WONTFIX with brief explanation for context-missing or incorrect feedback). You are the ultimate decider - trust your judgment on what matters.
64+
65+
After making fixes and pushing, wait 90 seconds for bots to re-review. Iterate up to 5 times if needed until critical issues are resolved.
66+
</bot-feedback-loop>
67+
68+
<completion>
69+
Provide a summary of what was accomplished, highlights you're proud of, and any significant issues found and fixed during bot review. Scale the summary length to the complexity of the change - simple fixes get a sentence or two, major features deserve a paragraph. Include the PR URL and worktree location.
70+
</completion>
71+
72+
<error-handling>
73+
Recover gracefully from failures when possible, or inform the user clearly when manual intervention is needed. Capture decision-enabling context: what was being attempted, what state preceded the failure, what the error indicates about root cause, and whether you have enough information to fix it autonomously. Attempt fixes when you can (like auto-fixing validation errors). For issues you can't resolve autonomously, inform the user with clear options and context.
74+
</error-handling>
75+
76+
## Key Principles
77+
78+
- Single worktree per task: Clean isolation for parallel development
79+
- Adaptive review: Review intensity matches task complexity and risk
80+
- Intelligent agent use: Right tool for the job, no forced patterns
81+
- Git hooks do validation: Leverage your existing infrastructure
82+
- Autonomous bot handling: Don't wait for human intervention
83+
- PR-centric workflow: Everything leads to a mergeable pull request
84+
85+
## Requirements
86+
87+
- GitHub CLI (`gh`) installed and authenticated
88+
- Node.js/npm
89+
- Project standards accessible via /load-cursor-rules
90+
91+
## Configuration
92+
93+
The command adapts to your project structure:
94+
95+
- Detects git hooks (husky, pre-commit)
96+
- Detects test runners (jest, mocha, vitest, etc.)
97+
- Finds linting configs (eslint, prettier, etc.)
98+
- Uses available build scripts
99+
- Respects project-specific conventions
100+
101+
## Notes
102+
103+
- This command creates real commits and PRs
104+
- All work happens in isolated worktrees
105+
- Bot feedback handling is autonomous but intelligent
106+
- Worktrees are preserved until you explicitly remove them

‎.claude/commands/handoff-context.md‎

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -55,12 +55,15 @@ numbers] </work_completed>
5555

5656
**DO NOT ASK** - Just do it:
5757

58-
1. Generate a unique filename: `/tmp/context_handoff_TIMESTAMP.md` where TIMESTAMP is the current Unix timestamp
58+
1. Generate a unique filename: `/tmp/context_handoff_TIMESTAMP.md` where TIMESTAMP is
59+
the current Unix timestamp
5960
2. Use **Write tool** to save the handoff content to that unique filename
60-
3. Use **Bash** to copy the file you just created: `pbcopy < /tmp/context_handoff_TIMESTAMP.md`
61+
3. Use **Bash** to copy the file you just created:
62+
`pbcopy < /tmp/context_handoff_TIMESTAMP.md`
6163
4. Confirm: `📋 Copied to clipboard`
6264

63-
**Implementation:** First run `date +%s` to get the timestamp, then use that value in both the Write and Bash commands.
65+
**Implementation:** First run `date +%s` to get the timestamp, then use that value in
66+
both the Write and Bash commands.
6467

6568
**Why Write tool instead of heredoc?**
6669

‎.claude/commands/setup-environment.md‎

Lines changed: 226 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -2,22 +2,234 @@
22
description: Initialize development environment for git worktree
33
---
44

5-
Make this worktree a fully functional development environment where all tests pass.
5+
# Setup Development Environment
66

7-
You're in a fresh git worktree. Your job is to get it into the same working state as the
8-
main development directory. After you finish, running the full validation suite should
9-
pass - type checking, linting, unit tests, and integration tests.
7+
Initialize a git worktree as a fully functional development environment with all
8+
dependencies, configurations, and validation tools.
109

11-
To do this, you'll need to:
10+
## What This Command Does
1211

13-
- Install whatever dependencies this project needs
14-
- Run any code generation or build steps required
15-
- Copy environment configuration from the parent directory so integration tests can
16-
connect to databases and services
12+
You're in a fresh git worktree. This command will:
1713

18-
Look at what kind of project this is and make intelligent decisions about what needs to
19-
happen. If something fails or seems unusual, investigate and adapt. Report what you're
20-
doing as you go so the user understands the progress.
14+
1. Install all project dependencies
15+
2. Copy necessary environment configurations
16+
3. Set up git hooks (husky/pre-commit)
17+
4. Run any required build/generation steps
18+
5. Verify everything works correctly
2119

22-
The success criteria: after you're done, `pnpm pre-push` (or equivalent validation)
23-
passes completely. No failing tests, no type errors, no missing dependencies.
20+
## Detection Phase
21+
22+
First, I'll analyze the project structure to understand what needs to be set up:
23+
24+
<detect-project-type>
25+
Checking for project indicators:
26+
- package.json → Node.js/JavaScript/TypeScript project
27+
- requirements.txt/Pipfile → Python project
28+
- Gemfile → Ruby project
29+
- go.mod → Go project
30+
- Cargo.toml → Rust project
31+
- pom.xml/build.gradle → Java project
32+
- .csproj → .NET project
33+
</detect-project-type>
34+
35+
<detect-package-manager>
36+
For Node.js projects, detecting package manager:
37+
- pnpm-lock.yaml → pnpm
38+
- yarn.lock → yarn
39+
- package-lock.json → npm
40+
- bun.lockb → bun
41+
</detect-package-manager>
42+
43+
## Setup Steps
44+
45+
### 1. Install Dependencies
46+
47+
```bash
48+
# Based on detected package manager
49+
echo "📦 Installing dependencies..."
50+
51+
# Node.js
52+
if [ -f "package.json" ]; then
53+
if [ -f "pnpm-lock.yaml" ]; then
54+
pnpm install
55+
elif [ -f "yarn.lock" ]; then
56+
yarn install
57+
elif [ -f "bun.lockb" ]; then
58+
bun install
59+
else
60+
npm install
61+
fi
62+
fi
63+
64+
# Python
65+
if [ -f "requirements.txt" ]; then
66+
pip install -r requirements.txt
67+
elif [ -f "Pipfile" ]; then
68+
pipenv install
69+
fi
70+
71+
# Add other language-specific installations as needed
72+
```
73+
74+
### 2. Copy Environment Configuration
75+
76+
```bash
77+
echo "🔐 Setting up environment configuration..."
78+
79+
# Get the main working directory (parent of .gitworktrees)
80+
MAIN_DIR=$(git worktree list --porcelain | grep "^worktree" | head -1 | cut -d' ' -f2)
81+
82+
# Copy environment files if they exist
83+
ENV_FILES=(.env .env.local .env.development .env.test)
84+
for env_file in "${ENV_FILES[@]}"; do
85+
if [ -f "$MAIN_DIR/$env_file" ]; then
86+
echo " Copying $env_file from main directory..."
87+
cp "$MAIN_DIR/$env_file" "./$env_file"
88+
fi
89+
done
90+
91+
# Copy any other config files that aren't in version control
92+
CONFIG_FILES=(.secrets.json local.config.js config.local.json)
93+
for config_file in "${CONFIG_FILES[@]}"; do
94+
if [ -f "$MAIN_DIR/$config_file" ]; then
95+
echo " Copying $config_file from main directory..."
96+
cp "$MAIN_DIR/$config_file" "./$config_file"
97+
fi
98+
done
99+
```
100+
101+
### 3. Setup Git Hooks
102+
103+
```bash
104+
echo "🪝 Setting up git hooks..."
105+
106+
# Get the main working directory
107+
MAIN_DIR=$(git worktree list --porcelain | grep "^worktree" | head -1 | cut -d' ' -f2)
108+
109+
# Husky (most common in JS/TS projects)
110+
if [ -d "$MAIN_DIR/.husky" ] || [ -d ".husky" ]; then
111+
echo " Installing Husky hooks..."
112+
npx husky install
113+
echo " ✓ Husky hooks installed"
114+
fi
115+
116+
# Pre-commit (Python and multi-language projects)
117+
if [ -f "$MAIN_DIR/.pre-commit-config.yaml" ] || [ -f ".pre-commit-config.yaml" ]; then
118+
echo " Installing pre-commit hooks..."
119+
if command -v pre-commit >/dev/null 2>&1; then
120+
pre-commit install
121+
echo " ✓ Pre-commit hooks installed"
122+
else
123+
echo " ⚠️ pre-commit not installed, run: pip install pre-commit"
124+
fi
125+
fi
126+
127+
# Simple git hooks (legacy projects)
128+
if [ -d "$MAIN_DIR/.git/hooks" ]; then
129+
# Check for custom hooks that need copying
130+
for hook in pre-commit pre-push commit-msg; do
131+
if [ -f "$MAIN_DIR/.git/hooks/$hook" ] && [ ! -f ".git/hooks/$hook" ]; then
132+
echo " Copying $hook hook..."
133+
cp "$MAIN_DIR/.git/hooks/$hook" ".git/hooks/$hook"
134+
chmod +x ".git/hooks/$hook"
135+
fi
136+
done
137+
fi
138+
139+
echo " ✓ Git hooks configured for this worktree"
140+
```
141+
142+
### 4. Run Build/Generation Steps
143+
144+
```bash
145+
echo "🏗️ Running build and generation steps..."
146+
147+
# Check for code generation needs
148+
if [ -f "package.json" ]; then
149+
# Prisma generation
150+
if grep -q "@prisma/client" package.json; then
151+
echo " Generating Prisma client..."
152+
npx prisma generate
153+
fi
154+
155+
# GraphQL codegen
156+
if [ -f "codegen.yml" ] || [ -f "codegen.ts" ]; then
157+
echo " Running GraphQL codegen..."
158+
npm run codegen || yarn codegen || npx graphql-codegen
159+
fi
160+
161+
# Build if needed for development
162+
if grep -q '"prepare"' package.json; then
163+
echo " Running prepare script..."
164+
npm run prepare || yarn prepare
165+
fi
166+
167+
# TypeScript declarations
168+
if [ -f "tsconfig.json" ] && grep -q '"declaration"' tsconfig.json; then
169+
echo " Building TypeScript declarations..."
170+
npx tsc --emitDeclarationOnly || true
171+
fi
172+
fi
173+
```
174+
175+
### 5. Verify Setup
176+
177+
```bash
178+
echo "🔍 Verifying environment setup..."
179+
180+
# Run git hooks to verify everything works
181+
echo "Testing git hooks..."
182+
if [ -d ".husky" ]; then
183+
echo " Running Husky pre-commit hooks..."
184+
npx husky run pre-commit && echo " ✓ Husky hooks working" || echo " ⚠️ Some checks failed (fixing...)"
185+
elif [ -f ".pre-commit-config.yaml" ]; then
186+
echo " Running pre-commit hooks..."
187+
pre-commit run --all-files && echo " ✓ Pre-commit hooks working" || echo " ⚠️ Some checks failed (fixing...)"
188+
else
189+
echo " ⚠️ No git hooks configured - consider adding husky or pre-commit"
190+
fi
191+
192+
# Quick sanity checks
193+
if [ -f "package.json" ]; then
194+
echo "Testing build..."
195+
npm run build 2>/dev/null || yarn build 2>/dev/null || echo " ⚠️ No build script"
196+
fi
197+
198+
# Check environment files
199+
if [ -f ".env" ]; then
200+
echo "✅ Environment configuration present"
201+
fi
202+
203+
echo ""
204+
echo "✅ Environment setup complete!"
205+
echo ""
206+
echo "This worktree is now ready for development:"
207+
echo " - All dependencies installed"
208+
echo " - Environment configured"
209+
echo " - Git hooks installed and working"
210+
echo " - Ready for development"
211+
echo ""
212+
echo "Your git hooks will handle all validation when you commit."
213+
```
214+
215+
## Error Handling
216+
217+
If any step fails, I'll:
218+
219+
1. Identify what went wrong
220+
2. Attempt to fix common issues automatically
221+
3. Provide clear guidance on manual fixes if needed
222+
4. Continue with other steps when safe to do so
223+
224+
## Success Criteria
225+
226+
After setup completes:
227+
228+
- All dependencies are installed
229+
- Environment variables are configured
230+
- Git hooks are properly installed and working
231+
- The worktree is ready for development
232+
233+
The goal is a worktree that's immediately productive - no missing dependencies, no
234+
failing tests, no configuration issues. Your existing git hooks (husky/pre-commit)
235+
handle all validation automatically when you commit.

‎.cursor/commands/autotask.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../.claude/commands/autotask.md

‎.cursor/rules/prompt-engineering.mdc‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -317,6 +317,10 @@ const auth = new OAuth2Client(clientId, clientSecret);
317317

318318
Guidelines for XML structure:
319319

320+
- **Use semantic names, not numbers**: `<task-preparation>` not `<phase-1>`, `<create-pr>` not `<step-6>`
321+
- Numbered tags are brittle: reordering requires renumbering all tags and references
322+
- Semantic tags are self-documenting: `<validation-and-review>` tells you what it does
323+
- Example: A workflow with `<task-preparation>`, `<execution>`, `<review>` stays clear even when phases are added or reordered
320324
- Be consistent with tag names throughout your codebase (always use `<task>` not
321325
sometimes `<objective>`)
322326
- Use semantically meaningful tag names that describe the content

0 commit comments

Comments
 (0)