agentleFS
Sign inStart free
coreline-aicoreline-ai/codex-devflow-plugin/skills/plan-eng-review/SKILL.md

plan-eng-review

Skill1 starsChanged 7 months agoMITView on GitHub

Engineering-manager style implementation plan review. Use when asked to review architecture, lock in an execution plan, assess data flow, edge cases, test coverage, performance, rollout risk, or perform an engineering review before coding.

51 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use qa-only, document-release and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ramybarsoumSkill

    qa-only

    Report-only QA testing. Systematically tests a web application and produces a structured report with health score, screenshots, and repro steps, but never fixes anything. Use when asked to "just report bugs", "qa report only", or "test but don't fix". For the full test-fix-verify loop, use /qa instead. Proactively suggest when the user wants a bug report without any code changes.

    Also in 17 projects that use this

  • ramybarsoumSkill

    document-release

    Post-ship documentation update. Reads all project docs, cross-references the diff, updates README/ARCHITECTURE/CONTRIBUTING/CLAUDE.md to match what shipped, polishes CHANGELOG voice, cleans up TODOS, and optionally bumps VERSION. Use when asked to "update the docs", "sync documentation", or "post-ship docs". Proactively suggest after a PR is merged or code is shipped.

    Also in 17 projects that use this

  • ayudaySkill

    land-and-deploy

    Land and deploy workflow. Merges the PR, waits for CI and deploy, verifies production health via canary checks. Takes over after /ship creates the PR. Use when: "merge", "land", "deploy", "merge and verify", "land it", "ship it to production".

    Also in 14 projects that use this

  • seek888Skill

    plan-devex-review

    Interactive developer experience plan review. Explores developer personas, benchmarks against competitors, designs magical moments, and traces friction points before scoring. Three modes: DX EXPANSION (competitive advantage), DX POLISH (bulletproof every touchpoint), DX TRIAGE (critical gaps only). Use when asked to "DX review", "developer experience audit", "devex review", or "API design review". Proactively suggest when the user has a plan for developer-facing products (APIs, CLIs, SDKs, libraries, platforms, docs). (gstack) Voice triggers (speech-to-text aliases): "dx review", "developer experience review", "devex review", "devex audit", "API design review", "onboarding review".

    Also in 11 projects that use this

  • ayudaySkill

    unfreeze

    Clear the freeze boundary set by /freeze, allowing edits to all directories again. Use when you want to widen edit scope without ending the session. Use when asked to "unfreeze", "unlock edits", "remove freeze", or "allow all edits".

    Also in 14 projects that use this

  • ShreyRaviSkill

    plan-tune

    Self-tuning question sensitivity + developer psychographic for gstack (v1: observational). Review which AskUserQuestion prompts fire across gstack skills, set per-question preferences (never-ask / always-ask / ask-only-for-one-way), inspect the dual-track profile (what you declared vs what your behavior suggests), and enable/disable question tuning. Conversational interface — no CLI syntax required.

    Also in 6 projects that use this

  • +2 more from ramybarsoum
  • +3 more from ayuday

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 42 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the target plan and relevant project docs.

    line 14
  2. Distinctive:

    Check architecture and data flow.

    line 16
  3. Distinctive:

    Check ownership boundaries, contracts, and dependencies.

    line 17
  4. Distinctive:

    Check edge cases, failure modes, security, performance, and rollback.

    line 18
  5. Distinctive:

    Check test strategy and smoke coverage.

    line 19
  6. Distinctive:

    If requested, update the plan with accepted recommendations.

    line 21
  7. Distinctive:

    Use this compact structure:

    line 44
  8. Very specific:

    Read references/eng-review-checklist.md for a full checklist when needed.

    line 53

“Common” is measured: kept by at least 6 in 10 of the 42 edited versions of this file we could read. “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

Plan Eng Review

Overview

Review an implementation plan before coding. The goal is to catch architecture risks, missing contracts, test gaps, and over/under-engineering while the plan is still cheap to change.

Review Workflow

  1. Read the target plan and relevant project docs.
  2. Restate the goal and scope in plain language.
  3. Check architecture and data flow.
  4. Check ownership boundaries, contracts, and dependencies.
  5. Check edge cases, failure modes, security, performance, and rollback.
  6. Check test strategy and smoke coverage.
  7. Produce opinionated recommendations with priority.
  8. If requested, update the plan with accepted recommendations.

Review Standards

Prefer:

  • explicit contracts over implicit coupling
  • boring technology over clever abstractions
  • incremental changes over big-bang rewrites
  • deterministic tests over manual-only confidence
  • minimal diff with enough edge-case coverage

Flag:

  • shared files with unclear owners
  • stubs without follow-up path
  • tests that only cover happy paths
  • hidden migration or rollout risks
  • plans that mix unrelated features
  • scope creep disguised as cleanup

Output Shape

Use this compact structure:

  1. Verdict: ready / needs revision / blocked
  2. Top risks
  3. Architecture and contract notes
  4. Test coverage notes
  5. Required plan edits
  6. Recommended next action

Read references/eng-review-checklist.md for a full checklist when needed.

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.

Check your setup, free