@silverassist/agents-toolkit 2.0.0

package/templates/shared/prompts/prepare-pr.prompt.md

@@ -0,0 +1,123 @@
+---
+agent: agent
+description: Prepare code for a pull request by running all validations
+---
+
+# Prepare for Pull Request
+
+Prepare the current branch for a pull request by running all validations.
+
+## Prerequisites
+- Reference: `.github/prompts/_partials/validations.md`
+- Reference: `.github/prompts/_partials/git-operations.md`
+
+## Steps
+
+### 1. Check Branch Status
+
+```bash
+BASE_BRANCH=$(node -e "try{const c=require('./.agents-toolkit.json');console.log(c.pr?.targetBranch||c.git?.defaultBranch||'main')}catch{console.log('main')}")
+git branch --show-current
+git status
+git log --oneline -5
+```
+
+Verify:
+- Not on protected branch (main, dev, stg, master, `${BASE_BRANCH}`)
+- All changes are committed
+- Branch follows naming: `feature/TICKET-*` or `bugfix/TICKET-*`
+
+### 2. Code Quality Checks
+
+#### Lint Check
+```bash
+npm run lint --if-present
+```
+- Fix auto-fixable: `npm run lint --if-present -- --fix`
+- Report issues needing manual fix
+
+#### Type Check
+```bash
+npm run type-check --if-present
+if [ -f tsconfig.json ]; then npx tsc --noEmit; fi
+```
+- Fix any TypeScript errors
+- Ensure no `any` types introduced
+
+### 3. Run Test Suite
+
+```bash
+npm run test --if-present
+npm run build --if-present
+```
+- Review test results
+- Check coverage report
+- Fix any failing tests
+
+### 4. Code Review Checks
+
+Verify:
+- [ ] No `console.log` or debug statements
+- [ ] No sensitive data exposed (API keys, secrets)
+- [ ] No `any` types introduced
+- [ ] JSDoc comments on new/modified functions
+- [ ] Props interfaces documented
+
+### 5. Review Changes
+
+```bash
+git diff --stat
+git diff "$BASE_BRANCH" --name-only
+```
+
+Check:
+- Files changed align with ticket scope
+- No unintended changes
+- README/docs updated if needed
+
+### 6. Commit Hygiene
+
+Verify commit messages:
+- Follow format: `TICKET-ID: Description`
+- Use present tense, imperative mood
+- No merge commits (rebase on base branch if needed)
+
+If merge commits are present, rebase non-interactively on base branch:
+```bash
+git fetch origin
+git rebase "origin/${BASE_BRANCH}"
+```
+
+### 7. Documentation Check
+
+- [ ] JSDoc comments on new functions
+- [ ] README updated if needed
+- [ ] Inline comments for complex logic
+- [ ] Component props documented
+
+## Output: Readiness Report
+
+### ✅ Passed Checks
+- List all passed checks
+
+### ⚠️ Warnings
+- Issues to address but not blockers
+
+### ❌ Blockers
+- Must fix before proceeding
+
+### 📁 Changed Files
+- List all modified files
+
+### 📝 Summary
+Brief summary for PR description
+
+### 👥 Suggested Reviewers
+Based on changed files:
+- @reviewer1 (reason)
+- @reviewer2 (reason)
+
+## Next Steps
+- Fix any blockers
+- Address warnings
+- Use `create-pr` to create the pull request

package/templates/shared/prompts/prepare-release.prompt.md

