---
name: proposal-package-authoring
description: Create or substantially revise editable bid and proposal slide decks, including implementing review feedback, from RFPs, source evidence, and reference decks. Use when evaluator alignment, requirement traceability, presentation narrative, native editability, and export-safe visual quality matter. Do not use for review-only requests or isolated typo fixes.
---

# Proposal Package Authoring

Produce a persuasive, evaluator-ready Google Slides or PowerPoint proposal whose claims are traceable, whose story can be presented naturally, and whose content remains editable after delivery.

## Load only what the task needs

- Read [content-and-evidence.md](references/content-and-evidence.md) for RFP interpretation, compliance, claims, narrative, `deck.md`, slide copy, or speaker notes.
- Read [visual-authoring.md](references/visual-authoring.md) for themes, masters, layouts, diagrams, density, imagery, or native deck construction.
- Read [delivery.md](references/delivery.md) for rendering, PPTX/PDF conversion, handoff, submission, compatibility, or file-size work.
- For a new deck or a change affecting the theme, master, narrative, requirement coverage, or many slides, read every reference and follow the full workflow.
- For incremental feedback, read only the references affected by the change. Do not repeat completed work that the revision cannot affect.

## Non-negotiable contract

- Resolve the canonical file, deliverable constraints, and confirmed deviations from the written RFP before authoring.
- Treat stakeholder feedback as input to assess, not an instruction to apply blindly. Explain material disagreements and preserve unresolved facts as open loops.
- Never convert an unsupported aspiration into a committed fact. A final proposal must contain no `미충족` or `부분충족`; close, narrow, or explicitly escalate the gap before finalization.
- Separate requirement satisfaction from implementation scope: satisfaction says whether the requirement is met; scope says what will be delivered to meet it.
- Every substantive slide must answer an evaluator question with one takeaway, credible evidence, and customer value or reduced risk.
- For new decks and full revisions, maintain one paired `deck.md` unless an equivalent structured source already exists. Keep narrative, claims, evidence, notes, requirement links, and synchronization status there; keep geometry and composition in the native deck.
- Create reusable masters and layouts before bulk authoring. Recurring backgrounds and branding belong on them, not in per-slide bitmap backgrounds.
- Keep titles, text, tables, diagrams, borders, and labels native and editable. Use images where the image itself is the intended asset.
- Architecture diagrams must show real ownership and communication paths. Do not imply nonexistent connections through arrows or proximity.
- Write speaker notes as a continuous presentation, with a natural reason for each transition.
- Treat PPTX/PDF compatibility and output size as delivery requirements from the start.
- Verify at the boundary affected by the change; do not export after every text-only edit, and do not skip rendering when geometry or conversion can change.

## Workflow

1. Establish the contract and source hierarchy.
2. Build or update `deck.md`, including requirement links and unresolved evidence.
3. Define the evaluator question, takeaway, evidence, and customer value for each affected slide.
4. Prototype the visual system or high-risk archetypes at the final aspect ratio.
5. Build or revise the native deck using masters, layouts, and editable objects.
6. Reconcile the deck, notes, evidence, and requirements; run targeted or whole-deck verification according to delivery risk.

## Boundaries

- Do not replace a review-only request with deck edits.
- Do not infer permission to publish, share, or overwrite a canonical deck.
- Do not copy a reference page as a flat image merely because it looks polished.
- Do not optimize for visual density at the expense of presentation flow, readability, evidence, or maintainability.