Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit a67e552

Browse files
committed
it builds.
1 parent c25dc1b commit a67e552

9 files changed

+727
-9
lines changed

docs/examples/_category_.json

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,7 @@
1-
{\n "label": "Examples",\n "position": 3,\n "link": {\n "type": "generated-index"\n }\n}
1+
{
2+
"label": "Examples",
3+
"position": 3,
4+
"link": {
5+
"type": "generated-index"
6+
}
7+
}

docs/examples/code-development.md

Lines changed: 89 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,89 @@
1-
---\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
1+
---
2+
title: Code Development Examples
3+
description: Examples of implementing features, fixing bugs, and writing tests
4+
---
5+
6+
# Code Development Examples
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

Lines changed: 55 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,55 @@
1-
---\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
1+
---
2+
title: Code Review and Analysis Examples
3+
description: Using MyCoder to review PRs, analyze code quality, and suggest improvements
4+
---
5+
6+
# Code Review and Analysis Examples
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.

0 commit comments

Comments
 (0)