@@ -0,0 +1,74 @@
+---
+description: Prepare a new release for a Silver Assist WordPress plugin (version bump, changelog, tag, PR)
+agent: agent
+tools:
+  - run_in_terminal
+  - read_file
+  - replace_string_in_file
+  - create_file
+---
+
+# Prepare Release
+
+Prepare a new version release for the current Silver Assist plugin.
+
+## Inputs
+
+Ask the user:
+1. **Version type** — Is this a `patch`, `minor`, or `major` release? (default: patch)
+2. **Changelog entry** — What changed? (or offer to generate from recent commits)
+
+## Steps
+
+1. **Detect plugin** — Find the plugin root, main plugin file, and current version.
+
+2. **Determine new version** — Based on the version type, calculate the next semantic version.
+
+3. **Run quality checks** — Execute `./scripts/run-quality-checks.sh --skip-wp-setup phpcs phpstan` to verify the code is clean before release. Do NOT proceed if checks fail.
+
+4. **Update version** — Run the version update script:
+   ```bash
+   ./scripts/update-version.sh X.Y.Z
+   ```
+   Or if the plugin uses the simple variant:
+   ```bash
+   ./scripts/update-version-simple.sh X.Y.Z
+   ```
+   This updates the version in the main plugin file, `readme.txt` (if present), and `composer.json`.
+
+5. **Update CHANGELOG.md** — Add a new entry at the top following this format:
+   ```markdown
+   ## [X.Y.Z] - YYYY-MM-DD
+
+   ### Added/Changed/Fixed
+   - Description of change
+   ```
+
+6. **Create release branch and commit** — Following the branch naming convention:
+   ```bash
+   git checkout -b release/vX.Y.Z
+   git add -A
+   git commit -m "chore: bump version to X.Y.Z"
+   ```
+
+7. **Push and create PR** — Push the branch and create a PR:
+   ```bash
+   git push origin release/vX.Y.Z
+   gh pr create --title "Release vX.Y.Z" --body "## Changes\n\n- changelog entry" | cat
+   ```
+
+8. **Post-merge instructions** — Remind the user:
+   - After merging the PR, create the tag from the main/master branch:
+     ```bash
+     git checkout main && git pull
+     git tag vX.Y.Z
+     git push origin vX.Y.Z
+     ```
+   - The GitHub Actions release workflow will automatically build the ZIP and create the GitHub Release.
+
+## Important
+
+- **NEVER reuse an existing tag** — tags are immutable. If a tag exists, bump to the next version.
+- The release-management skill has full documentation — use it for troubleshooting.
+- Some plugins use `master` instead of `main` (e.g., silver-assist-post-revalidate).
+- Always verify the default branch with `git branch --show-current` or `gh repo view --json defaultBranchRef | cat`.

package/templates/shared/prompts/quality-check.prompt.md

@@ -0,0 +1,45 @@
+---
+description: Run code quality checks (PHPCS, PHPStan, PHPUnit) on a Silver Assist WordPress plugin
+agent: agent
+tools:
+  - run_in_terminal
+  - read_file
+  - replace_string_in_file
+---
+
+# Quality Check
+
+Run the full quality check suite on the current Silver Assist plugin.
+
+## Steps
+
+1. **Detect the plugin** — Identify the plugin root directory from the current workspace or active file. Look for `composer.json` and the main plugin PHP file.
+
+2. **Ensure dependencies** — Verify `vendor/` exists. If not, run `composer install`.
+
+3. **Run PHPCS** — Execute `vendor/bin/phpcs` to check WordPress Coding Standards compliance.
+   - If errors are found, first attempt auto-fix with `vendor/bin/phpcbf`.
+   - Re-run `vendor/bin/phpcs` and report remaining errors that need manual fixes.
+
+4. **Run PHPStan** — Execute `vendor/bin/phpstan analyse --memory-limit=1G` for static analysis at level 8.
+   - Report any type errors with file locations and suggested fixes.
+
+5. **Run PHPUnit** — Execute `vendor/bin/phpunit` to run the test suite.
+   - If the WordPress Test Suite is not available, note which tests failed and why.
+
+6. **Summary** — Provide a clear summary table:
+
+| Check   | Status | Issues |
+|---------|--------|--------|
+| PHPCS   | ✅/❌  | Count  |
+| PHPStan | ✅/❌  | Count  |
+| PHPUnit | ✅/❌  | Count  |
+
+If all checks pass, confirm the plugin is ready for commit/release.
+If any check fails, provide actionable fix suggestions.
+
+## Important
+
+- Always run checks from the **plugin root directory** (where `composer.json` is).
+- Use `| cat` after commands to avoid pager issues.
+- The quality-checks skill has full documentation on rules and common errors — use it if needed.

package/templates/shared/prompts/review-code.prompt.md

