Add Examples Section to Documentation

blog/github-mode-productivity.md

@@ -0,0 +1,96 @@
+---
+title: GitHub Mode as a Productivity Multiplier
+shortTitle: GitHub Mode Productivity
+date: 2025-03-07
+authors: [ben]
+tags: [github, productivity, workflow]
+---
+
+One of the most powerful aspects of MyCoder is its ability to use GitHub as a persistent, external memory store. This approach fundamentally transforms how you can interact with an AI coding assistant, turning it from a transient helper into a fully integrated team member with long-term memory.
+
+<!-- truncate -->
+
+## The Productivity Breakthrough
+
+Using GitHub Mode with MyCoder can lead to dramatic productivity improvements:
+
+- **3x to 5x increase in development velocity**
+- **More autonomous work** with less need for constant oversight
+- **Higher quality contributions** through structured workflows
+
+## How GitHub Mode Transforms the Workflow
+
+GitHub Mode enables MyCoder to interact with GitHub in ways that mirror a human team member:
+
+### 1. GitHub as External Memory
+
+GitHub serves as both a readable and writable memory store, allowing MyCoder to:
+
+- **Create GitHub issues** to track tasks and document its analyses
+- **Comment on issues** with detailed breakdowns before implementation
+- **Retrieve existing issues** and execute them autonomously
+- **Reference past work** to maintain context across multiple sessions
+
+### 2. Pull Requests as Work Units
+
+Using PRs as the primary unit of work changes the interaction model:
+
+- Instead of real-time back-and-forth, you can **batch your reviews**
+- Each PR provides a **clear, reviewable unit of submitted work**
+- MyCoder can **refine PRs** based on your feedback or CI/CD results
+- You can let MyCoder work autonomously, then review asynchronously
+
+### 3. Leveraging CI/CD Feedback
+
+MyCoder can integrate with your development pipeline:
+
+- **Retrieve GitHub Action logs** to detect failures
+- **Iterate on PRs** until they're in a mergeable state
+- **Eliminate grunt work** normally required to debug automated tests
+
+## Real-World Examples
+
+### Example 1: Asynchronous Code Review
+
+```
+In PR #45, which fixes issue #44, you mentioned adding a pre-push hook with the same validation as the pre-commit hook. Can you confirm whether this introduces redundant checks that might slow down development? If so, we should optimize it.
+```
+
+**Why this works well:**
+- Asks MyCoder to analyze its own previous work
+- Focuses on optimization and developer experience
+- Treats MyCoder as a teammate who can explain their decisions
+
+### Example 2: Batch Processing Multiple Issues
+
+```
+Can you implement GitHub issues #31 and #30 together in a single PR? This will ensure related changes are reviewed and merged simultaneously. Once done, submit the PR and link both issues.
+```
+
+**Why this works well:**
+- Groups related tasks for efficient implementation
+- Provides clear instructions on the desired outcome
+- Leverages GitHub references to maintain context
+
+### Example 3: Autonomous Debugging
+
+```
+You just created PR #34, fixing issues #30 and #31. However, the CI is failing. Check GitHub Actions to diagnose the issue and determine if your recent repository reorganization has affected workflows or Docker configurations. If unrelated to the fixes, create a separate GitHub issue and submit an independent PR to address it.
+```
+
+**Why this works well:**
+- Asks MyCoder to independently investigate a problem
+- Provides context about potential causes
+- Gives clear guidance on how to proceed based on findings
+- Maintains proper issue/PR hygiene
+
+## Transforming the Developer Experience
+
+Using GitHub Mode doesn't just increase productivity—it fundamentally changes how you interact with MyCoder:
+
+- **Reduced cognitive load**: You don't need to maintain context between sessions
+- **Asynchronous collaboration**: You can review MyCoder's work on your schedule
+- **Increased autonomy**: MyCoder can work independently on well-defined tasks
+- **Better accountability**: All changes are tracked, reviewed, and properly attributed
+
+By structuring work through GitHub, you're providing MyCoder with a system of record that ensures continuity across tasks and makes it easy to revisit past work, turning your AI assistant into a true coding collaborator rather than a tool you need to micromanage.

blog/tags.yml

@@ -47,3 +47,18 @@ case-study:
   label: Case Study
   permalink: /case-study
   description: Real-world examples and case studies
+
+github:
+  label: GitHub
+  permalink: /github
+  description: Content related to GitHub features and workflows
+
+productivity:
+  label: Productivity
+  permalink: /productivity
+  description: Tips and techniques for improving productivity
+
+workflow:
+  label: Workflow
+  permalink: /workflow
+  description: Development workflows and process improvements

docs/examples/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Examples",
+  "position": 3,
+  "link": {
+    "type": "doc",
+    "id": "examples/index"
+  }
+}

docs/examples/code-development.md

