Skip to content

Commit 7b4d2be

Browse files
bhoustonbhouston
authored
Merge pull request #47 from drivecore/add-examples-section
Add Examples Section to Documentation
2 parents d246ee9 + 156513f commit 7b4d2be

10 files changed

+559
-1
lines changed

‎blog/github-mode-productivity.md

+96
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
---
2+
title: GitHub Mode as a Productivity Multiplier
3+
shortTitle: GitHub Mode Productivity
4+
date: 2025-03-07
5+
authors: [ben]
6+
tags: [github, productivity, workflow]
7+
---
8+
9+
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.
10+
11+
<!-- truncate -->
12+
13+
## The Productivity Breakthrough
14+
15+
Using GitHub Mode with MyCoder can lead to dramatic productivity improvements:
16+
17+
- **3x to 5x increase in development velocity**
18+
- **More autonomous work** with less need for constant oversight
19+
- **Higher quality contributions** through structured workflows
20+
21+
## How GitHub Mode Transforms the Workflow
22+
23+
GitHub Mode enables MyCoder to interact with GitHub in ways that mirror a human team member:
24+
25+
### 1. GitHub as External Memory
26+
27+
GitHub serves as both a readable and writable memory store, allowing MyCoder to:
28+
29+
- **Create GitHub issues** to track tasks and document its analyses
30+
- **Comment on issues** with detailed breakdowns before implementation
31+
- **Retrieve existing issues** and execute them autonomously
32+
- **Reference past work** to maintain context across multiple sessions
33+
34+
### 2. Pull Requests as Work Units
35+
36+
Using PRs as the primary unit of work changes the interaction model:
37+
38+
- Instead of real-time back-and-forth, you can **batch your reviews**
39+
- Each PR provides a **clear, reviewable unit of submitted work**
40+
- MyCoder can **refine PRs** based on your feedback or CI/CD results
41+
- You can let MyCoder work autonomously, then review asynchronously
42+
43+
### 3. Leveraging CI/CD Feedback
44+
45+
MyCoder can integrate with your development pipeline:
46+
47+
- **Retrieve GitHub Action logs** to detect failures
48+
- **Iterate on PRs** until they're in a mergeable state
49+
- **Eliminate grunt work** normally required to debug automated tests
50+
51+
## Real-World Examples
52+
53+
### Example 1: Asynchronous Code Review
54+
55+
```
56+
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.
57+
```
58+
59+
**Why this works well:**
60+
- Asks MyCoder to analyze its own previous work
61+
- Focuses on optimization and developer experience
62+
- Treats MyCoder as a teammate who can explain their decisions
63+
64+
### Example 2: Batch Processing Multiple Issues
65+
66+
```
67+
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.
68+
```
69+
70+
**Why this works well:**
71+
- Groups related tasks for efficient implementation
72+
- Provides clear instructions on the desired outcome
73+
- Leverages GitHub references to maintain context
74+
75+
### Example 3: Autonomous Debugging
76+
77+
```
78+
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.
79+
```
80+
81+
**Why this works well:**
82+
- Asks MyCoder to independently investigate a problem
83+
- Provides context about potential causes
84+
- Gives clear guidance on how to proceed based on findings
85+
- Maintains proper issue/PR hygiene
86+
87+
## Transforming the Developer Experience
88+
89+
Using GitHub Mode doesn't just increase productivity—it fundamentally changes how you interact with MyCoder:
90+
91+
- **Reduced cognitive load**: You don't need to maintain context between sessions
92+
- **Asynchronous collaboration**: You can review MyCoder's work on your schedule
93+
- **Increased autonomy**: MyCoder can work independently on well-defined tasks
94+
- **Better accountability**: All changes are tracked, reviewed, and properly attributed
95+
96+
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

+15
Original file line numberDiff line numberDiff line change
@@ -47,3 +47,18 @@ case-study:
4747
label: Case Study
4848
permalink: /case-study
4949
description: Real-world examples and case studies
50+
51+
github:
52+
label: GitHub
53+
permalink: /github
54+
description: Content related to GitHub features and workflows
55+
56+
productivity:
57+
label: Productivity
58+
permalink: /productivity
59+
description: Tips and techniques for improving productivity
60+
61+
workflow:
62+
label: Workflow
63+
permalink: /workflow
64+
description: Development workflows and process improvements

‎docs/examples/_category_.json

+8
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
{
2+
"label": "Examples",
3+
"position": 3,
4+
"link": {
5+
"type": "doc",
6+
"id": "examples/index"
7+
}
8+
}

‎docs/examples/code-development.md