@@ -0,0 +1,81 @@
+---
+agent: agent
+description: Quick code review of current changes
+---
+
+# Quick Code Review
+
+Perform a quick code review of the current changes.
+
+## Steps
+
+### 1. Get Changed Files
+
+```bash
+git diff --name-only HEAD~1
+# or for unstaged changes:
+git diff --name-only
+```
+
+### 2. Review Each File
+
+For each changed file:
+
+#### Code Quality
+- [ ] No `console.log` or debug statements
+- [ ] No `any` types
+- [ ] No hardcoded values (use constants)
+- [ ] No commented-out code
+
+#### Style & Conventions
+- [ ] Follows project naming conventions
+- [ ] Imports organized alphabetically
+- [ ] Proper TypeScript types
+- [ ] Consistent formatting
+
+#### Logic
+- [ ] No nested ternaries
+- [ ] Early returns used appropriately
+- [ ] Error handling in place
+- [ ] Edge cases considered
+
+#### Documentation
+- [ ] JSDoc on new functions
+- [ ] Complex logic has comments
+- [ ] Props interfaces documented
+
+### 3. Security Check
+
+- [ ] No sensitive data (API keys, secrets)
+- [ ] No exposed credentials
+- [ ] No unsafe user input handling
+
+### 4. Performance
+
+- [ ] No unnecessary re-renders (React)
+- [ ] Efficient data structures
+- [ ] No memory leaks potential
+
+## Output
+
+### Review Summary
+
+| File | Status | Issues |
+|------|--------|--------|
+| file1.ts | ✅/⚠️/❌ | issue description |
+| file2.tsx | ✅/⚠️/❌ | issue description |
+
+### Issues Found
+
+#### ❌ Critical (must fix)
+- Issue 1: Description and fix
+
+#### ⚠️ Warnings (should fix)
+- Warning 1: Description and suggestion
+
+#### 💡 Suggestions (nice to have)
+- Suggestion 1: Improvement idea
+
+### Overall
+- **Status**: Ready / Needs Work
+- **Recommendation**: Summary

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

@@ -0,0 +1,96 @@
+---
+agent: agent
+description: Start working on a GitHub issue with full workflow setup
+---
+
+# Work on GitHub Issue
+
+Start working on GitHub issue **#{issue-number}** in repository **{owner}/{repo}** with complete workflow setup.
+
+## Prerequisites
+
+- GitHub MCP connection or `gh` CLI required
+- Reference: `.github/prompts/_partials/github-integration.md`
+- Reference: `.github/prompts/_partials/git-operations.md`
+
+## Steps
+
+### 1. Read Complete Issue
+
+Fetch issue **#{issue-number}** with all details:
+- Title and description
+- Labels and priority
+- Current state
+- All comments for context
+- Acceptance criteria
+
+### 2. Analyze Project Context
+
+Read project conventions:
+- `AGENTS.md` — Agent instructions (Copilot/Codex)
+- `CLAUDE.md` — Agent instructions (Claude Code)
+- `copilot-instructions.md` or `.github/copilot-instructions.md` — Project guidelines
+- `.github/instructions/` — File-type specific instructions
+- `docs/` — Related documentation
+
+### 3. Analyze Technical Impact
+
+Search codebase for:
+- Related components
+- Existing patterns
+- Files to modify
+- Dependencies
+
+### 4. Create Work Plan
+
+Create planning document at `docs/{feature-name}-plan.md`:
+- Problem statement
+- Current architecture
+- Proposed changes
+- Phase breakdown
+- Testing strategy
+
+### 5. Create Working Branch
+
+From latest `main`:
+```bash
+git checkout main
+git pull origin main
+git checkout -b feature/{issue-number}-short-description
+# or for bugs:
+git checkout -b fix/{issue-number}-short-description
+```
+
+### 6. Initial Commit
+
+```bash
+git add docs/{feature-name}-plan.md
+git commit -m "docs: Add implementation plan for #{issue-number}"
+```
+
+### 7. Update GitHub Issue
+
+Add comment to the issue:
+```markdown
+## Development Started
+- Branch: `feature/{issue-number}-description`
+- Plan: `docs/{feature-name}-plan.md`
+
+## Phases
+- [ ] Phase 1: ...
+- [ ] Phase 2: ...
+```
+
+## Output
+
+Report:
+1. ✅ Issue summary
+2. ✅ Branch created
+3. ✅ Planning document created
+4. ✅ Ready to start implementation
+
+## Next Steps
+
+- Begin implementation following the plan
+- Use `prepare-pr` when ready for review
+- Use `create-pr` to submit pull request

package/templates/shared/prompts/work-ticket.prompt.md

