Skill Hub — AI-Assisted Development

AI-generated code review

Review AI-authored changes before merge: diff inspection, tests, security checks, public/private boundaries, architecture drift, and final merge checklist.

What this skill is for

This skill provides a structured review workflow for code produced or edited by AI agents. The output is a reviewed diff with explicit human decisions on each risk category, plus a final merge checklist.

When to use this skill

  • You are reviewing a PR that an agent authored or heavily edited.
  • You want to catch hallucinations, architecture drift, and privacy leaks before merge.
  • You need a repeatable review process for AI-generated contributions.
  • You maintain a public repository and must ensure no private material is exposed.

Real work situations

Agent adds new Atlas pages

An agent created several new Atlas pages. The reviewer checks that all pages have status: needs_verification, verified: false, robots: noindex,follow, and sitemap: false. The reviewer confirms that generated artifacts were regenerated and that no private paths appear in the diff.

Agent refactors a script

An agent refactored a Python generator. The reviewer verifies that the script still produces identical output, that tests pass, and that no new dependencies were added without justification.

Agent updates site navigation

An agent updated the Skill Hub index to include a new skill group. The reviewer checks that all links are valid, that the homepage was not modified, and that the change does not break Jekyll build.

Inputs required

  • Pull request or diff — the AI-authored changes.
  • Original task brief — what the agent was asked to do.
  • Validation commands — tests, builds, link checks, and linters.
  • Protected files list — homepage, legal pages, verified pages, generated files.
  • Project conventions — frontmatter patterns, naming rules, SEO rules.

Questions to ask

  • Does the diff match the original task brief?
  • Are there changes to files that should not have been touched?
  • Do tests, builds, and link checks pass?
  • Are there new secrets, private paths, or unverified content?
  • Does the change preserve architecture and conventions?
  • Would a human reviewer understand why each change was made?

Working method

  1. Read the task brief. Know what the agent was supposed to do.
  2. Inspect the diff file by file. Do not rely on summary comments alone.
  3. Run validation commands. Tests, builds, link checks, SEO checks, and public-repo hygiene checks.
  4. Check for secrets and private paths. Search for tokens, env files, local paths, and private notes.
  5. Check public/private boundaries. Ensure no private corpus, client data, or internal IDs are exposed.
  6. Check architecture drift. Confirm the change follows existing patterns and does not introduce inconsistency.
  7. Check SEO and site quality. For site content, verify frontmatter, links, robots, and sitemap settings.
  8. Check generated artifacts. If the repo has generators, confirm they were run and outputs are consistent.
  9. Record findings. Mark each item as pass, fail, or needs discussion.
  10. Decide on merge. Approve only when all blockers are resolved.

Decision rules

  • If a protected file was modified without approval, reject.
  • If validation fails, reject until fixed.
  • If secrets or private paths are found, reject and rotate credentials if needed.
  • If architecture drift is introduced, request a redesign or split the PR.
  • If generated artifacts are inconsistent, request regeneration.
  • If the change is large, request smaller sequential PRs.

Deliverables

  • Review report — pass/fail/needs-discussion for each category.
  • Corrected diff — the approved version of the changes.
  • Validation log — command outputs proving checks pass.
  • Merge checklist — signed-off yes/no items.

Templates

Review report

PR: [URL or branch]
Agent task: [brief]

Diff inspection:
- [ ] Files changed match the task scope.
- [ ] No protected files were modified.
- [ ] No secrets, tokens, or env files added.
- [ ] No private paths or client data exposed.

Validation:
- [ ] Tests pass: [command + output]
- [ ] Build passes: [command + output]
- [ ] Link check passes: [command + output]
- [ ] SEO/public-repo checks pass: [command + output]

Quality:
- [ ] Architecture and conventions preserved.
- [ ] Generated artifacts consistent.
- [ ] Frontmatter/SEO settings correct.

Decision: [Approve / Request changes / Reject]

Quality checklist

  • Every changed file was inspected, not just summarized.
  • Validation commands were run and passed.
  • No secrets, private paths, or unverified public content are present.
  • Protected files remain unchanged unless explicitly approved.
  • Generated artifacts are consistent with source changes.
  • The merge checklist is complete and signed off.

Common mistakes

  • Trusting the agent summary. Consequence: missed changes to protected files.
  • Skipping validation. Consequence: broken tests or links reach main.
  • Ignoring architecture drift. Consequence: inconsistent patterns accumulate.
  • Approving because "it looks fine." Consequence: public repo hygiene failures or security leaks.

Agent instructions

When using this skill, start by reading the task brief and the full diff. Separate facts from assumptions: the diff contents are facts; the agent's intent is an assumption. Run all validation commands and capture outputs. Produce the four deliverables. Do not approve a PR because the agent claims it works; approve because the evidence shows it works. If any blocker is found, report it explicitly.

Related skills

Related Atlas pages

Verification status and limitations

This skill is a public working interpretation of code-review practice. It is not official vendor documentation. The exact validation commands depend on the project's tech stack and must be adapted locally.