forgeflow-review
Skill1 starsChanged 45 days agoMITView on GitHub
Run Forgeflow review with evidence-first findings and validation follow-up.
In this repository37 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/forgeflow-lean.mdcCursor rule
- aegis-verifySkill
- agent-chat-offSkill
- agent-chat-onSkill
- auditSkill
- consultSkill
- create-agentSkill
- debateSkill
- discussSkill
- forgeflow-capabilitiesSkill
- forgeflow-consultSkill
- forgeflow-implementSkill
- forgeflow-research-divergence-adviceSkill
- forgeflow-research-divergence-evalSkill
- forgeflow-reviewSkill
- forge-reviewSkill
- implementSkill
- planSkill
- quickSkill
- researchSkill
- shipSkill
- taskSkill
- update-forgeflowSkill
- verifier-verifySkill
- forgeflow-auditSkill
- forgeflow-capabilitiesSkill
- forgeflow-implementSkill
- forgeflow-lean-auditSkill
- forgeflow-lean-debtSkill
- forgeflow-lean-primeSkill
- forgeflow-lean-reviewSkill
- forgeflow-leanSkill
- forgeflow-planSkill
- forgeflow-research-divergence-adviceSkill
- forgeflow-shipSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
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
- Very specific: line 8
Use this skill when the host supports skill discovery but not Forgeflow slash-command browsing.
- Distinctive: line 12
Do not commit, push, install dependencies, edit host settings, call the network, or launch long-running services unless the user explicitly …
- Distinctive: line 46
Keep the existing public finding envelope, E1 claim sidecars and evaluator schemas.
- Distinctive: line 60
Before synthesis, prepare current proof from this same session:
- Distinctive: line 83
Never insert workflow agent identities or local evidence references into application source, comments, docstrings, tests, fixtures, …
- Distinctive: line 84
Before staging or publishing, inspect the actual staged diff, outgoing commits, and public text.
≈ “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.
Files
forgeflow-review
Use this skill when the host supports skill discovery but not Forgeflow slash-command browsing.
In Codex, execute this skill directly; do not invoke /review, which is a Codex built-in. In Claude Code, run /review. If slash commands are unavailable, follow the same objective manually and preserve current user instructions, local evidence, validation, security, accessibility, and repository boundaries.
Do not commit, push, install dependencies, edit host settings, call the network, or launch long-running services unless the user explicitly asks or the command workflow requires it.
Focused questions and bounded follow-up
For every non-skip packet-backed review, supply concrete questions before compilation with --review-assignments "$REVIEW_ASSIGNMENTS_INPUT". The trusted local JSON input has {schema_version:"1",assignments:[{assignment_id,reviewer,question,artifact_ids,expected_evidence}]}. Use the unchanged canonical route roster, including required audit coverage, with exactly one falsifiable project question per required reviewer and nonempty expected-evidence descriptions. Authorized IDs name sealed source/diff/original-contract inputs, never peer reports, answer keys or advisory memory. Before construction use source-<sha256(repository-relative normalized slash path)> for source and git-diff-full for the diff; after seal inspect the actual authorized_evidence_artifacts inventory and confirm IDs/coverage. The returned required_reviewers and review_assignments must match the supplied contract. Questions focus attention while preserving independent discovery, security, accessibility and every ordinary domain duty. Do not invent generic role slogans or use question planning as another model wave. Missing helper, roster member or decisive evidence is a visible coverage gap; stop enforced dispatch and repair it. Skip has no dispatch, session or challenge. --no-context-pack is explicitly legacy unenforced behavior, unsupported for E3 immutable enforcement. A compiler call without assignments records focused_questions: "not_enabled" and cannot claim E3 enforcement.
After successful compilation and current E2 inspection, the orchestrator prepares REVIEW_SESSION_INPUT outside the seal: {schema_version:"1",evidence_ref:<exact returned ref>,required_reviewers:<unchanged canonical roster>,assignments:<same concrete assignments>,limits:{}}. Missing limits use hard ceilings; values may only lower them, including zero. Persist the returned session reference in a unique trusted local file outside the seal, keep it across chunks/restarts/alias handoffs, and never choose a latest session:
REVIEW_SESSION_JSON=$(node "$FORGEFLOW_HELPER_DIR/review-questions-cli.js" start --root "$PROJECT_ROOT" --input "$REVIEW_SESSION_INPUT" --json) || exit 1
REVIEW_SESSION_STATE_DIR="$PROJECT_ROOT/.forgeflow/$(basename "$PROJECT_ROOT")/review-session-inputs"
[ ! -L "$REVIEW_SESSION_STATE_DIR" ] || exit 1
mkdir -p -m 700 "$REVIEW_SESSION_STATE_DIR" || exit 1
REVIEW_SESSION_REF=$(mktemp "$REVIEW_SESSION_STATE_DIR/session-ref.XXXXXX") || exit 1
printf '%s' "$REVIEW_SESSION_JSON" | node -e 'let s="";process.stdin.on("data",c=>s+=c);process.stdin.on("end",()=>{const r=JSON.parse(s);if(!r.session_ref)process.exit(1);process.stdout.write(JSON.stringify(r.session_ref))})' > "$REVIEW_SESSION_REF" || exit 1
node "$FORGEFLOW_HELPER_DIR/review-questions-cli.js" inspect --root "$PROJECT_ROOT" --session "$REVIEW_SESSION_REF" --json || exit 1In command hosts use FORGEFLOW_HELPER_DIR="$HELPER_DIR"; in skill hosts use the already resolved helper directory. Run from the project root. Input and session reference files are trusted orchestrator-owned files within the project's local .forgeflow, outside the seal; safe readers reject outside-root paths. Never let reviewer payloads select paths or overwrite references. The full review has at most 2 requests/reviewer, 4 requests/review, 64 KiB serialized response/request, 128 KiB/review and 2 independent challenges/review, shared across all chunks, retries, denied attempts and resumed calls. Deep audit and mandatory accessibility coverage remain required; if the roster exceeds supported capacity, report unsupported coverage rather than dropping members. Freeze the union of required chunk reviewers before compilation, including any deep audit identity; never use the wave builder's thin override. Do not start a fresh session per chunk or silently refund/reset budgets. In incremental mode each changed source identity requires an explicitly new contract; never mix old judgments or reset a single review's allowance invisibly.
Request and resume
Give each reviewer its concrete assignment and allowed artifact IDs. A reviewer needing decisive proof returns only {schema_version:"1",request_id,assignment_id,reviewer,artifact_id,extent,why_decisive}, where extent is {mode:"full"} or {mode:"lines",start_line,end_line}. No paths, refs, commands, tools, limits, counters or scope expansion. In enabled mode route all follow-up through the session, not direct mutable file reads or unaccounted E2 retrieval. The orchestrator saves the actual request as a trusted local input and resolves it:
node "$FORGEFLOW_HELPER_DIR/review-questions-cli.js" request --root "$PROJECT_ROOT" --session "$REVIEW_SESSION_REF" --input "$REVIEW_REQUEST_INPUT" --jsonResume only the relevant reviewer with the retained resolution and original assignment. Fulfilled delivery contains exact UTF-8 evidence or explicit line-context omissions; inspect status before using it. Denied, exhausted, unavailable, stale and interrupted requests leave decisive questions unresolved. Successful retrieval is execution state, not claim truth. Absent proof needs explicit new-run authorization and visibly reissued assignments; never automatic supplements or mixed evidence identities. Save complete actual resumed result and existing decision bytes outside the seal. The orchestrator records {schema_version:"1",response_id,kind:"reviewer",subject_id:<assignment_id>,result_path,decision_path,artifact_ids} with trusted project-relative result paths:
node "$FORGEFLOW_HELPER_DIR/review-questions-cli.js" response --root "$PROJECT_ROOT" --session "$REVIEW_SESSION_REF" --input "$REVIEW_RESPONSE_INPUT" --json || exit 1Keep the existing public finding envelope, E1 claim sidecars and evaluator schemas. Retain complete actual responses, not a summary or inferred approval. Never turn request completion into a supported claim.
Independent challenge before peer exposure
Before exposing any reviewer response to the challenger, and before existing claim-bearing high-risk verification, prepare a consequential neutral challenge from the original user contract and question. Input is exactly {schema_version:"1",challenge_id,assignment_id,question,original_contract,artifact_ids,user_constraints}; IDs must be a subset of authorized neutral inputs. Ask which alternatives fit the source and which distinguishing observation resolves them. Do not send the initial claim proposition/direction, peer identity, verdict, severity, repair, rationale, reviewer-derived facts, grader output or expected answer.
node "$FORGEFLOW_HELPER_DIR/review-questions-cli.js" challenge --root "$PROJECT_ROOT" --session "$REVIEW_SESSION_REF" --input "$REVIEW_CHALLENGE_INPUT" --json || exit 1Inspect the exact prepared prompt/export inventory before dispatch. Use a fresh restricted case-only challenger with no full-history fork, sibling memory or peer reports. Record actual host/settings/isolation limits; prompt-only separation is labelled as such and is not OS isolation. Preparation consumes one of the two global challenge calls even if interrupted. Save complete actual challenge response and decision, then use the same response command with kind:"challenge" and subject_id:<challenge_id>. No universal extra reviewer wave. Challenge completion requires retained actual bytes; uncompleted reservations remain unresolved. Then retain the existing high-risk verifier gate with its claim-bearing inputs.
Current synthesis and unresolved coverage
Before synthesis, prepare current proof from this same session:
node "$FORGEFLOW_HELPER_DIR/review-questions-cli.js" synthesis --root "$PROJECT_ROOT" --session "$REVIEW_SESSION_REF" --json || exit 1Give synthesis and final acceptance the returned current retained references, unchanged roster coverage and unresolved statuses alongside original packets and ordinary reports. This command implements prepareSynthesis; it does not approve the review. Missing/exhausted evidence or missing required reviewer/challenge responses stay explicit unresolved questions, never supported findings or clean acceptance. Source/integrity failure stops current adjudication; historical intact bytes remain historical. Preserve normal full/deep/audit/accessibility duties, route skip behavior and final acceptance. Focused implementation tests support safety only; roadmap closure still requires observed real-PR behavior, independence and the frozen overhead gate.
Immutable review evidence
Resolve helpers from the checkout scripts/forgeflow first, then the installed Forgeflow runtime for this host. In Codex, follow the maintained forgeflow-review skill when installed; otherwise use this same evidence sequence directly with native reviewer dispatch. Do not substitute a Codex built-in review.
For route skip do not prepare or dispatch. Otherwise prepare concrete assignments and the resolved repository-relative file list, then run render-review-wave-prep.js --prepare --root <project-root> --prep-id <stable-preparation-id> --files <resolved-files> --mode <already-selected-mode> --review-assignments <trusted-assignments-json> --json. Preserve the preparation id across interruption. Only review_ready:true permits dispatch; ready is input preparation, not review approval. Keep the returned receipt, parent run_dir/evidence_ref_file and all packets with exact immutable references. Iterate verified packets sequentially, bind each entry run_dir/evidence_ref_file as ACTIVE_REVIEW_PACKET_DIR/ACTIVE_REVIEW_EVIDENCE_REF for matching reviewer context, and inspect it before dispatch. Preserve parent bindings for the single session and final synthesis. Retain wave identities and complete reviewer responses covering all assigned waves. Dispatch with the unchanged required roster and proof; never dispatch an over-budget parent packet or reset parent session request/challenge limits per wave. Inspect named blockers and task_id with task.js status. Reconcile pending/unknown effects before continuing; no automatic retries or latest fallback. Changed source/inputs require resolving the old attempt before a separately identified fresh preparation. Use review-evidence-cli.js inspect --root <project-root> --ref <exact-reference-file> --require-current for parent and child proof before consumption and synthesis. Hash integrity, source freshness and claim truth are separate.
Preparation checks configured budgets and returns verified bounded inputs or a named blocker. Keep lean advisory output, history, reviewer reports and decisions outside the sealed run. If using advise-context.js --record, supply --root <project-root> --file <run_dir>/context-telemetry.json and --history <project-local-path-outside-run>. Preserve native host authorization.
In legacy unenforced mode only, for consequential proof consumption, use review-evidence-cli.js retrieve --root <project-root> --ref <pinned-reference> --artifact <manifest-artifact-id>; use --raw-required when full proof is required. Save actual result and decision bytes outside the sealed run, then opt in to record --root <project-root> --ref <pinned-reference> --id <unique-id> --kind review --result <actual-result-path> --decision <actual-decision-path> --artifacts <consumed-artifact-ids>. Use kind synthesis for synthesis and retain the returned separate sidecar in the local report/task evidence. Native identities stay unknown when unobserved. Do not invent decisions or treat successful inspection as claim truth. This does not require an E3 claim ledger for every observation.
Local-only workflow boundary
- Treat every
.forgeflow/directory, its contents, and workflow agent identities as local working context only. Never stage, commit, push, attach, upload, or sync this state, including through memory-sync commands. Use Git's localinfo/excludefor generated state; never force-add it. Ignore rules do not protect already tracked files. - Never include local artifact paths, agent names, persona names, role labels, agent verdict attribution, or workflow signatures in PR titles, bodies, comments, commit messages, release notes, or published artifacts. Describe the change and observed validation in ordinary engineering language. Keep detailed review attribution and evidence links in local reports.
- Never insert workflow agent identities or local evidence references into application source, comments, docstrings, tests, fixtures, identifiers, UI text, or shipped documentation. Use domain-based names and explain technical reasons without agent attribution.
- Before staging or publishing, inspect the actual staged diff, outgoing commits, and public text. A local-state file or workflow attribution leak blocks the action until corrected. Do not silently delete local evidence or rewrite existing history; report already tracked or committed state for cleanup.
- These rules govern project work produced with Forgeflow. Forgeflow's own maintained agent definitions, integration code, and documentation may name the agents and state paths needed to implement the tool; generated session state is always local. Ordinary domain terms that happen to match a role name are not workflow attribution.
- Local CLI labels, orchestration messages, and local report schemas may retain identities. This boundary takes precedence over instructions to copy local reports into public output or sync session memory.
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
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.

