Bidding Doc Domain

Problem

Bidding documents usually fail not because prose is weak, but because required sections are missing, project data is inconsistent, bid prices do not match between tables, and disqualification risks are not checked item by item. Bidding Doc Domain captures these constraints as a domain reference: task lists, dependency topology, section requirements, risk checkpoints, and exemplar indexes.

How It Works

The skill is a domain payload for Universal Task OS rather than an execution engine. It supplies three inputs: bidding-catalog for task types and dependencies, bidding-requirements for required components and format rules, and exemplars for reusable samples when available. The default chain is B1 tender parsing → B2 commercial bid → B3 technical bid → B4 price bid → B5 disqualification risk control → B6 global validation. Key constraints include:
- Ask for missing core data: project name, bidder name, total price, delivery/service period, and warranty period.
- Price consistency: Chinese and Arabic numerals must match; line items must sum to totals; tables must cross-check.
- Deviation handling: negative deviations must be flagged; critical parameters cannot be negatively deviated.
- Global consistency: project name, ID, price, and duration must be synchronized.

Boundaries

Without universal-task-os, the skill is read-only for references, requirements, and exemplar indexes, and must not produce bids or run risk checks. Many exemplars are marked [pending], so users must de-identify and register them before sample-based use. Content must come from tender documents and user-provided facts; do not fabricate performance records, prices, qualifications, or deviations.