personal-assistant-review

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# 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](../../../docs/architecture/pa-agent-architecture-plan.md#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:

```text
启动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:

```text
从程序员、架构师、产品经理、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:

From edonyzpc/personal-assistant, AGPL-3.0.

More from edonyzpc/personal-assistant