cyrus-edge-worker 0.2.39 → 0.2.41

package/dist/prompts/subroutines/changelog-update.md

@@ -1,79 +0,0 @@
-# Changelog Update - Document Changes
-
-All verification checks have passed. Now update the changelog if the project uses one.
-
-## Your Tasks
-
-### 1. Push Current Branch and Create Draft PR
-First, push the current branch (even if there are no new commits) and create a draft PR to get a PR number:
-
-```bash
-# Push the branch to remote
-git push -u origin HEAD
-
-# Check if PR already exists, if not create a draft PR
-# IMPORTANT: The --base flag MUST match the base_branch from the issue context
-gh pr view --json url,number 2>/dev/null || gh pr create --draft --base [base_branch from context] --title "WIP: [brief description]" --body "Work in progress for [ISSUE-ID]. Full description to follow."
-```
-
-Record the PR URL and number for use in the changelog entry.
-
-### 2. Check for Changelog Files
-Check if the project has changelog files:
-```bash
-ls -la CHANGELOG.md CHANGELOG.internal.md 2>/dev/null || echo "NO_CHANGELOG"
-```
-
-**If no changelog files exist, complete with:** `Draft PR created at [PR URL]. No changelog files found.`
-
-### 3. Check for Existing Changelog Entry
-If changelog files exist, check if there's already a changelog entry for this issue:
-- Look in the `## [Unreleased]` section for entries mentioning the current Linear issue identifier
-- If an entry already exists for this issue, you may update it to add the PR link, but do NOT add duplicate entries
-
-### 4. Update Changelog with PR Link
-If changelog files exist and no entry exists (or entry needs PR link):
-
-**For user-facing changes (CHANGELOG.md):**
-- Add entry under `## [Unreleased]` in the appropriate subsection (`### Added`, `### Changed`, `### Fixed`, `### Removed`)
-- Focus on end-user impact from the perspective of users running the CLI
-- Be concise but descriptive about what users will experience differently
-- Include both the Linear issue identifier AND the PR link
-- Format: `- **Feature name** - Description. ([ISSUE-ID](https://linear.app/...), [#NUMBER](PR_URL))`
-
-**For internal/technical changes (CHANGELOG.internal.md):**
-- Add entry if the changes are internal development, refactors, or tooling updates
-- Follow the same format as CHANGELOG.md
-
-## Important Notes
-
-- **Create draft PR first** - this gives you the PR number to include in the changelog
-- **Always specify `--base`** - use the base branch from the `<base_branch>` tag in the issue context. Do NOT rely on the repository's default branch setting.
-- **Only update changelogs if they exist** - not all projects use changelogs
-- **Avoid duplicate entries** - check if an entry already exists for this issue before adding
-- **Follow Keep a Changelog format** - https://keepachangelog.com/
-- **Group related changes** - consolidate multiple commits into a single meaningful entry
-- **Do NOT commit or push the changelog changes** - that happens in the next subroutine
-- 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):
-
-```
-Draft PR created at [PR URL]. Changelog updated for [ISSUE-ID].
-```
-
-Or if no changelog exists:
-
-```
-Draft PR created at [PR URL]. No changelog files found.
-```
-
-Or if entry already existed:
-
-```
-Draft PR created at [PR URL]. Changelog entry already exists for this issue.
-```

package/dist/prompts/subroutines/coding-activity.md

@@ -1,12 +0,0 @@
-# Implementation Phase
-
-Implement the requested changes:
-- Write production-ready code
-- Run tests to verify it works
-- Follow existing patterns
-
-**Do NOT**:
-- Commit, push, or create PRs (later phases handle that)
-- Touch the changelog (a separate subroutine handles changelog updates)
-
-Complete with: `Implementation complete - [what was done].`

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

@@ -1,67 +0,0 @@
-# Summary - Brief Response for Linear
-
-Generate a concise summary of the work completed for posting to Linear.
-
-## Your Task
-
-Create a clear, brief summary that covers:
-
-### 1. Work Completed
-- What was accomplished (1-2 sentences)
-- Key outcome or result
-
-### 2. Key Details (if applicable)
-- Files modified or created (brief list)
-- Important changes made
-- PR link if created
-
-### 3. Status
-- Completion status
-- Any follow-up needed
-
-## Format Requirements
-
-- **Be concise** - aim for 3-5 paragraphs maximum
-- Use clear, professional language suitable for Linear
-- Use markdown formatting for readability
-- Focus on what matters to stakeholders
-- **To mention someone**: Use `https://linear.app/linear/profiles/username` syntax where `username` is the Linear username (e.g., `https://linear.app/linear/profiles/alice` to mention @alice)
-
-## Constraints
-
-- **You have exactly 1 turn** - generate the summary in a single response
-- This is the final output that will be posted to Linear
-- Make it informative but brief
-
-## Example Format
-
-```
-## Summary
-
-[Brief description of what was done]
-
-+++Changes Made
-- [Key change 1]
-- [Key change 2]
-+++
-
-+++Files Modified
-- [File 1]
-- [File 2]
-+++
-
-## Status
-
-[Current status and any next steps]
-
-[PR link if applicable]
-```
-
-## Collapsible Sections
-
-**IMPORTANT**: When creating your summary, make the following sections collapsible (collapsed by default):
-
-- **"Changes Made"** section - Wrap with `+++Changes Made\n...\n+++`
-- **"Files Modified"** section - Wrap with `+++Files Modified\n...\n+++`
-
-This keeps the summary concise while preserving detailed information for those who want to expand and read it.

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

