Awesome/awesome-copilot
1
0
Fork 0
mirror of https://github.com/github/awesome-copilot.git synced 2026-04-11 02:35:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Correct phrasing in SDK documentation (#1254)

Browse Source 
* Correct phrasing in SDK documentation

* Fix typos in Go instructions

Fix typos in Go instructions
This commit is contained in:
jjpinto
2026-04-01 19:02:19 -04:00
committed by GitHub
parent ca87cfcc9e
commit eb5cff89fa
2 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
instructions/copilot-sdk-go.instructions.md
View File

@@ -123,7 +123,7 @@ session, err := client.ResumeSessionWithOptions("session-id", &copilot.ResumeSes
### Event Subscription Pattern ### Event Subscription Pattern
ALWAYS use channels or done signals for waiting on session events: ALWAYS use channels or done signals to wait for session events:
```go ```go
done := make(chan struct{}) done := make(chan struct{})
@@ -381,7 +381,7 @@ session2.Send(copilot.MessageOptions{Prompt: "Hello from session 2"})
## Bring Your Own Key (BYOK) ## Bring Your Own Key (BYOK)
Use custom API providers via `ProviderConfig`: Use custom API providers by configuring `ProviderConfig`:
```go ```go
session, err := client.CreateSession(&copilot.SessionConfig{ session, err := client.CreateSession(&copilot.SessionConfig{
@@ -437,7 +437,7 @@ session.On(func(evt copilot.SessionEvent) {
## Connectivity Testing ## Connectivity Testing
Use Ping to verify server connectivity: Use `Ping` to verify server connectivity:
```go ```go
resp, err := client.Ping("test message") resp, err := client.Ping("test message")

6
instructions/go.instructions.md
View File

@@ -91,7 +91,7 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Use line comments (`//`) for most comments - Use line comments (`//`) for most comments
- Use block comments (`/* */`) sparingly, mainly for package documentation - Use block comments (`/* */`) sparingly, mainly for package documentation
- Document why, not what, unless the what is complex - Document why, not what, unless the what is complex
- Avoid emoji in comments and code - Avoid using emoji in comments and code
### Error Handling ### Error Handling
@@ -224,7 +224,7 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
### HTTP Clients ### HTTP Clients
- Keep the client struct focused on configuration and dependencies only (e.g., base URL, `*http.Client`, auth, default headers). It must not store per-request state - Keep the client struct focused on configuration and dependencies only (e.g., base URL, `*http.Client`, auth, default headers). It must not store any per-request state
- Do not store or cache `*http.Request` inside the client struct, and do not persist request-specific state across calls; instead, construct a fresh request per method invocation - Do not store or cache `*http.Request` inside the client struct, and do not persist request-specific state across calls; instead, construct a fresh request per method invocation
- Methods should accept `context.Context` and input parameters, assemble the `*http.Request` locally (or via a short-lived builder/helper created per call), then call `c.httpClient.Do(req)` - Methods should accept `context.Context` and input parameters, assemble the `*http.Request` locally (or via a short-lived builder/helper created per call), then call `c.httpClient.Do(req)`
- If request-building logic is reused, factor it into unexported helper functions or a per-call builder type; never keep `http.Request` (URL params, body, headers) as fields on the long-lived client - If request-building logic is reused, factor it into unexported helper functions or a per-call builder type; never keep `http.Request` (URL params, body, headers) as fields on the long-lived client
@@ -368,6 +368,6 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Not understanding nil interfaces vs nil pointers - Not understanding nil interfaces vs nil pointers
- Forgetting to close resources (files, connections) - Forgetting to close resources (files, connections)
- Using global variables unnecessarily - Using global variables unnecessarily
- Over-using unconstrained types (e.g., `any`); prefer specific types or generic type parameters with constraints. If an unconstrained type is required, use `any` rather than `interface{}` - Overusing unconstrained types (e.g., `any`); prefer specific types or generic type parameters with constraints. If an unconstrained type is required, use `any` rather than `interface{}`
- Not considering the zero value of types - Not considering the zero value of types
- **Creating duplicate `package` declarations** - this is a compile error; always check existing files before adding package declarations - **Creating duplicate `package` declarations** - this is a compile error; always check existing files before adding package declarations