@silverassist/agents-toolkit 2.0.0

package/templates/shared/prompts/_partials/jira-integration.md

@@ -0,0 +1,155 @@
+# Jira Integration Partial
+
+Reusable Jira/Atlassian MCP operations for prompts.
+
+## Usage
+
+Include these steps in prompts that require Jira integration.
+
+---
+
+## Ticket Operations
+
+### Step: Verify Jira Access
+
+1. **Test MCP connectivity**:
+   - Use Atlassian MCP `getAccessibleAtlassianResources` to verify access
+   - Confirm the correct cloud ID is available
+
+---
+
+### Step: Read Jira Ticket
+
+1. **Fetch ticket details**:
+   - Use `getJiraIssue` with the ticket ID
+   - Request fields: `summary`, `description`, `status`, `issuetype`, `priority`
+
+2. **Extract key information**:
+   - **Summary**: Main ticket title
+   - **Description**: Full details and context
+   - **Issue Type**: Feature, Bug, Task, etc.
+   - **Priority**: Critical, High, Medium, Low
+   - **Status**: Current workflow state
+
+3. **Read ticket comments**:
+   - Fetch all comments for additional context
+   - Note any clarifications or updates
+
+4. **Identify acceptance criteria**:
+   - Look in description for "Acceptance Criteria" section
+   - List all checkable requirements
+
+---
+
+### Step: Search Jira
+
+1. **Search using Rovo**:
+   - Use `search` tool for natural language queries
+   - Find related tickets or documentation
+
+2. **Search using JQL** (advanced):
+   - Use `searchJiraIssuesUsingJql` for specific queries
+   - Example: `project = WEB AND status = "In Progress"`
+
+---
+
+## Update Operations
+
+### Step: Add Comment to Ticket
+
+1. **Add progress comment**:
+   - Use `addCommentToJiraIssue`
+   - Include relevant links (PR, branch, etc.)
+   - Use Markdown formatting for readability
+
+2. **Comment templates**:
+   ```markdown
+   ## Development Started
+   - Branch: `feature/WEB-XXX-description`
+   - PR: [Link to PR]
+   
+   ## Progress
+   - [x] Initial implementation
+   - [ ] Tests
+   - [ ] Documentation
+   ```
+
+---
+
+### Step: Transition Ticket Status
+
+1. **Get available transitions**:
+   - Use `getTransitionsForJiraIssue` to see valid next states
+
+2. **Transition ticket**:
+   - Use `transitionJiraIssue` with the transition ID
+   - Common transitions:
+     - "In Progress" → Development started
+     - "In Review" → PR created
+     - "Ready for QA" → PR merged
+     - "Done" → Verified and complete
+
+---
+
+### Step: Link PR to Ticket
+
+1. **Add PR comment**:
+   ```markdown
+   ## Pull Request
+   - PR Link: [PR Title](PR_URL)
+   - Target: `dev` branch
+   - Reviewers: @team-member
+   ```
+
+2. **The Bitbucket-Jira integration** will automatically link PRs if:
+   - Ticket ID is in branch name
+   - Ticket ID is in PR title
+
+---
+
+## Ticket Analysis
+
+### Step: Analyze Ticket Impact
+
+1. **Identify affected areas**:
+   - Components that need changes
+   - Files likely to be modified
+   - Dependencies and integrations
+
+2. **Estimate complexity**:
+   - **Simple**: 1-2 files, straightforward change
+   - **Medium**: 3-5 files, some logic changes
+   - **Complex**: 6+ files, architectural changes
+
+3. **Identify risks**:
+   - Breaking changes
+   - Migration requirements
+   - External dependencies
+   - Testing complexity
+
+---
+
+## Common JQL Queries
+
+| Purpose | JQL Query |
+|---------|-----------|
+| My open tickets | `assignee = currentUser() AND status != Done` |
+| Sprint tickets | `project = WEB AND sprint in openSprints()` |
+| Recently updated | `project = WEB AND updated >= -7d` |
+| Blockers | `project = WEB AND priority = Highest` |
+| PR ready | `project = WEB AND status = "In Review"` |
+
+---
+
+## Ticket Workflow States
+
+```
+┌──────────┐    ┌─────────────┐    ┌───────────┐
+│   Open   │───▶│ In Progress │───▶│ In Review │
+└──────────┘    └─────────────┘    └───────────┘
+                                         │
+                                         ▼
+                ┌──────────┐     ┌──────────────┐
+                │   Done   │◀────│ Ready for QA │
+                └──────────┘     └──────────────┘
+```

package/templates/shared/prompts/_partials/pr-template.md

