An EOI is not a writing job. It is an assembly job with a deadline, and most of the week goes on parts you have written before. Here is the run, skill by skill, in the order the work actually happens.
The EOI you lost was probably not lost on the writing. It was lost on the third page, where a criterion got a general answer instead of a specific one, because it was 9pm on the Thursday and someone was pasting in a project sheet from 2023.
That is what this is for. Not a machine that writes your submission, which would be both obvious and bad. A set of small, named jobs that each take out one of the fifteen chunks of a week, so the hours you have left land on the part that actually wins: what you are proposing to do for this client, on this site, with these people.
Every skill named here is real and free. They all live in one pack on this site, 56 skills in total, no email wall. The download sits at the bottom, and each name below is the actual folder name so you can find it.
A skill is just your process, written down once. If that phrase means nothing yet, start with what is a skill, then come back. It takes four minutes.
Like a builder who prices the job off the drawings, not off the phone call.
The EOI document is sixty pages and four of them matter. Somewhere in there is the weighting table, the page limit, the mandatory forms, and the one clause that quietly excludes you. Every practice knows this and every practice still skims it, because reading it properly is nobody's favourite Monday.
Reads the whole document and gives back only the parts you need, structured and traceable. It is the difference between remembering a requirement and having a list of them.
Stands up the folder tree, your templates and a memory file in one move, so the submission has somewhere to live before four people start emailing versions to each other.
Digs across sources on the client, the site and the programme, and hands back findings with the sources named. Not a summary you have to take on faith.
Interrogates your read of the brief until nothing is vague. This is the one that catches the assumption everybody made and nobody said out loud.
Read the attached EOI document. Give me back, in this order:
1. Every mandatory requirement, as a checklist, with the page and clause
it comes from.
2. The selection criteria with their weightings, highest first.
3. The submission format rules: page limit, font, file naming, portal,
closing time and time zone.
4. Anything that would exclude us on the spot, flagged separately.
Quote the source line for every item. Do not summarise, do not
paraphrase, and if something is ambiguous say so instead of guessing.
Our practice: [size, disciplines, sectors].
The one mistake: asking for a summary. A summary is the enemy here. You want the list, with the clause numbers, so a junior can tick it off at 5pm on the Friday without reading the document again.
Every practice says they are collaborative. Nobody says what they would do on Tuesday.
The evidence half of an EOI is where the hours go, and it is also where a submission is genuinely won or lost. Not the claim that you understand the site, but the paragraph that proves it by naming the overlay everyone else missed.
A first-pass planning and site constraints read for the address: zoning, overlays, setback and height questions, and a flag on anything that must be verified with the authority rather than assumed.
Finds real built precedents that fit the brief, so your relevant experience section argues from projects rather than gestures at a mood.
Generates and compares early options against the brief and the constraints. Useful when the EOI asks for an approach and you want to show a direction without pretending it is a design.
Plans a full render set from one input, labelled by angle, time and lens, so the images in the submission are a considered set rather than whatever was on the server.
Here are the selection criteria and our project list. For each criterion, pick the 2 projects from our list that answer it best, and for each one write 3 sentences: - what the problem was on that job, - what we specifically did about it, - what the measurable outcome was. Rules: no adjectives about our practice, no "we are passionate about". If a criterion has no project that genuinely answers it, say so and tell me what evidence we would need instead. Criteria: [paste them] Projects: [paste the list, with your role and the outcome]
The one mistake: letting it write the project sheets from the project names. It will produce something fluent and hollow. Feed it your real outcomes, including the ugly ones, and it will argue from those instead.
The assessor is scoring against a rubric, not reading for pleasure.
This is the part where an architect writes what they find interesting and the assessor scores what they were told to score. The gap between those two is most of the marks.
Answers each criterion in the language a jury rewards, drawn from your own facts. Written for award entries, and it transfers straight to selection criteria, which is the same task with a duller name.
Turns a list of phases into a defensible programme with dependencies, milestones and critical decisions marked. Their dates, your resourcing, on one page.
A ballpark order-of-cost from a GFA or room breakdown, using rate ranges you supply. A sanity check, and it says so, which is exactly what you want in a document you will be held to.
Pulls the risks into one register with an owner and a date on every line. Written for the monthly delivery sweep, and it does the job for the risk section of a submission just as well.
Score our draft answer against this criterion the way an assessor would, then rewrite it. Criterion: [paste it, with the weighting and any sub-points] Our draft: [paste it] First: mark it out of 10 against each sub-point, and say which words in our draft earned nothing. Then: rewrite it to the word limit, keeping every specific fact and cutting every claim we cannot evidence. Finally: list what we would need to add to move it from its score to full marks.
The one mistake: asking it to write the answer. Ask it to score your answer first. The scoring pass is where the value is, because it tells you which sentences are doing no work, and those are usually the ones you were proudest of.
Compliance is not a formality. It is the cheapest way to lose.
Submissions get put aside for a wrong file name and a missing form. Not often, but often enough that every office has the story. The last stage is unglamorous on purpose.
Builds the compliance matrix as a working spreadsheet with live formulas, every requirement against where it is answered, so the gaps are visible rather than remembered.
Produces the submission as a properly formatted Word file in your letterhead, returned with tracked changes so you can see what it did rather than trusting it.
Strips the AI cliches out so it reads like your practice wrote it. Run it last, on everything, without exception.
Build a compliance matrix for this submission as a spreadsheet. One row per requirement from the EOI. Columns: clause reference, requirement in plain words, where we answer it (document and page), status, owner, and a notes column. Then give me two lists underneath: - requirements with no answer yet, - requirements answered somewhere but not where the EOI asked for it. EOI requirements: [paste the checklist from stage 1] Our current draft contents: [paste your document structure]
The one mistake: running anti-ai-voice on the covering letter only. The tells hide in the criteria responses, where the pressure to sound impressive is highest. Run it on the whole document, then read the first line of every paragraph aloud.
Every prompt above starts by giving Claude something real: the actual document, the actual project list, the actual draft. That is not politeness, it is the whole method. Asked to produce a capability statement from nothing, it will write the average of every capability statement ever published, which is precisely the document the assessor has already read four times that morning.
Give it your facts and it argues. Give it nothing and it fills space.
The other half of the habit is the order. Read, evidence, criteria, assemble. Practices that lose EOIs usually run it backwards: they start writing on day one and go looking for the evidence on day four, by which point the narrative is already fixed and the facts have to be bent to fit it.
The 15 above ship inside the full framework pack: 56 skills, one folder each, plus a README with the guidelines. No email wall, no sign-up. Drop each folder into your skills directory and call it by name.
Download the pack (.zip)If you want the wider map these sit inside, it is here: the AI framework for architects and PM. If you want the version of this aimed at the delivery phase instead of the pursuit, that is the construction PM skills.
Two decisions inside every EOI are entirely yours, and both are worth more than the fifteen skills combined.
The first is whether to bid at all. A week on a submission you were never going to win is the most expensive thing in this article, and no tool on this page can tell you that the incumbent has already done the feasibility for them. Your read of the market is the input, not the output.
The second is what you are prepared to promise. Every EOI contains a sentence that will be quoted back at you in eighteen months, in a meeting you are not looking forward to. Deciding how far to go on programme, on fee, on the team you are naming, is a judgement about risk your practice can carry. That stays with the person who signs it.
Everything else in the week is assembly. That part you can hand over.
Or take it straight from the download above. It is the same file, and there is no sign-up either way.