Rfp Gates

rfp-gates

Step 4 of the RFP Agent Swarm. Orchestrates three NON-NEGOTIABLE human approval gates — Security Completeness, Legal Review, and Pricing Approval — before an RFP response package is allowed to progress to assembly and final submit.

This skill does NOT make approval decisions. It prepares evidence, dispatches Teams adaptive-card approval requests to named approvers, tracks responses, and aggregates a blocking go/no-go verdict. The pipeline remains paused until all three gates return Approved. Any rejection routes back to the originating team with a structured reason and is logged to the audit trail.

When to use this skill

Invoke rfp-gates after rfp-respond has produced a tiered responses.json and rfp-review has attached human-reviewed flags to legal responses. Invoke it before rfp-assemble runs.

Triggers

• "run quality gates"
• "security gate check"
• "legal review gate"
• "pricing approval gate"
• "QA this RFP response"
• "gate sign-off"
• "send for gate approval"
• "run RFP compliance check"
• "send approvals for this bid"
• "gate this response package"

Do NOT use for

• Drafting answers — that is rfp-respond.
• Line-level editing of a specific legal clause — that is legal-redliner.
• Producing the final PDF — that is rfp-assemble.
• Deciding whether to bid at all — that is rfp-fit-assessment.
• Populating the answer bank with approved content — that is rfp-answer-bank.
• Internal narrative Q&A about pricing strategy — that is a deal-room task.

Design principles applied here

Built-In Skills Used

Inputs, outputs, and file contract

Inputs

Outputs

Sequence diagram (parallel approvals, single blocking aggregator)

  rfp-respond -> responses.json
       |
       v
 +-------------+
 | run_gates   |  automated prechecks (security, legal, pricing)
 +-------------+
       | gate_precheck.json
       v
 +---------------------+---------------------+---------------------+
 |                     |                     |                     |
 v                     v                     v                     v
 send_gate_approval    send_gate_approval    send_gate_approval
 (security)            (legal)               (pricing)
 -> Security Lead      -> Legal Counsel      -> Account Exec
 (Teams card)          (Teams card)          (Teams card)
 |                     |                     |
 v                     v                     v
 Approved / Rejected   Approved / Rejected   Approved / Rejected
 +---------------------+---------------------+
                       |
                       v
               gate_status_tracker
                       |
         +-------------+-------------+
         |                           |
         v                           v
    ALL APPROVED                ANY REJECTED
         |                           |
         v                           v
    rfp-assemble             gate-rejection-notice
                             -> originating team
                             pipeline stays paused

Workflow

1. Run scripts/run_gates.py to produce automated prechecks. Non-zero exit if any auto-fail condition is hit; the gate request is not sent until those blockers are resolved by the originating team.
2. For each of the three gates, run scripts/send_gate_approval.py to build the adaptive-card payload. In production, a Power Automate flow sends the card; locally, the payload is rendered via render-ui.
3. Approvers respond in Teams. Their response (Approved or Rejected with mandatory comment) is written to working/gate_statuses.json.
4. scripts/gate_status_tracker.py aggregates statuses. Verdict is PASS only if all three gates are Approved.
5. On rejection, assets/gate-rejection-notice.md is routed to the team owning the defect (see references/gate-rejection-routing.md).

Usage

# 1. Evidence pack
python scripts/run_gates.py \
  --responses working/responses.json \
  --approved-certs working/approved_certs.json \
  --pricing-inputs working/authorised_pricing_inputs.json \
  --output working/gate_precheck.json

# 2. Build approval cards (one per gate)
python scripts/send_gate_approval.py \
  --gate security --precheck working/gate_precheck.json \
  --approver-email security.lead@example.com \
  --output working/approval_request_security.json

python scripts/send_gate_approval.py \
  --gate legal --precheck working/gate_precheck.json \
  --approver-email legal.counsel@example.com \
  --output working/approval_request_legal.json

python scripts/send_gate_approval.py \
  --gate pricing --precheck working/gate_precheck.json \
  --approver-email account.exec@example.com \
  --output working/approval_request_pricing.json