@@ -0,0 +1,216 @@
+# Pull Request Template Partial
+
+Reusable PR templates and steps for prompts.
+
+## Usage
+
+Include these templates when creating or reviewing pull requests. Choose the format matching your project's issue tracker.
+
+---
+
+## Format A: GitHub Issues (Conventional Commits)
+
+### PR Title Format
+
+```
+type: Short description of changes
+```
+
+Examples:
+- `feat: Add rate limiting middleware`
+- `fix: Resolve CORS headers for image requests`
+- `refactor: Extract validation into middleware`
+
+### PR Description Template
+
+```markdown
+## Description
+Brief summary of what this PR accomplishes.
+
+## Related Issue
+Closes #ISSUE_NUMBER
+
+## Changes Made
+- Change 1: Description
+- Change 2: Description
+- Change 3: Description
+
+## Type of Change
+- [ ] Bug fix (non-breaking change fixing an issue)
+- [ ] New feature (non-breaking change adding functionality)
+- [ ] Breaking change (fix or feature causing existing functionality to break)
+- [ ] Documentation update
+- [ ] Refactoring (no functional changes)
+
+## Testing
+- [ ] Unit tests added/updated
+- [ ] Manual testing performed
+- [ ] Integration tests added/updated
+
+## Checklist
+- [ ] Code follows project style guidelines
+- [ ] Self-review completed
+- [ ] Documentation updated
+- [ ] Tests pass locally
+- [ ] No new warnings introduced
+```
+
+---
+
+## Format B: Jira Ticket Reference
+
+### PR Title Format
+
+```
+{TICKET-ID}: Short description of changes
+```
+
+Examples:
+- `WEB-726: Add font size accessibility controls`
+- `WEB-734: Fix responsive logo sizing in mobile header`
+- `WEB-800: Refactor contact form validation`
+
+### PR Description Template
+
+```markdown
+## Summary
+Brief description of what this PR accomplishes.
+
+## Jira Ticket
+[{TICKET-ID}](https://your-org.atlassian.net/browse/{TICKET-ID})
+
+## Changes Made
+- Change 1: Description
+- Change 2: Description
+- Change 3: Description
+
+## Type of Change
+- [ ] 🐛 Bug fix (non-breaking change fixing an issue)
+- [ ] ✨ New feature (non-breaking change adding functionality)
+- [ ] 💥 Breaking change (fix or feature causing existing functionality to break)
+- [ ] 📝 Documentation update
+- [ ] 🔧 Refactoring (no functional changes)
+- [ ] 🧪 Test addition or update
+
+## Testing
+Describe how changes were tested:
+- [ ] Unit tests added/updated
+- [ ] Manual testing performed
+- [ ] E2E tests added/updated
+
+## Checklist
+- [ ] Code follows project style guidelines
+- [ ] Self-review completed
+- [ ] Comments added for complex logic
+- [ ] Documentation updated
+- [ ] No new warnings introduced
+- [ ] Tests pass locally
+
+## Deployment Notes
+Any special deployment considerations:
+- Database migrations needed
+- Environment variables to add
+- Cache invalidation required
+```
+
+---
+
+## PR Checklist Steps
+
+### Step: Prepare PR Description
+
+1. **Gather information**:
+   - Get issue/ticket title and description
+   - List all changed files
+   - Identify type of change
+
+2. **Fill template sections**:
+   - Summary from issue description
+   - Link to issue (GitHub `Closes #N` or Jira URL)
+   - List key changes made
+   - Describe testing performed
+
+3. **Add context**:
+   - Screenshots for UI changes
+   - Before/after comparisons
+   - Architecture diagrams if complex
+
+---
+
+### Step: Set PR Metadata
+
+1. **Title**: `type: description` (GitHub) or `{TICKET-ID}: description` (Jira)
+2. **Source branch**: Your feature/fix branch
+3. **Target branch**: `main` (or project default from `.agents-toolkit.json`)
+4. **Reviewers**: Based on code owners or changed files
+5. **Labels**: Match issue labels where appropriate
+
+---
+
+## PR Size Guidelines
+
+| Size | Files Changed | Recommendation |
+|------|---------------|----------------|
+| Small | 1-5 files | ✅ Ideal |
+| Medium | 6-15 files | ⚠️ Acceptable |
+| Large | 16+ files | ❌ Consider splitting |
+
+---
+
+## PR Merge Checklist
+
+Before merging:
+- [ ] All review comments addressed
+- [ ] CI/CD pipeline passes
+- [ ] Branch is up-to-date with target
+- [ ] No merge conflicts
+- [ ] Documentation complete
+- [ ] Issue linked and will auto-close
+
+## PR Size Guidelines
+
+| Size | Files Changed | Recommendation |
+|------|---------------|----------------|
+| Small | 1-5 files | ✅ Ideal |
+| Medium | 6-15 files | ⚠️ Acceptable |
+| Large | 16+ files | ❌ Consider splitting |
+
+**Tips for large PRs**:
+- Split into multiple smaller PRs
+- Create base branch for related changes
+- Use feature flags for partial releases
+
+---
+
+## Common PR Comments
+
+### Request Changes
+```markdown
+**Suggestion:** Consider using X instead of Y because...
+
+**Issue:** This could cause Z problem in edge case...
+
+**Question:** What happens when...?
+```
+
+### Approval
+```markdown
+✅ LGTM! 
+
+Reviewed:
+- Code quality
+- Test coverage
+- Documentation
+```
+
+---
+
+## PR Merge Checklist
+
+Before merging:
+- [ ] All review comments addressed
+- [ ] CI/CD pipeline passes
+- [ ] Branch is up-to-date with target
+- [ ] No merge conflicts
+- [ ] Documentation complete
+- [ ] Jira ticket updated

