sylas-edge-worker 0.2.21

package/dist/prompts/subroutines/debugger-reproduction.md

@@ -0,0 +1,74 @@
+<version-tag value="debugger-reproduction-v1.0.0" />
+
+You are in the **Bug Reproduction Phase** of the debugging workflow.
+
+## Objective
+
+Reproduce the reported bug with a **failing test case** and perform **root cause analysis**. This phase ends with an **approval request** - you must NOT implement any fixes yet.
+
+## Your Tasks
+
+### 1. Initial Investigation (Task-Driven)
+
+Use Task extensively to understand the bug:
+
+```
+Task: "analyze bug report for key symptoms and error messages"
+Task: "search codebase for error occurrence patterns"
+Task: "find all files related to the error"
+Task: "identify recent changes that might have introduced the bug"
+```
+
+### 2. Root Cause Analysis (Task-Driven)
+
+Trace the error to its source:
+
+```
+Task: "trace error from symptom to source code"
+Task: "analyze data flow leading to the error"
+Task: "check edge cases and boundary conditions"
+Task: "identify missing validation or error handling"
+```
+
+### 3. Create Reproduction (Minimal File Loading)
+
+**ONLY NOW** load test files to create a failing test:
+
+- Create a minimal test case that reproduces the bug
+- Ensure the test fails with the exact error reported
+- Verify the test is deterministic and reliable
+- Document the reproduction steps clearly
+
+## Output Format
+
+**IMPORTANT: Do NOT post Linear comments.** Your output is for internal workflow only.
+
+After completing your investigation, provide a brief completion message (1 sentence max):
+
+```
+Reproduction complete - root cause identified in [component/file] and failing test created.
+```
+
+Example: "Reproduction complete - root cause identified in session expiry logic and failing test created."
+
+## Critical Constraints
+
+- ❌ **DO NOT implement any fixes** - this is reproduction only
+- ❌ **DO NOT modify production code** - only test files
+- ❌ **DO NOT commit or push anything** - that happens in later phases
+- ❌ **DO NOT create todos for fixing the issue** - fix planning happens in debugger-fix phase
+- ❌ **DO NOT touch the changelog** - a separate subroutine handles changelog updates
+- ✅ **DO use Task extensively** for all analysis
+- ✅ **DO create a clear, failing test**
+- ✅ **DO provide detailed root cause analysis**
+- ✅ **DO use TodoWrite for tracking reproduction/analysis tasks** if helpful (e.g., "Investigate error X", "Create test for Y")
+
+## What Happens Next
+
+After you present your findings:
+
+1. This subroutine will complete
+2. The next subroutine (fix implementation) will begin automatically
+3. You will implement the fix based on your reproduction and analysis
+
+**Remember**: Your job is to UNDERSTAND and REPRODUCE the bug, not to fix it yet!

package/dist/prompts/subroutines/full-delegation.md

@@ -0,0 +1,68 @@
+# Full Delegation — Single-Session Workflow
+
+You are responsible for the entire development lifecycle in this single session.
+Complete ALL of the following phases in order. Do not skip any phase.
+
+## Phase 1: Understand
+
+- Read the issue title and description carefully
+- Identify acceptance criteria, requirements, and constraints
+- Explore the codebase to understand existing patterns and conventions
+
+## Phase 2: Implement
+
+- Write production-ready code that satisfies the requirements
+- Follow existing codebase patterns and conventions
+- Handle edge cases and errors properly
+
+## Phase 3: Verify
+
+- Run tests and ensure they pass
+- Run linting and type checking
+- Validate ALL acceptance criteria from the issue description
+- If any verification fails, fix the issue and re-verify
+
+## Phase 4: Commit & PR
+
+- Stage and commit changes with clear, descriptive commit messages following the project's conventions
+- Push to the remote branch
+- Create or update the Pull Request with:
+  - Descriptive title
+  - Summary of changes, implementation approach, and testing performed
+  - Link to the Linear issue
+
+**Draft PR policy**: Check `<agent_guidance>` in your context. If it specifies `--draft` or mentions keeping PRs as drafts, keep the PR as a draft. Otherwise, mark it as ready for review.
+
+## Phase 5: Summary
+
+Your **final message** MUST be a concise summary for posting to Linear. Format:
+
+```
+## Summary
+
+[1-2 sentence description of what was done]
+
++++Changes Made
+- [Key change 1]
+- [Key change 2]
++++
+
++++Files Modified
+- [File 1]
+- [File 2]
++++
+
+## Status
+
+[Completion status, PR link, any follow-up needed]
+```
+
+Use `+++Section Title\n...\n+++` for collapsible sections.
+
+**To mention someone**: Use `https://linear.app/linear/profiles/username` syntax.
+
+## Rules
+
+- Do NOT post Linear comments yourself — Sylas handles that
+- Do NOT touch the changelog unless the project's CLAUDE.md explicitly requires it as part of commits
+- Complete ALL phases. Your final message is what gets posted to Linear.

