agentleFS
roronoazoroshao369roronoazoroshao369/vibe-coding-os/skills/agents/writer-critic-pair/SKILL.md

writer-critic-pair

Skill1 starsChanged 5 months agoMITView on GitHub

Use a two-role agent pattern where a writer or implementer creates the artifact and a critic or reviewer independently challenges it before final delivery. Use for complex implementations, risky changes, architecture decisions, high-stakes user communication, ambiguous requirements, security-sensitive work, or any task where same-context self-approval would be too weak. Original task, acceptance criteria, scope boundaries, writer output or diff, validation results, repository conventions, known risks, and time or tool constraints. A handoff with:

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use a two-role agent pattern where a writer or implementer creates the artifact and a critic or reviewer independently challenges it before …

    line 16
  2. Distinctive:

    Use for complex implementations, risky changes, architecture decisions, high-stakes user communication, ambiguous requirements, …

    line 20

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Writer-Critic Pair

Purpose

Use a two-role agent pattern where a writer or implementer creates the artifact and a critic or reviewer independently challenges it before final delivery.

When to use

Use for complex implementations, risky changes, architecture decisions, high-stakes user communication, ambiguous requirements, security-sensitive work, or any task where same-context self-approval would be too weak.

Inputs

Original task, acceptance criteria, scope boundaries, writer output or diff, validation results, repository conventions, known risks, and time or tool constraints.

Workflow

  1. Assign the writer to understand the task, inspect context, propose or implement the smallest correct solution, and report verification honestly.
  2. Assign the critic to read the original task and evidence independently before reading the writer's summary.
  3. The critic challenges correctness, assumptions, scope, tests, compatibility, safety, and maintainability.
  4. The writer responds with a fix plan, applies necessary changes, and records any deferred risks.
  5. The critic re-reviews the revised artifact or explicitly states why re-review was not possible.
  6. The final owner synthesizes the result and decides whether to ship, revise, or ask for clarification.

Outputs

A handoff with:

  • Task: original goal and constraints.
  • Writer output: summary, changed files or artifact, and verification run.
  • Critic findings: critical, important, and minor findings with evidence.
  • Writer response: fixes applied, deferred items, and rationale.
  • Re-review: critic result after fixes.
  • Final decision: ship, revise, or ask.

Failure modes

  • Writer and critic share the same assumptions and miss the same bug.
  • Critic rubber-stamps instead of adversarially checking evidence.
  • Roles edit the same files concurrently and create conflicting changes.
  • Handoff omits validation results or known limitations.
  • Critic blocks on taste rather than task risk.
  • Final owner ignores unresolved critical findings.

Verification checklist

  • Writer and critic responsibilities are distinct.
  • Critic reviewed against the original task, not only the writer summary.
  • Findings are severity-ranked and evidence-based.
  • Writer response addresses or explicitly defers each critical and important finding.
  • Final decision reflects re-review status and residual risk.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.