package/templates/shared/prompts/_partials/validations.md

@@ -0,0 +1,87 @@
+# Validations Partial
+
+Reusable validation steps for code quality checks.
+
+## Usage
+
+Include these steps in prompts that require code validation before proceeding.
+
+---
+
+## Code Quality Validation Steps
+
+### Step: Run Validations
+
+Before running checks, inspect `package.json` scripts and use project-supported commands.
+
+Use this order:
+- Lint: `npm run lint` (if script exists)
+- TypeScript: `npm run type-check` (if script exists), otherwise `npx tsc --noEmit` when `tsconfig.json` exists
+- Tests: `npm run test` (if script exists)
+- Build (recommended before PR to protected branches): `npm run build` (if script exists)
+
+**Run all code quality checks:**
+
+1. **Lint check**:
+   - Run `npm run lint --if-present` to check for linting errors
+   - Fix any auto-fixable issues with `npm run lint --if-present -- --fix`
+   - Report any remaining issues that need manual attention
+
+2. **Type check**:
+   - Run `npm run type-check --if-present` if available
+   - If there is no `type-check` script and `tsconfig.json` exists, run `npx tsc --noEmit`
+   - Identify and fix any type errors
+   - Ensure no `any` types were introduced
+
+3. **Test suite**:
+   - Run `npm run test --if-present` to execute all unit tests
+   - Review test coverage if available
+   - Identify any failing tests and suggest fixes
+   - Ensure no regressions were introduced
+
+4. **Build check**:
+   - Run `npm run build --if-present` before PR/push to protected branches
+   - Ensure no build-time regressions
+
+5. **Report results**:
+   - ✅ List all passed checks
+   - ⚠️ List warnings that should be addressed
+   - ❌ List blockers that must be fixed before proceeding
+
+---
+
+## Quick Validation (Minimal)
+
+For quick checks without full test suite:
+
+```bash
+npm run lint --if-present
+npm run type-check --if-present
+if [ -f tsconfig.json ]; then npx tsc --noEmit; fi
+```
+
+---
+
+## Full Validation (Comprehensive)
+
+For complete validation before PR:
+
+```bash
+npm run lint --if-present
+npm run type-check --if-present
+if [ -f tsconfig.json ]; then npx tsc --noEmit; fi
+npm run test --if-present
+npm run build --if-present
+```
+
+---
+
+## Validation Checklist
+
+- [ ] No linting errors
+- [ ] No TypeScript errors
+- [ ] All tests pass
+- [ ] No `console.log` or debug statements
+- [ ] No sensitive data exposed (API keys, secrets)
+- [ ] No `any` types introduced
+- [ ] JSDoc comments on new functions

package/templates/shared/prompts/add-tests.prompt.md