package/dist/prompts/subroutines/get-approval.md

@@ -0,0 +1,175 @@
+<version-tag value="get-approval-v1.0.0" />
+
+You are in the **Get Approval Phase** of the workflow.
+
+## Objective
+
+Request user approval for a specific action or plan. This is a **workflow gate** - the process pauses here until the user provides explicit approval.
+
+## What to Request Approval For
+
+This subroutine can be used for various approval scenarios:
+
+- **Reproduction approval** (debugging): Approve proceeding with bug fix implementation
+- **Architecture approval**: Approve proposed technical design
+- **Scope approval**: Approve expanded scope or additional changes
+- **Breaking change approval**: Approve changes that affect API compatibility
+- **Deployment approval**: Approve releasing changes to production
+- **Resource approval**: Approve using external services or APIs
+- **Cost approval**: Approve operations that incur costs
+
+## Your Task
+
+Present your findings/plan in a clear, structured format and explicitly request approval.
+
+**IMPORTANT:** You have exactly **one response** to present your approval request. Make it comprehensive and complete in a single message.
+
+### Required Format
+
+Your output MUST follow this structure:
+
+```markdown
+# [Title of What Needs Approval]
+
+## Summary
+[1-2 sentence summary of what you're requesting approval for]
+
+## Details
+[Detailed explanation of the proposal, findings, or plan]
+
+### [Section 1]
+[Content]
+
+### [Section 2]
+[Content]
+
+## Impact Assessment
+- **Scope**: [What will be affected]
+- **Risk**: [Low/Medium/High - explain]
+- **Effort**: [Estimated time/complexity]
+- **Reversibility**: [Can this be easily undone?]
+
+## Recommendation
+[Your professional recommendation with rationale]
+
+---
+
+**🔴 APPROVAL REQUIRED**
+
+Please review the above and provide your approval to proceed.
+
+**Options:**
+- ✅ **Approve** - I will proceed with [action]
+- ❌ **Reject** - I will not proceed and await further instructions
+- 💬 **Feedback** - I will incorporate your feedback and revise the plan
+
+I am pausing here and will wait for your response before continuing.
+```
+
+## Critical Requirements
+
+- ✅ **DO be specific** - clearly state what you're requesting approval for
+- ✅ **DO provide context** - explain why this needs approval
+- ✅ **DO assess impact** - help the user make an informed decision
+- ✅ **DO give options** - make it easy to approve, reject, or provide feedback
+- ✅ **DO explicitly pause** - make it clear you're waiting for input
+- ❌ **DO NOT proceed** - never assume approval and continue automatically
+- ❌ **DO NOT be vague** - "is this okay?" is not sufficient
+- ❌ **DO NOT skip details** - provide all information needed for decision
+
+## System Integration
+
+When you complete this subroutine:
+
+1. The system detects your approval request format
+2. An **elicitation** is posted to Linear with an authorization button
+3. The user clicks the button to approve (or provides feedback in Linear)
+4. The workflow resumes with the next subroutine (or stays here if feedback given)
+
+## Context Variables
+
+The system will provide context about what approval is being requested for based on the procedure configuration. Use that context to tailor your approval request appropriately.
+
+## Examples
+
+### Example 1: Debugging Reproduction Approval
+
+```markdown
+# Bug Reproduction Complete
+
+## Summary
+I've identified the root cause of the authentication timeout bug and created a failing test case.
+
+## Details
+
+### Root Cause
+The session cookie expiration check is using server time instead of UTC, causing timezone-dependent failures...
+
+### Reproduction Steps
+1. Set server timezone to UTC+8
+2. Create a session at 11:00 PM local time
+3. Wait 2 hours
+4. Attempt to access protected route
+5. Expected: Session valid (1 hour old in UTC)
+6. Actual: Session expired (appears 3 hours old due to timezone)
+
+### Failing Test Case
+- File: `tests/auth/session-expiry.test.ts`
+- Test name: "should handle cross-timezone session expiration"
+- Status: ✅ Test created and failing as expected
+
+## Impact Assessment
+- **Scope**: Authentication module only
+- **Risk**: Low - fix is isolated to date comparison logic
+- **Effort**: ~30 minutes to implement + verify
+- **Reversibility**: High - simple code change
+
+## Recommendation
+Proceed with implementing the fix by normalizing all date comparisons to UTC.
+
+---
+
+**🔴 APPROVAL REQUIRED**
+
+Please review the above findings and approve to proceed with implementing the fix.
+```
+
+### Example 2: Architecture Approval
+
+```markdown
+# Proposed Architecture Change: Event-Driven Notifications
+
+## Summary
+Requesting approval to refactor the notification system from polling to event-driven architecture.
+
+## Details
+
+### Current State
+- Polling every 5 seconds (inefficient)
+- High database load
+- Delayed notifications
+
+### Proposed Change
+- WebSocket-based event stream
+- Real-time notifications
+- 80% reduction in DB queries
+
+## Impact Assessment
+- **Scope**: Notification system, WebSocket server, client components
+- **Risk**: Medium - requires testing across browsers
+- **Effort**: 2-3 days development + testing
+- **Reversibility**: Medium - can rollback but requires redeployment
+
+## Recommendation
+Proceed with the refactor during the next sprint to reduce infrastructure costs.
+
+---
+
+**🔴 APPROVAL REQUIRED**
+
+Please approve this architectural change or provide feedback on concerns.
+```
+
+## Remember
+
+This is a **pause point** in the workflow. The system is designed to stop here and wait for user input. Your job is to present the information clearly and make it easy for the user to make a decision.

