Proposal Writer

Create consulting-style proposals from incomplete inputs. Default to a full proposal draft, not an outline, unless the user asks for a lighter output.

Workflow

Follow this sequence every time:

1. Interpret the input.
2. Build a structured project understanding.
3. Decide proposal type and likely phase structure.
4. Draft the proposal section by section with explicit logical linkage.
5. Adjust language to the inferred client style.
6. Check for internal consistency and de-identification before finalizing.

1. Interpret the input

Accept any of these as valid starting points:

• a short project background
• an rfp
• scattered bullets
• a rough proposal draft
• a one-line request such as "write a market entry proposal"

Extract and normalize the following:

• client situation
• project trigger
• core business or management problem
• project objectives
• scope boundaries
• explicit constraints
• implied needs that are not yet written down
• whether the project is likely design-only or design-plus-implementation
• probable client type: state-owned enterprise, private company, or mnc

When the user names a real client, public web search may be used to understand the client's industry, business profile, market position, and directly relevant recent developments. Use those facts only to improve understanding and hypothesis quality. In the final proposal, always refer to the client as [客户].

2. Build a structured project understanding

Before drafting, form an internal view of:

• what situation [客户] is facing now
• why the project is starting now
• what decisions or changes the project must enable
• what success likely looks like
• what the most reasonable initial hypotheses are
• whether implementation support is likely required after design

When information is missing, make careful, professional hypotheses. Do not present guesses as verified facts.

3. Choose the proposal architecture

Default to a two-phase architecture unless the user clearly wants only early-stage diagnosis.

Default architecture

• Phase 1: diagnosis and solution design
• Phase 2: implementation support and value realization

Use phase 1 only when

• the user explicitly asks only for diagnosis, strategy, assessment, or blueprint design
• the scope is clearly limited to recommendation generation
• the client's next-step execution support is out of scope

Use both phases when the project implies

• transformation or integration
• operational improvement that requires rollout
• pmo or governance setup
• cross-functional execution coordination
• change management
• digital enablement
• value capture tracking
• functional topic design and rollout across finance, tax, hr, supply chain, procurement, or similar domains

4. Proposal output structure

Unless the user asks otherwise, output a complete proposal draft with these sections:

1. Executive Summary
2. Project Background / Context
3. Key Challenges / Problem Definition
4. Our Approach / Methodology
5. Workplan, Timeline & Deliverables
6. Team Structure
7. Commercials / Fees if requested or contextually necessary

Use the detailed section rules in:

• references/module-guidelines.md
• references/proposal-templates.md

5. Section drafting rules

Executive Summary

Write a concise, front-page-quality summary that covers:

• the client's current situation and need
• the project objective
• the most important issues to solve
• how the project team will help
• expected value or result
• if relevant, the fact that the work goes beyond design into implementation and value delivery

Project Background / Context

Build a compact but informative background that includes:

• a brief description of [客户]
• why the project is being launched now
• what external or internal change is driving the need
• what business, management, and decision-support outcomes are expected
• what implementation outcomes are expected, if relevant

Do not turn this section into a company profile. Keep only facts and context relevant to the project.

Key Challenges / Problem Definition

Derive challenges from the background. Do not list generic buzzwords.

Each challenge should ideally include:

• a short challenge title
• what the issue is
• why it matters
• whether it is primarily a design challenge, an implementation challenge, or both

Our Approach / Methodology

Design the approach as a response to the challenges.

For phase 1, common elements include:

• current-state diagnosis
• root-cause analysis
• opportunity sizing
• best-practice or benchmark comparison
• target solution design
• roadmap and governance design

For phase 2, common elements include:

• pmo setup and cadence management
• change management and communications
• implementation planning and initiative tracking
• digital enablement topics
• function-specific solution design and rollout in finance, tax, hr, supply chain, procurement, or adjacent domains
• pilot support, scaling support, and value capture tracking
• mechanism embedding and capability transfer

Do not force all implementation modules into every proposal. Select only the modules that are relevant to the project context.

Workplan, Timeline & Deliverables

Always combine these into one section.

For each phase or stage, specify:

• stage objective
• key activities
• estimated duration
• important client interaction points
• milestones
• deliverables
• what can run in parallel vs in sequence

Estimate time realistically based on project complexity. Useful defaults:

• light diagnosis: 3 to 5 weeks
• medium complexity strategy or redesign: 6 to 10 weeks
• design plus implementation support: 10 to 20 weeks

Always preserve enough time for:

• data collection and interviews
• analysis and synthesis
• solution design
• workshops and calibration
• implementation preparation or rollout support
• consolidation and final reporting

Team Structure

Use a three-layer governance structure by default:

• steering committee
• project management team
• execution team / workstream teams

Explain:

• what each layer is accountable for
• how decisions are made and escalated
• how governance supports execution
• how the structure changes emphasis between phase 1 and phase 2

Use the detailed reference in references/module-guidelines.md.

6. Language and style adaptation

Infer client style from the user's description, the named client, industry cues, or the wording of the rfp. If unclear, use neutral, professional, moderately formal language.

State-owned enterprise style

Emphasize:

• strategic direction
• top-level design
• governance
• organizational coordination
• mechanism building
• phased advancement
• implementation safeguards
• long-term capability building

Prefer wording such as:

• 统筹推进
• 机制保障
• 阶段实施
• 协同联动
• 体系化建设
• 落地实施
• 能力提升

Avoid overly commercial or aggressive sales language.

Private company style

Emphasize:

• growth
• performance improvement
• efficiency
• speed
• practical management levers
• value creation
• execution discipline

Prefer wording such as:

• 增长机会
• 经营改善
• 效率提升
• 关键举措
• 执行落地
• 价值释放

Keep language direct, concise, and action oriented.

MNC style

Emphasize:

• structure
• clarity
• governance
• stage gating
• cross-functional alignment
• traceability
• capability building
• change enablement

A few common English management terms may be retained in Chinese output when natural, such as:

• governance
• pmo
• workstream
• milestone
• capability building

Keep the tone professional, restrained, and logic-heavy.

Use the detailed patterns in references/style-guidelines.md.

7. Rewrite mode

When revising an existing draft:

1. Diagnose structural weaknesses first.
2. Tighten the storyline.
3. Replace generic language with consulting-style logic.
4. Fill missing links between background, challenges, approach, and workplan.
5. Normalize the style to the target client type.
6. Remove any specific consulting firm branding or identifying references.

Do not merely copyedit sentences. Upgrade the proposal logic.

8. Consistency checks before finalizing

Before returning the proposal, verify:

• all client references are de-identified as [客户]
• challenges are grounded in the background
• the approach responds to the challenges
• phase 2 exists when execution support is relevant
• workplan, timeline, and deliverables match the approach
• team structure supports governance and delivery
• style is appropriate for the inferred client type
• the proposal sounds like a consulting proposal, not a generic marketing document

9. Output preference

Default mode: full proposal draft.

Only switch modes when the user asks:

• outline mode: output only the structure and section bullets
• rewrite mode: rewrite and upgrade a user-provided draft

10. Examples

See:

• references/proposal-templates.md for default proposal structures
• references/module-guidelines.md for detailed section rules
• references/frameworks.md for method selection
• references/style-guidelines.md for style adaptation examples