@@ -0,0 +1,89 @@
+---
+title: Code Development
+description: Examples of implementing features, fixing bugs, and writing tests
+---
+
+# Code Development
+
+MyCoder can assist with a wide range of code development tasks, from implementing new features to fixing bugs and improving existing code. This page showcases real-world examples of effective prompts for these scenarios.
+
+## Implementing Feature Requests
+
+### Example: Implementing Recommendations from an Issue
+
+```
+Can you implement the recommendations 2 and 3 from issue #44? You can look at the CI Github Actions workflow in ../mycoder-websites/.github as guide to setting up a similar CI action that validates the build and runs lint, etc for this repo.
+```
+
+**Why this works well:**
+- References specific recommendations from an existing issue
+- Points to an example implementation in another repository as a reference
+- Clearly defines the scope (recommendations 2 and 3)
+- Provides context about the expected outcome (CI action for build validation and linting)
+
+**Technique:** Referencing existing issues and providing examples from other parts of the codebase helps MyCoder understand both the requirements and the implementation style.
+
+## Architectural Changes and Refactoring
+
+### Example: Refactoring an SDK Implementation
+
+```
+Recently this project was converted from using the Anthropic SDK directly to using the Vercel AI SDK. Since then it has created reliability problems. That change was made 4 days ago in this PR: https://github.com/drivecore/mycoder/pull/55/files
+
+And it was built upon by adding support for ollama, grok/xai and openai in subsequent PRs. I would like to back out the adoption of the Vercel AI SDK, both the 'ai' npm library as well as the '@ai-sdk' npm libraries and thus also back out support for Ollama, OpenAI and Grok.
+
+In the future I will add back these but the Vercel AI SDK is not working well. While we back this out I would like to, as we re-implement using the Anthropic SDK, I would like to keep some level of abstraction around the specific LLM.
+
+Thus I would like to have our own Message type and it should have system, user, assistant, tool_use, tool_result sub-types with their respective fields. We can base it on the Vercel AI SDK. And then we should implement a generic generateText() type that takes messages and the tools and other standard LLM settings and returns a new set of messages - just as anthropic's SDK does.
+
+We can have an Anthropic-specific function that takes the API key + the model and returns a generateText() function that meets the generic type. Thus we can isolate the Anthropic specific code from the rest of the application making it easier to support other models in the future.
+
+The anthropic specific implementation of generateText will have to convert from the generic messages to anthropics specific type of messages and after text completion, it will need to convert back. This shouldn't be too involved.
+
+We can skip token caching on the first go around, but lets create both an issue for this main conversion I've described as well as follow on issues to add token caching as well as OpenAI and Ollama support. You can check out old branches of the code here if that helps you analyze the code to understand.
+
+I would like a plan of implementation as a comment on the first issue - the main conversion away from Vercel AI SDK.
+```
+
+**Why this works well:**
+- Provides detailed background on the current implementation
+- References specific PRs for context
+- Clearly outlines the desired architecture with specific components
+- Explains the rationale behind the changes
+- Specifies what to include now vs. future additions
+- Requests both implementation issues and a plan
+
+**Technique:** For complex architectural changes, providing detailed context and a clear vision of the desired outcome helps MyCoder understand both the technical requirements and the reasoning behind them.
+
+## Debugging and Troubleshooting
+
+### Example: Investigating Build Configuration Issues
+
+```
+When I run this command \"pnpm --filter @web3dsurvey/api-server build\" in the current directory, it runs into an error because one of the packages in this mono-repo upon which @web3dsurvey/api-server is dependent is not built, but I am confused because I thought that pnpm would automatically build packages that are depended upon.
+
+I must have some part of the configuration of the current project incorrect right? Can you create an issue for this and then investigate. You can use the command \"pnpm clean:dist\" to reset the package to its non-built state.
+```
+
+**Why this works well:**
+- Describes the specific command that's failing
+- Explains the expected behavior and the actual outcome
+- Shares the developer's hypothesis about the cause
+- Provides a command for reproducing the issue
+- Asks for both an issue creation and an investigation
+
+**Technique:** When troubleshooting, providing MyCoder with the exact commands, expected behavior, and reproduction steps helps it diagnose and fix the issue more effectively.
+
+### Example: Investigating CI Failures
+
+```
+It seems that the latest GitHub action failed, can you investigate it and make a GitHub issue with the problem and then push a PR that fixes the issue? Please wait for the new GitHub action to complete before declaring success.
+```
+
+**Why this works well:**
+- Identifies a specific problem (GitHub action failure)
+- Requests a complete workflow: investigation, issue creation, and fix implementation
+- Sets clear expectations for verification (waiting for the GitHub action to complete)
+
+**Technique:** Asking MyCoder to handle the full cycle from investigation to fix helps ensure that the problem is properly understood and addressed.
+

docs/examples/code-review.md

