planning-lob-gap-audit git:20260817.f8cf74dA

Immutable. This exact content never changes and is served at /api/v1/blob/9f3993bcc9223775.

---
name: planning-lob-gap-audit
sheetId: "0.10"
description: >-
  Audit ONE line of business (an L1 LOB such as 3.0 Operations) after a planning
  cycle: inventory its Drive folder, read its plan Doc + Refresh addendum and its
  rows in the planning Main Tracker, and cross-check five gap classes — P0/P1
  items with no doctrine/SOP or owner-named plan, role docs / SOPs that contradict
  the plan (stale tools, stale owners), docs the plan cites that do not exist,
  superseded snapshots without a [SUPERSEDED] banner, and open decisions the plan
  needs from the founder. Produces a wave-ordered heal list (SOR sync → banners →
  build missing doctrine → rewrites) with 可交 Claude flags and the owning skill
  per fix, written as a NEW report Doc 「[N.0.1] <LOB> — <cycle> Gap Audit & Heal
  Plan（YYYY-MM-DD）」 plus a NEW 「行動追蹤表」 Sheet in the LOB folder.
  Report-only: it never edits, renames or moves an existing Doc, and never
  executes a fix. Trigger on /planning-lob-gap-audit or when Peter says
  "部門缺口稽核", "幫我做 3.0 的 gap audit", "檢查營運部門的文件有沒有跟計畫對齊",
  "文件缺口盤點", "做一份 heal plan", "哪些 SOP 過時了", "audit the ops docs
  against the H2 plan", "LOB gap audit", "gap audit and heal plan for <LOB>".
  Distinct from admin-governance (local _INDEX.md ↔ Drive INDEX sync — metadata
  only, all LOBs, weekly), from consult-governance (the consulting ENGAGEMENT
  portfolio — a pattern source only), and from planning-suite-reconciler (WRITES
  the plan addendum this skill only READS — this skill writes no addenda).
category: strategy
project: planning-lob-gap-audit
platform: claude
status: Done
author: Peter Tu
input: "One L1 LOB number + cycle label; plan Doc / tracker IDs from ./references/planning-sources.md; the LOB Drive folder ID (admin-governance's folder map if installed, else asked)"
process: "Resolve cycle + sources + LOB folder → inventory folder one level deep → read plan addendum + SOR rows → cross-check G1–G5 → heal list in waves W1–W4 (owner · 可交 Claude · owning skill) → ONE confirmation → write report Doc + 行動追蹤表 → close-out"
output: "A NEW report Doc 「[N.0.1] <LOB> — <cycle> Gap Audit & Heal Plan」 + a NEW 行動追蹤表 Sheet (README · 修復清單 · 待決事項) in the LOB folder, plus GM-directory entry + did-not list"
synergy:
  - "planning-suite-reconciler"
  - "planning-tracker-sync"
  - "admin-governance"
  - "consult-governance"
  - "zynkr-kms"
---

# Planning LOB Gap Audit

```bash
npx skills add https://github.com/peter-tu-zynkr/zynkr-skill-builder --skill planning-lob-gap-audit
```

After a planning cycle lands, each line of business owns a plan Doc, a slice of the Main
Tracker, and a Drive folder full of role docs, SOPs and snapshots that were written before
the room — and the three drift apart: a P0 that runs from one person's memory, a role doc
that still names a retired tool, a snapshot nobody marked superseded, a decision the plan
quietly assumes the founder made. This skill audits ONE LOB against its plan and tracker,
classifies every gap into five classes, and hands back a wave-ordered heal list as a new
report Doc plus a 行動追蹤表 Sheet the team executes from — for the founder or the LOB
owner in the weeks after `planning-suite-reconciler` has written the addenda. It is
report-only, quotes evidence for every finding, and names owner + owning skill per fix.

---

## How this differs from its neighbours

- **admin-governance** (3.05) — the report-only pattern source: it diffs Drive
  `modifiedTime` against local `_INDEX.md` lines, all LOBs, weekly, metadata only. This
  skill reads Doc CONTENT for one LOB and routes index lines to admin-governance.
