[autoresearch] baseline: system prompt quality tests (5/5 passing)
This commit is contained in:
evandrodevbr committed
1 parent
05cc036f6d
commit
60b0101717
142 files changed
+18589
-9947
No files matched your search
@@ -0,0 +1,140 @@
|
||||
---
|
||||
name: code-review
|
||||
description: Structured code review protocol for inspecting code quality against the full rule set. Use when auditing code written by yourself or another agent, during the /audit workflow, or when the user asks for a code review.
|
||||
---
|
||||
|
||||
# Code Review Skill
|
||||
|
||||
## Purpose
|
||||
Systematically review code against the full antigravity rule set. Catches issues that linters miss: architectural violations, missing observability, business logic errors, pattern inconsistencies.
|
||||
|
||||
## When to Invoke
|
||||
- During the `/audit` workflow (Phase 1: Code Review)
|
||||
- When user asks for a code review outside any workflow
|
||||
- **Best practice:** Invoke in a fresh conversation (not the same one that authored the code) to avoid confirmation bias
|
||||
|
||||
## Review Process
|
||||
|
||||
### 1. Scope the Review
|
||||
Identify the files/features to review. Determine the review scope:
|
||||
- **Feature review** — all files in a feature directory
|
||||
- **PR review** — only changed files
|
||||
- **Full codebase audit** — all features
|
||||
|
||||
### 2. Load the Rule Set
|
||||
Read all applicable rules from `.agents/rules/`. Use `rule-priority.md` for severity classification.
|
||||
|
||||
### 3. Review Categories (Priority Order)
|
||||
|
||||
Review each file/feature against these categories, in order from `rule-priority.md`:
|
||||
|
||||
#### Critical (Must Fix)
|
||||
- **Security** — injection, hardcoded secrets, broken auth
|
||||
- **Data loss** — missing error handling on writes, no transaction boundaries
|
||||
- **Resource leaks** — unclosed connections, missing cleanup
|
||||
|
||||
#### Major (Should Fix)
|
||||
- **Testability** — I/O not behind interfaces, untested error paths
|
||||
- **Observability** — missing logging on operations, no correlation IDs
|
||||
- **Error handling** — empty catch blocks, swallowed errors
|
||||
- **Architecture** — circular dependencies, wrong layer access
|
||||
|
||||
#### Minor (Nice to Fix)
|
||||
- **Pattern consistency** — deviation from established codebase patterns
|
||||
- **Naming** — unclear variable/function names
|
||||
- **Code organization** — functions too long, mixed responsibilities
|
||||
|
||||
#### Nit (Optional)
|
||||
- **Style** — formatting issues the linter would catch
|
||||
- **Documentation** — missing comments on complex logic
|
||||
|
||||
### 4. Produce Findings
|
||||
|
||||
Output a structured findings document:
|
||||
|
||||
```markdown
|
||||
# Code Review: {Feature/Module Name}
|
||||
Date: {date}
|
||||
Reviewer: AI Agent (fresh context)
|
||||
|
||||
## Summary
|
||||
- **Files reviewed:** N
|
||||
- **Issues found:** N (X critical, Y major, Z minor, W nit)
|
||||
|
||||
## Critical Issues
|
||||
- [ ] **[SEC]** {description} — [{file}:{line}](file:///path)
|
||||
- [ ] **[DATA]** {description} — [{file}:{line}](file:///path)
|
||||
|
||||
## Major Issues
|
||||
- [ ] **[TEST]** {description} — [{file}:{line}](file:///path)
|
||||
- [ ] **[OBS]** {description} — [{file}:{line}](file:///path)
|
||||
|
||||
## Minor Issues
|
||||
- [ ] **[PAT]** {description} — [{file}:{line}](file:///path)
|
||||
|
||||
## Nit
|
||||
- [ ] {description} — [{file}:{line}](file:///path)
|
||||
|
||||
## Rules Applied
|
||||
List of rules referenced during this review.
|
||||
```
|
||||
|
||||
### 5. Save the Report
|
||||
|
||||
When invoked via the `/audit` workflow, you **MUST** persist the findings to the repo:
|
||||
|
||||
**Path:** `docs/audits/review-findings-{feature}-{YYYY-MM-DD}-{HHmm}.md`
|
||||
|
||||
1. Create `docs/audits/` if it doesn't exist
|
||||
2. Write the findings document to that path
|
||||
3. This makes the report accessible from other conversations and agents
|
||||
|
||||
When invoked as a standalone review (not via `/audit`), saving to `docs/audits/` is recommended but optional.
|
||||
|
||||
### 6. Severity Tags
|
||||
|
||||
| Tag | Category | Rule Source |
|
||||
| -------- | -------------------- | -------------------------------------------------- |
|
||||
| `[SEC]` | Security | `security-principles.md` |
|
||||
| `[DATA]` | Data integrity | `error-handling-principles.md` |
|
||||
| `[RES]` | Resource leak | `resources-and-memory-management-principles.md` |
|
||||
| `[TEST]` | Testability | `architectural-pattern.md`, `testing-strategy.md` |
|
||||
| `[OBS]` | Observability | `logging-and-observability-mandate.md` |
|
||||
| `[ERR]` | Error handling | `error-handling-principles.md` |
|
||||
| `[ARCH]` | Architecture | `architectural-pattern.md`, `project-structure.md` |
|
||||
| `[PAT]` | Pattern consistency | `code-organization-principles.md` |
|
||||
| `[INT]` | Integration contract | `api-design-principles.md` |
|
||||
| `[DB]` | Database design | `database-design-principles.md` |
|
||||
| `[CFG]` | Configuration | `configuration-management-principles.md` |
|
||||
|
||||
### 7. Language-Specific Anti-Patterns
|
||||
|
||||
Load the anti-pattern checklist for the language(s) under review:
|
||||
|
||||
| Language | Anti-Patterns |
|
||||
|---|---|
|
||||
| **Go** | `languages/go.md` |
|
||||
| **TypeScript** | `languages/typescript.md` *(placeholder — create when needed)* |
|
||||
| **Flutter/Dart** | `languages/flutter.md` *(placeholder — create when needed)* |
|
||||
| **Rust** | `languages/rust.md` *(placeholder — create when needed)* |
|
||||
|
||||
> Anti-patterns listed in language files are **auto-fail** — they require no judgment call. If the pattern exists in the code, it is a finding.
|
||||
|
||||
### 8. Cross-Boundary Checks
|
||||
|
||||
For full audits, cross-boundary concerns (integration contracts, database schema, configuration hygiene, dependency health, test coverage gaps) are checked via the dedicated dimension checklist in the `/audit` workflow — **Phase 1.5: Cross-Boundary Review**.
|
||||
|
||||
When invoking this skill standalone (outside `/audit`), apply the applicable dimensions from that checklist manually and tag findings with `[INT]`, `[DB]`, or `[CFG]` as appropriate.
|
||||
|
||||
**Zero-Findings Guard:** If this review produces fewer than 3 findings, you MUST produce a "Dimensions Covered" attestation section in the findings document, listing each cross-boundary dimension and the specific files or queries you examined. Only then may you declare a clean result.
|
||||
|
||||
---
|
||||
|
||||
## Rule Compliance
|
||||
This skill enforces all rules in `.agents/rules/`. Key references:
|
||||
- Rule Priority @rule-priority.md (severity classification)
|
||||
- Security Principles @security-principles.md
|
||||
- Architectural Patterns @architectural-pattern.md
|
||||
- Testing Strategy @testing-strategy.md
|
||||
- Logging and Observability Mandate @logging-and-observability-mandate.md
|
||||
- Error Handling Principles @error-handling-principles.md
|
||||
@@ -0,0 +1,89 @@
|
||||
# Go Anti-Patterns (Auto-Fail)
|
||||
|
||||
> **Load this file** during code reviews of Go code. Patterns listed here are **immediate findings** — no judgment needed. If the pattern exists, it is a finding.
|
||||
|
||||
---
|
||||
|
||||
## Auto-Fail Table
|
||||
|
||||
| Pattern | Severity | Tag | Correct Fix |
|
||||
|---|---|---|---|
|
||||
| `defer X.Close()` (bare) | Critical | `[RES]` | Error-checked closure with `slog.Warn` |
|
||||
| `//nolint:errcheck` | Critical | `[ERR]` | Handle the error — use error-checked closure |
|
||||
| `defer tx.Rollback()` (bare) | Critical | `[RES]` | Error-checked closure with `sql.ErrTxDone` guard |
|
||||
| `fmt.Printf` / `fmt.Println` | Major | `[OBS]` | Replace with `slog` structured logging |
|
||||
| `log.Printf` / `log.Println` | Major | `[OBS]` | Replace with `slog` structured logging |
|
||||
| `resp.Body.Close()` without drain | Major | `[RES]` | `io.Copy(io.Discard, resp.Body)` then close |
|
||||
| Empty `if err != nil {}` block | Critical | `[ERR]` | Handle, return, or log the error |
|
||||
| `_ = someFunc()` (discarded error) | Major | `[ERR]` | Handle the error explicitly |
|
||||
|
||||
---
|
||||
|
||||
## Detection Commands
|
||||
|
||||
Use these grep patterns to scan for anti-patterns before manual review:
|
||||
|
||||
```bash
|
||||
# Bare defer Close/Rollback (no error check)
|
||||
grep -rn 'defer.*\.Close()' --include='*.go'
|
||||
grep -rn 'defer.*\.Rollback()' --include='*.go'
|
||||
|
||||
# nolint:errcheck suppression
|
||||
grep -rn 'nolint:errcheck' --include='*.go'
|
||||
|
||||
# Unstructured logging in production code
|
||||
grep -rn 'fmt\.Printf\|fmt\.Println\|log\.Printf\|log\.Println' --include='*.go' | grep -v '_test.go'
|
||||
|
||||
# Discarded errors
|
||||
grep -rn '_ = ' --include='*.go' | grep -v '_test.go'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Correct Patterns (Reference)
|
||||
|
||||
### Resource Cleanup
|
||||
|
||||
```go
|
||||
// ✅ Rows / Statements / Connections
|
||||
defer func() {
|
||||
if err := rows.Close(); err != nil {
|
||||
slog.Warn("failed to close rows", "error", err, "operation", "<operation>")
|
||||
}
|
||||
}()
|
||||
|
||||
// ✅ Transaction Rollback
|
||||
defer func() {
|
||||
if err := tx.Rollback(); err != nil && !errors.Is(err, sql.ErrTxDone) {
|
||||
slog.Error("failed to rollback transaction", "error", err, "operation", "<operation>")
|
||||
}
|
||||
}()
|
||||
|
||||
// ✅ HTTP Response Body
|
||||
defer func() {
|
||||
if _, err := io.Copy(io.Discard, resp.Body); err != nil {
|
||||
slog.Warn("failed to drain response body", "error", err)
|
||||
}
|
||||
if err := resp.Body.Close(); err != nil {
|
||||
slog.Warn("failed to close response body", "error", err)
|
||||
}
|
||||
}()
|
||||
```
|
||||
|
||||
### Structured Logging
|
||||
|
||||
```go
|
||||
// ❌ fmt.Printf("User %s logged in from %s\n", userID, ip)
|
||||
// ❌ log.Printf("User %s logged in from %s", userID, ip)
|
||||
|
||||
// ✅
|
||||
slog.Info("user login", "userId", userID, "ip", ip)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
- Go Idioms and Patterns @go-idioms-and-patterns.md
|
||||
- Logging and Observability Principles @logging-and-observability-principles.md
|
||||
- Error Handling Principles @error-handling-principles.md
|
||||
- Resources and Memory Management Principles @resources-and-memory-management-principles.md
|
||||
Reference in new issue
Block a user