symfonia-ai-tools 1.0.0

package/templates/base/_ai/prompts/security-review.prompt.md

@@ -0,0 +1,46 @@
+# Security Review
+
+Perform a security audit of the current branch changes. Check for OWASP Top 10 vulnerabilities and common security issues.
+
+## Steps
+
+1. Run `git diff {{BASE_BRANCH}}...{{CURRENT_BRANCH}} --name-only` to get changed files
+2. Read each changed file and analyze for:
+
+### Input Validation
+- [ ] All user input is validated and sanitized
+- [ ] No SQL injection vectors (raw queries with string interpolation)
+- [ ] No XSS vectors (unescaped output in HTML/templates)
+- [ ] No command injection (user input in shell commands)
+- [ ] No path traversal (user input in file paths)
+
+### Authentication & Authorization
+- [ ] Auth checks on every protected endpoint
+- [ ] No hardcoded credentials, tokens, or API keys
+- [ ] Secrets come from environment variables, not code
+- [ ] Session handling is secure
+
+### Data Exposure
+- [ ] No sensitive data in logs (passwords, tokens, PII)
+- [ ] API responses don't leak internal data (stack traces, DB schema)
+- [ ] Error messages don't reveal implementation details
+- [ ] No `.env` files or secrets in committed code
+
+### Dependencies
+- [ ] No known vulnerable dependencies
+- [ ] Dependencies are pinned to specific versions
+
+### General
+- [ ] CORS configured correctly (not `*` in production)
+- [ ] HTTPS enforced for external calls
+- [ ] Rate limiting on public endpoints
+- [ ] File uploads validated (type, size, content)
+
+## Output
+
+For each finding:
+1. **Severity**: Critical / High / Medium / Low
+2. **File:line**: exact location
+3. **Issue**: what's wrong
+4. **Fix**: how to fix it
+5. **Code**: corrected code snippet

package/templates/base/_ai/skills/README.md

@@ -0,0 +1,80 @@
+# Skills Framework
+
+Specialized AI agent skills providing expert guidance on specific aspects of development.
+
+## Available Skills Structure
+
+```
+.github/skills/           # GitHub Copilot skills
+├── README.md
+├── TEMPLATE.md
+├── skill-name/
+│   └── SKILL.md
+└── another-skill/
+    └── SKILL.md
+
+.cursor/skills/            # Cursor IDE skills
+├── skill-name/
+│   └── SKILL.md
+└── another-skill/
+    └── SKILL.md
+```
+
+## Creating a New Skill
+
+### 1. Copy Template
+```bash
+mkdir -p .github/skills/my-skill
+cp templates/skills/TEMPLATE.md .github/skills/my-skill/SKILL.md
+```
+
+### 2. Fill In Metadata
+```yaml
+---
+name: my-skill
+description: Clear one-sentence description
+---
+```
+
+### 3. Complete Content
+1. Title and Overview
+2. When to Use (5-10 specific scenarios)
+3. Main Sections with code examples
+4. Best Practices (do's and don'ts)
+5. Quick Reference
+
+### 4. Quality Checklist
+- [ ] Front matter complete
+- [ ] "When to Use" has 5+ scenarios
+- [ ] At least 3 code examples
+- [ ] Best practices with do's/don'ts
+- [ ] Quick reference section
+- [ ] No placeholder text
+
+## Content Principles
+
+1. **Specific > Generic** - Focus on project-specific patterns
+2. **Examples > Theory** - Show, don't just tell
+3. **Actionable > Descriptive** - Clear next steps
+4. **Concise > Verbose** - Respect reader's time
+
+## Using Skills in Conversations
+
+```
+"Using the playwright skill, help me write a test for login"
+"Review this code following codereview best practices"
+```
+
+## Skill Discovery
+
+**By Activity**:
+- Writing code → implementation skill
+- Reviewing code → codereview skill
+- Recording tests → playwright-record skill
+- Writing tests → playwright skill
+
+## Maintenance
+
+- Review monthly for outdated examples
+- Update after major project changes
+- Deprecate obsolete skills with notice + 3 month grace period

package/templates/base/_ai/skills/TEMPLATE.md

