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.
\nAn 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.
\nI 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.
\nThat would have been a reasonable approach, but it presented two problems.
\nThe 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.
\nWe 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.
\nWe decided not to begin with a tone-of-voice questionnaire.
\nQuestions 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.
\nInstead, we designed a series of small experiments.
\nThe 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.
\nOne of the first experiments began with a simple question: where should someone start with AI?
\nOf 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.
\nThat choice told us more than which words I preferred. It revealed a way of developing an argument:
\nThis pattern kept resurfacing.
\nAt one point, an important distinction emerged.
\nThe 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.
\nEditing them out, however, should not flatten the thinking behind them.
\nA sentence we developed during one of the experiments became one of the central instructions in the skill:
\nBring structure to the thinking without reducing its depth.
\nThe 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.
\nThe voice we were looking for depended less on a particular vocabulary than on the shape of the reasoning.
\nOne 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.
\nAt first glance, the idea seems reasonable. A well-written prompt can certainly improve the result. The problem begins when we use the word “perfect.”
\nPerfect by what standard?
\nJudging 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.
\nThere 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.
\nThis 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.
\nYou 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.
\nThis 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.
\nWe also wanted to understand how to approach technical concepts.
\nWe began with a common question: what is an API?
\nA 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.
\nI suggested describing an API as a kind of contract between two parties.
\nOne 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.
\nThe 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.
\nThat experiment gave us a useful sequence for explaining technical subjects:
\nIn this context, simplifying does not mean removing complexity from the concept. It means making that complexity easier to approach.
\nThere was an easy trap to fall into during this process.
\nIf 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.
\nThe result would have been a caricature.
\nWe therefore separated hypotheses from confirmed characteristics.
\nA 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.
\nFor 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.
\nThe difference may seem small, but it prevents the skill from mechanically applying a choice outside the context that made it useful.
\nThe small experiments eventually produced four files:
\nfrancesco-voice/\n├── SKILL.md\n└── references/\n ├── voice-profile.md\n ├── approved-examples.md\n └── 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.
\nKeeping these materials separate helps us avoid confusing different layers.
\nThe 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.
\nThe small experiments were useful, but they remained controlled exercises.
\nThe 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.
\nThe test helped us separate two responsibilities.
\nThe 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.
\nThe revision confirmed that the voice could work across a complete article. It did not answer every question.
\nThat 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.
\nThis article is the next step.
\nThe first version of the skill does not try to describe every aspect of my voice.
\nWe 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.
\nThese are not gaps we should fill with assumptions.
\nThey are questions that only real work can answer.
\nThe 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.
\nThe 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.
\nIf those preferences reappear, we can record them. If they only work for this article, they will remain local choices.
\nAt first, I thought defining a voice meant describing it as completely as possible.
\nThe process led us in a different direction.
\nA 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.
\nIts value does not depend on being complete from day one.
\nIts 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.
","headings":[{"level":2,"text":"Testing the Voice in Small Steps","id":"testing-the-voice-in-small-steps"},{"level":2,"text":"We Were Not Trying to Reproduce the Way I Speak","id":"we-were-not-trying-to-reproduce-the-way-i-speak"},{"level":2,"text":"The Perfect Prompt Does Not Exist","id":"the-perfect-prompt-does-not-exist"},{"level":2,"text":"Accessible Does Not Mean Superficial","id":"accessible-does-not-mean-superficial"},{"level":2,"text":"One Preference Does Not Make a Rule","id":"one-preference-does-not-make-a-rule"},{"level":2,"text":"How We Organized the Files","id":"how-we-organized-the-files"},{"level":2,"text":"The First Real-World Test","id":"the-first-real-world-test"},{"level":2,"text":"A Skill That Is Meant to Evolve","id":"a-skill-that-is-meant-to-evolve"},{"level":2,"text":"A System That Learns Through Use","id":"a-system-that-learns-through-use"}]}}