@@ -0,0 +1,151 @@
+---
+agent: agent
+description: Add tests for a component or function
+---
+
+# Add Tests
+
+Add tests for **{target-file}** or **{component-name}**.
+
+## Prerequisites
+- Reference: `.github/instructions/tests.instructions.md`
+
+## Steps
+
+### 1. Analyze Target
+
+Read the target file to understand:
+- Exported functions/components
+- Props and interfaces
+- Dependencies and imports
+- Edge cases to test
+
+### 2. Determine Test Location
+
+Based on project structure:
+- Components: `src/components/{name}/__tests__/{name}.test.tsx`
+- Hooks: `src/hooks/__tests__/{hook-name}.test.ts`
+- Utils: `src/lib/__tests__/{util-name}.test.ts`
+- Actions: `src/actions/__tests__/{action-name}.test.ts`
+
+### 3. Create Test File
+
+Use this template:
+
+```typescript
+import { render, screen } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+import ComponentName from '../index';
+
+describe('ComponentName', () => {
+  // Setup
+  const defaultProps = {
+    // default test props
+  };
+
+  // Rendering tests
+  describe('rendering', () => {
+    it('renders without crashing', () => {
+      render(<ComponentName {...defaultProps} />);
+      expect(screen.getByRole('...')).toBeInTheDocument();
+    });
+
+    it('renders with custom props', () => {
+      render(<ComponentName {...defaultProps} customProp="value" />);
+      expect(screen.getByText('value')).toBeInTheDocument();
+    });
+  });
+
+  // Behavior tests
+  describe('behavior', () => {
+    it('handles click events', async () => {
+      const user = userEvent.setup();
+      const handleClick = jest.fn();
+      
+      render(<ComponentName {...defaultProps} onClick={handleClick} />);
+      await user.click(screen.getByRole('button'));
+      
+      expect(handleClick).toHaveBeenCalledTimes(1);
+    });
+  });
+
+  // Edge cases
+  describe('edge cases', () => {
+    it('handles empty data', () => {
+      render(<ComponentName {...defaultProps} data={[]} />);
+      expect(screen.getByText('No data')).toBeInTheDocument();
+    });
+
+    it('handles null values', () => {
+      render(<ComponentName {...defaultProps} value={null} />);
+      expect(screen.queryByText('error')).not.toBeInTheDocument();
+    });
+  });
+});
+```
+
+### 4. Test Categories
+
+Include tests for:
+
+#### Rendering
+- [ ] Renders without crashing
+- [ ] Renders all expected elements
+- [ ] Conditional rendering works
+
+#### Props
+- [ ] Default props work
+- [ ] Custom props applied correctly
+- [ ] Required props validated
+
+#### User Interactions
+- [ ] Click handlers work
+- [ ] Form inputs update
+- [ ] Keyboard navigation
+
+#### State Changes
+- [ ] Initial state correct
+- [ ] State updates properly
+- [ ] Side effects trigger
+
+#### Edge Cases
+- [ ] Empty data handled
+- [ ] Null/undefined handled
+- [ ] Error states displayed
+
+### 5. Run Tests
+
+```bash
+# Preferred when test runner supports file filters (Jest/Vitest):
+npm run test -- --testPathPattern="{test-file}"
+
+# Fallback for projects without file-filter flags:
+npm run test --if-present
+```
+
+### 6. Check Coverage
+
+```bash
+# If coverage is configured in the project:
+npm run test -- --coverage
+```
+
+## Output
+
+### Test Summary
+- Tests created: N
+- Passing: N
+- Coverage: X%
+
+### Test Cases
+1. ✅ Test case 1
+2. ✅ Test case 2
+3. ✅ Test case 3
+
+### Coverage Report
+| Metric | Coverage |
+|--------|----------|
+| Statements | X% |
+| Branches | X% |
+| Functions | X% |
+| Lines | X% |

package/templates/shared/prompts/analyze-github-issue.prompt.md

@@ -0,0 +1,73 @@
+---
+agent: agent
+description: Analyze a GitHub issue without creating branches or making changes
+---
+
+# Analyze GitHub Issue
+
+Analyze GitHub issue **#{issue-number}** in repository **{owner}/{repo}** and provide a comprehensive assessment without making any code changes.
+
+## Prerequisites
+
+- GitHub MCP connection or `gh` CLI required
+- Reference: `.github/prompts/_partials/github-integration.md`
+
+## Steps
+
+### 1. Fetch Issue Details
+
+- Use `mcp_github_github_issue_read` with the issue number, or `gh issue view {issue-number} | cat`
+- Read: title, body, labels, assignees, milestone, and linked pull requests
+- Read all comments for additional context and discussion
+
+### 2. Analyze Codebase Impact
+
+- Search the codebase for related components, files, and patterns
+- Identify files likely to be created or modified
+- Check for existing implementations or patterns that should be followed
+- Review project conventions (README, copilot-instructions.md, existing architecture)
+
+### 3. Check Related Issues
+
+- Search for related or dependent issues using labels or keywords
+- Identify blockers or prerequisites
+- Note any duplicate or overlapping issues
+
+### 4. Generate Report
+
+Provide the following structured analysis:
+
+#### Summary
+Brief overview of what needs to be done.
+
+#### Acceptance Criteria
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+(Extract from issue body if present, or derive from the description)
+
+#### Technical Impact
+| Area | Files/Components | Impact Level |
+|------|------------------|--------------|
+| Components | list | High/Medium/Low |
+| Tests | list | High/Medium/Low |
+| Config | list | High/Medium/Low |
+
+#### Complexity Estimate
+- **Level**: Simple / Medium / Complex
+- **Estimated effort**: X hours/days
+- **Reasoning**: Why this complexity level
+
+#### Risks & Blockers
+- Risk 1: Description and mitigation
+- Risk 2: Description and mitigation
+
+#### Dependencies
+- Related issues: #X, #Y
+- External dependencies: packages, services
+- Prerequisites that must be completed first
+
+## Output Format
+
+Present findings in a clear, structured format that can be referenced during implementation. Do NOT create branches, write code, or make any changes — analysis only.