gsd-trae 1.0.0 → 1.0.2

package/refs/vbenchmark/.cursor/commands/document.md

@@ -1,52 +0,0 @@
----
-description: Create or update documentation with research, planning, and review
----
-
-Document $ARGUMENTS
-
-Help me create or update documentation systematically.
-
-## Workflow
-
-1. **Research** - Understand what to document:
-   - Spawn @codebase-explorer to find existing docs and code to document
-   - Spawn @researcher for external doc best practices if needed
-   - Synthesize: target audience, format, examples needed
-
-2. **Plan** - Design the documentation:
-   - Structure (sections, order, examples, audience-specific content)
-   - List files to create/update
-   - Present the plan to me and get my approval
-
-3. **Execute** - Write the documentation:
-   - Use TodoWrite to track progress
-   - Spawn @documenter agents (one per file for parallel work)
-   - Provide clear instructions with target audience and format
-
-4. **Review** - Validate quality:
-   - Verify: accuracy, completeness, clarity, working examples, consistency, valid links
-   - Test all code examples
-   - Optionally spawn @reviewer for critical docs
-
-5. **Report** - Summarize for me:
-   - What was created/updated
-   - Key sections added
-   - Examples included
-   - Any follow-up needed
-
-## Documentation Types
-
-- **README** - Project overview, installation, quick start, usage examples
-- **API docs** - Function signatures, parameters, return values, errors, examples
-- **User guides** - Step-by-step instructions, use cases, troubleshooting
-- **Architecture** - System overview, component relationships, data flow, design decisions
-- **Inline comments** - Why not what, edge cases, algorithms, performance notes
-- **Changelogs** - Version, date, breaking changes, features, fixes, migrations
-
-## Best Practices
-
-- **Audience-focused** - Write for the intended reader (end users, developers, contributors)
-- **Example-driven** - Show don't tell, realistic copy-pasteable examples with expected output
-- **Maintainable** - Keep docs close to code, update together, consistent formatting
-- **Clear and concise** - Simple language, define terms, break into steps, structured headings
-- **Accurate** - Test all examples, match implementation, verify links

package/refs/vbenchmark/.cursor/commands/gather-context.md

@@ -1,58 +0,0 @@
----
-description: Gather context about repository state and recent changes
----
-
-Gather Context $ARGUMENTS
-
-Understand the current state of the repository and recent changes.
-
-## Workflow
-
-1. **Understand what I need** - Ask me if unclear:
-   - Working tree changes (unstaged/staged)?
-   - Recent commits (how many)?
-   - Specific file/directory focus?
-   - General repository overview?
-   - Default: working tree + last 10 commits
-
-2. **Gather git information** - Run in parallel:
-   - `git status -s` for working tree state
-   - `git diff` for unstaged changes
-   - `git diff --staged` for staged changes
-   - `git log --oneline -n [N]` for recent commits
-   - `git diff HEAD~[N]..HEAD` for changes in last N commits
-
-3. **Analyze codebase** - Understand the code:
-   - If specific files/directories: spawn @codebase-explorer for structure and patterns
-   - If general overview: identify key directories, technologies, recent activity
-   - If unfamiliar tech found: spawn @researcher for context on tools and best practices
-
-4. **Synthesize context** - Organize findings:
-   - 📊 **REPOSITORY STATE** - Current branch, uncommitted changes, status
-   - 📝 **RECENT ACTIVITY** - Commits, themes, development patterns
-   - 📁 **KEY FILES** - Important files with file:line references
-   - 🎯 **FOCUS AREAS** - Recommended areas to explore
-   - ⚠️ **WARNINGS** - Conflicts, issues, or concerns
-
-5. **Present summary** - Show me:
-   - High-level overview of repository state
-   - Specific changes with file:line references
-   - Recent development activity and themes
-   - Recommendations for what to focus on
-   - Any warnings (uncommitted changes, merge conflicts, etc.)
-
-## Scope Options
-
-- **Working tree** - Current uncommitted changes
-- **Recent commits** - Last N commits (default: 10)
-- **General overview** - Project structure, technologies, architecture
-- **Focused analysis** - Deep dive into specific areas
-- **Combined** - Mix any of the above
-
-## Tips
-
-- Run git commands in parallel for efficiency
-- Spawn @codebase-explorer and @researcher in parallel when both needed
-- Focus on actionable insights, not raw data
-- Provide file:line references for easy navigation
-- Identify development themes from commit history