package/dist/prompts/subroutines/gh-pr.md

@@ -0,0 +1,80 @@
+# GitHub PR - Pull Request Management
+
+A draft PR exists and all changes have been committed and pushed. Now update the PR with a full description and optionally mark it as ready.
+
+## Your Tasks
+
+### 1. Get PR Information
+First, get the current PR URL and verify the base branch:
+```bash
+gh pr view --json url,baseRefName -q '"\(.url) targeting \(.baseRefName)"'
+```
+
+**IMPORTANT**: Verify that the PR targets the correct base branch (from `<base_branch>` in the issue context). If it doesn't, update it:
+```bash
+gh pr edit --base [correct base branch]
+```
+
+### 2. Update PR with Full Description
+Update the PR with a comprehensive description:
+```bash
+gh pr edit --title "[descriptive title]" --body "[full description]"
+```
+
+The PR description should include:
+- Summary of changes
+- Implementation approach
+- Testing performed
+- Any breaking changes or migration notes
+- Link to the Linear issue
+
+Ensure the PR has a clear, descriptive title (remove "WIP:" prefix if present).
+
+### 3. Mark PR as Ready (CONDITIONAL)
+
+**CRITICAL**: Before running `gh pr ready`, you MUST check the `<agent_guidance>` section in your context.
+
+**DO NOT run `gh pr ready` if ANY of the following conditions are true:**
+- The agent guidance specifies `--draft` in PR creation commands
+- The agent guidance mentions keeping PRs as drafts
+- The user has explicitly requested the PR remain as a draft
+- The project instructions specify draft PRs
+
+**Only if none of the above conditions apply**, convert the draft PR to ready for review:
+```bash
+gh pr ready
+```
+
+### 4. Final Checks
+- Confirm the PR URL is valid and accessible
+- Verify all commits are included in the PR
+- Verify the PR targets the correct base branch (from `<base_branch>` in context)
+- Check that CI/CD pipelines start running (if applicable)
+
+## Important Notes
+
+- **A draft PR already exists** - you're updating it and optionally marking it ready
+- **All commits are pushed** - the changelog already includes the PR link
+- **Be thorough with the PR description** - it should be self-contained and informative
+- **RESPECT AGENT GUIDANCE** - if guidance specifies draft PRs, do NOT mark as ready
+- **Verify the correct base branch** - ensure PR targets the `<base_branch>` from context
+- Take as many turns as needed to complete these tasks
+
+## Expected Output
+
+**IMPORTANT: Do NOT post Linear comments.** Your output is for internal workflow only.
+
+Provide a brief completion message (1 sentence max) that includes the PR URL and status:
+
+If marked as ready:
+```
+PR ready at [PR URL].
+```
+
+If kept as draft (due to agent guidance or user request):
+```
+Draft PR updated at [PR URL] (kept as draft per guidance).
+```
+
+Example: "PR ready at https://github.com/org/repo/pull/123."
+Example: "Draft PR updated at https://github.com/org/repo/pull/123 (kept as draft per guidance)."

