When I first started thinking about using AI to write articles, tutorials, and social posts, the problem was not how to produce well-written text.
An AI assistant can already generate something grammatically correct, organized, and apparently professional. The real challenge was deciding whether I could genuinely publish that text under my own name.
I could have taught an assistant how I write by giving it a large collection of articles and posts I had already published. We could have analyzed the words I use most often, the length of my sentences, the rhythm of my paragraphs, and other recurring features.
That would have been a reasonable approach, but it presented two problems.
The first was practical: I had no intention of writing ten new articles simply so that we could study them. The second was harder to recognize: something I published in the past does not necessarily represent how I want to write today.
We needed a process light enough not to become a project in its own right, but precise enough to distinguish writing that genuinely represented me from writing I merely considered good.
Testing the Voice in Small Steps
We decided not to begin with a tone-of-voice questionnaire.
Questions such as “Do you prefer a formal or informal tone?” or “How authoritative do you want to sound?” can be useful. They also ask you to describe in the abstract something that may be much easier to recognize in practice.
Instead, we designed a series of small experiments.
The assistant would show me two or three short versions of the same idea. I could choose the one that felt closest to me, point out a sentence I would never use, or explain what seemed to be missing. In other cases, I answered a question freely and left the assistant to give my thoughts a clearer structure.
One of the first experiments began with a simple question: where should someone start with AI?
Of the different options, I preferred the one that recommended beginning with a task you already know well. If you understand how to perform the task yourself, you are in a better position to judge what the AI contributes. You can see what it does better than you, where your involvement remains necessary, and how the process might gradually improve.
That choice told us more than which words I preferred. It revealed a way of developing an argument:
- begin with a concrete situation;
- keep the experiment within clear boundaries;
- evaluate the result without idealizing it;
- recognize the person’s role;
- use the first attempt as the beginning of an improvement process.
This pattern kept resurfacing.
We Were Not Trying to Reproduce the Way I Speak
At one point, an important distinction emerged.
The way I work through an idea spontaneously is not necessarily the way I want a published text to read. I may repeat myself, open a parenthesis, or follow a diversion before returning to the main point. Those hesitations and detours do not need to be reproduced word for word just to make the result sound like me.
Editing them out, however, should not flatten the thinking behind them.
A sentence we developed during one of the experiments became one of the central instructions in the skill:
Bring structure to the thinking without reducing its depth.
The assistant can make an argument more linear, calm, and balanced. It can remove superficial repetition and make the relationships between ideas easier to follow. It should not remove genuine uncertainty, turn a preference into an absolute rule, or erase a meaningful distinction simply because that distinction requires a longer explanation.
The voice we were looking for depended less on a particular vocabulary than on the shape of the reasoning.
The Perfect Prompt Does Not Exist
One of the most useful experiments dealt with a familiar claim: to use AI well, you first need to learn how to write the perfect prompt.
At first glance, the idea seems reasonable. A well-written prompt can certainly improve the result. The problem begins when we use the word “perfect.”
Perfect by what standard?
Judging the quality of a prompt requires criteria. Those criteria change with the task, the desired result, and the perspective from which we examine it. A prompt can be clear but incomplete, detailed but too rigid, effective in one situation and unhelpful in another.
There is also a more basic limit: the person writing the prompt does not have a complete view of the problem. They may forget a piece of information, struggle to express an idea, or discover during the work that the result they want differs from what they originally imagined.
This does not mean that prompts are unimportant. It means that developing them gradually is often more sustainable than trying to make them perfect from the beginning.
You can start with a simple description, observe what the assistant has understood, and progressively clarify what is missing. Every error or omission becomes useful information for the next step.
This experiment revealed another recurring characteristic of my voice: recognizing the reasonable part of a position before examining its limits. Criticism should not stop at disproving an idea. It should replace that idea with a more useful way forward.
Accessible Does Not Mean Superficial
We also wanted to understand how to approach technical concepts.
We began with a common question: what is an API?
A simple definition and a concrete example made the concept understandable, but I felt something was missing. For someone who is not used to thinking about how two pieces of software communicate, the explanation could still feel abstract.
I suggested describing an API as a kind of contract between two parties.
One party makes a request. The other provides information or makes certain operations available. The contract establishes what can be requested, which information must be provided, and the form the response will take. If the request does not follow those conditions, it is not considered valid.
The analogy works because it gives the reader a familiar way into an abstract concept. It should not, however, be treated as a perfect equivalence. A contract between people and an interface between software systems are not the same thing.
That experiment gave us a useful sequence for explaining technical subjects:
- introduce the concept in familiar language;
- show a concrete example;
- add an everyday image when it helps;
- explain the relevant limits or conditions;
- show what the reader can do with what they have learned.
In this context, simplifying does not mean removing complexity from the concept. It means making that complexity easier to approach.
One Preference Does Not Make a Rule
There was an easy trap to fall into during this process.
If I approved a short sentence, we might have concluded that I always prefer short sentences. If I liked an analogy, we might have decided that every explanation needed one. If a rhetorical question worked well, we might have turned it into a recurring feature of every article.
The result would have been a caricature.
We therefore separated hypotheses from confirmed characteristics.
A single reaction gives us a clue worth testing, not a rule. A preference becomes more reliable when it reappears in different contexts or when I confirm it explicitly. Even then, the rule needs to preserve the conditions that made the original choice useful.
For example, we did not simply record that “Francesco uses analogies.” The instruction is more precise: an everyday analogy can help when an abstract concept still feels out of reach, but it should not pretend to reproduce the technical system perfectly.
The difference may seem small, but it prevents the skill from mechanically applying a choice outside the context that made it useful.
How We Organized the Files
The small experiments eventually produced four files:
francesco-voice/
├── SKILL.md
└── references/
├── voice-profile.md
├── approved-examples.md
└── format-adaptations.mdSKILL.md contains the instructions for applying the voice. It establishes the order of the sources, explains how to preserve the original meaning, and states what the assistant must not invent.
voice-profile.md describes confirmed characteristics such as the calm tone, the relationship with the reader, and the way an argument develops. It also preserves the questions that remain open.
approved-examples.md collects pieces of writing that I recognized as representative. Each example includes an explanation of why it works. These are not templates to copy. They make concrete a rule that could otherwise be interpreted in several different ways.
Finally, format-adaptations.md describes what changes between knowledge-base content, tutorials, articles, and social posts.
The underlying voice should remain recognizable, but these formats do not require the same density. A tutorial needs to guide the reader through a dependable sequence. An article can leave more room for the argument to develop. LinkedIn requires a complete but more compact line of thought. On X, a thread may be necessary when forcing everything into a single post would remove an essential step from the reasoning.
Keeping these materials separate helps us avoid confusing different layers.
The profile records what we know about the voice. The examples show the evidence behind those conclusions. The format adaptations explain what changes across different types of content. The skill defines how all of this should be used during the work.
The First Real-World Test
The small experiments were useful, but they remained controlled exercises.
The first real-world test came when we applied the skill to an existing editorial draft. In that case, tone was not the only concern. We also needed to preserve technical accuracy, sources, structure, and the requirements of the format.
The test helped us separate two responsibilities.
The editorial rules determined the structure required by the publication. The voice skill governed the way the reasoning developed: the language, the connections between sections, the clarity of the explanations, and the degree of certainty attached to each conclusion.
The revision confirmed that the voice could work across a complete article. It did not answer every question.
That work began with an already developed draft. It showed that the skill could recognize and strengthen my voice, but not yet that it could construct it from a request and a collection of source material.
This article is the next step.
A Skill That Is Meant to Evolve
The first version of the skill does not try to describe every aspect of my voice.
We still do not know how much room there should be for humor and irony. We do not have enough examples to define stable differences between LinkedIn and X. One successful test in English is not enough to establish all my preferences in that language.
These are not gaps we should fill with assumptions.
They are questions that only real work can answer.
The Italian version of this article came first for exactly that reason. Only after approving it did we prepare the English version, preserving its reasoning and emotional temperature without mechanically translating the structure of every sentence.
The social content will become another set of experiments. We will be able to observe how much of the reasoning a LinkedIn post needs to preserve, and when an X thread preserves the reasoning better than forcing it into a single post.
If those preferences reappear, we can record them. If they only work for this article, they will remain local choices.
A System That Learns Through Use
At first, I thought defining a voice meant describing it as completely as possible.
The process led us in a different direction.
A voice skill is not an immutable picture of a person, nor is it a formula capable of automatically producing the right text. It is a system that preserves what we have learned, makes visible what we still do not know, and helps us test both through real work.
Its value does not depend on being complete from day one.
Its value lies in its ability to evolve without losing the evidence behind each decision. A recognizable voice does not come from freezing it into a formula. It comes from understanding what can change, what should remain, and why.