From idea to tool
Everything this site describes was built the same way. An everyday irritant becomes an idea, the idea becomes a concept, the concept is built with Claude, goes through the test stage, then is put into service and maintained. Skipping a stage always costs more than doing it.
The five stages
1. Idea: the problem in one sentence
- Write down the problem, not the solution: “every absence triggers a chain of emails and rooms are left empty”.
- Check that it recurs: at least once a week, or the same instruction given three times.
- Pick one first need; the others will wait.
Warning sign: wanting to automate everything at once. Start with what wastes the most time.
2. Concept: what the tool will be
- Choose the form: a skill (know-how that Claude applies), an artifact (a page you consult), a routine (a scheduled task), a project (a workspace per hat), or an online tool (for people who do not use Claude).
- Define the inputs, the output and the deliverable: what the tool reads, what it produces, where it stores it.
- Write the safeguards before the first line: what it will never do without your approval.
- List the open questions and settle them before building.
Warning sign: a specification that only one person understands. Have Claude review it: “what is ambiguous?”.
3. Build: what you ask Claude for
- A minimal first version, then small successive requests.
- Every delivery numbered (v1, v2…), the previous one archived.
- Real data never embedded in anything that will be shared.
Warning sign: fixing ten things in a single request. One request, one change, one test.
4. Test: proving that it works
- Test on a real case, then on an edge case (missing data, unknown name, unusual action).
- Have Claude check what a human no longer re-reads: discrepancies between two sources, names, identifiers, links.
- Fix nothing without approval: the test stage produces a list, not changes.
Warning sign: a test that passes on your computer proves nothing for your colleagues’ computers.
5. Deployment: deliver, publish, keep it going
- Always deliver the same thing, in the same place, under the same name.
- Write the publication procedure for someone who has never done it, including what they should see at the end.
- Announce it to users with an email drafted in the conversation and sent by you.
- Compress the discussion into a skill: difficulties already solved should not have to be learned again.
Warning sign: a tool with no owner and no procedure dies at the first failure.
The five stages, depending on what you build
| Skill | Artifact | Routine | Project | Online tool | |
|---|---|---|---|---|---|
| Idea | An instruction given three times | A question asked every day | A check done every day | Mixed-up conversations | Colleagues who do not have Claude |
| Concept | Name, triggers, steps, deliverable, safeguards, hand-offs | One question per page; data in a database, not in the page | A run plan written in a file; budget | One hat per project; reference documents; boundaries | Specification, tabs, architecture, access rights |
| Build | Ask Claude to write the skill from the conversation | Publish the page, then connect it to a database | Create the task that reads the plan | Create the project, add instructions and documents | Build it version by version |
| Test | Test it on three real requests | Check on a phone and with several users | Review the log of the first runs | Check that a question goes to the right project | Triple test, double check |
| Deployment | Add it to the skills map | Pin it; archive duplicates | Monitor with status lights; notify only when action is needed | Pin the useful conversations | Publication in four clicks, announcement, skill |
See a complete case
- The department schedule: fifteen steps, with the difficulties encountered and the warning signs.
- More cases will follow: a conference presentation skill, a bibliography skill, the anticipation dashboard, separating projects by hat.