@@ -1,92 +0,0 @@
-<version-tag value="debugger-fix-v1.0.0" />
-
-You are in the **Bug Fix Implementation Phase** of the debugging workflow.
-
-## Context
-
-The reproduction phase is complete. You have:
-
-- ✅ A failing test case that reproduces the bug
-- ✅ Root cause analysis from the reproduction phase
-- ✅ A proposed fix approach
-
-## Objective
-
-Implement a **minimal, targeted fix** that resolves the bug without introducing regressions.
-
-## Your Tasks
-
-### 1. Implementation Planning (Task-Driven)
-
-Before making any changes, use Task to plan your approach:
-
-```
-Task: "analyze optimal fix approach based on root cause"
-Task: "check for similar fixes in the codebase"
-Task: "identify potential side effects of the fix"
-Task: "plan minimal set of files to modify"
-```
-
-### 2. Fix Implementation (Focused File Loading)
-
-**NOW you can load and edit files:**
-
-- Load ONLY the files you need to modify
-- Implement the minimal fix that addresses the root cause
-- Follow existing code patterns and conventions
-- Add comments explaining the fix if it's non-obvious
-- Use Task for any reference lookups
-
-**Principles:**
-- Minimal changes - fix the bug, nothing more
-- Targeted - only touch affected code paths
-- Defensive - add validation/error handling if missing
-- Tested - the fix must make the failing test pass
-
-### 3. Verification (Task-Driven)
-
-After implementing the fix, verify it works:
-
-```
-Task: "run the failing test to confirm it now passes"
-Task: "run full test suite to check for regressions"
-Task: "verify edge cases are handled"
-Task: "check that error messages are clear"
-```
-
-## Output Format
-
-**IMPORTANT: Do NOT post Linear comments.** Your output is for internal workflow only.
-
-After implementing and verifying your fix, provide a brief completion message (1 sentence max):
-
-```
-Fix implemented in [files] - [brief description of what was fixed].
-```
-
-Example: "Fix implemented in src/auth/session.ts - normalized date comparisons to UTC."
-
-## Critical Constraints
-
-- ✅ **DO implement the minimal fix** - this is your primary objective
-- ✅ **DO verify all tests pass** - no regressions allowed
-- ✅ **DO follow existing patterns** - maintain code consistency
-- ✅ **DO use Task for analysis** - direct file loading only for editing
-- ❌ **DO NOT add unrelated improvements** - fix the bug only
-- ❌ **DO NOT commit or push** - that happens in later phases
-- ❌ **DO NOT run linting or type checking** - that happens in verifications phase
-- ❌ **DO NOT touch the changelog** - a separate subroutine handles changelog updates
-
-## What Happens Next
-
-After you complete the fix:
-
-1. The `verifications` subroutine will run (tests, linting, type checking)
-2. The `git-gh` subroutine will commit and create/update PR
-3. A summary will be generated
-
-Your fix should be **production-ready** and **thoroughly tested** at this point.
-
-## Remember
-
-You're implementing a fix based on a clear root cause analysis. Stay focused on resolving the specific bug - the verification and git workflows will handle the rest.

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

@@ -1,74 +0,0 @@
-<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/get-approval.md

@@ -1,175 +0,0 @@
-<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

@@ -1,110 +0,0 @@
-# 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]"
-```
-
-**IMPORTANT: Assignee attribution**
-Check the `<assignee>` section from the issue context and add assignee information at the **very top** of the PR description body, before the summary:
-
-- If a `<github_username>` is available, format as: `Assignee: @username ([Display Name](linear_profile_url))` — the @mention triggers a GitHub notification and the Linear profile link provides an audit trail
-- If only a `<linear_profile_url>` is available (no GitHub username), format as: `Assignee: [Display Name](linear_profile_url)` using the `<linear_display_name>` and `<linear_profile_url>` values
-
-Follow this with a blank line, then the rest of the description. If no assignee information is available at all, skip this step.
-
-**IMPORTANT: Cyrus attribution marker**
-You MUST include the following hidden HTML comment somewhere in the PR body (e.g. at the very end). This marker is used to identify Cyrus-authored PRs for tracking purposes:
-```
-<!-- generated-by-cyrus -->
-```
-This marker is invisible when rendered on GitHub but allows the webhook to detect that this PR was authored by Cyrus, even when the PR is created under a human user's GitHub account.
-
-The PR description should include:
-- Summary of changes
-- Implementation approach
-- Testing performed
-- Any breaking changes or migration notes
-- Link to the Linear issue
-
-**IMPORTANT: Cyrus interaction tip**
-At the end of the PR body (before the `<!-- generated-by-cyrus -->` marker), include a tip section using the following exact format:
-
-```
----
-
-> **Tip:** I will respond to comments that @ mention @{{github_bot_username}} on this PR. You can also submit a "changes requested" review with all your feedback at once, and I will automatically wake up to address each comment.
-```
-
-This helps reviewers know how to interact with Cyrus directly on the PR.
-
-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)."
-
-## Deploy Preview (Optional)
-
-If a skill is available in your environment whose "use me when" description refers to creating deploy previews for a branch, you can invoke it to set up a preview environment for testing this PR. This is useful for validating changes in a live environment before the code is merged. Use the skill if you want to create a preview environment, set up infrastructure for testing, or deploy to a preview platform.

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

@@ -1,37 +0,0 @@
-# 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."