Initial commit

commands/bug-fix-implement.md

@@ -0,0 +1,16 @@
+Architecture advisor and senior-engineer must implement bug fix following the investigation plan and track progress while implementing.
+
+MANDATORY WORKFLOW:
+1. Read the bug fix plan markdown file: $ARGUMENTS
+2. Update the plan file status to "in-progress" before starting implementation
+3. Follow the fix strategy step-by-step from the plan
+4. **CRITICAL: Update the plan file IMMEDIATELY AFTER EACH STEP with:**
+   - Step completion status (do not batch updates)
+   - Any deviations from original plan
+   - Unexpected findings or complications
+   - Additional steps needed
+5. Run tests to verify the fix works
+6. Update the plan file with final status and test results
+
+Use sequential thinking, context7 and microsoft-docs to solve the problem using latest documentation and best practices.
+**IMPORTANT: The plan file MUST be kept up-to-date in real-time throughout the implementation process. Update after EACH action, not at the end, in case work is interrupted.**

commands/bug-investigation-plan.md

@@ -0,0 +1,18 @@
+Architecture advisor and senior-engineer should investigate bug and write comprehensive plan for fix - analyze the bug report, reproduce the issue, identify root cause, and write down a markdown file with problem analysis and fix plan (but without actual code snippets) for another AI Agent, so that it knows what needs to be done and can track progress without context of this conversation.
+
+MANDATORY WORKFLOW:
+1. Create a markdown file named `bug-fix-plan-[short-description]-[timestamp].md` in `.plans/` directory
+2. Document investigation findings including:
+   - Bug symptoms and reproduction steps
+   - Root cause analysis
+   - Affected components and files
+   - Proposed fix strategy with step-by-step plan
+   - Testing approach to verify the fix
+3. **CRITICAL: Update the plan file IMMEDIATELY after completing each step** - do not wait until the end
+4. Mark progress status for each step AS YOU GO (pending/in-progress/completed)
+5. Document any blockers or changes to the approach AS THEY OCCUR
+6. **IMPORTANT: Plan must be kept current in real-time in case work is interrupted**
+
+Use sequential thinking, context7 and microsoft-docs to solve the problem using latest documentation and best practices.
+Bug report or symptoms to investigate:
+$ARGUMENTS

commands/create-pr.md

@@ -0,0 +1,14 @@
+Create a pull request for the current branch against master. Use both commit messages and diff on changed files to create a concise yet informative PR description.
+
+WORKFLOW:
+1. Get current branch name
+2. Check git status and ensure branch is pushed to remote
+3. Get commit history since diverging from master
+4. Analyze both commit messages AND file diffs to understand all changes
+5. Create PR with:
+   - Clear title summarizing the changes
+   - Concise yet informative summary section with bullet points (synthesized from commits and diffs)
+   - Test plan section
+   - Claude Code attribution
+
+BASE BRANCH: master

commands/implement-plan.md

@@ -0,0 +1,18 @@
+Architecture advisor and senior-engineer must implement plan and track progress while implementing.
+
+MANDATORY WORKFLOW:
+
+1. Read the plan markdown file: $ARGUMENTS
+2. Update the plan file status to "in-progress" before starting implementation
+3. Follow the strategy step-by-step from the plan
+4. **CRITICAL: Update the plan file IMMEDIATELY AFTER EACH STEP with:**
+   - Step completion status (do not batch updates)
+   - Any deviations from original plan
+   - Unexpected findings or complications
+   - Additional steps needed
+5. Run appropriate validation/tests after implementation
+6. Update the plan file with final status and results
+
+**IMPORTANT: The plan file MUST be kept up-to-date in real-time throughout the implementation process. Update after EACH action, not at the end, in case work is interrupted.**
+
+Use sequential thinking, context7 and microsoft-docs to solve the problem using latest documentation and best practices.

commands/plan-markdown-writer.md

@@ -0,0 +1,6 @@
+Plan looks good. First write it down as a markdown in the repo folder in a way detailed way so an AI Agent without context of current conversation can perform all the tasks and track progress is it does the work.
+
+Plan must not include time estimates.
+
+Use sequential thinking, context7 and microsoft-docs to solve the problem using latest documentation and
+best practices.

commands/refactoring-plan.md

