Skill: write-tech-proposal

Metadata

• Trigger keywords: 写技术方案、写方案、写标书、技术方案、生成技术方案、写投标文件、投标响应、方案编写、招标文件应答
• Prerequisites: Tender documents (scoring table + procurement requirements), project information confirmed by the user
• Output: Plain-text docx (<project_short_name>_技术方案_v1_纯文字.docx) -> Evaluator review -> Revision -> Trigger generate-charts
• Rule set: See hierarchical loading table below

Core Prohibitions

• Do NOT discuss images -- do not preset image count, do not calculate image targets
• Do NOT generate images, take screenshots, or insert images -- all handled by generate-charts
• Only output plain-text semi-finished product -- docx contains no images

Pipeline Position

• Entry state: idle
• Exit state: content_confirmed (after evaluator review + revision)
• New node: evaluator_review (automatic evaluator review, replacing the original manual review hard gate)
• State file: temp/pipeline_state.json

Hierarchical Rule Loading

Layer 1: Core Must-Read (read before every proposal writing session)

1. references/01-core/proposal-essence.md -- The foundation determining "what to write"
2. references/01-core/section-decision-rules.md -- 8 fixed sections + on-demand additions + title rules
3. ../_shared/references/wording-redlines.md -- One-veto rules

Layer 2: Load by Step

• Step 0: references/02-by-step/pre-writing-checklist.md -- Core pre-writing rules + historical issue checklist
• Step 1: references/02-by-step/general-writing-rules.md
• Step 3: references/02-by-step/after-sales-rules.md
• Step 3: references/02-by-step/implementation-plan-rules.md -- Core section specific methodology
• Step 3 (when value-added service scoring items exist): references/02-by-step/value-added-service-rules.md
• Step 4: references/02-by-step/evaluator-rules.md -- Evaluator review mechanism

Layer 3: Special Scenario Trigger

• Zero-experience domain: references/03-conditional/zero-experience-domain-writing.md (Trigger condition: the user says "never done before/new domain/no reference/no digestion/no knowledge base/first time/new business/never bid"; OR AI Step 1 auto-detection: no reference cases + no technical parameters + no domain-specific rules -> all three empty -> notify the user for confirmation -> load)

Execution Steps

Step 0: Start-up Check

1. Create folder: outputs/<sequence_no>_<project_short_name>/temp/
2. Initialize temp/pipeline_state.json (state = idle) -- must also generate rule_snapshot (record current mtime hash for 5 core rule files):
   - references/01-core/proposal-essence.md
   - references/01-core/section-decision-rules.md
   - ../_shared/references/wording-redlines.md
   - skills/write-tech-proposal/SKILL.md
   - references/02-by-step/evaluator-rules.md
   - Hashing method: python -c "import os,hashlib; print(hashlib.md5(str(os.path.getmtime('file_path')).encode()).hexdigest()[:8])"
3. Read 3 core must-read files + pre-writing-checklist.md
4. Confirm basic project information (project name/budget/business line type)

Step 1: Thorough Tender Document Analysis + Web Verification

1. Interpret the tender document (core pre-rules implementation):
   - Break down each procurement requirement, understand the real problem the client wants to solve behind each item
   - Traverse procurement requirements, auto-classify proposal-type items ("XX方案"): combine semantics and context -> needs proposal writing / commitment letter with seal only / ambiguous context auto-judgment -> execute directly, write into bid-analysis.md「2.5 Auto-judgment of Proposal Items in Procurement Requirements」
   - Decompose scoring rules (if any), tag each scoring item to corresponding section
   - Output temp/bid-analysis.md (following assets/bid-analysis-template.md format)
2. WebSearch parallel search for similar project cases, industry standards, university information
3. Read general-writing-rules.md
4. Domain status auto-determination (new):
   - Search ../../knowledge/reference-cases/project-index.md -> project with same business line exists? (yes/no)
   - Search ../../knowledge/tech-param-indices/ -> technical parameters for this domain exist? (yes/no)
   - Search references/ -> domain-specific rules for this domain exist? (yes/no)
   - All three empty AND the user has not verbally triggered this rule -> append domain_status: "uncharted" in execution_intent.md -> Notify the user: "This project is in a zero-experience domain (no reference cases/no technical parameters/no domain-specific rules). It is recommended to load the Zero-Experience Domain Writing methodology. Confirm?" -> After user confirmation, load zero-experience-domain-writing.md, subsequent steps follow enhanced execution under that rule
   - All three empty BUT the user has already verbally triggered and confirmed -> skip notification, execute directly under zero-experience rules. Append domain_status: "uncharted" in execution_intent.md
   - Not all three empty -> normal flow. Append domain_status: "known" -> load domain knowledge files under ../../knowledge/tech-param-indices/ for that business line as reference (if exists)