package/refs/vbenchmark/.cursor/commands/init.md

@@ -1,56 +0,0 @@
----
-description: Initialize AGENTS.md file with best practices for agentic development
----
-
-# Initialize AGENTS.md
-
-Analyze the codebase and create an AGENTS.md file with project-specific guidance for AI coding agents.
-
-**Injected into every agent prompt** - Make it concise but comprehensive. Include only what agents can't infer from code.
-
-## Process
-
-1. **Analyze codebase** - Examine: README (project overview, tech stack, commands, setup), config files (package.json, tsconfig.json, etc.), project structure (business logic, database schemas, API routing, applications, components), code organization patterns, testing setup, existing agent rules (.cursor/rules/, .cursorrules, .github/copilot-instructions.md)
-2. **Generate AGENTS.md** - Include: **Build/lint/test commands** (especially single test execution), **Project structure** (where to find business logic, schemas, routes, apps, components), **Code style** (imports, formatting, types, naming, error handling), **Key conventions**, **Safety constraints**, incorporate existing Cursor/Copilot rules if found
-3. **Write** - If AGENTS.md exists, improve it; otherwise create new; write to specified path (default: current directory)
-
-## Guidelines
-
-- Be specific, not generic - avoid vague phrases like "Follow best practices"
-- Exact commands with syntax, especially single test execution
-- Essential sections: Commands, Code Style, Conventions, Safety
-
-## Example Structure
-
-Analyze the project and generate appropriate content. Example format only:
-
-```markdown
-# AGENTS.md
-
-## Commands
-- Install: [dependency install command]
-- Test all: [test command]
-- Test single: [single test execution with path]
-- Lint: [linter command]
-
-## Project Structure
-- Business logic: [location of core business logic]
-- Database schemas: [location of schema definitions]
-- API routes: [location of API routing/endpoints]
-- Applications: [location of app entry points]
-- Components: [location of UI/shared components]
-- Tests: [location and organization of tests]
-
-## Code Style
-- [Language-specific style guidelines]
-- [Import/module patterns]
-- [Error handling patterns]
-
-## Conventions
-- [File organization patterns]
-- [Naming conventions]
-
-## Safety
-- Never execute shell commands with user input
-- Never use `sudo` without explicit permission
-```

package/refs/vbenchmark/.cursor/commands/preset-help.md

@@ -1,50 +0,0 @@
----
-description: Explain what this preset provides and how to use it
----
-
-Explain this agentic development preset to me.
-
-## What to Cover
-
-### 1. The Orchestrator (@orchestrator)
-Explain the 5-step workflow:
-- **Understand** - Assess complexity, decide to ask or build
-- **Research** - Spawn subagents to gather context
-- **Plan** - Create plan, todos, surface unresolved questions
-- **Execute** - Work through tasks, delegate to specialists
-- **Complete** - Verify quality, all todos done
-
-### 2. Available Subagents
-Explain each and when to use:
-- **@codebase-explorer** - Find files, analyze implementations, trace data flow
-- **@researcher** - External docs, best practices, API references
-- **@implementer** - Focused code changes to single files
-- **@tester** - Write tests (TDD or verification mode)
-- **@debugger** - Deep error diagnosis, root cause analysis
-- **@reviewer** - Code review for correctness, security, performance
-- **@documenter** - READMEs, API docs, guides, changelogs
-
-### 3. Available Commands
-List each with brief description:
-- `/commit` - Commit with meaningful message
-- `/review` - Code review with automated checks
-- `/test` - Run or write tests
-- `/debug` - Diagnose errors
-- `/refactor` - Refactor with safety checks
-- `/research` - Research codebase and external docs
-- `/document` - Generate documentation
-- `/init` - Create AGENTS.md for the project
-- `/gather-context` - Repo state and recent changes
-
-### 4. How to Work With This Setup
-- Just describe what you need - the orchestrator handles delegation
-- Use slash commands for specific workflows
-- The agent tracks progress with todos
-- You control git - agent won't auto-commit
-
-### 5. Customization
-- `AGENTS.md` - Add project-specific rules
-- `.agent/agents/` - Modify subagent behavior
-- `.agent/commands/` - Add or edit commands
-
-Keep the explanation practical and concise. Focus on how to use it, not theory.