- **consult-governance** (2.45) — the other report-only sweep, over the consulting
  engagement portfolio. Pattern borrowed (findings → 建議動作 → owning skill → 未檢查).
- **planning-suite-reconciler** (0.08) — upstream: it WRITES the dated Refresh addendum
  in each plan Doc. This skill READS that addendum as the plan's current truth; a plan
  Doc with no addendum is a finding routed back to the reconciler, never fixed here.
- **planning-tracker-sync** (0.09) — the weekly agenda / nudge pass over tracker cells.
  Stale cells this audit notices are routed there; this skill edits no cell.

## Fixed facts (read the references first)

- **`./references/planning-knowledge-pack.md`** — vocabulary (§1), the L1 numbering and
  LOB names used in titles (§2), P0–P3 + the exact 狀態 strings (§3), the SOR tab layout
  (§6), the `[SUPERSEDED YYYY-MM]` + banner convention and "tracker is the SOR" (§8),
  and the never-do list (§9). Do not restate these; cite them.
- **`./references/planning-sources.md`** — §A holds the Main Tracker + SOR tab gid, the
  seven per-LOB plan Doc IDs and the 6.0 shortcut, the GM Knowledge Directory, and the
  Ops exemplar pair (report Doc + 行動追蹤表) whose shape this skill reproduces. IDs come
  from there or from the user — never from memory.
- **`./references/gap-audit-checklist.md`** — this skill's own contract: input
  resolution (§1), the inventory record (§2), G1–G5 definitions + finding-line format
  (§3), waves W1–W4 + heal-item fields + the 可交 Claude rule (§4), owning-skill routing
  (§5), the report Doc skeleton (§6), the 行動追蹤表 layout + colours (§7), the GM
  directory entry text (§8), the close-out shape (§9).
- **LOB folder** — from `~/.claude/skills/admin-governance/references/lob-folder-map.md`
  when admin-governance is installed. Its rows are labelled `0` · `1.0` · `2.0` · `3.0`
  · `4.0` · `5 (SDLC, legacy)` · `5.0 (Product)` · `7 (People)` (three sibling folders)
  · `8.0` — there is no `6.0` row (out of scope there). Match on the LOB's L1 number
  (`5.0` → the `5.0 (Product)` row, never the legacy `5` row; `7.0` → `7 (People)`);
  the map may lag a rename. Not installed / no row / name mismatch → the user supplies
  the folder ID.
- **Google account** for every `google-workspace` call: the one in the sources header,
  unless the user overrides.
- **Tool gotchas** (tabbed Docs · folder placement · shortcuts · tables · listing
  pagination) live in checklist §7 "Creation path"; read them before Steps 2, 3 and 8.

## Hard rules

1. **Report-only, absolutely.** Never edit, rename, move, trash or banner an existing
   Doc / Sheet / folder — not the plan Doc, not a role doc, not the Main Tracker, not a
   `_INDEX.md`. The only writes are the two NEW files (report Doc + 行動追蹤表), and only
   after Step 7's confirmation. A fix this skill could do in one call is still written
   as a heal item, not done.
2. **Every finding quotes its evidence** — a title + ID + modifiedTime, a Tracker
   `#N.NN`, or a quoted addendum / role-doc sentence. A finding without evidence is
   deleted before the report is written (pack §9: never invent).
3. **Every heal item has an owner and a route.** 負責人 = the tracker's 負責人 for the
   item it serves, else `待認領`; 建議技能 = a real skill from checklist §5 or `手動`.
   A problem with neither is noise, not a finding.
4. **The tracker is the SOR** (pack §8) — when the plan body and the SOR tab disagree,
   the finding says the DOC is stale (W1), unless the addendum itself says otherwise.
