# Generator Reviewer Loop

> Two-pass code delivery discipline. Use for EVERY code task — writing, reviewing, debugging, refactoring, implementing features, fixing bugs, producing snippets, creating components, patching, or any code artifact, including prototypes, demos, and quick fixes. Enforces a Generator (Staff Engineer) pass that writes code correctly the first time against the full standards bar, followed by a Reviewer…

- **Type:** Skill
- **Install:** `agentstack add skill-vmvenkatesh78-engineering-skills-generator-reviewer-loop`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [vmvenkatesh78](https://agentstack.voostack.com/s/vmvenkatesh78)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [vmvenkatesh78](https://github.com/vmvenkatesh78)
- **Source:** https://github.com/vmvenkatesh78/engineering-skills/tree/main/skills/generator-reviewer-loop

## Install

```sh
agentstack add skill-vmvenkatesh78-engineering-skills-generator-reviewer-loop
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Generator–Reviewer Loop

The operating contract for every code task. One model, two disciplined stances — not theatre, not "pretending to be two agents." What changes between passes is the cognitive mode and the artifacts that leave each stage. **Nothing crosses from generate → deliver without the review pass producing findings (or an explicit, justified "no findings" statement) and a final confidence rating.**

This skill composes with `engineering-standards` and `production-ui-standard`. The Reviewer enforces every rule in those skills — this skill defines *how* that enforcement is structured, gated, and surfaced to the user.

---

## Pass 1 — Generator (Staff Engineer)

**Mandate:** produce code against the full standards bar on the first attempt. Not "draft and iterate." Write it correctly the first time, because the Reviewer is going to tear it apart regardless, and laziness here just wastes the review pass on trivialities.

Before emitting a single line of code, complete these steps explicitly:

- Trace the request against `engineering-standards` and `production-ui-standard` and note which rules apply to this specific task.
- Identify every async boundary, every user input, every rendering context, every failure mode.
- Decide naming, file structure, and type shapes before writing bodies.
- Plan the test surface: what behavior is covered, what edge cases, what queries.
- Flag any deferred decisions with `TODO(TICKET): rationale + v2 approach` — never a bare `// TODO`.

Generator output always includes:

1. **The code** — every file, every line, every test.
2. **Design rationale** — one paragraph: what was chosen, what was rejected, why.
3. **Dependencies touched** — files, packages, contracts, call sites.
4. **Risk surface** — what could fail and what the code does about it.

---

## Pass 2 — Reviewer (Principal Engineer / Architect)

**Mandate:** adversarial. Not a rubber stamp. Not "LGTM with nits." Assume the code is wrong until each piece earns its place. The Reviewer has authority to block on anything — naming, a single `??` vs `||`, an unnecessary `useMemo`, a test that asserts implementation instead of behavior, a `:focus` instead of `:focus-visible`, a magic number, a cognitive-complexity violation SonarQube would catch.

### Five granularities

Tear the code apart at each level, explicitly and in order:

**1. File level**
- Does this file need to exist?
- Is it named correctly? Does the filename match the default export?
- Is it in the right location?
- Does it do one thing?
- Is it under the size limit? Components ` on non-mutating params. `export type {}` for type-only re-exports.

### React
One component per file, name matches filename. Compound components over prop-heavy APIs — more than 8 props means split. `forwardRef` requires `displayName`. Every async `useEffect` uses `AbortController` + cleanup. Exhaustive dep arrays, or line-level disable with rationale. Four-state rule — loading / error / empty / success — on every async operation. Boolean props prefixed `is` / `has` / `allow` / `enable`. `handle` prefix for internal handlers, `on` prefix for props. Options objects over boolean parameters.

### CSS
Tokens only — zero hardcoded hex / px / rem / font. Data-attribute variants, not class-based. No `!important` without a comment justifying it. `:focus-visible` never `:focus`. Transitions only on `color` / `background-color` / `border-color` / `opacity` / `transform` / `box-shadow` — **never** on `padding` / `margin` / `width` / `height` / `border-radius`.

### Production UI
Blue `#2563EB` (light) / `#3B82F6` (dark) — not indigo, not purple. Slate grays, not neutral. No gradients on buttons. No shadows on cards when the page background is white — use a border. Max `border-radius` `12px` on rectangles. `font-weight: 700` only on page-level titles. Every interactive element has visible `:focus-visible` — 2px solid, 2px offset. WCAG AA contrast minimum, target AAA where possible.

### Accessibility
Native HTML before ARIA. `` before ``. Icon-only buttons have `aria-label`. `tabIndex > 0` never. Color-only state indication never. Touch targets 44 × 44 on mobile. Reduced motion respected. Landmarks on all regions. Labels on all inputs.

### Error handling
No empty `catch` blocks. 4xx vs 5xx distinguished in UI. Inline form errors, not toasts. Retry on network errors. `Promise.allSettled` where partial success is acceptable. Every `switch` has `default`. Never assume an API response matches the TypeScript interface at runtime — validate at the boundary.

### Performance
No O(n²) on arrays that can exceed 100 items. No `new RegExp()` in render. Stable keys — never indices for reorderable lists. Route-level code splitting minimum. Lazy-load below the fold. `useMemo` / `useCallback` only when profiling justifies it.

### Security
No secrets, tokens, or PII in source or logs. Input sanitized at the boundary. `dangerouslySetInnerHTML` only with DOMPurify — prefer avoiding entirely. `eval` / `new Function` / `innerHTML` with user content forbidden. File uploads use an allowlist, not a blocklist, and validate size. CORS never `*` in production. CSS custom properties from user input: block `url()`, `@import`, `expression()`.

### Testing
Behavior, not implementation. `getByRole` / `getByLabelText` / `getByText` primary — never `data-testid`-first. Four-state tests on every component. Hook contract tests. Mock at boundaries, not internals. `jest-axe` / `vitest-axe` on all rendered components. Test names describe what the user sees.

### SonarLint / SonarQube — the extended bar
Cognitive complexity within thresholds. No duplicated code blocks. No deeply nested conditions. No useless assignments. No variable shadowing. No magic numbers. No over-long parameter lists. No empty collections where they shouldn't be. No nullable / non-nullable type mismatches. No functions exceeding the complexity budget. The Reviewer runs the Sonar checklist mentally against every submission.

### File sizes
Components < 300 lines. Functions < 40 lines. Nesting depth < 3. Util files < 500 lines.

### Git
Conventional commits. One concern per PR. No `console.log` in commits. No commented-out code. No `// TODO` without a ticket reference.

---

## Non-negotiables

- **Never ship code before the review pass completes and confidence hits 10/10.**
- **Never inflate a rating to close a loop.** If a Medium finding cannot be justified away, confidence stays at 9/10 and iteration continues.
- **Never skip standards because "the task is small."** Prototypes, demos, and quick fixes hit the same bar as production code.
- **Never hide findings.** Every issue the Reviewer catches is surfaced to the user, not silently patched.
- **Never treat the Reviewer pass as a formality.** If generation is clean on pass one, the Reviewer says so explicitly with the checklist showing each rule verified.

---

## When this skill does NOT apply

Only these cases:

- Pure explanation or teaching — no code is being produced.
- Reading and analyzing existing code someone else wrote — no new code produced, no modification made.
- Pseudocode or napkin-sketch walkthroughs explicitly framed as conceptual, with the framing stated in the reply.

Everything else — every function, every component, every test, every config edit, every bugfix, every script, every one-file demo — runs the full loop.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [vmvenkatesh78](https://github.com/vmvenkatesh78)
- **Source:** [vmvenkatesh78/engineering-skills](https://github.com/vmvenkatesh78/engineering-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-vmvenkatesh78-engineering-skills-generator-reviewer-loop
- Seller: https://agentstack.voostack.com/s/vmvenkatesh78
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.