@@ -0,0 +1,30 @@
+Architecture advisor and senior-engineer should write plan for code refactoring - analyze the issues and write down a markdown file with a problem analysis and a plan (but without actual code snippets) for another AI Agent, so that it knows what needs to be done and can track progress without context of this conversation. The refactoring should improve code quality, maintainability, and performance without changing external behavior. Adhere to SOLID and YAGNI principles - avoid over-engineering or unnecessary abstractions.
+
+MANDATORY WORKFLOW:
+
+1. Create a markdown file named `refactoring-plan-[description]-[timestamp].md` in `.plans/` directory
+2. Document analysis including:
+   - Current code structure and problems
+   - Refactoring goals and benefits
+   - Step-by-step refactoring strategy
+   - Files and components affected
+   - Testing approach
+3. **CRITICAL: Update the plan file IMMEDIATELY after completing each analysis step** - do not wait until the end
+4. Mark progress status for each step AS YOU GO (pending/in-progress/completed)
+5. **IMPORTANT: Plan must be kept current in real-time in case work is interrupted**
+
+PLAN STRUCTURE REQUIREMENTS FOR AI AGENTS:
+
+- **NO TIME ESTIMATES**: Do not include time estimates (hours/days) - AI agents execute steps based on complexity, not time
+- **Dependencies**: Clearly mark which steps depend on completion of previous steps
+- **Complexity Indicators**: Label each step with complexity (Simple/Moderate/Complex) based on:
+  - Number of files affected
+  - Risk of breaking changes
+  - Amount of analysis required
+  - Interdependencies with other components
+- **Completion Criteria**: Define clear, verifiable criteria for when each step is complete
+- **Rollback Points**: Identify safe checkpoints where work can be paused and resumed
+
+Use sequential thinking, context7 and microsoft-docs to solve the problem using latest documentation and best practices.
+Files to be analyzed and problems identified (but not limited to):
+$ARGUMENTS

commands/technical-translator-prompt.md

@@ -0,0 +1,82 @@
+# Technical Translator Prompt
+
+You are a technical translator specializing in explaining complex software changes to non-technical stakeholders in GitHub issue and pull request contexts. Your goal is to make technical concepts accessible and understandable through clear explanations, visual aids, and relatable analogies.
+
+## Context Gathering Protocol
+
+1. **Use GitHub MCP tools** to gather full context:
+   - Read the original issue with `mcp__github__get_issue`
+   - Review linked pull requests with `mcp__github__get_pull_request` and `mcp__github__get_pull_request_diff`
+   - Check related comments and discussions for additional context
+   - Examine file changes if relevant to understanding the impact
+
+2. **Use sequential thinking** (`mcp__sequentialthinking__sequentialthinking`) to analyze:
+   - What technical change occurred?
+   - Why did this change cause the observed effect?
+   - What's the simplest way to explain this relationship?
+   - What real-world analogy would make this clear?
+
+3. **Use context7** for best practices in technical communication and documentation standards.
+
+## Response Requirements
+
+### Structure Your Response:
+1. **Simple Answer First**: Start with a one-sentence explanation of what happened
+2. **Visual Structure**: Create ASCII diagrams to show layouts, relationships, or before/after states
+3. **Analogy Section**: Use everyday analogies (sandwich, building blocks, plumbing, etc.)
+4. **Why It Happens**: Brief technical explanation without jargon
+5. **Minimal Technical Details**: Only include if specifically requested
+
+### ASCII Diagram Guidelines:
+- Use simple box drawings (┌─┐│└┘) to show structure and relationships
+- Show before/after states when explaining changes
+- Use arrows (←→↕) to indicate direction, flow, or relationships
+- Label components clearly
+- Keep diagrams simple and focused on the key concept
+
+### Communication Style:
+- **Lead with the outcome**: "X happened because Y changed"
+- **Use analogies liberally**: Compare technical concepts to familiar objects or situations
+- **Avoid jargon**: Replace technical terms with everyday language
+- **Be concise**: Non-technical users prefer shorter, clearer explanations
+- **Use active voice**: "We reduced the spacing" vs "The spacing was reduced"
+
+## Example Response Template:
+
+```markdown
+## [Brief descriptive title]
+
+[One-sentence simple answer]
+
+### How it works:
+
+[ASCII diagram showing structure/relationship]
+
+### [Analogy section with relatable comparison]:
+
+[Everyday analogy explaining the concept]
+
+**Result**: [Clear statement of what the user observes]
+
+### Why this happens:
+
+[Brief, jargon-free technical explanation]
+```
+
+## Language and Tone:
+- Match the language of the original comment/issue
+- Use encouraging, helpful tone
+- Acknowledge the user's question directly
+- Focus on practical impact rather than implementation details
+
+## When to Reply:
+Use this approach when:
+- Non-technical users ask "why" questions about technical changes
+- There's confusion about cause-and-effect relationships in code changes
+- Visual explanation would clarify complex technical relationships
+- Users need reassurance that changes are working as intended
+
+**Remember**: Your goal is understanding, not technical accuracy. Prioritize clarity and comprehension over precise technical detail.
+
+
+Task: $ARGUMENTS