Agent skill · Audited from source
ce-doc-review
skill · everyinc/compound-engineering-pluginMIT licenceAudited 31 Oct 2026 · source 3cd83b124cb4
Is it safe? With care — CAUTION, grade B (89/100). We read this skill's source at commit 3cd83b124cb4 and observed filesystem access and no hard-coded secrets. The audit raised 8 findings, 0 critical or high. What it does: Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document.
Cite
Cite this page
ModelsAtlas. “ce-doc-review (everyinc/compound-engineering-plugin)”. Retrieved 31 Oct 2026. https://modelsatlas.com/skills/everyinc/ce-doc-review
Trust audit
Audit 0.4.1 · source read 31 Oct 2026
CAUTION means the audit found things worth knowing before you trust this skill. Grade B is shared by 16,667 of 17,602 audited skills.
What the source does
- FilesystemDeclared3 observations
- NetworkNone observedNo outbound calls in the source
- ShellNone observedNo commands run in the source
- DependenciesPinnedNothing floats
- SecretsNone foundNo keys in source
Five audit layers
| Layer | What we check | Result | Findings |
|---|---|---|---|
L0 Provenance | Repo owner, licence, archive status, activity | WARN | 5 |
L1 Static source | Secrets, path traversal, supply chain, hidden code | PASS | 0 |
L2 Instructions | Prompt injection, authority framing, hidden directives | PASS | 3 |
L3 Inventory | The files and declarations match the source | PASS | 0 |
L4 Sandbox | Run in isolation and watch behaviour | SKIPPED why | 0 |
Gates applied: no behavioural pass.
Findings (8)
MEDIUMInventory / provenanceinv.symlink · .agy/plugin.json
.agy/plugin.json
- Why
- link not followed
- Fix
- —
MEDIUMInventory / provenanceinv.symlink · .agy/skills
.agy/skills
- Why
- link not followed
- Fix
- —
MEDIUMInventory / provenanceinv.symlink · .claude/skills
.claude/skills
- Why
- link not followed
- Fix
- —
LOWInventory / provenanceinv.symlink · CLAUDE.md
CLAUDE.md
- Why
- link not followed
- Fix
- —
LOWInventory / provenanceinv.symlink · site/_guides
site/_guides
- Why
- link not followed
- Fix
- —
LOWPrompt injectionreview.data_transfer · references/cross-model-review.md
The host resolves and approves one concrete route before any document content leaves the machine
- Why
- The package explicitly directs sending user document content to an external model host.
- Fix
- rewrite it so the instruction says plainly what it does, and asks the user before it acts
INFOPrompt injectionprompt.authority_framing · references/personas/design-lens-reviewer.md:1
You are a senior product designer reviewing plans for missing design decisions. Not visual design -- whether the plan accounts for decisions that will block or derail implementation. When plans skip t
- Why
- No further detail recorded for this rule.
- Fix
- —
INFOPrompt injectionprompt.authority_framing · references/personas/product-lens-reviewer.md:1
You are a senior product leader. The most common failure mode is building the wrong thing well. Challenge the premise before evaluating the execution.
- Why
- No further detail recorded for this rule.
- Fix
- —
Audit 0.4.1 · source sha 3cd83b124cb4 · 31 Oct 2026Report an issue or request a re-scan
Provenance
Who published it, and what the verdict is pinned to
- Publishereveryinc GitHub organizationOwner of the repository this skill is read from
- Source foldereveryinc/compound-engineering-plugin/skills/ce-doc-reviewThe exact folder we audited
- LicenceMITAs the repository states it
- Commit pinned for this verdict3cd83b124cb4A new audit runs when the source changes
- Repository statusNot archivedPushed today
- Sandboxed runNot runSkills are read, not executed; layer L4 is skipped
What it tells the agent
Full source on GitHub ↗Its description: Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document.
---
name: ce-doc-review
description: Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document.
argument-hint: "[mode:non-interactive] [path/to/document.{md,html}]"
---
# Document Review
Help the author finish a sound document they can use to carry out the agreed work. Find problems that would change that work's outcome or materially hinder execution, and resolve them within the authority already given. Judge the document by whether it guides correct work, not by how much detail it contains. Serious consequences warrant attention even when the defect is small. An adequate document needs no changes.
Reviewer personas supply evidence; the judgment is yours. Check their claims against the whole document, project facts, and settled decisions. Correct proven errors that prevent an existing decision from being carried out, within the edit authority and reviewer requirements the synthesis reference states. Return only worthwhile improvements still needing permission, consequential choices or essential information only the user can supply, and useful observations.
**Done when:** every selected reviewer has returned or is named as failed in Coverage, retained findings have a verified consequence for the agreed work, and every authorized correction assigned to Apply has been made and checked. Report that final state through the interactive approval or decision process, or return it as structured text in non-interactive mode.
## Interactive mode rules
**Read `references/modes.md` before anything else.** It defines how the mode is detected, the non-interactive argument contract, and the question-tool rules: match the host's blocking question tool already in the current tool list (never call a user-facing question tool to discover it), pre-load it at the top of the interactive flow if it is listed but unloaded, and fall back to a numbered list only when the harness genuinely lacks one.
Either way, a question that calls for a user decision calls the tool or falls back loudly. Narrating it as plain text is a bug.
## Artifact Root
Resolve `<root>` **only** in the no-path interactive branch, which discovers the most recent plan under `<root>/plans/`. Every other run reads the document at the path it was handed. So an absolute-path or non-interactive review — `/tmp/plan.md`, possibly outside any repo — never depends on a repo root or a CE config it does not need.
<!-- ce-docs-root:start -->
**Resolve the CE artifact root `<root>` before composing any artifact path.**
- **Read** `docs_root` from `<repo-root>/.compound-engineering/config.yaml` only (`<repo-root>` = `git rev-parse --show-toplevel`). Do not read it from `config.local.yaml`. Unset -> `<root>` is `docs`, exactly as before.
- **Validate** a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under `.git/`. Otherwise stop with an error naming `docs_root` and the value -- never fall back to `docs`.
- **Use** `<root>` as the sole artifact location: create it if absent, compose each path as `<root>/<subdir>` with this skill's own subdirectory, and never also read `docs`.
<!-- ce-docs-root:end -->
## Phase 1: Get and Analyze Document
**Read `references/document-intake.md` now.** It covers how the document is obtained in each mode, what to do and say when no document is found, and the classification signals.
Two of its rules apply to every later step.
**Verify before any dispatch.** Every resolved path must be readable on disk. If one is not, dispatch **no** personas: reviewers read from the filesystem, so they cannot reach a path that exists only on an unchecked-out branch (issue #925).
**Classify by content, not readiness labels or file path.** A unified artifact with only a Product Contract is **`unified-requirements`**; missing implementation sections are expected. Any implementation planning makes it **`unified-plan`**, including incomplete or blocked planning that needs review. Other artifacts use the legacy `requirements` / `plan` split.
HTML unified artifacts take the same routes. Every fix lands in the document's native format; never insert markdown into HTML. That reference covers ID-bearing items. Pass the classification to each persona in the `{document_type}` slot.
## Phase 2: Announce and Dispatch Personas
Skip dispatch only when the completed-review reuse condition in `references/document-intake.md` passes; continue with that evidence at Phase 3.
**Read `references/persona-selection.md`** for each conditional persona's activation signals and the announcement format. Two of those signals over-activate on plausible evidence: the sensitive-data bound on `security-lens-reviewer`, and the challenge-surface bar on `adversarial-document-reviewer`. Then read **`references/dispatch.md`** for payload variables, slicing, model tiering, and reviewer-failure handling.
The team is `coherence-reviewer` and `feasibility-reviewer` always, plus each activated conditional persona. Announce the team briefly before any dispatch, and stay quiet while reviewers run.
Dispatch generic subagents with **bounded parallelism** through the platform's subagent primitive. Give each one its `references/personas/<reviewer-name>.md` as `references/dispatch.md` describes. Never dispatch a standalone agent by type or name.
A capacity rejection is backpressure, not reviewer failure: wait and retry. If capacity cannot recover and selected reviewers remain undispatched, collect and clean up any started cross-model jobs as `references/cross-model-review.md` describes, then stop as incomplete without synthesis, fixes, or a success handoff. Preserve collected outcomes and report which reviewers completed, failed, or could not run, and why.
### Cross-Model Judgment Pass
Run this pass if any of the **conditional judgment trio** was activated: `adversarial-document-reviewer`, `product-lens-reviewer`, `security-lensExcerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.
Install
Pinned to the audited commit 3cd83b1
git clone https://github.com/everyinc/compound-engineering-plugin git -C compound-engineering-plugin checkout 3cd83b124cb4
The author documents no install command, so this uses the repository directly. Our verdict covers commit 3cd83b124cb4 only.
Works in which agents?
What its own text says, not a test
| Agent | Status | More |
|---|---|---|
| Claude Code | Mentioned in its text, not tested | Skills for Claude Code · About Claude Code |
| Codex | Mentioned in its text, not tested | Skills for Codex · About Codex |
| Cursor | Mentioned in its text, not tested | Skills for Cursor · About Cursor |
Audit history
Every audit, every source change
- !CAUTION B 89 / 100
first audit · source
3cd83b124cb4
README badge
For maintainers · shows the latest audit
[](https://modelsatlas.com/skills/everyinc/ce-doc-review/)
The badge shows our verdict and grade for this skill, and links back to this page. It changes when the audit does.
Similar skills
All docs & writing skills →everyinc/compound-engineering-plugin
Explain how and why something has its current shape, or what happened over a window of work, grounded in evidence. Use when the user asks for an explanation. Use ce-pov for a judgment or recommendation.
everyinc/compound-engineering-plugin
Document a solved problem as a durable repo learning. Use when verified work produced non-obvious reasoning absent from its final code, tests, or existing docs; avoid routine fixes whose artifacts already explain the…
everyinc/compound-engineering-plugin
Refresh the repo's captured learnings against the current codebase. Use when auditing stale, overlapping, superseded, or drifted learnings; avoid general refactor, debugging, or code review unless the learnings store is…
everyinc/compound-engineering-plugin
Commit, push, and open a PR. Use when asked to ship/open a PR, or for PR-description-only flows like writing, rewriting, or describing a PR body.
everyinc/compound-engineering-plugin
Create a git commit with a clear, value-communicating message. Use when the user asks to commit/save staged or unstaged changes with a repo-appropriate message.
everyinc/compound-engineering-plugin
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on…
Add this badge to your README
[](https://modelsatlas.com/skills/everyinc/ce-doc-review/)
<a href="https://modelsatlas.com/skills/everyinc/ce-doc-review/"><img src="https://modelsatlas.com/skills/everyinc/ce-doc-review/badge.svg" alt="ModelsAtlas: CAUTION B"></a>
Questions about ce-doc-review
What does the ce-doc-review skill do?
Is ce-doc-review safe to install?
What can ce-doc-review access on my machine?
Which assistants does ce-doc-review work with?
How current is this page?
Sources
- github.com/everyinc/compound-engineering-plugin/tree/main/skills — the audited source at commit 3cd83b124cb4 and every finding aboveObserved · 31 Oct 2026
Spotted something wrong? Report a correction · Methodology
Keep going in your AI
Opens with this page as the source. We add nothing else to the prompt.
- What does the ce-doc-review skill do?
- Is ce-doc-review safe to install?
- What can ce-doc-review access on my machine?