[enhancement] /idd-plan native support for meeting-issue type — Plan tier currently assumes chain to /idd-implement TDD loop

[kiki830621]

Problem

Source: surfaced during /idd-plan kiki830621/ai_martech_global_scripts#615 tangential observations sweep (Step 2.5). #615 is a meeting issue (deliberation event), not a code-change work item — Plan tier routing required ad-hoc adaptation.

/idd-plan Plan-tier flow assumes:

1. Diagnosis emits Complexity: Plan via Layer P
2. /idd-plan drafts Implementation Plan with Files & Changes section
3. EnterPlanMode → user approves
4. Step 6 chains to /idd-implement for TDD loop execution
5. /idd-update sets phase → planning → implemented after TDD done

This sequence implicitly assumes the deliverable is code changes that follow TDD discipline. For meeting issues (alignment events that produce decisions, not code), the assumption breaks down:

• "Files & Changes" section is misleading — no production code modifies
• "Test Plan" section doesn't apply — meeting decisions are verified by closing summary, not unit tests
• Step 6 chain to /idd-implement → TDD loop is wrong — meeting flow is pre-meeting prep + meeting + post-meeting follow-up
• Approval semantics misalign — Plan approval ≠ meeting decisions approval (those happen DURING the meeting, separate deliberation)

Type

enhancement (skill design)

Concrete usage example (kiki830621/ai_martech_global_scripts#615)

#615 was filed as [meeting] 6-layer ETL 標準修正會議 — 釐清現況 + 決定要改什麼. Diagnosis correctly identified Plan via Layer P (decision-heavy + 5+ ordered agenda items). User invoked /idd-plan #615. The skill required the executing agent to:

1. Manually adapt Plan body schema (replace "Files & Changes" with "Phase A/B/C deliverables")
2. Override Step 6 chain — don't auto-invoke /idd-implement (meeting is user-driven, not TDD)
3. Handle "approval = run Phase A pre-meeting prep + stop" instead of standard "approval = run TDD loop"
4. Explain to user that Plan approval semantically gates meeting agenda, not code merge

Ad-hoc adaptation worked but isn't reproducible — next agent encountering meeting issue would re-derive the adaptation from scratch. Concrete Plan body in #615 demonstrates one workable pattern but isn't documented as canonical.

Expected (post-fix)

Three possible approaches (not mutually exclusive):

Option A: Explicit meeting-issue type

Add meeting to issue type taxonomy alongside bug/feature/refactor/docs. /idd-diagnose for meeting type emits a different Strategy template (Phase A/B/C). /idd-plan detects type=meeting and uses meeting-adapted Plan body schema + skips Step 6 chain to /idd-implement (or chains to a new /idd-meeting skill).

Pros: explicit + discoverable + reproducible
Cons: new type adds taxonomy weight; requires diagnosis updates too

Option B: Configurable post-Plan chain step

/idd-plan Step 6 makes "chain to /idd-implement" configurable via plan-mode metadata. User selects post-approval action: --chain idd-implement (default, TDD) / --chain idd-meeting-prep (pre-meeting prep) / --no-chain (manual continuation).

Pros: flexible without new types
Cons: post-approval ambiguity; user may not know what to chain

Option C: Documentation-only (best practice pattern)

Add references doc references/meeting-issue-adaptation.md documenting:

• When to file as meeting issue (deliberation event with coupled decisions)
• How to draft meeting-adapted Plan body (Phase A/B/C schema)
• Post-approval flow (run Phase A only, defer Phase B to user-driven session, file Phase C work items separately)
• Closing semantics (no /idd-verify TDD pass; closing summary = decision → action mapping)

Pros: lowest implementation cost; lets pattern evolve before formalizing
Cons: relies on agent reading docs at the right moment

Actual

• /idd-plan SKILL.md doesn't mention meeting-issue type
• Plan body schema (Files & Changes / Test Plan / Risks etc.) is code-centric
• Step 6 hardcodes chain to /idd-implement
• No reference for "what to do when Plan tier doesn't need TDD execution"

Impact

• Cognitive cost: agents encountering meeting issues re-derive adaptation each time
• Inconsistency risk: different agents may adapt differently → audit trail divergence
• Discoverability gap: new IDD users don't realize meeting issues are valid use case
• Documentation drift: ad-hoc adaptations in individual issues don't propagate as canonical patterns

Cross-references

• kiki830621/ai_martech_global_scripts#615 — concrete usage example (the meeting issue that surfaced this gap)
• kiki830621/ai_martech_global_scripts#615 comment 4414625044 — adapted Plan body posted during /idd-plan execution as one workable pattern
• kiki830621/ai_martech_global_scripts#608 — broader ETL refactor umbrella; #615 is its meeting-issue companion

Severity rationale

• P3 — meeting issues are uncommon but legitimate use case
• Doesn't block any current workflow — agents can adapt manually as demonstrated in #615
• Would benefit if pattern formalizes (Option C documentation alone helps a lot)
• Option A/B require deeper plugin design changes; defer until pattern proves stable across multiple issues

Recommended next step

Start with Option C (reference doc) as cheapest improvement. Observe more meeting-issue usage. If pattern stabilizes across 3+ instances, consider Option A (explicit type) or Option B (configurable chain).