git:20260817.f8cf74d to git:20260918.2429d96

---

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.