5. **Carry the previous audit forward, don't re-run it.** If the folder already holds a
   `[N.0.1]` report + 行動追蹤表, read the 修復清單 statuses first: items 完成/放棄 are
   not re-raised; open items are carried into the new heal list marked `承前`. A re-run
   in the same cycle also adds ONE W2 heal item: rename the previous pair to
   `[SUPERSEDED YYYY-MM] …` + one-line banner pointing at the new pair (pack §8) —
   proposed, never applied (rule 1).
6. **One LOB, one cycle per run.** "All LOBs" = N runs, each with its own pair of files.
7. **Honesty list.** Anything skipped — deeper sub-folders, Docs audited by title only,
   shortcuts into other LOBs, files that errored — goes into §8 未檢查, never silently.
8. **Nothing is sent, nothing is executed.** No mail, no nudges, no `/zynkr-kms` runs —
   the heal list only names them.

## Workflow

### Step 0 — Resolve cycle + sources

Read `./references/planning-sources.md`. Take `cycle` (`H1` / `H2` / `YE` + year) and
any ID overrides from the user; default to §A. Print one line before anything else:
`Cycle: <H1|H2|YE> <year> · LOB: <N.0 name> · Tracker: <ID> (SOR gid <n>) · Plan Doc:
<ID or 待解析 shortcut> · LOB folder(s): <ID(s) or 待詢問> · account: <email> · date:
YYYY-MM-DD`. If the user's cycle label and the tracker title disagree, stop and ask.

### Step 1 — Resolve the LOB, its folder, plan Doc and tracker rows

