Personal Assistant Review

Personal Assistant Review

Core Rule

Use this skill for review-only or review-first work in the personal-assistant repository.

Default to high-signal review. Find correctness, product-contract, state, privacy, concurrency, docs/tests consistency, and release-blocking risks before polish. Treat green checks and working happy paths as supporting evidence, not closure. Do not invent findings to satisfy a role or lane.

Start

1. Treat the task as review-only unless the user explicitly asks to fix.
2. Bound the current surface:
   • git status --short --branch
   • git diff --stat
   • git diff --name-only
3. Read the requirements/current contract, targeted diffs, and necessary dependencies before the implementer's conclusions. Form an independent view, then reconcile their explanation and validation evidence. For PA Agent/runtime/command changes, first check the Command Architecture Contract against the task's owner/factual-basis mapping and real call chain. Host admission must use explicit authority or execution facts, not prose intent; correctable attempts and accepted/unknown effects must remain distinct. This is a normal gate check before green-test acceptance, not optional polish.
4. Lead the final answer with findings ordered by severity.
5. State validation run and validation not run.

Mode Selection

Use gate mode by default. This matches prompts such as:

启动agent team对代码修改进行review
review current diff
release-readiness review

Gate mode optimizes for accurate P0/P1/P2 findings and direct fixability.

Use exploration mode when the user explicitly asks for many perspectives, for example:

从程序员、架构师、产品经理、UI/UX、性能、desktop&mobile多端支持等角度评审
多角度体检
全面扫描产品、架构、UI 和性能

Exploration mode may include P3 design debt and polish, but still must not force a finding per role.

Use hybrid mode for broad diffs when unsure: run gate mode first, then add optional exploration findings under a separate Optional Polish section.

Subagent Lanes

Select lanes from the actual diff and its affected dependencies; the examples below are not mandatory read sets. Use independent subagent lanes when requested or when parallel work saves time or improves coverage. Keep a narrow review local when splitting adds no value; if tools are unavailable, cover the relevant risks locally. Docs/skills-only reviews need no unrelated Pagelet/runtime lane.

Assign bounded risk questions without requiring a finding from each lane. Follow AGENTS.md Multi-Agent Validation Coordination: the main agent merges evidence and schedules expensive gates; reviewers report findings and focused evidence without each running full tests/build/deploy. Review-only lanes do not edit files, including while a final gate is running.

Gate Mode Lanes

1. Functional state and concurrency

   • Inspect Pagelet orchestration, foreground run guards, stale result handling, save state, panel/tab routing, command aliases, hidden side effects on old state, and tests.
   • Focus files: src/pagelet/orchestrator.ts, src/pagelet/AnalysisSessionManager.ts, src/pagelet/ReviewNoteSaveFlow.ts, src/pagelet/BubbleCoordinator.ts, src/pagelet/commands.ts, src/pagelet/panel/PanelView.ts, src/pagelet/tab/*, touched Pagelet tests.

2. Spec, docs, tests, i18n, product contract

   • Compare runtime behavior against changed docs and SDD/plans.
   • Inspect docs that changed plus relevant contract docs, especially Pagelet async-result, write-action, release, Memory/VSS, and tracker docs.
   • Check whether tests encode a behavior that contradicts a product/privacy non-goal.
   • Keep deterministic harness, actual-model semantic/recovery and real-app evidence distinct; none substitutes for another changed boundary.
   • Check whether tests cover failure, compatibility, stale-state, and concurrency edges, not only the easiest success path.

3. Obsidian/community compatibility and lifecycle

   • Scan for runtime DOM injection blockers: createElement('style'), innerHTML =, outerHTML =.
   • Inspect timers, listeners, observers, root unmount, CSS scope, public exports, old settings, command ids, storage scopes, generated assets, packaging/deploy impact, and compatibility-sensitive APIs.

4. UI/UX/accessibility/mobile

   • Inspect focus management, keyboard behavior, ARIA, mobile overflow, touch gestures, text clipping, theme variables, and ordinary-user copy (follow Memory/VSS Product Rules from AGENTS.md for user-facing terms).
   • Keep UI findings concrete: include the visible symptom or user flow.

5. Performance, safety, and maintainability

   • Inspect repeated scans, render loops, large-vault behavior, sync waits, background work, unnecessary provider calls, and teardown/unload behavior.
   • Inspect note text exposure, provider output persistence, file writes, external links, and command-triggered AI work for security/privacy risk.
   • Inspect misleading names, helper boundaries, and abstractions that could cause future callers to use an API incorrectly.

Exploration Mode Lanes

Use the gate lanes, then add perspectives only where relevant:

• programmer/correctness
• architect/module boundaries
• product manager/workflow and value
• UI/UX/accessibility
• performance/rendering
• desktop/mobile support
• security/privacy
• naming/maintenance cost

Do not let these labels create coverage pressure. If a lane has no actionable issue, say so.

Maintainability And Probe Reliability

• For a new module or complex state change, walk through one plausible change adjacent to the current requirement. Locate the entry point, state owner, and invariants a future maintainer must preserve without the implementation conversation. Use the exercise to expose concrete coupling or misleading APIs; do not implement the hypothetical feature or require speculative abstractions. Apply the existing severity rules to any resulting finding.
• For changed tests/checkers/probes, select the risks they actually exercise: semantic comparison rather than incidental object-key order, text/frontmatter boundaries, async cleanup, repeatability, and expectations derived from the contract rather than copied implementation assumptions. Do not turn this list into a mandatory test matrix for every feature.
• Before relying on a new or materially changed probe's verdict, inspect the smallest normal and counterexample evidence for its relevant assertion. It must accept valid behavior and reject the failure it claims to detect. Missing evidence is a validation gap; review-only work reports it without writing fixtures or changing production code to satisfy the checker.