{\n "label": "Examples",\n "position": 3,\n "link": {\n "type": "generated-index"\n }\n}

---\ntitle: Code Development Examples\ndescription: Examples of implementing features, fixing bugs, and writing tests\n---\n\n# Code Development Examples\n\nMyCoder 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.\n\n## Implementing Feature Requests\n\n### Example: Implementing Recommendations from an Issue\n\n```\nCan 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.\n```\n\n**Why this works well:**\n- References specific recommendations from an existing issue\n- Points to an example implementation in another repository as a reference\n- Clearly defines the scope (recommendations 2 and 3)\n- Provides context about the expected outcome (CI action for build validation and linting)\n\n**Technique:** Referencing existing issues and providing examples from other parts of the codebase helps MyCoder understand both the requirements and the implementation style.\n\n## Architectural Changes and Refactoring\n\n### Example: Refactoring an SDK Implementation\n\n```\nRecently 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\n\nAnd 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.\n\nIn 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.\n\nThus 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.\n\nWe 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.\n\nThe 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.\n\nWe 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.\n\nI would like a plan of implementation as a comment on the first issue - the main conversion away from Vercel AI SDK.\n```\n\n**Why this works well:**\n- Provides detailed background on the current implementation\n- References specific PRs for context\n- Clearly outlines the desired architecture with specific components\n- Explains the rationale behind the changes\n- Specifies what to include now vs. future additions\n- Requests both implementation issues and a plan\n\n**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.\n\n## Debugging and Troubleshooting\n\n### Example: Investigating Build Configuration Issues\n\n```\nWhen 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.\n\nI 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.\n```\n\n**Why this works well:**\n- Describes the specific command that's failing\n- Explains the expected behavior and the actual outcome\n- Shares the developer's hypothesis about the cause\n- Provides a command for reproducing the issue\n- Asks for both an issue creation and an investigation\n\n**Technique:** When troubleshooting, providing MyCoder with the exact commands, expected behavior, and reproduction steps helps it diagnose and fix the issue more effectively.\n\n### Example: Investigating CI Failures\n\n```\nIt 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.\n```\n\n**Why this works well:**\n- Identifies a specific problem (GitHub action failure)\n- Requests a complete workflow: investigation, issue creation, and fix implementation\n- Sets clear expectations for verification (waiting for the GitHub action to complete)\n\n**Technique:** Asking MyCoder to handle the full cycle from investigation to fix helps ensure that the problem is properly understood and addressed.\n

---\ntitle: Code Review and Analysis Examples\ndescription: Using MyCoder to review PRs, analyze code quality, and suggest improvements\n---\n\n# Code Review and Analysis Examples\n\nMyCoder 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.\n\n## PR Review and Analysis\n\n### Example: Reviewing a PR for Potential Duplication\n\n```\nIn 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?\n```\n\n**Why this works well:**\n- References a specific PR and issue\n- Quotes specific text from the PR description\n- Asks a focused question about a potential issue (duplication)\n- Expresses concern about a specific impact (performance slowdown)\n\n**Technique:** When reviewing PRs, asking MyCoder targeted questions about specific aspects helps surface potential issues that might not be immediately obvious.\n\n## Identifying Configuration Issues\n\n### Example: Reviewing Package Manager Configuration\n\n```\nI 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.\n```\n\n**Why this works well:**\n- Identifies a specific concern (npm vs. pnpm assumptions)\n- Points to a reference implementation with the desired approach\n- Clearly defines the expected deliverables (GitHub issue and PR)\n- Provides context about the current state and desired outcome\n\n**Technique:** Asking MyCoder to compare configurations across projects helps identify inconsistencies and standardize approaches.\n\n## UI and Design Review\n\n### Example: Requesting UI Improvements\n\n```\nCan 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.\n```\n\n**Why this works well:**\n- Makes specific, focused requests for UI changes\n- Clearly describes the desired outcome\n- Specifies the process (create an issue and PR)\n\n**Technique:** For UI changes, being specific about the desired visual outcome helps MyCoder implement changes that match your expectations.\n

---\ntitle: DevOps and Configuration Examples\ndescription: Setting up CI/CD, Docker configurations, and environment management\n---\n\n# DevOps and Configuration Examples\n\nMyCoder 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.\n\n## CI/CD Configuration\n\n### Example: Setting Up GitHub Actions Workflows\n\n```\nCan 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.\n```\n\n**Why this works well:**\n- References specific recommendations from an existing issue\n- Points to an example implementation in another repository\n- Clearly defines the expected outcome (CI action for build validation and linting)\n\n**Technique:** Providing reference implementations helps MyCoder understand your preferred approach to CI/CD configuration.\n\n## Package Manager Configuration\n\n### Example: Converting from npm to pnpm\n\n```\nI 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.\n```\n\n**Why this works well:**\n- Identifies a specific configuration issue (npm vs. pnpm)\n- Points to a reference implementation with the desired approach\n- Clearly defines the expected deliverables (GitHub issue and PR)\n\n**Technique:** When migrating between different tools or approaches, providing MyCoder with examples of the target configuration helps ensure consistency.\n\n## Build Configuration Troubleshooting\n\n### Example: Investigating Mono-Repo Build Issues\n\n```\nWhen 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.\n\nI 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.\n```\n\n**Why this works well:**\n- Describes the specific command that's failing\n- Explains the expected behavior and the actual outcome\n- Shares the developer's hypothesis about the cause\n- Provides a command for reproducing the issue\n\n**Technique:** For build configuration issues, providing MyCoder with the exact commands and expected behavior helps it diagnose and fix configuration problems effectively.\n\n## Investigating CI/CD Failures\n\n### Example: Debugging GitHub Actions\n\n```\nIt 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.\n```\n\n**Why this works well:**\n- Identifies a specific problem (GitHub action failure)\n- Requests a complete workflow: investigation, issue creation, and fix implementation\n- Sets clear expectations for verification\n\n**Technique:** Having MyCoder investigate CI failures helps identify and resolve configuration issues that might be complex or time-consuming to debug manually.\n

