/weekly-review

name: weekly-review
description: Refresh one project's dashboard and dated history from selected new evidence, preserving human corrections and identifying changes needed in the underlying project plan. Use on request or as the task inside an explicitly configured schedule.

Weekly Review

Public adaptation v2.1, 2026-11-12. Adds a strict session-only `nochange` preview and a required comparison of new evidence with Tab 2. Retains the shared workflow's baseline-first synthesis and bounded dashboard/history updates, with portable source discovery and explicit correction handling. This is a reference instruction workflow; it does not bundle a Google Docs writer, private prefetch scripts, authentication, or a scheduler.

Tab roles and user-chosen names

Use **Tab 1** for the current dashboard and dated meeting/review history, and **Tab 2** for the research design or project plan. These are workflow roles, not required tab titles. Users may name or rename either tab. Resolve each role to its verified document tab ID from the project's configuration and actual document structure. Do not select a tab by its name or ordinal position alone, rename it to match a template, or assume `t.0` is Tab 1. For local documents, map the same roles to their agreed file paths.

Older versions called the detailed weekly log "Tab 2" and used `tab2only` for that log. That is not this version's meaning of Tab 2. If adapting an older configuration or receiving `tab2only`, establish the intended output before writing. Keep dated history in the configured Tab 1 history region.

`nochange`: preview in the session only

Recognize `nochange` anywhere in the request, for example `/weekly-review nochange` or `/weekly-review [project name] nochange`. Determine this mode before invoking helpers or collecting sources. It overrides standing write permissions and conflicting save/apply options for this run.

Read the accessible project configuration, both tabs, comments, and selected new evidence. Perform the normal synthesis and Tab 2 comparison, but print the full proposed Tab 1 dashboard, the proposed dated history entry, and the separate Tab 2 suggestions in the current session. Do not return only a summary of changes. Include source gaps and unresolved questions, and state that nothing was changed.

Do not create or modify local summaries, snapshots, proposal files, configuration, logs, processed-source state, or refresh checkpoints. Do not edit Google Docs, reply to or resolve comments, move/archive transcripts, or create/change schedules. Use read-only source tools and in-session content. Skip fetching/exporting or normalization helpers that write files, reporting any resulting access gap. If the request also asks to save or apply the preview, keep this run read-only and explain that saving or applying requires a subsequent request without `nochange`.

After printing the preview, stop before the apply, record-outcome, and scheduling steps below.

Default and `nosave` modes

An ordinary `/weekly-review [project name]` request runs the review and applies the bounded Tab 1 update within the user's current or standing authorization. Honor an explicit propose-only project setting. It does not authorize Tab 2 edits. Do not require a separate preview run or repeated approval when the dashboard update is already authorized.

Recognize `nosave` anywhere in the request. Run the same review but omit the local narrative summary file. Google Doc updates, recovery snapshots, and the verified completion/source records follow the ordinary workflow and authorization. `nosave` does not mean read-only or skip verification. If both options occur, `nochange` takes precedence and prohibits all writes.

Resolve scope and capability

Resolve the named project

For a request such as `/weekly-review gang entry`, treat `gang entry` as the project name or alias, excluding recognized mode options such as `nochange` and `nosave`. Resolve it using the known project list, project locations, aliases, or context available to the agent. Use the current project when no project name is supplied and that context is unambiguous. An explicit name must not silently fall back to the current folder or another project. If multiple projects match, ask which one. If the project cannot be located, ask for its location rather than searching unrelated accounts.

Use configuration first, with index fallback

Work on the selected project, not every accessible project or account. Read its instructions and established configuration. New dashboard setups use `PROJECT_CONFIG.json`, populated by setup-project-management with verified destinations and tab IDs. Older installations may use fenced YAML in `.claude/CLAUDE.md`; inspect and map it rather than creating a competing config. Installing a skill alone does not create project configuration.

Use valid, complete configuration directly for document destinations, tab-role mappings, selected sources, and review settings. Verify those destinations and roles against the actual document before writing. A complete configuration does not require a separate read of `PROJECT_INDEX.md`, and a missing index is not a blocker when configuration supplies the necessary information.

If configuration is absent or incomplete, use the project's `PROJECT_INDEX.md` to supply missing links or file locations. It may live at the root or within an established collaboration folder. Follow explicitly identified current destinations, not an arbitrary first link or an archived document. Use the setup configuration contract for new routing records rather than inventing unsupported fields. For local documents, resolve the agreed file paths. The user should not need to paste Doc links every run or look up internal IDs themselves.

Ask only when configuration and the available index do not supply enough information, or when an actual ambiguity or conflict needs resolution. If a conflict is encountered between configuration,