@@ -0,0 +1,106 @@
+---
+name: [skill-name]
+description: [One-sentence description of what this skill does and when to use it.]
+---
+
+# [Skill Display Name]
+
+[2-3 sentence overview. What it helps with, who it's for, main value.]
+
+## When to Use This Skill
+
+Use this skill when the user:
+
+- [Specific request pattern 1]
+- [Specific request pattern 2]
+- [Specific request pattern 3]
+- [Scenario 4]
+- [Scenario 5]
+
+## [Main Section 1: Core Concepts]
+
+[Primary concept or workflow]
+
+### [Key Component]
+
+```[language]
+// Example code
+```
+
+**Key Points**:
+- [Best practice 1]
+- [Best practice 2]
+
+## [Main Section 2: Practical Usage]
+
+### Step-by-Step Guide
+
+**Step 1: [Action]**
+[Instructions]
+
+```bash
+# Command
+```
+
+**Step 2: [Action]**
+[Instructions]
+
+### Common Patterns
+
+**Pattern 1: [Name]**
+[When to use]
+
+```[language]
+// Example
+```
+
+## Best Practices
+
+### Do's
+1. **[Practice 1]** - [Explanation]
+2. **[Practice 2]** - [Explanation]
+
+### Don'ts
+1. **[Anti-pattern 1]** - Why to avoid, what to do instead
+2. **[Anti-pattern 2]** - Why to avoid, what to do instead
+
+## Troubleshooting
+
+### Common Issues
+
+**Issue 1: [Problem]**
+- Symptoms: [What user sees]
+- Solution: [Steps to resolve]
+
+## Quick Reference
+
+### Key Commands
+```bash
+# [Description]
+[command]
+```
+
+### Cheat Sheet
+| Concept | Usage | Example |
+|---------|-------|---------|
+| [Item 1] | [When] | `[code]` |
+| [Item 2] | [When] | `[code]` |
+
+## Resources
+
+- **Related Skill**: `path/to/related/SKILL.md`
+- **Documentation**: `[path]`
+- **External**: [URL]
+
+---
+
+**Remember**: [Key takeaway for this skill]
+
+<!--
+TEMPLATE NOTES (remove when creating actual skill):
+1. Replace all [placeholders] with actual content
+2. Remove sections that don't apply
+3. Keep code examples relevant and tested
+4. Make "When to Use" specific and actionable
+5. Provide copy-paste-ready code snippets
+-->

package/templates/base/_ai/skills/babysit-prs/SKILL.md

@@ -0,0 +1,105 @@
+# Skill: Babysit PRs
+
+## Trigger
+Use when user wants to monitor PRs waiting for their review, check for new pull requests, or set up recurring PR review monitoring.
+
+## Overview
+
+Monitor open pull requests waiting for your review. Detects hosting platform (GitHub or Bitbucket) automatically from `git remote` and sets up a polling loop.
+
+## Step 1: Detect User and Repo
+
+```bash
+git config user.name
+git remote get-url origin
+```
+
+**Parse origin URL** to determine platform and extract workspace/repo:
+- `git@github.com:{owner}/{repo}.git` → GitHub, owner, repo
+- `https://github.com/{owner}/{repo}.git` → GitHub, owner, repo
+- `git@bitbucket.org:{workspace}/{repo}.git` → Bitbucket, workspace, repo
+- `https://bitbucket.org/{workspace}/{repo}.git` → Bitbucket, workspace, repo
+
+Store as `{USER_NAME}`, `{OWNER}`, `{REPO}`, `{PLATFORM}`, `{TODAY}` (YYYY-MM-DD).
+
+## Step 2: Setup Loop
+
+1. Use CronCreate with `*/10 * * * *` and the cron prompt below (substitute values)
+2. Confirm job ID
+3. Run first check immediately
+
+### Cron Prompt (template)
+
+```
+Check PRs waiting for review. Platform: {PLATFORM}. Repo: {OWNER}/{REPO}. User: {USER_NAME}. Today: {TODAY}. Fetch open PRs. For each PR where author is NOT {USER_NAME}, check if {USER_NAME} already approved — skip if so. For remaining PRs, fetch the diff and do a quick summary — what changed, how big, any obvious issues. Show table: PR | Description | Verdict | Link | Action. If none: "No new PRs to review."
+```
+
+## Step 3: How to Check PRs
+
+### GitHub (using `gh` CLI)
+
+1. Fetch open PRs requesting your review:
+   ```bash
+   gh pr list --repo {OWNER}/{REPO} --search "is:open review-requested:@me" --json number,title,author,headRefName,url
+   ```
+
+2. For each PR, check if you already approved:
+   ```bash
+   gh pr view {number} --repo {OWNER}/{REPO} --json reviews --jq '.reviews[] | select(.author.login == "{USER_NAME}" and .state == "APPROVED")'
+   ```
+   Skip PRs where you already approved.
+
+3. For remaining PRs, fetch the diff:
+   ```bash
+   gh pr diff {number} --repo {OWNER}/{REPO}
+   ```
+
+### Bitbucket (using MCP)
+
+1. Fetch open PRs:
+   ```
+   mcp__mcp-bitbucket__bb_get
+   path: /repositories/{OWNER}/{REPO}/pullrequests
+   queryParams: {"pagelen": "50", "q": "state=\"OPEN\" AND created_on >= {TODAY}"}
+   ```
+
+2. Filter out PRs where author matches `{USER_NAME}`.
+
+3. For each remaining PR, fetch participants:
+   ```
+   mcp__mcp-bitbucket__bb_get
+   path: /repositories/{OWNER}/{REPO}/pullrequests/{id}
+   ```
+   Skip PRs where `{USER_NAME}` has `approved: true`.
+
+4. For remaining PRs, fetch diff:
+   ```
+   mcp__mcp-bitbucket__bb_get
+   path: /repositories/{OWNER}/{REPO}/pullrequests/{id}/diff
+   ```
+
+## Step 4: Present Results
+
+| PR | Description | Verdict | Link | Action |
+|----|-------------|---------|------|--------|
+| **#1234** TICKET | What changed (1-2 sentences) | **LOOKS GOOD** / **CHECK** + reason | [Open PR](url) | `approve 1234` |
+
+- **LOOKS GOOD**: small, clear change, no obvious issues
+- **CHECK**: large change, complex logic, or something that needs closer human review
+- After table: "Type `approve {id}` to auto-approve, or `approve all` to approve all."
+
+## Step 5: Approve
+
+### GitHub
+```bash
+gh pr review {number} --repo {OWNER}/{REPO} --approve
+```
+
+### Bitbucket
+```
+mcp__mcp-bitbucket__bb_post
+path: /repositories/{OWNER}/{REPO}/pullrequests/{id}/approve
+body: {}
+```
+
+If no PRs need review: "No new PRs to review."

package/templates/base/_ai/skills/debug/SKILL.md

@@ -0,0 +1,93 @@
+# Skill: Systematic Debugging
+
+## Trigger
+Use when investigating a bug or unexpected behavior.
+
+## Input
+- Bug description / error message
+- Steps to reproduce
+- Expected vs actual behavior
+
+## Steps
+
+### 1. Reproduce the bug
+
+Before investigating, confirm the bug exists:
+- Follow the exact reproduction steps
+- Capture the error message, stack trace, or unexpected output
+- Note the environment (dev/staging/prod, browser, etc.)
+
+If you cannot reproduce → ask for more details. Do not guess.
+
+### 2. Read the error
+
+Parse the error message/stack trace:
+- **What** failed (file, line, function)
+- **Why** (null reference, type error, 404, timeout, etc.)
+- **Where** in the call chain
+
+### 3. Form a hypothesis
+
+Based on the error, form ONE specific hypothesis:
+- "The user object is null because the auth middleware is not applied"
+- "The API returns 422 because field X is required but not sent"
+
+Write it down. Do not investigate multiple hypotheses at once.
+
+### 4. Verify hypothesis
+
+Add minimal logging/debugging to confirm or reject:
+
+```bash
+# Check logs
+{{TEST_COMMAND}}  # or check log files
+```
+
+- Read the relevant code carefully
+- Check recent changes (git log, git diff)
+- Check configuration
+
+### 5. If hypothesis is wrong
+
+- Document what you learned
+- Form a new hypothesis based on new information
+- Go back to step 4
+
+### 6. If hypothesis is correct → fix
+
+- Make the smallest fix possible
+- Do not refactor surrounding code
+- Do not fix other issues you noticed (note them separately)
+
+### 7. Verify the fix
+
+```bash
+# Reproduce original steps - bug should be gone
+{{TEST_COMMAND}}
+
+# Run full test suite - nothing else should break
+{{LINT_COMMAND}}
+```
+
+### 8. Write regression test
+
+Create a test that would have caught this bug:
+
+```
+test_[what_was_broken]_[expected_behavior]
+```
+
+The test should:
+- Fail without the fix
+- Pass with the fix
+
+### 9. Verification checklist
+
+- [ ] Bug confirmed reproducible before fix
+- [ ] Root cause identified (not just symptom)
+- [ ] Fix is minimal and focused
+- [ ] Original reproduction steps now pass
+- [ ] Full test suite passes
+- [ ] Regression test added
+- [ ] No debug logging left in code
+- [ ] Commit message describes the root cause

package/templates/base/_ai/skills/fill-worklogs/SKILL.md

@@ -0,0 +1,158 @@
+# Skill: Fill Worklogs
+
+## Trigger
+Use when needing to fill Jira worklogs to meet daily hour targets, when user says to log hours, fill timesheets, complete worklogs for a date or date range, or when asked about missing logged time.
+
+## Overview
+
+Fills Jira worklog gaps by cross-referencing git commits with existing Jira worklogs, then proposing and registering time entries to meet the daily target. Requires Jira MCP server.
+
+## Input
+
+Accepts flexible date inputs from the user:
+
+| Input | Interpretation |
+|-------|---------------|
+| `today` | Current date only |
+| `yesterday` | Previous workday |
+| `this week` | Mon-Fri of current week |
+| `last week` | Mon-Fri of previous week |
+| `2026-03-25` | Single date |
+| `2026-03-23 to 2026-03-27` | Date range |
+
+Default daily target: **7h 30m** (configurable — user can override, e.g. "fill worklogs this week, 8h per day").
+
+## Step-by-Step
+
+### 1. Parse Dates
+
+Convert user input to a list of **workdays** (skip weekends). Store daily target (default 7h 30m = 450 minutes).
+
+### 2. Fetch Existing Worklogs
+
+Search Jira for all issues with worklogs by current user in the date range:
+
+```
+mcp__mcp-atlassian__jira_search(
+  jql: "worklogDate >= '{start}' AND worklogDate <= '{end}' AND worklogAuthor = currentUser()",
+  fields: "summary,worklog",
+  limit: 50
+)
+```
+
+**Filter worklogs** — only count entries where `author.emailAddress` matches the user (issues may have worklogs from other people). Group by date (`started` field).
+
+### 3. Fetch Git Commits
+
+Get all commits by the user in the date range:
+
+```bash
+git log --all --author="$(git config user.name)" --since="{start}" --until="{end+1day}" --format="%ad | %h | %s" --date=short | sort
+```
+
+**Extract ticket numbers** from commit messages (pattern: `{{JIRA_PREFIX}}-\d+`). Group commits by date and ticket.
+
+### 4. Calculate Gaps
+
+For each workday:
+
+```
+gap = daily_target - existing_worklogs_sum
+```
+
+Build a structure:
+```
+{
+  "2026-03-24": {
+    "existing": [{"ticket": "{{JIRA_PREFIX}}-123", "hours": "2h", "comment": "..."}],
+    "commits": [{"ticket": "{{JIRA_PREFIX}}-456", "message": "Refactor service..."}],
+    "logged_minutes": 120,
+    "gap_minutes": 330
+  }
+}
+```
+
+### 5. Propose Distribution
+
+**Rules for distributing remaining hours:**
+
+1. **Prioritize tickets with commits but no worklogs** — these represent real work that wasn't logged
+2. **Estimate based on commit complexity:**
+   - Single small fix commit → 1h-1h30
+   - Multiple commits on same ticket → 2h-4h
+   - Large architectural change (many files, new classes) → 4h-6h
+   - Docs-only commits → 30m-1h
+3. **Use round increments** — 30m, 1h, 1h30, 2h, 2h30, 3h, etc.
+4. **If gap remains after commit-based tickets**, distribute to the largest ticket of the day or to parent story
+5. **If still not enough tickets to fill the day**, ask the user which ticket to log against — do NOT invent tickets. Wait for user's answer before proceeding.
+6. **Write realistic comments** — based on actual commit messages, not generic text
+
+### 6. Present Proposal
+
+Show a **per-day table** with existing + proposed entries:
+
+```
+### Mon 24.03 — logged 2h00, missing +5h30
+
+| Ticket | Current | Add | Total | Justification |
+|--------|---------|-----|-------|---------------|
+| {{JIRA_PREFIX}}-123 | 2h | — | 2h | |
+| {{JIRA_PREFIX}}-456 | — | +5h30 | 5h30 | Refactor service |
+| | | | **7h30** | |
+```
+
+End with total summary table.
+
+### 7. Apply User Changes
+
+If the user requests modifications, recalculate and re-present. Common adjustments:
+
+- Move hours between tickets on the same day
+- Change a comment
+- Add/remove a ticket from a day
+- Change the daily target
+
+Re-present the updated table and ask for confirmation again.
+
+### 8. Register Worklogs
+
+On user confirmation, register ALL proposed worklogs:
+
+```
+mcp__mcp-atlassian__jira_add_worklog(
+  issue_key: "{TICKET}",
+  time_spent: "{time}",
+  comment: "{comment}",
+  started: "{date}T{staggered_time}.000+0100"
+)
+```
+
+**Stagger start times** within each day to avoid overlaps:
+- First entry: 09:00
+- Next: previous_start + previous_duration + 00:30 buffer
+
+**Timezone:** Use `+0100` (CET) or `+0200` (CEST) based on date.
+
+### 9. Summary
+
+After all worklogs are registered, show final confirmation with per-day totals.
+
+## Edge Cases
+
+| Case | Handling |
+|------|----------|
+| Day already has >= target hours | Skip day, report "already filled" |
+| Day has MORE than target | Warn user, don't touch |
+| No commits found for a day | Ask user which tickets to log against |
+| Weekend date in range | Skip automatically |
+| User changes target mid-conversation | Recalculate all gaps |
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Counting other people's worklogs | Filter by `author.emailAddress` matching the user |
+| Generic comments like "development work" | Use commit messages to write specific, technical comments |
+| Not checking for DST timezone offset | CET (+0100) vs CEST (+0200) depending on date |
+| Proposing 15m or 45m increments | Stick to 30m increments for readability |
+| Firing worklogs before user confirms | ALWAYS wait for explicit confirmation |

package/templates/base/_ai/skills/hotfix/SKILL.md

@@ -0,0 +1,52 @@
+# Skill: Hotfix
+
+## Trigger
+Production bug that needs immediate fix.
+
+## Input
+- Bug description or error log
+- Affected endpoint/feature
+- Production branch name (default: `main`)
+
+## Steps
+
+### 1. Create hotfix branch
+```bash
+git fetch origin
+git checkout -b hotfix/{{JIRA_PREFIX}}-XXXX-short-description origin/main
+```
+
+### 2. Reproduce & diagnose
+- Read error logs and stack trace
+- Identify the root cause (not just symptoms)
+- Find the minimal change needed — hotfix is NOT refactoring
+
+### 3. Implement fix
+- Change ONLY what's necessary to fix the bug
+- Do not refactor surrounding code
+- Do not add features
+- Do not update dependencies
+
+### 4. Add regression test
+- Write a test that fails WITHOUT the fix and passes WITH it
+- Test covers the exact scenario from the bug report
+
+### 5. Verify
+```bash
+{{TEST_COMMAND}}
+{{LINT_COMMAND}}
+```
+
+### 6. Prepare for merge
+- Self-review the diff: `git diff origin/main...HEAD`
+- Ensure the change is minimal and focused
+- Write commit message with issue reference
+
+## Verification Checklist
+- [ ] Fix addresses root cause, not symptoms
+- [ ] Only bug-related files changed (no unrelated changes)
+- [ ] Regression test added
+- [ ] All tests pass
+- [ ] Lint passes
+- [ ] Commit message references issue number
+- [ ] Ready for cherry-pick to release branch if needed