5. Determine emergency plan: Procurement requirements/scoring rules explicitly require -> must write; otherwise, judge project characteristics based on search results -> propose to the user for confirmation
6. Zero-experience domain specific output (only when domain_status == "uncharted"):
   - Output temp/domain_research.md (three-dimensional decoding: technical/compliance/commercial dimensions, format per zero-experience-domain-writing.md Layer 3)
   - Output temp/competitor_analysis.md (>= 3 competitor proposal analyses, format same as above)
7. Output temp/execution_intent.md (with domain_status + capability_matrix reference)
8. Update pipeline_state.json -> intent_draft
9. Confirmation node: User confirms execution intent -> intent_confirmed (confirmation node classification per ../_shared/references/behavior-rules.md Section 10)

Step 2: Structure Design

1. Read section-decision-rules.md (including「2.5 Scoring Rule Driven H2/H3 Hierarchy Decision」)
2. Determine section list:
   - 8 fixed sections -> H2 title customizable (business line + section nature), but must correspond to scoring major item names
   - Scoring major items -> must be independent H2; scoring sub-items -> must be independent H3, no merging
   - Procurement requirement proposal items (auto-judgment results) -> those needing writing included in section list, commitment letters skipped
   - On-demand additions (scoring rules requirement/emergency plan)
3. Section naming = project business line + section nature; titles align with scoring items/procurement requirement keywords
4. All H2/H3 titles must not contain punctuation marks
5. Output structure outline
6. Update pipeline_state.json -> structure_designed
7. Confirmation node: User confirms structure -> structure_confirmed (confirmation node classification per ../_shared/references/behavior-rules.md Section 10)
   - Auto-pass: Routine projects, no structural anomalies -> AI proceeds independently, report after completion

Step 3: Body Writing - Core Step

1. Fill each section with four questions (purpose -> problem -> response -> implementation)
2. Pass four-layer safety boundary for each paragraph
3. After-sales per specialized rules (>= 15 paragraphs, four-level titles)
4. "We/us" diversified usage check
5. Sentence structure anti-mechanization (five opening types alternating, no two consecutive paragraphs starting with same pattern)
6. Write to temp/project_config.json (_charts field as empty object)
7. Handover validation (new): python scripts/validate_project_config.py <temp>/project_config.json --stage text-only -> if failed, fix and re-validate, must not skip
8. python ../_shared/scripts/shared_wps_gen.py <temp>/wps_config.json
9. Output plain-text docx
10. Step 3 mandatory self-check printout (printing = mandatory execution. Print each item's result, blank = incomplete = cannot enter Step 4):

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Step 3 Writing Completion Self-Check - ALL must pass before Step 4
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Content Depth]
  [ ] After-sales section paragraphs: ___ (>=15 qualified / FAILED, need ___ more)
  [ ] Value-added service items: ___, paragraphs per item: ___/___/___ (>=3 paragraphs/item qualified / FAILED)
  [ ] Every section except section 1 reaches H4 level (yes / FAILED sections: ___)

[Safety Boundaries]
  [ ] Full text search for "no/lack/insufficient" -> (none / WARNING: __ locations, cleaned)
  [ ] Full text search for fabricated project experience numbers -> (none / WARNING: cleaned)
  [ ] Every paragraph passes four-layer safety boundary (passed per paragraph / FAILED: only precheck not per-paragraph)

[Syntax]
  [ ] "We/us" at start of 3 consecutive paragraphs -> (none / WARNING: __ locations, adjusted)
  [ ] Five opening type distribution: scene___/problem___/data___/comparison___/effect___
      (Missing types: [list], suggest adding)

[Scoring Sub-item Coverage] 
  [ ] Scoring major items: ___ -> H2 count: ___ -> mapping match: ___/___ ; missing H2: ___
  [ ] Scoring sub-items: ___ -> H3 count: ___ (independent, no merging) -> mapping match: ___/___
      Missing or merged H3: ___
  [ ] Procurement requirement proposal items: total ___, need to write ___, already in H2/H3, commitment letter skip ___
  [ ] All H2/H3 titles with punctuation: ___ locations -> cleaned/not cleaned

[Zero-experience Specific] Only print when domain_status="uncharted":
  [ ] Three evidence types covered: capability statements ___ / adjacent experience ___ / method deduction ___
      (Missing types: [list])
  [ ] Micro-stories embedded: actual ___ (>=3 qualified / FAILED, need ___ more)
  [ ] Full text no self-deprecation + no fabricated experience (confirmed / FAILED)