# 3. After approvers respond, aggregate
python scripts/gate_status_tracker.py \
  --statuses working/gate_statuses.json \
  --output working/gate_verdict.json

Gate definitions

Rejection handling

See references/gate-rejection-routing.md. Summary:

Troubleshooting

Audit and learning loop

Every rejection is captured with:

• gate (security | legal | pricing)
• rejected_by (approver identity)
• reason (free text, mandatory in the card)
• affected_questions (array of question IDs)
• timestamp_utc

This feed is consumed by rfp-answer-bank to prevent the same defect recurring, and by skill-factory to refine the prechecks in run_gates.py.

Audit Log

All gate lifecycle events are written as immutable rows to output/rfp-<rfp_id>/audit-log.xlsx via the Excel built-in skill. Each row is appended — NEVER updated or deleted — so that a rejection followed by a re-submission and subsequent approval appears as three separate events with three distinct timestamps.

Schema and helper:

• audit-log-schema.md — canonical column order, types, and validation rules.
• append_audit.py — append-only writer; refuses to modify existing rows.

Immutability rule: gate events are IMMUTABLE. Rejections are captured as events in their own right; a subsequent approval does NOT overwrite the rejection row. A new event row is written for each re-submission cycle so that the full decision history — including every reversal — is reconstructible from the log alone.

Adaptive Card Dashboard

Rendered via the Adaptive Cards built-in skill. Two surfaces: a live dashboard card that tracks the three gates in one view, and a per-gate approval-request card that carries the Approve/Reject buttons.

Live 3-gate dashboard card

Three status tiles — Security / Legal / Pricing — rendered side-by-side. Each tile shows:

• Approver name (pulled from the gate definition table)
• Status badge: Pending | Approved | Rejected
• Timestamp of the most recent event for that gate

The dashboard refreshes on every new row appended to audit-log.xlsx.

On rejection

The offending tile expands inline to surface:

• The rejection reason (mandatory free-text captured from the approver)
• A list of affected question IDs, each a deep-link routed back to rfp-respond for rework

No other tiles are cleared; approved gates remain Approved. Only the rejected gate must be re-submitted once rework is complete.

On all-approved

A pipeline-resumed card replaces the dashboard, showing:

• All three approver names and their individual decision_timestamp values
• The aggregate PIPELINE_RESUMED timestamp
• An auto-advance CTA button: "Assemble the submission package" (invokes rfp-assemble)

Per-gate approval-request card

Each gate's approval request is itself an Adaptive Card, dispatched via Email or Teams. Every card carries Approve and Reject buttons (Reject is disabled until a reason is entered) plus the gate-specific context pack:

Boundaries

• rfp-gates NEVER signs off on behalf of a human approver.
• rfp-gates NEVER generates pricing, legal positions, or security claims.
• rfp-gates NEVER modifies responses.json; it only reads and evaluates.
• rfp-gates NEVER bypasses a gate for deadline reasons.

Related Skills

RFP chain

rfp-intake → rfp-fit-assessment → rfp-respond → THIS SKILL → rfp-review → rfp-assemble

• THIS SKILL is the non-negotiable checkpoint in the chain. It cannot be bypassed, skipped, or auto-advanced under deadline pressure. There is no --force flag.
• On rejection, control routes back to rfp-respond for ONLY the affected questions (carried by affected_question_ids on the GATE_REJECTED event). Previously approved gates do not need re-approval unless the rework changes their scope.
• On all-approved, the pipeline unlocks rfp-assemble — which will refuse to run until a PIPELINE_RESUMED event is present in the audit log.

Cowork built-ins leveraged

Cross-references

• references/security-completeness-checklist.md
• references/legal-playbook.md
• references/pricing-authorization-rules.md
• references/gate-rejection-routing.md
• scripts/run_gates.py
• scripts/send_gate_approval.py
• scripts/gate_status_tracker.py
• assets/gate-approval-request-template.md
• assets/gate-rejection-notice.md