mirror of
https://github.com/github/awesome-copilot.git
synced 2026-09-07 16:25:47 +00:00
33 lines
2.5 KiB
Markdown
33 lines
2.5 KiB
Markdown
# Anti-Patterns
|
|
|
|
| Avoid | Prefer | Why |
|
|
|---|---|---|
|
|
| One agent owns planning, implementation, testing, and approval | Keep Producer, Dev, and optional QA responsibilities distinct | Independent perspectives reduce blind spots without requiring ceremony for every change. |
|
|
| Hardcoded tool or model allowlists | Inherit the developer's enabled tools and selected model | Extensions and MCP tools remain available without plugin updates. |
|
|
| A mandatory process for every change | Scale planning, review, and QA to risk | Small changes stay fast; high-impact changes receive more scrutiny. |
|
|
| Universal Git command recipes | Follow repository contribution and branch policy | Projects use different remotes, protections, and merge strategies. |
|
|
| Rewriting shared history or discarding unknown work | Preserve work and coordinate destructive actions | Parallel sessions and contributors may depend on existing state. |
|
|
| Large plans that duplicate project documentation | Record only outcomes, constraints, decisions, and next actions | Concise context is easier to maintain and recover. |
|
|
| Bugs and decisions kept only in chat | Use the repository's issue tracker and durable context | Future sessions can discover them. |
|
|
| QA fixes application source | QA reports behavior; Dev implements fixes | Separation preserves independent verification. |
|
|
| Treating every automated suggestion as a requirement | Assess relevance, confidence, scope, and practical risk | Review should improve the product, not expand scope without limit. |
|
|
|
|
## Role responsibilities (Do / Don't)
|
|
|
|
- Producer
|
|
- Do: Clarify outcome, constraints, acceptance criteria, and explicit exclusions; coordinate reviewers and merge policy.
|
|
- Don't: Implement or ship code changes that should be reviewed by Dev.
|
|
|
|
- Dev
|
|
- Do: Implement the smallest complete solution, run listed verification, include tests, and prepare the PR with verification steps.
|
|
- Don't: Merge without required checks, failing tests, or without documenting risks and decisions.
|
|
|
|
- QA (optional)
|
|
- Do: Independently verify behavior, file reproducible issues, and confirm fixes after Dev applies them.
|
|
- Don't: Modify application source as a shortcut for failing verification — report and hand back to Dev.
|
|
|
|
## Decision logging guidance
|
|
|
|
- Record material decisions in a DECISIONS.md or the repository issue tracker with: title, date, owner, decision summary (1 line), rationale, and link to related PR/issue.
|
|
- Keep entries short and searchable; record the next action when a decision defers work.
|