- **Folder** — read `~/.claude/skills/admin-governance/references/lob-folder-map.md`
  if it exists (admin-governance's documented install path); match the row by L1
  number per Fixed facts (`5.0` → `5.0 (Product)`, `7.0` → `7 (People)`, `6.0` has no
  row) and take every folder ID on it. Not installed, no row, or the returned folder
  name does not match the LOB (pack §2: 5.0 was re-scoped) → ask for the folder ID; do
  not search Drive by name and assume. Several folders on one row → inventory each;
  the **target folder** for the two new files is the first folder on the row (the `[N]`
  parent) unless the user names another.
- **Plan Doc** — sources §A per-LOB row; 6.0 → `get_drive_file_permissions` on the
  shortcut → `shortcutDetails.targetId`. `inspect_doc_structure` reveals tabs; note the
  TITLE of the tab holding the plan body (`get_doc_as_markdown` has no `tab_id` — it
  returns every tab, each under a top-level heading).
- **Tracker rows** — `read_sheet_values` on the SOR tab (`<cycle> 專案項目`, columns per
  pack §6); keep only the block under this LOB's L1 header row. Normalise before
  reasoning: trim 狀態 onto the four exact strings (anything else → flagged, counted as
  未開始), Priority → P0–P3, `YYYY-MM-DD` placeholders → missing. Record 負責人 per
  item — this is the roster the heal list uses.
- **Prior audit** — note any `[N.0.1]` report / 行動追蹤表 seen in Step 2 for hard rule 5.

### Step 2 — Inventory the folder

`list_drive_items(folder_id, page_size=100)` on each LOB folder, then on each direct
sub-folder (one level); when a response carries `nextPageToken`, call again with
`page_token` until it is empty — a listing that stopped early is a 未檢查 line
(「<folder> 第 n 頁後未列」). Build the inventory record per checklist §2: id · name ·
mimeType · modifiedTime · parent · parsed prefix (`[N.x]` / `[SUPERSEDED …]` /
`[Archive]` / `[@]`) · role-doc flag · shortcut target. Print the count line
(`<n> items · <n> Docs · <n> Sheets · <n> sub-folders listed · <n> deeper folders
skipped`) — the skipped ones are the first 未檢查 lines.

### Step 3 — Read the plan Doc addendum + body

`get_doc_as_markdown` (no `tab_id` — every tab comes back, each under a top-level
heading; read under the tab title noted in Step 1). From the top-most Refresh addendum
(pack §8 heading) take: what changed · open decisions · the P0 list with owners ·
management fixes. From the body take: every Doc / Sheet / SOP it names or links, every tool /
channel / system / cadence it commits to, every owner it names, and every `待定` /
`NEEDS PETER` / `待決` marker. No addendum at all → record the coverage smell
(checklist §3) and route to `planning-suite-reconciler`; continue on the body.

### Step 4 — Read the role docs and SOPs the plan touches

Open (read-only, `get_doc_as_markdown`) every Doc the plan/addendum names, every
inventory item flagged role-doc, and any Doc a tracker 備註 links — capped at what fits;
list the rest under 未檢查. For each, note the sentences that name a tool, owner, KPI,
channel or cadence, plus the Doc's modifiedTime, so G2 findings can quote both sides.
Read for content only where G2/G3/G4 need it; everything else stays title-only. Also
open (read-only) the GM Knowledge Directory (sources §A) once and keep its rows for this
LOB — that is what lets G4 say which of two look-alike Docs the directory treats as live.

### Step 5 — Cross-check the five gap classes

Run checklist §3 in order and write each finding in the exact line format:

- **G1** — each P0/P1 tracker row: is there a doctrine/SOP Doc (inventory title or
  addendum link) OR an owner-named plan paragraph? Neither → G1, quoting `#N.NN`.
- **G2** — each role-doc / SOP sentence vs the plan/addendum: retired tool, departed
  owner (an owner absent from the tracker roster), dropped KPI, changed cadence → G2,
  quoting both sentences.
- **G3** — each Doc the plan cites vs the inventory (title match, then link ID) → miss
  = G3, listing the titles searched.
- **G4** — pairs of Docs claiming the same role, or older versions without the
  `[SUPERSEDED YYYY-MM]` prefix / banner → G4, naming which one is live per the plan
  or the GM Knowledge Directory.
- **G5** — every founder-only decision marker, deduplicated across plan, addendum,
  role docs and tracker 備註 → G5 with what it gates and any stated deadline.

Also compute the LOB smells (no addendum · zero P0/P1 rows · no `[N.x]` structure) and
count findings per class.

### Step 6 — Build the heal list in waves

Turn findings into heal items per checklist §4: W1 SOR sync → W2 banners & filing → W3
build missing doctrine → W4 rewrites. Fill every field: 波次 · 缺口 · 發現 · 修復動作
(one imperative sentence) · Tracker # · 負責人 (tracker 負責人 or 待認領) · 可交 Claude
(✓ only when the fix is mechanical from a readable source) · 建議技能 (checklist §5, or
`手動`) · 狀態 = 未開始 · 備註. G5 items become 待決事項 rows, not heal items. Prior-audit
open items enter with `承前` in 備註; a same-cycle re-run adds the W2 "banner the
previous `[N.0.1]` pair as `[SUPERSEDED YYYY-MM]`" item (hard rule 5, 可交 Claude ✓).
Pick the 最嚴重缺口 (3–5): the ones that block a P0 or leave a P0 running from memory.

### Step 7 — Print the audit and get ONE confirmation

Print, in this order, and wait for one "go" (or "只要摘要" to stop here):

1. The summary line (counts per G-id · per wave · decisions · 承前).
2. 最嚴重缺口.
3. The full heal list as a grid, then 待決事項, then 未檢查.
4. The two titles the files will take and the target folder ID (Step 1 rule).

Edits change the list; re-print only the changed rows. No confirmation → the audit ends
in the chat and nothing is written.

### Step 8 — Write the report Doc and the 行動追蹤表

Report Doc — write the eight sections of checklist §6 to a local `.md` (`#` title,
`##` per section, bullets, no tables) → `import_to_google_doc(file_name="[N.0.1] <LOB
name> — <cycle> Gap Audit & Heal Plan（YYYY-MM-DD）", file_path=<the .md>,
folder_id=<target folder id>)` — it lands in the folder directly and Drive converts
`#`/`##` to HEADING_1/HEADING_2. Alternative only if the import errors: `create_doc`
(plain text, lands in My Drive root) + `batch_update_doc` `update_paragraph_style`
HEADING_1/HEADING_2 on the nine title lines → `update_drive_file(file_id,
add_parents=<target folder id>, remove_parents="root")`. Read it back once; confirm the
eight headings and that 待決事項 is §7.

行動追蹤表 — `create_spreadsheet(title="[N.0.1] <LOB name> Gap Heal — 行動追蹤表
（YYYY-MM-DD）", sheet_names=["README","修復清單","待決事項"])` → `modify_sheet_values`
per tab (checklist §7 columns; 修復清單 rows in wave order, 狀態 = 未開始) →
`resize_sheet_dimensions(sheet_name="修復清單", frozen_row_count=1)` →
`manage_conditional_formatting` with the four 狀態 rules on `修復清單!A2:K1000` and the
已定案 rule on 待決事項 → `format_sheet_range` header bold `#F3F3F3` →
`update_drive_file(file_id, add_parents=<target folder id>, remove_parents="root")`
(`create_spreadsheet` takes no folder — it lands in My Drive root). Read the row counts
back and compare with Step 7.

Any API error → record it in the close-out; do not retry blind, do not "fix" by deleting.

### Step 9 — Close-out

Print checklist §9: what was written (titles + URLs + folder), the GM Knowledge Directory
entry suggestion (checklist §8 — text only), the did-not list (no existing Doc edited ·
no fix executed · tracker untouched · no `_INDEX.md` · nothing sent), 承前 count, and
未檢查. Then stop — the team executes from the 行動追蹤表.

## Outputs

- **Report Doc** 「[N.0.1] <LOB> — <cycle> Gap Audit & Heal Plan（YYYY-MM-DD）」 in the
  LOB folder: §1 摘要 · §2 審核範圍與方法 · §3 最嚴重缺口 · §4 逐項發現（G1–G5）· §5
  修復清單（依波次 W1–W4）· §6 追蹤表與知識目錄 · §7 待決事項 · §8 未檢查.
- **行動追蹤表** 「[N.0.1] <LOB> Gap Heal — 行動追蹤表（YYYY-MM-DD）」 in the LOB
  folder: `README` · `修復清單` (# · 波次 · 缺口 · 發現 · 修復動作 · Tracker # · 負責人 ·
  可交 Claude · 建議技能 · 狀態 · 備註, conditional colours on 狀態) · `待決事項`.
- In the chat: the Step 7 audit grid, the GM Knowledge Directory entry suggestion, and
  the Step 9 close-out with URLs, did-not list and 未檢查.

## Reference files

- `./references/planning-knowledge-pack.md` — shared pack: vocabulary, L1/L2 names,
  priority + 狀態 strings, tracker layout, §8 versioning convention, §9 never-do list.
  Byte-identical across the `planning-*` family; do not edit here.
- `./references/planning-sources.md` — shared sources: every live Drive/Docs/Sheets ID
  and gid, including the Ops exemplar pair. Byte-identical across the family.
- `./references/gap-audit-checklist.md` — this skill's own: input resolution, inventory
  record, G1–G5 contract, waves + 可交 Claude rule, owning-skill routing, report Doc
  skeleton, 行動追蹤表 layout + colours, GM directory entry text, close-out shape.

## Limitations

- One LOB per run and one level of folder recursion; deeper trees and Docs opened only
  by title are listed under 未檢查, not silently skipped.
- G2 contradiction detection is heuristic — it compares named tools / owners / KPIs /
  cadences; a subtler policy conflict needs a human read of the two docs.
- G4 relies on titles and the plan's own references to decide which of two look-alike
  Docs is live; when neither source says, it reports the pair as a decision (G5), not a
  verdict.
- Proposes only — the heal list is executed by the team (or the named skill), and the
  行動追蹤表 is the progress SOT; nothing here reports execution or trend.
- The folder map is admin-governance's file at its install path; not installed, no row,
  or stale → the audit is only as complete as the folder ID the user gives.