init: claude
This commit is contained in:
Prad Nukala committed
1 parent
2def250609
commit
3b87993d60
150 files changed
+29191
No files matched your search
@@ -0,0 +1,21 @@
|
||||
---
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(gh issue:*)
|
||||
description: Add a Subtask to the Current Issue or Another Issue
|
||||
---
|
||||
|
||||
Create a new sub-issue with the provided parent issue with an appropriate title, relevant file paths, and links to documentation if applicable using the following context: #$ARGUMENTS
|
||||
|
||||
## Warnings
|
||||
|
||||
- **If no Issue Number is provided use `gh issue list` and provide the number and titles for open issues. Only after a number is provided do you create a subtask for the parent task**
|
||||
- Use the provided context in order to generate the new sub-issue and require it to be linked to the parent issue.
|
||||
|
||||
## Requirements:
|
||||
|
||||
- Always keep the title short and descriptive so that it can be recorded as a single line in a changelog entry
|
||||
- Always include any expected data types as code formatted examples if necessary
|
||||
- Always include the relevant file paths of expected files to be changed
|
||||
- Always keep the issue body as succinct as possible with only essential context
|
||||
- Always use mcp\_\_exa_search to find associated documentation for the tasks
|
||||
- If protobuf or sql files will be changed with this issue add the 'breaking' label to the issue
|
||||
- Always assign the issue to myself
|
||||
@@ -0,0 +1,21 @@
|
||||
Write TODO comments for all unimplemented methods or broken functions found in the repository source code.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Recursively scan all source code files in the repository.
|
||||
2. Identify functions or methods that are unimplemented (e.g., empty bodies, `panic("not implemented")`, or stub implementations).
|
||||
3. Identify functions or methods that are broken or error-prone based on existing error handling or comments.
|
||||
4. For each such function or method:
|
||||
- Insert a clear TODO comment above the function definition indicating it requires implementation or fixing.
|
||||
- The TODO comment should describe the expected functionality or the issue to be resolved.
|
||||
5. Avoid duplicating TODO comments if one already exists for the function.
|
||||
6. Save the modified source files.
|
||||
7. Confirm completion with a summary message.
|
||||
|
||||
## Requirements
|
||||
|
||||
- TODO comments must be concise, actionable, and follow project comment style.
|
||||
- Use `mcp__exa_search` or other tools to gather context if needed.
|
||||
- Do not modify implemented or working functions.
|
||||
- Do not read any generated files or edit
|
||||
- Prompt for additional context if unclear about function status.
|
||||
@@ -0,0 +1,21 @@
|
||||
Collect all TODO comments found recursively in the repository and create grouped issues for them.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Recursively scan all source code files in the repository for TODO comments.
|
||||
2. Group TODOs by related feature, module, or context if possible.
|
||||
3. For each group of TODOs:
|
||||
- Create a new issue summarizing the group of TODOs using `mcp**github**create_issue`.
|
||||
- Include the relevant file paths and line numbers where TODOs were found.
|
||||
- Provide clear, concise descriptions of the tasks needed to resolve the TODOs.
|
||||
4. Avoid creating duplicate issues for the same TODOs.
|
||||
5. Confirm completion with a summary message listing all created issues.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Always keep issue titles short and descriptive.
|
||||
- Include expected data types or code examples if applicable.
|
||||
- Keep issue bodies succinct with only essential context.
|
||||
- Use `mcp__exa_search` to find associated documentation for TODO tasks.
|
||||
- Label issues appropriately (e.g., `enhance`, `bug`, `feature`, `docs`).
|
||||
- Prompt for additional context if TODO comments are unclear.
|
||||
@@ -0,0 +1,13 @@
|
||||
# Context7 Code Search
|
||||
|
||||
Use the context7 MCP server to search for relevant code context and documentation.
|
||||
|
||||
Usage: `/context <query>`
|
||||
|
||||
Example: `/context React hooks useState`
|
||||
|
||||
---
|
||||
|
||||
Search for code context related to: {{ARGS}}
|
||||
|
||||
Use the context7 MCP tools to find relevant documentation and code examples.
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(gh issue:*)
|
||||
description: Create a New Issue
|
||||
---
|
||||
|
||||
Create a new issue in the repository using the gh cli with an appropriate title, relevant file paths, and links to documentation if applicable using the following context: #$ARGUMENTS
|
||||
|
||||
# Instructions
|
||||
|
||||
1. For each url provided in the context use the `mcp__crawling_exa` to extract essential information.
|
||||
2. Think deeply about the cleanest implementation strategy prior to creating the issue.
|
||||
3. Add all File Paths affected and docs resources under a section in h2 for Context. If you cannot determine the file paths associated with the task then ask the user.
|
||||
4. Add Acceptance criteria as the last section with checkboxes under an h2 section. Ensure that the Acceptance Criteria enables Test-Driven Development.
|
||||
5. Always ensure issues are created in the same format as the Example in the final section
|
||||
|
||||
# Guidelines
|
||||
|
||||
- Always keep the title short and descriptive so that it can be recorded as a single line in a changelog entry
|
||||
- Always include any expected data types as code formatted examples if necessary
|
||||
- Always include the relevant file paths of expected files to be changed
|
||||
- Always keep the issue body as succinct as possible with only essential context
|
||||
- If protobuf or sql files will be changed with this issue add the 'breaking' label to the issue
|
||||
- Always assign the Issue to @prnk28
|
||||
|
||||
# Label List
|
||||
|
||||
NAME DESCRIPTION COLOR
|
||||
bug Something isn't working #d73a4a
|
||||
documentation Documentation improvements or additions #0075ca
|
||||
duplicate This issue or pull request already exists #CFD3D7
|
||||
enhancement Improvement to existing functionality #a2eeef
|
||||
feature New feature or request #0e8a16
|
||||
good first issue Good for newcomers #7057ff
|
||||
help wanted Extra attention is needed #008672
|
||||
logical Needs logical implementation for function #D6DC3B
|
||||
question Further information is requested #D4A5A5
|
||||
dependencies Dependency updates #0366d6
|
||||
database Database changes, migrations, or queries #1ABC9C
|
||||
webauthn WebAuthn authentication and credentials #FF7F0E
|
||||
refactor Code restructuring without changing functionality #d62728
|
||||
enhance Performance or usability improvements (use 'enhancement' instead) #9467bd
|
||||
api REST, gRPC, or WebAuthn API changes #2ECC71
|
||||
backend Core blockchain logic and keeper implementations #27AE60
|
||||
config Configuration files, parameters, or setup #16A085
|
||||
modules Cosmos SDK module changes (use specific x/* labels instead) #17becf
|
||||
observability Monitoring, logging, metrics, and debugging #FF6B6B
|
||||
testing Unit, integration, or e2e tests #4ECDC4
|
||||
deploy Docker, Kubernetes, or deployment configs #2496ED
|
||||
ipfs IPFS integration and decentralized storage #65C2CB
|
||||
devtools Development tooling, build scripts, or IDE #7F8C8D
|
||||
testnet Testnet configurations and deployments #8B5A3C
|
||||
breaking Breaking changes requiring migration #B60205
|
||||
docs Documentation updates (alias) #0366D6
|
||||
w3c W3C standards compliance (DID, WebAuthn, etc.) #005A9C
|
||||
x/did Decentralized Identity module #9B59B6
|
||||
cross-chain Multi-chain integrations and protocols #E67E22
|
||||
ibc Inter-Blockchain Communication protocol #F39C12
|
||||
ica Interchain Accounts functionality #F1C40F
|
||||
x/dwn Decentralized Web Node module #3498DB
|
||||
x/ucan User Controlled Authorization Networks module #E74C3C
|
||||
polish Code cleanup, formatting, or minor improvements #FFEAA7
|
||||
javascript JavaScript code changes #F7DF1E
|
||||
pkg/dns DNS package and resolution #0052CC
|
||||
pkg:ipfs IPFS package and storage #4A90E2
|
||||
pkg/vaults Vaults package and secure storage #2E86DE
|
||||
x/svc Service module #5DADE2
|
||||
x/dex Decentralized Exchange module #AF7AC5
|
||||
sdk #ededed
|
||||
pkg #ededed
|
||||
security #ededed
|
||||
cli #ededed
|
||||
test #ededed
|
||||
security/critical Critical security vulnerability requiring immediate attention (CVSS 9.0-10.0) #B60205
|
||||
security/high High priority security issue requiring prompt resolution (CVSS 7.0-8.9) #D93F0B
|
||||
security/medium Medium priority security issue (CVSS 4.0-6.9) #FBCA04
|
||||
security/low Low priority security improvement (CVSS 0.1-3.9) #0E8A16
|
||||
go Pull requests that update go code #16e2e2
|
||||
|
||||
# Example
|
||||
|
||||
An example issue should be formatted as:
|
||||
|
||||
```md
|
||||
Title: Implement x/dwn vaults plugin
|
||||
Labels: x/dwn, feature
|
||||
|
||||
## Requirements
|
||||
|
||||
- Must include DWN Bytes in Protobuf
|
||||
- Must Spawn DWN Plugins using Genesis Params
|
||||
- Must have Gas Free Query Methods for Spawn and Verify
|
||||
|
||||
## Context
|
||||
|
||||
### Affected Files
|
||||
|
||||
- @x/dwn/keeper/keeper.go
|
||||
- @x/dwn/client/wasm/main.go
|
||||
- @x/dwn/types/genesis.go
|
||||
|
||||
### Relevant Documentation
|
||||
|
||||
- [Example Doc 1](https://example.com)
|
||||
- [Example Doc 2](https://example.com)
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Tests for Spawning Plugins from the x/dwn Genesis
|
||||
- [ ] Tests for Resolving Vault Secret Data from IPFS
|
||||
- [ ] Test for full-round Sign/Verify/Refresh on-chain
|
||||
- [ ] Grpc Gateway Compatibility for HTTP Requests
|
||||
```
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
allowed-tools: Bash(devbox *), Bash(bun *), Bash(make *)
|
||||
description: Debug Errors for a command
|
||||
argument-hint: Command to run and Debug
|
||||
---
|
||||
|
||||
!$ARGUMENTS
|
||||
|
||||
You are responsible for debugging the errors present in the following command: `$ARGUMENTS`
|
||||
|
||||
- The command logs are provided
|
||||
- Read the logs returned by the command execution
|
||||
- Determine why the error occurred
|
||||
- Without generating disconnected spagheti code iteratively fix the issue
|
||||
- Keep the scope of changes specific to the package causing the command error
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Command successfully runs with no errors found in the log
|
||||
- The command successfully performs the action which is intended.
|
||||
- Never create MD files providing a summary of your changes
|
||||
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
description: Copy CHANGELOG.md into mdx docs
|
||||
---
|
||||
|
||||
- Read the contents of @docs/reference/changelog.mdx and find all referenced closed PRs.
|
||||
- Use `!gh pr view <ISSUE_NUMBER>` to view the pull request body for context on the version update.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Use the context found by viewing the PR to enhance the version update with helpful context on the release.
|
||||
- Keep the update short and only provide a concise list of relevant changes.
|
||||
- Always use the required Mintlify MDX format
|
||||
- Skip any releases already documented inside @docs/reference/changelog.mdx
|
||||
- Complete these tasks by assigning to @agent-documentation-expert
|
||||
|
||||
## Components Used
|
||||
|
||||
```mdx
|
||||
<Update label="2024-10-11" description="v0.1.0" tags={["Mintlify"]}>
|
||||
This is an update with a label, description, and tag.
|
||||
</Update>
|
||||
```
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(gh issue:*), Bash(git worktree:*)
|
||||
description: Enhance a OpenAPI Schema File
|
||||
argument-hint: OpenAPI File path and Module Readme
|
||||
---
|
||||
|
||||
- Update the contents of the following openapi file with clean documentation
|
||||
- Use the provided Module Readme for context
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
- Follow the best practices for the OpenAPI V3 Spec
|
||||
- Provide clean concise language for API docs
|
||||
- If docs are already formatted ensure they are properly formatted
|
||||
- Add x-mint metadata to the paths to assist with mintlify docs generation
|
||||
|
||||
## Mintlify Docs Metadata
|
||||
|
||||
### x-mint extension
|
||||
- The x-mint extension is a custom OpenAPI extension that provides additional control over how your API documentation is generated and displayed.
|
||||
|
||||
**Metadata**
|
||||
|
||||
- Override the default metadata for generated API pages by adding x-mint: metadata to any operation. You can use any metadata field that would be valid in MDX frontmatter except for openapi:
|
||||
|
||||
|
||||
{
|
||||
"paths": {
|
||||
"/users": {
|
||||
"get": {
|
||||
"summary": "Get users",
|
||||
"description": "Retrieve a list of users",
|
||||
"x-mint": {
|
||||
"metadata": {
|
||||
"title": "List all users",
|
||||
"description": "Fetch paginated user data with filtering options",
|
||||
"og:title": "Display a list of users"
|
||||
}
|
||||
},
|
||||
"parameters": [
|
||||
{
|
||||
// Parameter configuration
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Add content before the auto-generated API documentation using x-mint: content:
|
||||
|
||||
{
|
||||
"paths": {
|
||||
"/users": {
|
||||
"post": {
|
||||
"summary": "Create user",
|
||||
"x-mint": {
|
||||
"content": "## Prerequisites\n\nThis endpoint requires admin privileges and has rate limiting.\n\n<Note>User emails must be unique across the system.</Note>"
|
||||
},
|
||||
"parameters": [
|
||||
{
|
||||
// Parameter configuration
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
The content extension supports all Mintlify MDX components and formatting.
|
||||
|
||||
{
|
||||
"paths": {
|
||||
"/legacy-endpoint": {
|
||||
"get": {
|
||||
"summary": "Legacy endpoint",
|
||||
"x-mint": {
|
||||
"href": "/deprecated-endpoints/legacy-endpoint"
|
||||
}
|
||||
}
|
||||
},
|
||||
"/documented-elsewhere": {
|
||||
"post": {
|
||||
"summary": "Special endpoint",
|
||||
"x-mint": {
|
||||
"href": "/guides/special-endpoint-guide"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
When x-mint: href is present, the navigation entry will link directly to the specified URL instead of generating an API page.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
# Create GitHub Issue from Code Context
|
||||
|
||||
Analyzes code context and creates a GitHub issue using Claude with MCP.
|
||||
|
||||
Usage: `/issue-from-context <description>`
|
||||
|
||||
Example: `/issue-from-context Fix authentication bug in login flow`
|
||||
|
||||
---
|
||||
|
||||
Description: {{ARGS}}
|
||||
|
||||
Instructions:
|
||||
1. Use mcp::github::search_issues to find related issues
|
||||
2. Use mcp::exa::get_code_context_exa to find relevant code patterns
|
||||
3. Use mcp::github::create_issue to create a new issue with:
|
||||
- Title based on the description
|
||||
- Body with Summary, Requirements, and Acceptance Criteria
|
||||
- Relevant labels and assignees
|
||||
4. Return the created issue number in format: #123
|
||||
@@ -0,0 +1,19 @@
|
||||
# Ask Claude with MCP Context
|
||||
|
||||
Call Claude Code with MCP server context (github, exa, context7).
|
||||
|
||||
Usage: `/mcp-ask <query>`
|
||||
|
||||
Example: `/mcp-ask How do I implement OAuth2 in React?`
|
||||
|
||||
---
|
||||
|
||||
This command uses the context7, exa, and github MCP servers to gather relevant context, then provides a comprehensive answer.
|
||||
|
||||
Query: {{ARGS}}
|
||||
|
||||
Instructions:
|
||||
1. Use mcp::context7 tools to search for relevant code context
|
||||
2. Use mcp::exa::get_code_context_exa to find documentation
|
||||
3. Use mcp::github tools if repository-related
|
||||
4. Provide a detailed answer with code examples
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(gh issue:*), Bash(git worktree:*)
|
||||
description: Start work on Issue in new Branch
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- Read the content of PLAN.md
|
||||
- DO NOT CONTINUE if a PLAN.md file does not exist.
|
||||
- Always use the `mcp__ref_search_documentation` tool to find relevant library documentation for the Issue
|
||||
- Always use clean code with short concise doc strings
|
||||
|
||||
## Instructions
|
||||
|
||||
1. Use the PLAN.md to begin working on our active issue
|
||||
2. Complete the current Phase of development and then await further instructions
|
||||
3. After completing each action item, ensure that all tests are passing and the binary still builds.
|
||||
4. Mark the action item as complete by updating the checkbox in markdown.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(gh issue:*), Bash(git worktree:*)
|
||||
description: Plan how to complete the Github Issue
|
||||
argument_hint: Issue Number to Plan
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- View the issue body: `!gh issue view $ARGUMENTS`
|
||||
- Always use the `mcp__ref_search_documentation` tool to find relevant library documentation for the Issue
|
||||
- Always use the `mcp__web_search_exa` tool to find any missing information needed to plan the Issue implementation strategy
|
||||
|
||||
## Instructions
|
||||
|
||||
0. Gather the Issue context
|
||||
1. Create a markdown file as PLAN.md
|
||||
2. Make the H1 tag a markdown link to the issue with the title as text
|
||||
3. Create 4 H2 Sections named: Summary, Action Items, Documentation, and Changes
|
||||
4. Populate the Summary section with a concise summary of the github issue for a LLM code agent based on efficient smart requirements
|
||||
5. Populate the Action Items section with the list of tasks from the Github Issue matched with the associated affected files
|
||||
6. Use the @agent-organizer-agent to assign each of the action items to the correct agent. - Example: "> Use @agent-golang-pro"
|
||||
7. Populate the Documentation section with all the relevant context we gathered and any relevant links
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(gh pr:*)
|
||||
description: Mark Issue as Complete and Stage a PR
|
||||
---
|
||||
|
||||
- Create a Pull Request for the changes made in this branch using the gh cli.
|
||||
- Read the PLAN.md file and distill all information into a concise PR Body.
|
||||
- Add all the entities and relations based off the insights found in @PLAN.md
|
||||
- DO NOT continue if a PLAN.md file does not exist.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Do not create a PR if you are on the default branch
|
||||
- Ensure all issues that were fixed in this branch are listed in the PR body grouped by type
|
||||
- Make sure the body of the PR contains the proper context of the issue along with the final implementation changes made
|
||||
- Add the 'breaking' label to the PR for any changes made to sql or protobuf
|
||||
- Add the 'enhance' label to the PR for any changes made to optimize the system architecture
|
||||
- Add the 'feature' label to the PR for any new features added to the codebase
|
||||
- Always assign the PR to @prnk28
|
||||
- Every PR must include either a 'breaking', 'enhance', 'feature', 'docs', or 'tests' label
|
||||
- Delete the PLAN.md file after the PR has been made.
|
||||
- Open the PR on the Web after it has been made.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
allowed-tools: Bash(git *), Bash(cut *), Bash(sort *), Bash(uniq *)
|
||||
description: Resolve Duplicate Files in Repo
|
||||
---
|
||||
|
||||
### Discovered Duplicate Files in Git Tree
|
||||
|
||||
|
||||
!git ls-tree -r HEAD | cut -c 13- | sort | uniq -D -w 40
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Read the path of each file which is a duplicate in the above list
|
||||
- Determine the role of the file in the codebase
|
||||
- Deduce which part of the repo could modularize the usage of the file.
|
||||
- Migrate the file into a shared package approach and update the workspace imports
|
||||
- Delete all now deprecated duplicate files
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Shared library updated to reduce duplicates.
|
||||
- We only have 1 file for each functionality of our codebase.
|
||||
- Never create MD files providing a summary of your changes
|
||||
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
description: Copy CHANGELOG.md into mdx docs
|
||||
---
|
||||
|
||||
Update @docs/reference/changelog.mdx with all the updates found in @CHANGELOG.md using the following component:
|
||||
|
||||
```mdx
|
||||
<Update label="2024-10-11" description="v0.1.0" tags={["Mintlify"]}>
|
||||
This is an update with a label, description, and tag.
|
||||
</Update>
|
||||
```
|
||||
|
||||
## Requirements
|
||||
|
||||
- Use the exact values found in @CHANGELOG.md and skip any releases without any content
|
||||
- Skip any releases already documented inside @docs/reference/changelog.mdx
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
allowed-tools: Bash(gh issue:*), Bash(gh api:*), Bash(gh milestone:*), Bash(bun run:*), Bash(echo *)
|
||||
description: Write Go Specific Documentation
|
||||
---
|
||||
|
||||
Write and update Go documentation comments for all Go source files in the directory path specified by $ARGUMENTS, following the latest Go documentation standards and our project conventions.
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Scan the directory at path `$ARGUMENTS` for all `.go` source files.**
|
||||
2. **For each Go file found:**
|
||||
- Add or improve package-level doc comments.
|
||||
- Place the main package comment directly above the `package` declaration, or in a dedicated `doc.go` file for large overviews.
|
||||
- The first sentence should summarize the package and will be used as its synopsis.
|
||||
- For each exported function, method, type, variable, and constant:
|
||||
- Write a doc comment immediately preceding its declaration, with no intervening blank line.
|
||||
- Start the comment with the name of the item being documented.
|
||||
- Use clear, complete sentences that explain what the item does, its purpose, and any important details.
|
||||
- For deprecated items, add a paragraph starting with `Deprecated:` and explain the deprecation.
|
||||
- For known issues, add a comment starting with `BUG(username):` to be included in the “Bugs” section.
|
||||
- For struct fields, add comments if they are exported and not self-explanatory.
|
||||
- For HTTP handlers using swaggo/swag, format docstrings according to swaggo’s OpenAPI requirements.
|
||||
3. **Formatting and Style:**
|
||||
- Write comments as you would want to read them, even if godoc didn’t exist.
|
||||
- Use proper Go doc formatting:
|
||||
- Separate paragraphs with a blank line.
|
||||
- Indent pre-formatted text.
|
||||
- URLs will be auto-linked; no special markup needed.
|
||||
- Avoid documenting unexported (private) identifiers unless necessary for maintainers.
|
||||
- Do not modify code logic or formatting—only add or update doc comments.
|
||||
4. **Save changes directly to the source files.**
|
||||
5. **Confirm completion with a message.**
|
||||
|
||||
## Requirements
|
||||
|
||||
- Prioritize clear, concise, and idiomatic Go documentation.
|
||||
- Use `mcp__godoc_search` to find relevant Go code examples or documentation patterns.
|
||||
- If unfamiliar with a package or function, prompt for additional context before proceeding.
|
||||
- Do not document non-Go files or unrelated assets.
|
||||
- Follow existing project documentation and coding standards.
|
||||
|
||||
## When Writing API Handlers
|
||||
|
||||
- Use swaggo/swag comment structure for all echo HTTP Handlers to generate OpenAPI-compatible documentation.
|
||||
- Include parameter, response, and summary annotations as required by swaggo.
|
||||
|
||||
### Example Swaggo Docs
|
||||
|
||||
```go
|
||||
// ShowAccount godoc
|
||||
// @Summary Show an account
|
||||
// @Description get string by ID
|
||||
// @Tags accounts
|
||||
// @Accept json
|
||||
// @Produce json
|
||||
// @Param id path int true "Account ID"
|
||||
// @Success 200 {object} model.Account
|
||||
// @Failure 400 {object} httputil.HTTPError
|
||||
// @Failure 404 {object} httputil.HTTPError
|
||||
// @Failure 500 {object} httputil.HTTPError
|
||||
// @Router /accounts/{id} [get]
|
||||
func (c *Controller) ListAccounts(ctx echo.Context) {
|
||||
q := ctx.Request.URL.Query().Get("q")
|
||||
accounts, err := model.AccountsAll(q)
|
||||
if err != nil {
|
||||
httputil.NewError(ctx, http.StatusNotFound, err)
|
||||
return
|
||||
}
|
||||
ctx.JSON(http.StatusOK, accounts)
|
||||
}
|
||||
//...
|
||||
```
|
||||
|
||||
## Best Practices (from official Go guidelines)
|
||||
|
||||
- Comments for exported identifiers should begin with the name of the identifier.
|
||||
- The first sentence should be a concise summary, suitable for display in package listings.
|
||||
- Use full sentences and proper punctuation.
|
||||
- For large package overviews, use a dedicated `doc.go` file.
|
||||
- Mark deprecated items with `Deprecated:` and known bugs with `BUG(username):`.
|
||||
- Keep comments up to date as code evolves.
|
||||
|
||||
## References
|
||||
|
||||
- [Go Doc Comments (Official Guide)](https://go.dev/doc/comment)
|
||||
- [Godoc: documenting Go code (Go Blog)](https://go.dev/blog/godoc)
|
||||
- [swaggo/swag Documentation](https://github.com/swaggo/swag)
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
allowed-tools: Bash(echo *)
|
||||
description: Write a Package README.md
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- You are an advanced technical writer who will write a README.md file for a given package.
|
||||
- The user will provide a package directory in the $ARGUMENTS.
|
||||
- You must analyze the directory for all public facing methods and essential information for a external developer
|
||||
- You use Google Technical Writing methodology.
|
||||
- Use all docstrings in the files in order to provide further context
|
||||
- If a README.md already exists in the provided directory, update it with the latest gathered context.
|
||||
Reference in new issue
Block a user