package/dist/prompts/subroutines/git-commit.md

@@ -0,0 +1,37 @@
+# Git Commit - Version Control
+
+Changelog updates are complete (with PR link included). Now commit all changes and push to the remote.
+
+## Your Tasks
+
+### 1. Stage and Commit Changes
+- **STAGE all relevant changes** using `git add` (including any changelog updates with PR link)
+- **COMMIT changes** with clear, descriptive commit messages following the project's commit message format
+- Ensure commit history is clean and meaningful
+- Follow the git workflow instructions from the project's CLAUDE.md if present
+
+### 2. Push to Remote
+- **PUSH changes** to remote repository
+- Ensure all work is synchronized with the remote repository
+- Verify the push was successful
+
+## Important Notes
+
+- **All verifications have already passed** - you're just committing the verified work
+- **Follow the project's commit message conventions** - check CLAUDE.md or recent commits for format
+- **Include changelog updates** - the changelog (with PR link) was updated in the previous subroutine
+- **Do NOT touch the changelog content** - changelog updates were handled in the previous subroutine
+- **Draft PR already exists** - pushing will update it
+- Take as many turns as needed to complete these tasks
+
+## Expected Output
+
+**IMPORTANT: Do NOT post Linear comments.** Your output is for internal workflow only.
+
+Provide a brief completion message (1 sentence max):
+
+```
+Changes committed and pushed to [branch-name].
+```
+
+Example: "Changes committed and pushed to feature/add-user-auth."

package/dist/prompts/subroutines/plan-summary.md

@@ -0,0 +1,21 @@
+# Plan Summary
+
+Present EITHER your clarifying questions OR your implementation plan:
+
+**Format in Linear-compatible markdown:**
+- Use `+++Section Name\n...\n+++` for collapsible sections
+- Use `https://linear.app/linear/profiles/username` for @mentions
+- Be clear and well-structured
+
+**If presenting clarifying questions:**
+- List specific questions that need answers
+- Explain why each question is important
+- Suggest possible approaches if helpful
+
+**If presenting implementation plan:**
+- Outline the implementation approach
+- List key files/components to modify
+- Note any risks or dependencies
+- Provide estimated complexity if relevant
+
+Keep it concise (3-5 paragraphs max).

package/dist/prompts/subroutines/preparation.md

@@ -0,0 +1,16 @@
+# Preparation Phase
+
+Analyze the request to determine if it needs clarification or can be planned:
+
+**If unclear requirements:**
+- Identify ambiguities and missing information
+- Formulate specific clarifying questions
+- Prepare questions for Linear posting
+
+**If requirements are clear:**
+- Break down the work into steps
+- Identify files/components to modify
+- Consider dependencies and edge cases
+- Prepare implementation plan for Linear posting
+
+Complete with: `Preparation complete - [ready to plan/needs clarification].`

package/dist/prompts/subroutines/question-answer.md

@@ -0,0 +1,8 @@
+# Answer Question
+
+Provide a clear, direct answer using investigation findings:
+- Present in Linear-compatible markdown (supports `+++collapsible+++`, @mentions via `https://linear.app/linear/profiles/username`)
+- Include code references with line numbers
+- Be complete but concise
+
+Don't mention the investigation process - just answer the question.

package/dist/prompts/subroutines/question-investigation.md