---\ntitle: Effective Prompting Techniques\ndescription: Key patterns and strategies for getting the best results from MyCoder\n---\n\n# Effective Prompting Techniques\n\nAfter analyzing numerous successful MyCoder interactions, we've identified several key techniques that consistently lead to effective results. This page outlines these techniques to help you craft better prompts for your own projects.\n\n## Using GitHub as External Memory\n\nOne of the most powerful techniques is using GitHub as a persistent external memory store for your project. This approach provides several benefits:\n\n### Why This Works\n\n- **Maintains Context:** GitHub issues, PRs, and commits create a persistent record that MyCoder can reference\n- **Tracks Evolution:** Changes over time are documented and accessible\n- **Structures Work:** Breaking work into issues and PRs creates natural task boundaries\n- **Enables Collaboration:** Both humans and MyCoder can reference and build upon the same information\n\n### Implementation Techniques\n\n1. **Create Issues for Tasks:** Break work into discrete issues that MyCoder can reference by number\n2. **Reference Issue Numbers:** Use `#issue-number` in your prompts to give MyCoder context\n3. **Link Related Work:** Reference previous PRs or issues when asking for related work\n4. **Document Decisions:** Use issue comments to record decisions and rationale\n\n## Clear Task Definition\n\nClearly defining tasks helps MyCoder understand exactly what you need.\n\n### Why This Works\n\n- **Reduces Ambiguity:** Explicit instructions minimize misunderstandings\n- **Sets Expectations:** Clear deliverables help MyCoder know when it's done\n- **Provides Context:** Background information helps MyCoder make better decisions\n\n### Implementation Techniques\n\n1. **Specify Deliverables:** Clearly state what you expect (e.g., \"create a GitHub issue and PR\")\n2. **Provide Rationale:** Explain why you want something done a certain way\n3. **Set Boundaries:** Define what's in scope and out of scope\n4. **Reference Examples:** Point to existing code or documentation as examples\n\n## Breaking Down Complex Tasks\n\nComplex tasks are more manageable when broken into smaller pieces.\n\n### Why This Works\n\n- **Simplifies Implementation:** Smaller tasks are easier to understand and implement\n- **Enables Verification:** You can verify each piece before moving to the next\n- **Improves Quality:** Focused work typically results in better quality\n\n### Implementation Techniques\n\n1. **Create Multiple Issues:** Break large features into multiple GitHub issues\n2. **Implement Incrementally:** Ask MyCoder to implement one piece at a time\n3. **Verify Incrementally:** Check each implementation before moving forward\n4. **Build Complexity Gradually:** Start with core functionality, then add refinements\n\n## Providing References and Examples\n\nPointing MyCoder to existing code or documentation helps it understand your preferred approach.\n\n### Why This Works\n\n- **Maintains Consistency:** References help ensure new code matches existing patterns\n- **Reduces Explanation Needed:** Examples often communicate better than descriptions\n- **Leverages Existing Knowledge:** MyCoder can adapt patterns it sees in your codebase\n\n### Implementation Techniques\n\n1. **Reference Similar Code:** Point to similar implementations in your codebase\n2. **Provide File Paths:** Be specific about where to find reference implementations\n3. **Highlight Key Patterns:** Call attention to specific aspects of the examples\n4. **Cross-Repository References:** Reference patterns from other repositories when applicable\n\n## Iterative Refinement\n\nIterative feedback and refinement often leads to better results than trying to get everything perfect in one go.\n\n### Why This Works\n\n- **Builds Understanding:** Each iteration helps MyCoder better understand your needs\n- **Focuses Feedback:** You can address specific aspects in each iteration\n- **Improves Quality:** Progressive refinement typically leads to better outcomes\n\n### Implementation Techniques\n\n1. **Start Simple:** Begin with a basic implementation\n2. **Provide Specific Feedback:** Focus on particular aspects to improve\n3. **Acknowledge Progress:** Recognize what's working well\n4. **Build on Success:** Use successful patterns as references for future work\n

---\ntitle: MyCoder Examples\ndescription: Real-world examples of using MyCoder effectively\n---\n\n# MyCoder Examples\n\nThis section contains real-world examples of how to use MyCoder effectively. These examples are based on actual prompts that have proven successful in various scenarios.\n\nExamples are organized into categories to help you find relevant patterns for your specific needs.\n\n## Why Examples Matter\n\nSeeing how others effectively use MyCoder can help you:\n\n- Learn optimal prompt structures\n- Discover patterns for complex tasks\n- Understand how to break down problems\n- Improve your interaction efficiency\n\n## Using GitHub as External Memory\n\nOne key insight for getting the best results from MyCoder is using GitHub as a record of tasks and results. This serves as a persistent external memory store, allowing MyCoder to:\n\n- Reference previous work and decisions\n- Track the evolution of a project\n- Maintain context across multiple sessions\n- Build upon previous tasks systematically\n\nMany of the examples in this section demonstrate this approach in action.\n\n## Example Categories\n\n- [**Project Management**](./project-management.md) - Using MyCoder for planning, issue creation, and project organization\n- [**Code Development**](./code-development.md) - Examples of implementing features, fixing bugs, and writing tests\n- [**Code Review and Analysis**](./code-review.md) - Using MyCoder to review PRs, analyze code quality, and suggest improvements\n- [**DevOps and Configuration**](./devops.md) - Setting up CI/CD, Docker configurations, and environment management\n