@@ -0,0 +1,98 @@
+---
+agent: agent
+description: Start working on a Jira ticket with full workflow setup
+---
+
+# Work on Jira Ticket
+
+Start working on Jira ticket **{ticket-id}** with complete workflow setup.
+
+## Prerequisites
+- Atlassian MCP connection required
+- Reference: `.github/prompts/_partials/jira-integration.md`
+- Reference: `.github/prompts/_partials/git-operations.md`
+
+## Steps
+
+### 1. Verify Jira Access
+- Use `getAccessibleAtlassianResources` to confirm connectivity
+- Get the correct cloud ID
+
+### 2. Read Complete Ticket
+
+Fetch ticket **{ticket-id}** with all details:
+- Summary and description
+- Issue type and priority
+- Current status
+- All comments for context
+- Acceptance criteria
+
+### 3. Analyze Project Context
+
+Read project conventions:
+- `AGENTS.md` - Main agent workflow guidelines
+- `.github/copilot-instructions.md` - Additional project guidelines (if present)
+- `.github/instructions/` - File-type specific instructions
+- `docs/` - Related documentation
+
+### 4. Analyze Technical Impact
+
+Search codebase for:
+- Related components
+- Existing patterns
+- Files to modify
+- Dependencies
+
+### 5. Create Work Plan
+
+Create planning document at `docs/{feature-name}-plan.md`:
+- Problem statement
+- Current architecture
+- Proposed changes
+- Phase breakdown
+- Testing strategy
+
+### 6. Create Working Branch
+
+Resolve base branch from config, then branch from latest base:
+```bash
+BASE_BRANCH=$(node -e "try{const c=require('./.agents-toolkit.json');console.log(c.pr?.targetBranch||c.git?.defaultBranch||'main')}catch{console.log('main')}")
+git checkout "$BASE_BRANCH"
+git pull origin "$BASE_BRANCH"
+git checkout -b feature/{ticket-id}-short-description
+# or for bugs:
+git checkout -b bugfix/{ticket-id}-short-description
+```
+
+### 7. Initial Commit
+
+```bash
+git add docs/{feature-name}-plan.md
+git commit -m "{ticket-id}: Add implementation plan"
+```
+
+### 8. Update Jira Ticket
+
+Add comment with development started:
+```markdown
+## Development Started
+- Branch: `feature/{ticket-id}-description`
+- Plan: `docs/{feature-name}-plan.md`
+
+## Phases
+- [ ] Phase 1: ...
+- [ ] Phase 2: ...
+```
+
+## Output
+
+Report:
+1. ✅ Jira ticket summary
+2. ✅ Branch created
+3. ✅ Planning document created
+4. ✅ Ready to start implementation
+
+## Next Steps
+- Begin implementation following the plan
+- Use `prepare-pr` when ready for review
+- Use `create-pr` to submit pull request

package/templates/shared/skills/README.md

@@ -0,0 +1,53 @@
+# Skills
+
+Skills are specialized knowledge guides that GitHub Copilot, Claude Code, and Codex can use to understand project-specific patterns and conventions.
+
+## What are Skills?
+
+Skills are markdown files with YAML frontmatter that provide domain-specific guidance. Unlike prompts (which are actions) or instructions (which are general guidelines), skills are **deep knowledge bases** for specific topics.
+
+## Structure
+
+Each skill lives in its own folder with a `SKILL.md` file:
+
+```
+.github/skills/
+├── component-architecture/
+│   └── SKILL.md
+├── domain-driven-design/
+│   └── SKILL.md
+└── testing-patterns/
+    └── SKILL.md
+```
+
+## Frontmatter Format
+
+```yaml
+---
+name: skill-name
+description: When to use this skill. Agents use this to decide relevance.
+---
+```
+
+## Available Skills
+
+| Skill | Description |
+|-------|-------------|
+| `component-architecture` | React component patterns, folder structure, naming conventions |
+| `domain-driven-design` | DDD principles, domain organization, barrel exports |
+| `testing-patterns` | Jest + RTL patterns for Next.js 15 and Server Actions |
+
+## Usage
+
+Skills are automatically picked up by agents when relevant to your question. You can also reference them explicitly:
+
+```
+@workspace Use the component-architecture skill to create a new payment form component
+```
+
+## Creating Custom Skills
+
+1. Create a folder: `.github/skills/your-skill-name/`
+2. Create `SKILL.md` with frontmatter
+3. Document patterns, examples, and conventions
+4. Include ✅ CORRECT and ❌ INCORRECT examples