[Output]
  [ ] JSON schema validation: all content string? children nested correctly? _charts empty?
      (Passed / FAILED: need fix)
  [ ] precheck result: wording redlines ___ / company name ___ / banned words ___ (all 0 = passed / FAILED: residual)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  All passed -> update pipeline_state.json -> content_written
  Any failed -> fix and re-print until all pass
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

11. Update pipeline_state.json -> content_written

Step 4: Evaluator Automatic Review

4.0 Pre-check: python-docx availability (new)

After content_written, before triggering the evaluator, must verify python-docx availability:

python -c "from docx import Document; print('OK')"

• Returns OK -> proceed with evaluator trigger
• Returns error or ImportError -> Abort flow, notify the user: "python-docx is not installed, evaluator dimension 7 format review cannot execute. Suggestion: run pip install python-docx then continue." This check must not be skipped.

4.1 Trigger Evaluator Sub-agent

Auto-trigger after content_written. Load as sub-agent: references/02-by-step/evaluator-rules.md + temp/bid-analysis.md (must load complete file, including Section 3 scoring rule breakdown + Section 4.3 scoring sub-item to H3 mapping) + temp/project_config.json, and use python-docx to read the actual generated .docx file, produce structured review report. The evaluator must first execute dimension 0 (scoring sub-item mapping completeness check) -> if failed, abort review; then execute dimension 7 (format review) -> if failed, abort review; then execute dimensions 1-6. Only after all pass can proceed to main agent handling feedback.

4.2 Main Agent Processing Review Feedback

After the evaluator sub-agent returns the report, the main agent processes each "needs revision" item item by item, routing per the following rules:

Each needs-revision item -> filter through four-layer safety boundary
    |
    +-- Safe to expand (all four questions green)
    |   -> Auto-modify content, update docx
    |
    +-- Boundary constrained (any four questions red)
    |   -> Do not modify, retain original writing
    |   -> Record skip reason in pipeline_state.json
    |
    +-- "Clearly inappropriate"
        -> Escalate to the user for decision
        -> Record in evaluator.escalated + escalation_reason

Four-question filter (for each in-depth supplement suggestion from the evaluator, first pass through these four questions):
1. Is this supplement a process description or a result commitment?
2. After supplementing, will there be evidence the client can discover?
3. Do the supplemented numbers represent time frequency or deliverable counts?
4. Is the supplemented content within our capability boundary?

"Clearly inappropriate" judgment criteria (any of the following triggers escalation to the user):
- Evaluator suggests supplementing specific headcount/equipment models (boundary 3+4 conflict)
- Evaluator suggests supplementing commitments beyond our product capabilities (boundary 4 conflict)
- Evaluator suggestion conflicts with wording redlines (e.g., suggesting "ensure/guarantee" wording)
- In baseline mode, the evaluator tags many "insufficient information" items with no actionable suggestions
- Evaluator suggestion direction conflicts with known constraints from the delivery department

4.3 Post-completion Actions

• Update pipeline_state.json -> content_confirmed
• Update evaluator field (total_issues / auto_fixed / escalated / escalation_reason)
• Domain knowledge write-back (new): If domain_status == "uncharted" -> execute Layer 8 of zero-experience-domain-writing.md "Domain Knowledge Write-back" -- write domain knowledge/proposal key points/parameter templates/project records to ../../knowledge/tech-param-indices/<business_line>/, and update ../../knowledge/reference-cases/project-index.md. Notify the user after write-back completes.
• If there are escalated items -> first report evaluator review results and escalated items to the user, then trigger generate-charts after user confirmation
• If no escalated items -> immediately auto-call generate-charts Skill (use Skill tool, skill="generate-charts", args include project path and section list). Do not wait for the user to say "continue" or "generate images" -- this step is pipeline auto-flow, not manual trigger.

Handover File Format

Output: project_config.json

JSON Schema definition at assets/project-config-schema.md. Key rules:
- _charts field must be empty object {}
- sections is nested structure

Output: execution_intent.md

Project understanding + success criteria + strategy + risks + reference sources

Output: bid-analysis.md

Following assets/bid-analysis-template.md format, as evaluator review input

Self-Check List

• [ ] All 8 fixed sections covered
• [ ] Every section except section 1 reaches H4 level
• [ ] Zero wording redline violations
• [ ] No company names (only use "we/us/our")
• [ ] No AI-trace language
• [ ] After-sales independent H2, >= 15 paragraphs
• [ ] No image-related content anywhere
• [ ] _charts field is empty object
• [ ] Plain-text docx produced
• [ ] "We/us" usage diversified (no 3 consecutive paragraphs starting with "we/us")
• [ ] bid-analysis.md produced

Common Errors