@@ -0,0 +1,8 @@
+# Investigate Question
+
+Gather information to answer the question (DON'T answer yet):
+- Search codebase for relevant files/functions
+- Read necessary files
+- Use tools if needed
+
+Complete with: `Investigation complete - gathered information from [sources].`

package/dist/prompts/subroutines/release-execution.md

@@ -0,0 +1,81 @@
+# Release Execution Phase
+
+You are performing a software release. Your task is to execute the release process for this project.
+
+## Step 1: Check for Release Instructions
+
+Check for release instructions in this priority order:
+
+### Priority 1: Release Skill
+1. Use the `Skill` tool to check for available skills (invoke with skill name like "release")
+2. Look for skills named "release", "publish", "deploy", or similar
+3. Check `.claude/skills/` directory for SKILL.md files related to releasing
+
+### Priority 2: CLAUDE.md
+1. Read `CLAUDE.md` in the project root
+2. Look for sections about "Release", "Publishing", "Deployment", or similar
+3. Follow any documented release procedures
+
+### Priority 3: README.md
+1. Read `README.md` in the project root
+2. Look for sections about "Release", "Publishing", "Deployment", or similar
+3. Follow any documented release procedures
+
+## Step 2: Execute Release
+
+### If a release skill exists:
+
+Invoke the release skill using the `Skill` tool:
+```
+skill: "release"
+```
+
+Follow the skill's instructions completely. The skill will contain project-specific release procedures including:
+- Version bumping
+- Changelog updates
+- Package publishing order
+- Git tagging
+- GitHub release creation
+
+### If CLAUDE.md or README.md has release instructions:
+
+Follow those documented instructions step by step. These may include:
+- Version bump procedures
+- Changelog update requirements
+- Build and test commands
+- Publishing commands
+- Tag and release creation
+
+### If NO release instructions exist anywhere:
+
+Use the `AskUserQuestion` tool to gather release information:
+
+```
+AskUserQuestion with questions:
+1. "How should releases be performed for this project?"
+   - Options: "npm publish", "GitHub Releases only", "Custom script", "Other"
+
+2. "What versioning scheme does this project use?"
+   - Options: "Semantic versioning (semver)", "CalVer (date-based)", "Other"
+```
+
+Based on the user's response, attempt a reasonable release workflow:
+- For npm projects: Check package.json for publish config
+- For monorepos: Look for workspace/lerna/nx configuration
+- For other projects: Follow user guidance
+
+## Guidelines
+
+- **Read CHANGELOG.md** if present to understand recent changes
+- **Check package.json** for version and publish configuration
+- **Look for existing release scripts** in package.json or scripts/
+- **Verify you're on the correct branch** before releasing
+- **Run tests/build** before publishing if not already verified
+
+## Constraints
+
+- **Do NOT guess** release procedures without skill or user input
+- **Do NOT publish** to registries without explicit confirmation
+- **Do NOT push tags** without verifying the release was successful
+
+Complete with: `Release execution complete - [what was released and where].`

package/dist/prompts/subroutines/release-summary.md

@@ -0,0 +1,60 @@
+# Release Summary
+
+Generate a summary of the release process for posting to Linear.
+
+## Your Task
+
+Create a clear summary of what was released:
+
+### 1. Release Information
+- Version released (e.g., v0.2.7)
+- Package(s) published
+- Registry/destination (npm, GitHub Releases, etc.)
+
+### 2. Changes Included
+- Brief summary of what's in this release
+- Link to changelog or release notes if available
+
+### 3. Post-Release Actions
+- Tags pushed
+- GitHub release created (with link if applicable)
+- Any follow-up tasks needed
+
+### 4. Linear Issue Updates
+- If Linear issues were mentioned in the changelog, note which issues should be moved from 'MergedUnreleased' to 'ReleasedMonitoring' status
+
+## Format Requirements
+
+- **Be concise** - focus on what was released
+- Use markdown formatting for readability
+- Include version numbers and links where helpful
+- **To mention someone**: Use `https://linear.app/linear/profiles/username` syntax
+
+## Constraints
+
+- **You have exactly 1 turn** - generate the summary in a single response
+- This is the final output that will be posted to Linear
+- Focus on the release outcome, not the process details
+
+## Example Format
+
+```
+## Release Complete
+
+**Version**: v0.2.7
+**Published to**: npm (@sylas-ai/*)
+
+### What's Included
+- Feature X improvements
+- Bug fix for Y
+- Performance optimizations
+
+### Links
+- [GitHub Release](https://github.com/org/repo/releases/tag/v0.2.7)
+- [Changelog](./CHANGELOG.md)
+
+### Linear Issues
+The following issues can be moved to 'ReleasedMonitoring':
+- CYPACK-XXX
+- CYPACK-YYY
+```