+89
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
---
2+
title: Code Development
3+
description: Examples of implementing features, fixing bugs, and writing tests
4+
---
5+
6+
# Code Development
7+
8+
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.
9+
10+
## Implementing Feature Requests
11+
12+
### Example: Implementing Recommendations from an Issue
13+
14+
```
15+
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.
16+
```
17+
18+
**Why this works well:**
19+
- References specific recommendations from an existing issue
20+
- Points to an example implementation in another repository as a reference
21+
- Clearly defines the scope (recommendations 2 and 3)
22+
- Provides context about the expected outcome (CI action for build validation and linting)
23+
24+
**Technique:** Referencing existing issues and providing examples from other parts of the codebase helps MyCoder understand both the requirements and the implementation style.
25+
26+
## Architectural Changes and Refactoring
27+
28+
### Example: Refactoring an SDK Implementation
29+
30+
```
31+
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
32+
33+
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.
34+
35+
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.
36+
37+
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.
38+
39+
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.
40+
41+
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.
42+
43+
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.
44+
45+
I would like a plan of implementation as a comment on the first issue - the main conversion away from Vercel AI SDK.
46+
```
47+
48+
**Why this works well:**
49+
- Provides detailed background on the current implementation
50+
- References specific PRs for context
51+
- Clearly outlines the desired architecture with specific components
52+
- Explains the rationale behind the changes
53+
- Specifies what to include now vs. future additions
54+
- Requests both implementation issues and a plan
55+
56+
**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.
57+
58+
## Debugging and Troubleshooting
59+
60+
### Example: Investigating Build Configuration Issues
61+
62+
```
63+
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.
64+
65+
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.
66+
```
67+
68+
**Why this works well:**
69+
- Describes the specific command that's failing
70+
- Explains the expected behavior and the actual outcome
71+
- Shares the developer's hypothesis about the cause
72+
- Provides a command for reproducing the issue
73+
- Asks for both an issue creation and an investigation
74+
75+
**Technique:** When troubleshooting, providing MyCoder with the exact commands, expected behavior, and reproduction steps helps it diagnose and fix the issue more effectively.
76+
77+
### Example: Investigating CI Failures
78+
79+
```
80+
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.
81+
```
82+
83+
**Why this works well:**
84+
- Identifies a specific problem (GitHub action failure)
85+
- Requests a complete workflow: investigation, issue creation, and fix implementation
86+
- Sets clear expectations for verification (waiting for the GitHub action to complete)
87+
88+
**Technique:** Asking MyCoder to handle the full cycle from investigation to fix helps ensure that the problem is properly understood and addressed.
89+

‎docs/examples/code-review.md

+55
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
---
2+
title: Code Review
3+
description: Using MyCoder to review PRs, analyze code quality, and suggest improvements
4+
---
5+
6+
# Code Review
7+
8+
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.
9+
10+
## PR Review and Analysis
11+
12+
### Example: Reviewing a PR for Potential Duplication
13+
14+
```
15+
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?
16+
```
17+
18+
**Why this works well:**
19+
- References a specific PR and issue
20+
- Quotes specific text from the PR description
21+
- Asks a focused question about a potential issue (duplication)
22+
- Expresses concern about a specific impact (performance slowdown)
23+
24+
**Technique:** When reviewing PRs, asking MyCoder targeted questions about specific aspects helps surface potential issues that might not be immediately obvious.
25+
26+
## Identifying Configuration Issues
27+
28+
### Example: Reviewing Package Manager Configuration
29+
30+
```
31+
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.
32+
```
33+
34+
**Why this works well:**
35+
- Identifies a specific concern (npm vs. pnpm assumptions)
36+
- Points to a reference implementation with the desired approach
37+
- Clearly defines the expected deliverables (GitHub issue and PR)
38+
- Provides context about the current state and desired outcome
39+
40+
**Technique:** Asking MyCoder to compare configurations across projects helps identify inconsistencies and standardize approaches.
41+
42+
## UI and Design Review
43+
44+
### Example: Requesting UI Improvements
45+
46+
```
47+
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.
48+
```
49+
50+
**Why this works well:**
51+
- Makes specific, focused requests for UI changes
52+
- Clearly describes the desired outcome
53+
- Specifies the process (create an issue and PR)
54+
55+
**Technique:** For UI changes, being specific about the desired visual outcome helps MyCoder implement changes that match your expectations.

‎docs/examples/devops.md

+71
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
---
2+
title: DevOps
3+
description: Setting up CI/CD, Docker configurations, and environment management
4+
---
5+
6+
# DevOps
7+
8+
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.
9+
10+
## CI/CD Configuration
11+
12+
### Example: Setting Up GitHub Actions Workflows
13+
14+
```
15+
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.
16+
```
17+
18+
**Why this works well:**
19+
- References specific recommendations from an existing issue
20+
- Points to an example implementation in another repository
21+
- Clearly defines the expected outcome (CI action for build validation and linting)
22+
23+
**Technique:** Providing reference implementations helps MyCoder understand your preferred approach to CI/CD configuration.
24+
25+
## Package Manager Configuration
26+
27+
### Example: Converting from npm to pnpm
28+
29+
```
30+
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.
31+
```
32+
33+
**Why this works well:**
34+
- Identifies a specific configuration issue (npm vs. pnpm)
35+
- Points to a reference implementation with the desired approach
36+
- Clearly defines the expected deliverables (GitHub issue and PR)
37+
38+
**Technique:** When migrating between different tools or approaches, providing MyCoder with examples of the target configuration helps ensure consistency.
39+
40+
## Build Configuration Troubleshooting
41+
42+
### Example: Investigating Mono-Repo Build Issues
43+
44+
```
45+
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.
46+
47+
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.
48+
```
49+
50+
**Why this works well:**
51+
- Describes the specific command that's failing
52+
- Explains the expected behavior and the actual outcome
53+
- Shares the developer's hypothesis about the cause
54+
- Provides a command for reproducing the issue
55+
56+
**Technique:** For build configuration issues, providing MyCoder with the exact commands and expected behavior helps it diagnose and fix configuration problems effectively.
57+
58+
## Investigating CI/CD Failures
59+
60+
### Example: Debugging GitHub Actions
61+
62+
```
63+
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.
64+
```
65+
66+
**Why this works well:**
67+
- Identifies a specific problem (GitHub action failure)
68+
- Requests a complete workflow: investigation, issue creation, and fix implementation
69+
- Sets clear expectations for verification
70+
71+
**Technique:** Having MyCoder investigate CI failures helps identify and resolve configuration issues that might be complex or time-consuming to debug manually.

0 commit comments

Comments
 (0)