Back to Resources
AI Automation9 min read
How to Build a Tender Bid Workflow with Claude Code: 7 Steps
A step-by-step build of a reusable bid workflow in Claude Code: folder structure, company facts, bid rules, intake, compliance matrix, drafting, review and preflight.
What you'll build
By the end of this guide you'll have a reusable bid workspace: one folder of company facts and rules, a template for each new bid, and saved procedures that take a tender pack to a reviewed draft ready for human sign-off. It works for government quotations and tenders as well as private RFPs.
It uses the building blocks explained in Claude Code skills, hooks and subagents. If you haven't installed Claude Code yet, start with Terminal basics for Claude Code.
Set aside an afternoon for the first build. Most of that time goes into writing down facts and rules you already know. The code-like parts are short, and Claude writes most of them for you.
Step 1: Set up the folder structure
Create one workspace folder with a shared company folder, a templates folder, and a separate folder for each bid. A layout that works:
•
bids/company/: company profile, UEN and registration details, certifications, insurance, team CVs, approved boilerplate.
• bids/past/: previous bids, especially the ones you won, plus any buyer feedback.
• bids/rules/: your bid rules (Step 3).
• bids/2026-10-agency-xyz/: one folder per bid, with tender/, drafts/ and submit/ inside.
Start Claude Code from the top bids folder so it can see the company files from every bid. You can ask Claude to create the structure for you: describe it in a sentence and approve the folders it proposes.Step 2: Write the company facts and CLAUDE.md
Put every fact Claude may use into the company folder, and write a `CLAUDE.md` that says it may use nothing else. This is the single most important guard against invented claims.
Your
CLAUDE.md should cover:
• Who you are: company name, UEN, address and a one-paragraph description.
• Source rule: "Only state facts found in company/ or past/. Cite the file for every factual claim. If a requirement can't be met from these files, flag it instead of writing around it."
• Style: British English, S$ amounts, plain language, the buyer's own terminology.
• Boundaries: "Never change pricing. Never fill in declarations, signatures or certifications. Leave these for a person."
• Folder map: where tender documents, drafts and final files go.
Keep the facts themselves in separate files (company/certifications.md, company/projects.md) so they're easy to update. When a certification expires or a project completes, you change one file, and every future bid picks it up.Step 3: Write your bid rules
Turn your senior bidder's checklist into a numbered rules file that Claude checks every draft against. This is where your experience lives.
Good rules are specific and testable. The kinds of rules worth writing:
• Every mandatory requirement in the tender is answered explicitly, in the order the buyer listed it.
• Prices are identical everywhere they appear: price schedule, cover letter, summary.
• No section exceeds the buyer's page or word limit.
• Every claim about past work names a real project from
past/.
• The response uses the buyer's evaluation criteria as headings where the format allows.
• No placeholder text such as "[TBC]" or "XX" remains.
In our own document system, OTG Studio, we encode our bid principles as 20 rules for quotation work, each one grounded in something that actually went wrong. Expect your list to grow the same way: every lost bid or near-miss becomes a new rule.Step 4: Create the intake skill
Create a `/bid-summary` skill that reads a new tender pack and produces a one-page brief before anyone writes a word. Ask Claude to create it for you:
Create a skill called bid-summary. When I run it on a bid folder, read everything in tender/ and write drafts/00-brief.md with: buyer, scope, closing date and time, submission method, evaluation criteria and weightings, mandatory documents and forms, eligibility requirements, questions to clarify with the buyer, and a go/no-go note on whether we meet every mandatory requirement based on company/.
Read the brief yourself. This is where you decide whether to bid at all, which is the highest-value decision in the whole process. A fast, honest go/no-go saves more time than any amount of drafting speed.Step 5: Build the compliance matrix and draft
Run a `/compliance-matrix` skill to list every requirement, then draft section by section against it. The matrix is a table with one row per requirement: the requirement in the buyer's words, where in your response it's answered, the source file used, and its status (met, partly met, gap).
Then draft one section at a time, for example
Draft section 3, our approach, against rows 12 to 20 of the compliance matrix, using company/methodology.md and the two most relevant projects in past/. Drafting by section keeps each piece reviewable and makes it obvious which requirement each paragraph answers.
For long specifications, ask Claude to use a subagent to read the full document and return only the requirements that matter. Your main session stays focused on writing.Step 6: Review against your rules
Run a `/bid-review` skill that checks the full draft against every rule in `rules/` and the compliance matrix, and lists each problem with its location. Ask for a list of problems, not silent fixes, so a person decides what to change.
A strong review checks:
• Every row in the compliance matrix is met or explicitly flagged.
• Every factual claim traces to a file in
company/ or past/.
• Prices match across all documents.
• Page and word limits are respected.
• Mandatory forms are present and untouched by Claude.
For important bids, ask for the review to run as a separate subagent, so it judges the draft fresh rather than through the reasoning that produced it.Step 7: Add a preflight hook before export
Add a hook that blocks the final files from being written to `submit/` until a preflight check passes. Instructions can be forgotten; a hook runs every time. Ask Claude to set it up:
Add a hook to this project that runs before any file is written into a submit/ folder. It should check that every mandatory document listed in drafts/00-brief.md exists, that no file contains [TBC] or XX, and that the price total in the price schedule matches the cover letter. If any check fails, block the write and explain why.
Test it by deliberately leaving a placeholder in a draft and confirming the export is blocked. Then a person does the final read, completes declarations and pricing, and submits through the buyer's portal. Claude prepares; people decide and submit.
When the workflow is working, save the empty bid folder as a template. Each new bid becomes: copy the template, drop in the tender pack, run /bid-summary. For government tenders specifically, read our guide to GeBIZ tenders with AI on what Singapore SMEs should and shouldn't automate. If you'd like help building this for your team, our AI Foundations training and a free consultation are good starting points.Frequently asked questions
How long does it take to set up a bid workflow in Claude Code?
Expect an afternoon for the first version: an hour for the folder structure and company facts, an hour for bid rules, and the rest for skills and a preflight hook. Most of the time goes into writing down knowledge you already have. After that, each new bid starts from the template in minutes.
Can Claude Code fill in tender forms and price schedules?
It can check that forms are present and that prices are consistent across documents, but pricing decisions, declarations and signed forms should stay with an accountable person. Put that boundary in your `CLAUDE.md`, and use a hook to block edits to the pricing file, so Claude can't change it even by accident.
How do I stop AI from inventing credentials in a bid?
Keep every usable fact in a company folder and tell Claude, in `CLAUDE.md`, to state only facts from those files and to cite the source file for each claim. Then run a review skill that checks every claim traces to a file. Anything that can't be sourced is flagged for a person rather than written around.
What is a compliance matrix in a tender?
A compliance matrix is a table listing every requirement in the tender with where and how your response addresses it, and whether each is fully met, partly met or not met. It helps evaluators find your answers, and helps you make sure no mandatory requirement is missed. Claude Code can build a first draft directly from the tender documents.
Related articles
PreviousGeBIZ Tenders with AI: What Singapore SMEs Should AutomateNext Claude Code Skills, Hooks and Subagents, Explained for Business
Want to Apply This to Your Business?
We're a Singapore AI development and automation agency. Let's discuss how we can help solve your specific challenges.