@@ -0,0 +1,55 @@
+---
+title: Code Review
+description: Using MyCoder to review PRs, analyze code quality, and suggest improvements
+---
+
+# Code Review
+
+MyCoder is excellent at reviewing code, analyzing PRs, and providing feedback on potential improvements. This page showcases real-world examples of effective prompts for these scenarios.
+
+## PR Review and Analysis
+
+### Example: Reviewing a PR for Potential Duplication
+
+```
+In the current PR #45, which fixes issue #44 and it is also currently checked out as the current branch, there isn't duplication of the checks are there? In your writeup you say that \"added pre-push hook with the same validation\". It seems that we have both a pre-commit hook and a pre-push hook that do the same thing? Won't that slow things down?
+```
+
+**Why this works well:**
+- References a specific PR and issue
+- Quotes specific text from the PR description
+- Asks a focused question about a potential issue (duplication)
+- Expresses concern about a specific impact (performance slowdown)
+
+**Technique:** When reviewing PRs, asking MyCoder targeted questions about specific aspects helps surface potential issues that might not be immediately obvious.
+
+## Identifying Configuration Issues
+
+### Example: Reviewing Package Manager Configuration
+
+```
+I think that the github action workflows and maybe the docker build are still making assumptions about using npm rather than pnpm. Can you look at ../Business/drivecore/mycoder-websites as an example of docker files that use pnpm and also github action workflows that use pnpm and adapt the current project to use that style. Please create a github issue and then once the task is complete please submit a PR.
+```
+
+**Why this works well:**
+- Identifies a specific concern (npm vs. pnpm assumptions)
+- Points to a reference implementation with the desired approach
+- Clearly defines the expected deliverables (GitHub issue and PR)
+- Provides context about the current state and desired outcome
+
+**Technique:** Asking MyCoder to compare configurations across projects helps identify inconsistencies and standardize approaches.
+
+## UI and Design Review
+
+### Example: Requesting UI Improvements
+
+```
+Can you make the blue that is used for the links to be a little more dark-grey blue? And can you remove the underline from links by default? Please create a Github issue for this and a PR.
+```
+
+**Why this works well:**
+- Makes specific, focused requests for UI changes
+- Clearly describes the desired outcome
+- Specifies the process (create an issue and PR)
+
+**Technique:** For UI changes, being specific about the desired visual outcome helps MyCoder implement changes that match your expectations.

docs/examples/devops.md

@@ -0,0 +1,71 @@
+---
+title: DevOps
+description: Setting up CI/CD, Docker configurations, and environment management
+---
+
+# DevOps
+
+MyCoder can help with various DevOps tasks, including setting up CI/CD pipelines, configuring Docker, and managing build environments. This page showcases real-world examples of effective prompts for these scenarios.
+
+## CI/CD Configuration
+
+### Example: Setting Up GitHub Actions Workflows
+
+```
+Can you implement the recommendations 2 and 3 from issue #44. You can look at the CI Github Actions workflow in ../mycoder-websites/.github as guide to setting up a similar CI action that validates the build and runs lint, etc for this repo.
+```
+
+**Why this works well:**
+- References specific recommendations from an existing issue
+- Points to an example implementation in another repository
+- Clearly defines the expected outcome (CI action for build validation and linting)
+
+**Technique:** Providing reference implementations helps MyCoder understand your preferred approach to CI/CD configuration.
+
+## Package Manager Configuration
+
+### Example: Converting from npm to pnpm
+
+```
+I think that the github action workflows and maybe the docker build are still making assumptions about using npm rather than pnpm. Can you look at ../Business/drivecore/mycoder-websites as an example of docker files that use pnpm and also github action workflows that use pnpm and adapt the current project to use that style. Please create a github issue and then once the task is complete please submit a PR.
+```
+
+**Why this works well:**
+- Identifies a specific configuration issue (npm vs. pnpm)
+- Points to a reference implementation with the desired approach
+- Clearly defines the expected deliverables (GitHub issue and PR)
+
+**Technique:** When migrating between different tools or approaches, providing MyCoder with examples of the target configuration helps ensure consistency.
+
+## Build Configuration Troubleshooting
+
+### Example: Investigating Mono-Repo Build Issues
+
+```
+When I run this command \"pnpm --filter @web3dsurvey/api-server build\" in the current directory, it runs into an error because one of the packages in this mono-repo upon which @web3dsurvey/api-server is dependent is not built, but I am confused because I thought that pnpm would automatically build packages that are depended upon.
+
+I must have some part of the configuration of the current project incorrect right? Can you create an issue for this and then investigate. You can use the command \"pnpm clean:dist\" to reset the package to its non-built state.
+```
+
+**Why this works well:**
+- Describes the specific command that's failing
+- Explains the expected behavior and the actual outcome
+- Shares the developer's hypothesis about the cause
+- Provides a command for reproducing the issue
+
+**Technique:** For build configuration issues, providing MyCoder with the exact commands and expected behavior helps it diagnose and fix configuration problems effectively.
+
+## Investigating CI/CD Failures
+
+### Example: Debugging GitHub Actions
+
+```
+It seems that the latest GitHub action failed, can you investigate it and make a GitHub issue with the problem and then push a PR that fixes the issue? Please wait for the new GitHub action to complete before declaring success.
+```
+
+**Why this works well:**
+- Identifies a specific problem (GitHub action failure)
+- Requests a complete workflow: investigation, issue creation, and fix implementation
+- Sets clear expectations for verification
+
+**Technique:** Having MyCoder investigate CI failures helps identify and resolve configuration issues that might be complex or time-consuming to debug manually.