AgentSkillsCN

code-review-security-first

为 personal-config、email-security-pipeline 与 ctrld-sync 提供以安全为先的 PR 审查技能。在选择主要模式时，务必精确选定一种（安全/性能/美学），始终将安全置于首位，并以分类化的发现 + ELIR 为导向，产出一份以清单驱动的审查报告。对于 AI 生成的 PR（例如，由 Jules 或 Copilot 辅助生成的 PR），应视其为不可信，并需经过人工验证。

SKILL.md
--- frontmatter
name: code-review-security-first
description: >-
  Security-first PR review skill for personal-config, email-security-pipeline, and ctrld-sync.
  Choose exactly one primary mode (Security/Performance/Aesthetics), always surface security first,
  and produce a checklist-driven review with Categorized Findings + ELIR.
  Treat AI-generated PRs (e.g., Jules/Copilot-assisted) as untrusted and require human verification.

Security-First PR Review (Jules-Aware)

Purpose

Standardize PR reviews across:

  • •personal-config
  • •email-security-pipeline
  • •ctrld-sync

All reviews must be:

  • •Security-first
  • •Checklist-driven
  • •Auditable (ELIR-aligned)
  • •Explicit about uncertainty

When to use

Use this skill when:

  • •The user asks to review a PR or a diff
  • •The PR is labeled/prefixed Sentinel (security), Bolt (performance), or Palette (aesthetics/UX)
  • •The PR is AI-assisted or agent-generated (Jules/Copilot/Gemini present)
  • •The user asks, “Is this safe?”

Operating rules

  • •Always include: Route: T2+S+H
  • •Choose exactly one Primary mode:
    • •Security
    • •Performance
    • •Aesthetics
  • •If multiple apply:
    • •still choose one primary mode
    • •but review in this order: Security → Performance → Aesthetics
  • •Always list security concerns first, even when primary mode ≠ Security
  • •For agent-assisted PRs:
    • •Never claim “safe”
    • •Only claim “no obvious issues found” and require human verification

Output template (always use)

markdown
Route: T2+S+H

## Summary

- **Repo**: [personal-config | email-security-pipeline | ctrld-sync]
- **PR type**: [Agent-assisted | Human-authored | Mixed]
- **Primary mode**: [Security | Performance | Aesthetics]
- **Scope**: [1–2 sentences: what changed]
- **Risk surface**: [low | medium | high] (based on touched files + trust boundaries)

## Checklist

- [ ] **Correctness**: [Pass/Concern + 1-line why]
- [ ] **Security**: [Pass/Concern + 1-line why]
- [ ] **Performance**: [Pass/Concern or N/A + 1-line why]
- [ ] **Maintainability**: [Pass/Concern + 1-line why]
- [ ] **Testing**: [Pass/Concern + what’s missing]

## Categorized Findings

### Security

- **Critical (must fix before merge)**
  - [Issue + file:line + fix recommendation]
- **Suggestions**
  - [Suggestion + file:line]

### Performance

- **Critical (must fix before merge)**
  - [Issue + file:line + fix recommendation]
- **Suggestions**
  - [Suggestion + file:line]

### Aesthetics / Clarity

- **Critical (must fix before merge)**
  - [Issue + file:line + fix recommendation]
- **Suggestions**
  - [Suggestion + file:line]

## Verification (safe, non-destructive)

- [ ] Suggested checks to run (only if they exist in this repo): [...]
- [ ] What output increases confidence: [...]

## Mapping: Review Comment → Fix (if autofixing)

- Comment source: [Copilot | Gemini | Human]
  - Comment: [...]
  - Proposed fix: [...]
  - Files: [...]

## ELIR

- **PURPOSE**: [What this PR accomplishes and why]
- **SECURITY**: [Threats touched, protections, assumptions, trust boundaries]
- **FAILURE MODES**: [What could break → consequence → mitigation]
- **VERIFY**: [What the human should double-check]
- **MAINTAIN**: [Future dev notes + pitfalls]

Mode selection guidance

Pick the primary mode using:

  • •

    Title prefix

    • •Sentinel → Security
    • •Bolt → Performance
    • •Palette → Aesthetics
  • •

    If unclear, choose based on the most sensitive surface touched

    • •Shell execution, secrets/env handling, network/DNS, launchd/services → Security
    • •Hot paths, loops, regex work, I/O, concurrency → Performance
    • •Naming, docs, output formatting, UI/UX → Aesthetics

Repo-specific trust boundary reminders (review focus)

  • •personal-config
    • •Shell scripts, launchd plists, DNS/VPN behavior, filesystem operations, privilege boundaries
  • •email-security-pipeline
    • •Parsing untrusted email content, attachment handling, file type validation, logging of sensitive fields
  • •ctrld-sync
    • •External JSON inputs, API requests/retry logic, output/log sanitization, config/.env handling

Jules/Copilot/Gemini handling

When review input is generated by bots:

  • •Treat it as signal, not truth
  • •If a suggested change alters behavior or security posture, flag it as Needs human decision
  • •Never rubber-stamp; always require verification steps