Hey everyone! I've been lurking here for a few months while my team was trying to figure out how to actually use our coding assistant effectively. We kept running into the same issues—getting inconsistent results, forgetting to provide the right context, or just not knowing how to structure our asks.
So, we started documenting what actually worked. It started as a messy internal wiki, but my manager suggested we clean it up and share it. I'm honestly a bit nervous posting this, but I'm hoping it can help other teams who are just starting out like we were.
It's a public GitHub repo called "Team Workflow Recipes." It's basically a collection of markdown files with our real setups. For example, we have a "Code Review Checklist" we paste into the assistant before sending any PR code, and a set of custom instructions for our specific SaaS app's stack (React, Node, AWS). There are also notes on how we rolled it out to the whole dev team without causing chaos.
I'd be so grateful if you could check it out and tell me what you think. Are we missing something obvious? Are there better ways to structure any of these? This whole B2B software optimization thing is new to me, and I'm really just learning from all of you. The link is in my profile. Thanks for any feedback!
Love this. Taking internal best practices and making them public is a huge win for the community.
The "rollout without causing chaos" notes are probably the most valuable part for others. Could you add a bit on how you measured adoption? We tracked assistant usage as an event and built a simple dashboard to see which recipes got copied the most. It helped us double down on what actually worked.
Great idea. Excited to check out the repo.
data over opinions
This is a fantastic idea, especially the part about structuring your asks. In my world (SRE/on-call), we see the exact same problem when engineers try to write alerting queries. They get poor results because they don't frame the question right.
I'd suggest adding a recipe specifically for "Writing Alert Conditions." For example, a simple template like:
```
Goal: Detect when service latency degrades for users.
Context: Application is `frontend-api`, primary metric is `http_request_duration_seconds`.
Ask: Create a PromQL query that alerts if the 99th percentile latency for the `prod` job is above 0.5s for 5 out of the last 10 minutes.
```
Having that structure saves so much back-and-forth. Maybe you could add a section for ops/infra teams?
Sleep is for the weak
You're spot on about the structured template for alert conditions. That framework aligns perfectly with how we train new SREs to think about observability. The three-part breakdown forces clarity on intent, system boundaries, and concrete requirements.
I'd expand your example template to include a fourth component: "Validation." After receiving the generated query, you need a checklist to verify it. For instance:
* Does it filter for the correct `job` and `environment` labels?
* Are the aggregation windows (e.g., `rate()`) appropriate for the metric type?
* Is the threshold logically compared (e.g., `>` vs `<`)?
Without this step, you can easily deploy an alert that fires incorrectly or, worse, misses real incidents.
The ops/infra section is a natural fit. I've seen similar patterns work for cost anomaly detection queries in cloud monitoring tools, where the "Ask" must specify granularity, grouping dimensions, and baseline comparison periods.