Free course 4
Projects. Launch and grow.
In this course you will learn to
- launch a small project by a strict order of work (a protocol): a constitution (your main project document, two pages), a stage plan (a sprint page), a task with a criterion — a clear check
- work step by step and call an independent review — by someone other than the author
- release the result (show the finished thing to people) safely, able to go back, and not work “on a hunch”
Why a strict order
Agent projects fall apart without written records: the documents are in charge, not the chat
The chat is in charge
“We already decided that”
A decision left in a chat does not exist for the next chat. The agent (a chat with a role and a task that carries out steps itself) forgets, takes on too much and writes “done” without checking.
The documents are in charge
- Where it standsis written in documents, not in chat history
- Tasknames its limits and how to check it before work starts
- “Done”needs a shown result and the look of someone who did not do it
- Decisionsare written down, not remembered
Is a strict order needed? A one-off task belongs in a plain chat, as in course 1. Several documents, stages, a return in a week: a strict order.
Roles
The same roles as in course 3: you decide, three work
| Role | Does | Project documents |
|---|---|---|
| The owner (you) | Decides: the goal, the choices between options, the yes before a release | writes only the constitution, the main document |
| Navigator | Leads, sets the assignment, accepts the result | never edits them |
| Orchestrator | Plans and calls workers | the only one who changes them |
| Worker | One task, then ends | only reads and reports |
One chat per role, as in course 3. A worker does not make the choice: it returns the question to you.
Levels of work
Stage, part, step
| Level | What it is | The book exchange |
|---|---|---|
| Stage | A goal for weeks, with its own plan and clear signs of success | a working sign-up form for the book exchange |
| Part | A finished part of a stage, with its own result | the form with checks; the “my sign-ups” list; the release |
| Step | One small change with its own check | the form refuses an empty name |
Three levels are enough to start.
The project in documents
The project remembers a document, not a chat
- The stage plan (one page): the goal, how we will know it worked, “what we do not do”, the parts it is made of.
- The next action: one concrete action, never “carry on”. A new chat starts from it.
- The “stop” rule: a check failed twice, something outside the task is needed, rules disagree, something is published or deleted: the agent stops and asks you.
- The “for the human” section: what you decide and what to open first.
At the end, the stage plan in our example said so itself: “Status: closed”; the stage results are in a separate document, then the owner’s decision.
Starting documents
Five short documents before the first stage
- The idea: what the project is, for whom, what success looks like. One page at most.
- What it is made of: its parts, and what we leave out on purpose.
- The roadmap: stages as a list, one line a goal. It is not a to-do list; in course 3 the matching file was the “Plan”.
- What the work needs: which computer you have, which programs are needed, where the project files are kept.
- The to-do list: kept apart, everything not yet in work.
Password check: no passwords or access keys to your services may sit in the project documents.
A gift
The Project protocol skill: add it and take the first step
Leads you step by step and gives short templates: a small project
- It restates first: the skill (a ready-made instruction for a chat) retells your project in its own words and waits for your yes. If a strict order is not needed, it says so.
- One step at a time: from the starting documents to the release; it shows only the template for your step and names the next at the end.
- Roles as in course 3: one chat per role, you decide.
- Your first step: add the skill and write the starting documents with it.
The project constitution
Two pages the owner writes
The owner (you)
On the two pages
What we build and for whom
Who sees what and the visitor’s main path
What a person enters and how their data is protected
What we never do
What is not there
Program code
Detailed tasks: those are written separately
In the example, the owner’s answers became two pages: a three-field form, two possible exchange dates and the rule “a visitor sees only their own sign-ups”. The shared tablet at the door is this example’s setting, not advice to you. This is a real run, but the course author answered and checked in the owner’s place.
Stage planning
Plan the whole stage first, then do the work
- Goal in one sentence: a working sign-up page on this computer — the form, the list, the release.
- Success criteria: each a check that either passes or fails, or a visible fact. For example, an automatic check (a program that runs all the checks itself) with no failures.
- “What we do not do”: accounts, e-mail, payments, a server of our own (a separate computer for the site), other people’s ready-made pieces of programs.
- Parts before the work starts: the form and its checks; the “my sign-ups” list; the release.
The owner confirms the stage plan before any work starts.
The task
A task: what may change, what may not, how we check, the level of risk
Weak
“Make the form decent”
No limits, no check: the agent decides what “decent” means and says “done” itself.
The example’s first task
- Goalthe form refuses an empty name and shows a clear message
- May changethe page, the file with the form rules and a new file of checks
- Do not touchthe documents, other people’s ready-made pieces of programs, the book and date rules
- Criterionthe name check runs and passes (the agent runs it; you type nothing)
- Riskmedium
A criterion is a check that either passes or fails. Someone other than the writer runs it.
The working cycle
Scout, a check that fails first (red test), do, verify the result, close
- Scout: a worker only reads and reports facts. In the example: the project held only documents, no form and no program.
- A check that fails first: it must fail while the thing it checks does not exist yet. That is how we know it checks anything at all.
- Do: the smallest change that makes the check pass. The orchestrator does the work.
- Verify: run the checks and look at the numbers (how many passed, how many did not), not “seems to work”.
- Close: the report; the next step and the decisions go to the navigator.
The risk rule
The higher the risk, the earlier the stop
| Risk | What we do | In the example |
|---|---|---|
| Low | Do it and verify | this run had no such task |
| Medium | Do it, verify, show the numbers | the empty name: a new feature, but nothing is saved yet |
| High | Show the plan and wait for the owner’s yes | the “my sign-ups” list: privacy is the core promise |
At high risk: scout, a report with the plan, stop until the yes, and only then the check that fails first, and the work.
Checks and edge cases
A check is insurance, and a check that fails first is proof
- Insurance: a check guards against the system doing the wrong thing with a person’s data.
- An edge case is a rare situation: an empty name, a name of spaces only, a date outside the two possible ones.
From the run: first we tested the checks themselves: while an empty stand-in that accepted anything sat in place of the program, 2 of the 3 checks failed, as they should. Then the real program was written and all 3 passed. The worker did not count the very first failure: the check failed not on an error but because it could not find a file.
Protection against mistakes
Automatic protection beats a polite request: a rule asks, protection blocks
- Before starting: before work the agent must read the named documents. Not read, no work.
- The “stop” rule: the agent halts and shows the result before the next step.
- Scout before acting.
- A check that fails first: it fails before the program exists.
- One stage, one chat: start from a clean sheet and the documents, not a long chat history.
Start with the cheapest: ask to see the result of the check. “It all passes” with no result shown is not proof. The protection is set up in an assistant on your computer (course 3, slide 12); in a plain chat your own habit stands in for it.
Independent review
One writes, another checks — by six questions
One writes and checks
9 checks, all 9 passed
In the example all of the worker’s checks passed, but two checks from the task were not among them. “Passed” is worth what was checked.
Another checks
- Completenesseverything promised is there
- Consistencyno contradictions
- Namingthe name matches the content
- Decisionswhat was decided is written the same
- Linked placesevery place the edit touches is checked
- Leftoverswhat was removed is gone everywhere
Findings are labelled: SERIOUS (BREAK) stops the work, MISSED (GAP) does not, MINOR (NIT) is cosmetic (the same three labels as in course 2).
Reading a review report
What stops the work, what is put off
| Label | What was found | What was done |
|---|---|---|
| SERIOUS | The list was not cleared between visitors | returned; the fix is a separate task |
| SERIOUS | No check covered it: all 16 passed | first add the missing checks; on the earlier version (with the error) 4 of them failed, so they do catch the error |
| MISSED | Damaged records are silently overwritten; no name length limit | put off; the owner picks the length |
| MINOR | A stale word “planned” in a document | fixed at once |
How it really went: the course author planted this error on purpose. The worker’s report said two checks were not done, but did not name the error. The reviewer did not read that report and found the other visitors’ sign-ups in the list, and the checks that missed them, on their own. The shared tablet is the example’s setting, not advice.
Against working “on a hunch”
Nine habits instead of working by feel
- Before: do not write by feel · read what already exists first · a check that fails first.
- During: small checkable steps · do not trust your own result: let someone else check it · do not copy a rule into several documents, they will drift apart.
- After: know your requirements: have a written list of what should result · fix now, do not put it off in secret · know exactly what you changed.
A habit weakens when you are tired; automatic protection does not: it blocks the same on any day.
Traps when working with AI
Four traps and what to hand to an ordinary program, not to AI
| Trap | What happens | What to do |
|---|---|---|
| Cutting corners | The model (the program that writes the chat’s answers) hurries: skips checks and edge cases | ask for checks outright, name the edge cases in the task |
| A temporary placeholder | It gets built around as if it were a foundation | mark it “temporary” and write it into the put-off list |
| A word with two meanings | The model grabs one meaning and misreads the rest | use an exact word or invent your own |
| A long chat | Answers degrade | a new chat with the documents loaded |
Exact work to a program, meaning to the model. A program answers “where” and “how many”, the model “why” and “what for”. In the example an ordinary program (one that follows fixed rules exactly the same every time, like a calculator) checks the name, not a request to “check carefully”.
Decisions
A decision card: question, options, choice, why
- Question: one line on what is being decided.
- Options: three, each argued. If it feels like yes or no, find a third: defer or combine.
- Choice: an answer, not “one could”.
- Why: a reason that can be checked. Cards are kept one after another in one document.
From the run: the worker handed in the work and all its checks passed. Accept it? Options: accept; send back as it is; send back and ask for a check on what was missed, one that fails first. The third was chosen: “passed” is worth only what was checked.
Closing the stage
Check the criteria, results, lessons
| Criterion | Met? | Shown by |
|---|---|---|
| All checks pass | met | 31 of 31 checks passed at the close |
| Bad input is refused with a message | met | re-checked |
| The list shows this visit only | met in the program; on screen the course author looked, not the owner | the checks added with the fix |
| No ready-made pieces of programs from other people | met | an automatic search of the project’s files found nothing |
| The owner signs up on a phone in under a minute | not met | the course author checked in the owner’s place |
The stage closed with one criterion not met: the course author answered and checked in the owner’s place, so the real check moved to the next stage.
A safe release
Check first, then replace the old version with the new — and keep a way back
| Where to release | What it is | Take it if |
|---|---|---|
| Showing ready files | You put ready files there and they are shown as they are | the site does not need to store visitors’ data |
| Your own server | A separate computer for the site: you set it up and look after it | you need full control of the data |
| A ready-made service | The service runs and maintains it for you | the site must cope with many visitors without you fussing over equipment |
The rule: the new version’s checks pass — you replace the old with the new, the old one stays beside it, going back takes one action.
In the example the release was only on the course author’s computer: the working version was replaced by the new one, and the previous one could be restored with one action. Nothing was published online.
Course summary
All your tools
Next, your own project: start with the starting documents.
Every step is written down
We plan the demo version for November 2026 and the working version, with licences on sale, from 1 January 2027.
Go to the SANKORD site and subscribe there to the project’s updates.
Choose another course