package/refs/vbenchmark/.cursor/commands/refactor.md

@@ -1,71 +0,0 @@
----
-description: Large-scale refactoring with phased execution and validation
----
-
-Refactor $ARGUMENTS
-
-Help me refactor code systematically with minimal risk.
-
-## Strategy
-
-Minimize risk through:
-- Small phases (change one thing at a time)
-- Continuous testing (validate after each phase)
-- Incremental migration (old and new coexist temporarily)
-- Type-driven (let compiler catch breaks)
-- Reversible (each phase can be rolled back)
-
-## Workflow
-
-1. **Analyze** - Understand the scope:
-   - Spawn @codebase-explorer to find affected files and dependencies
-   - Spawn @tester to identify test coverage gaps
-   - Map integration points and risks
-
-2. **Design strategy** - Create a phased plan:
-   - Break into incremental phases that can be validated independently
-   - Each phase should be reversible and build on previous phases
-   - Present the strategy to me with phase breakdown and effort estimates
-   - Get my confirmation before proceeding
-
-3. **Prepare tests** - Establish baseline:
-   - Spawn @tester in TDD mode to create characterization tests
-   - Ensure existing behavior is captured
-   - Run tests to establish baseline (proves refactor doesn't change behavior)
-
-4. **Execute phases** - For each phase:
-   - Implement changes (stay focused on one thing)
-   - Run tests (spawn @debugger if failing)
-   - Type check and fix immediately
-   - Manual validation
-   - Atomic commit with clear message
-   - Update me on progress
-   - If phase fails repeatedly: reassess, break into smaller phases, ask me
-
-5. **Cleanup** - Finalize the refactoring:
-   - Remove scaffolding and temporary code
-   - Final validation (all tests pass, types valid, no dead code)
-   - Spawn @reviewer for final check
-   - Document lessons learned
-
-6. **Report** - Summarize for me:
-   - What was refactored
-   - Phases completed
-   - Tests added/updated
-   - Issues encountered
-   - Follow-up recommendations
-
-## Validation Checklist
-
-**After each phase:**
-- [ ] All tests pass
-- [ ] Types valid
-- [ ] Manual testing done
-- [ ] Commit created
-
-**Before declaring complete:**
-- [ ] All phases done
-- [ ] Old code removed
-- [ ] Tests comprehensive
-- [ ] Documentation updated
-- [ ] Review completed

package/refs/vbenchmark/.cursor/commands/research.md

@@ -1,37 +0,0 @@
----
-description: Research codebase and external docs with parallel analysis
----
-
-Research $ARGUMENTS
-
-Help me research a topic using codebase analysis and external docs.
-
-## Workflow
-
-1. **Understand what I need** - Ask me:
-   - Internal codebase understanding?
-   - External documentation/best practices?
-   - Combination of the above?
-
-2. **Spawn subagents in parallel** - Always run concurrently for efficiency:
-   - Spawn @codebase-explorer to find files and analyze implementations
-   - Spawn @researcher for external docs, best practices, comparisons
-   - Wait for all to complete
-
-3. **Synthesize findings** - Combine and analyze:
-   - **Codebase**: How it works, file:line references, patterns, architectural decisions
-   - **External**: Key concepts, best practices, code examples, pitfalls, doc links
-   - **Combined**: Current state vs recommended approach, gap analysis, options with trade-offs
-
-4. **Present results** - Show me:
-   - High-level overview
-   - Detailed findings with specific references (file:line, doc URLs)
-   - Patterns and best practices
-   - Actionable recommendations
-
-## Tips
-
-- Always run subagents in parallel for maximum efficiency
-- Focus on synthesis, not raw data dump
-- Provide actionable recommendations
-- Note version-specific information

package/refs/vbenchmark/.cursor/commands/review.md

@@ -1,38 +0,0 @@
----
-description: Comprehensive code review with testing and quality checks
----
-
-Review $ARGUMENTS
-
-Help me review code changes for quality, correctness, and best practices.
-
-## Workflow
-
-1. **Gather context** - Understand what changed:
-   - Run `git status` and `git diff` to see my changes
-   - Ask me what the purpose of these changes is
-
-2. **Run automated checks** - Execute in parallel:
-   - Run tests
-   - Run type checking
-   - Run linting
-
-3. **Manual review** - Deep inspection:
-   - Spawn @reviewer with full context (changes, test results, purpose)
-   - Focus on: correctness, security, performance, maintainability, architecture
-
-4. **Synthesize findings** - Organize by severity:
-   - 🔴 **CRITICAL** - Must fix (bugs, security, breaking changes)
-   - 🟡 **SUGGESTED** - Should fix (performance, maintainability)
-   - ℹ️ **NOTES** - Consider (style, minor improvements)
-
-5. **Provide verdict** - Give me clear recommendation:
-   - Approve
-   - Approve with notes
-   - Request changes
-
-For each issue, tell me:
-- Specific location (file:line)
-- What's wrong and why it matters
-- Suggested fix with example
-- Impact if not addressed

package/refs/vbenchmark/.cursor/commands/test.md

@@ -1,61 +0,0 @@
----
-description: Write comprehensive tests with TDD or verification approach
----
-
-Test $ARGUMENTS
-
-Help me write comprehensive tests for my code.
-
-## Workflow
-
-1. **Analyze** - Understand what to test:
-   - Spawn @codebase-explorer to find implementation files and test patterns
-   - Identify coverage gaps
-   - Ask me: TDD (tests before implementation) or Verification (tests for existing code)?
-
-2. **Plan strategy** - Prioritize test cases:
-   - Happy path → Edge cases → Error paths → Integration
-   - Focus on: core business logic, public APIs, error handling, security-critical code
-
-3. **Write tests** - Create comprehensive test suite:
-   - Spawn @tester with mode (TDD or Verification)
-   - Follow project conventions and framework patterns
-   - Use clear, descriptive test names (AAA pattern: Arrange, Act, Assert)
-
-4. **Execute** - Run and validate:
-   - Run tests
-   - Verify pass/fail matches expectations
-   - Check coverage
-
-5. **Iterate** - Improve coverage:
-   - If bugs found: spawn @debugger to fix
-   - Add missing test cases for edge cases
-   - Focus on critical paths
-
-## Test Priorities
-
-**Must test:**
-- Core business logic
-- Public APIs
-- Error handling
-- Security-critical code
-
-**Should test:**
-- Edge cases and boundaries
-- Integration points
-- Data transformations
-
-**Can skip:**
-- Trivial getters/setters
-- Framework code
-- Third-party libraries
-
-## Validation Checklist
-
-- [ ] All planned tests written
-- [ ] Tests follow project conventions
-- [ ] Clear, descriptive test names
-- [ ] Edge cases covered
-- [ ] Error paths tested
-- [ ] Tests pass (verification) or fail appropriately (TDD)
-- [ ] No flaky tests