This article was originally written in Japanese and translated into English with AI assistance. Please note that some expressions may carry nuances from the original Japanese.
🇯🇵 日本語版はこちら / Japanese version
About This Article
In my previous article, “Reflecting on DX Talent — Through the Lens of Capability Expansion and a Divergent State”, I touched briefly on my experience of “using AI to build a textbook on a certain industrial device.” At the end of that article I promised, “The seven patterns and the textbook-building method will be introduced in detail in the next blog post.” This article is that promised content.
This is not a simple how-to. It is an account of the trail of thought I followed and a few discoveries I encountered along the way. The artifacts produced through this work are humble ones, but I would like to share them so you can put them to use as well.
Why I Started This
Alongside my work as Soul Resonant Works, I serve in a sales-promotion role at a manufacturer. The job of a sales-promotion role at a manufacturer is to support the sales team and ultimately drive revenue. To sell, you need product knowledge — not only for me in the sales-promotion role, but for the front-line sales team as well, who need that knowledge to do their work. Obviously enough, you cannot sell a product you do not know well.
Here a practical problem comes up. We handle multiple products, and you cannot become equally deep on every one of them. Especially when working with products somewhat outside my own area of expertise, I was on the side of “I do not really understand this.” Customer environments also vary, so we need to deliver appropriate knowledge transfer matched to each situation.
Naturally, training material has been prepared, but whether it covers everything is — unfortunately — not always the case. Manufacturers tend to dive into the specifications of their own products, but a perspective on “how it looks in the customer’s environment” is also necessary, and whether that is properly reflected in the material is, in many cases, not really so.
Product knowledge also extends beyond a single product in isolation. Understanding the historical evolution and the background of why a product takes the form it does is part of the picture. Yet items that experts treat as “obvious” are often the items not written down anywhere.
The most straightforward way to obtain that kind of background information is to ask a domain expert inside the company, and you can in fact go ask them. But experts tend to be busy people. The more “naive beginner” your question is, the more hesitant you become about taking up their valuable time. The reservation that says “is it really okay to take a busy person’s time with such a low-level question?” was, in effect, narrowing my own learning opportunities.
So I decided to at least learn and understand on my own as much as I could, by leaning on AI. The AI does occasionally tell me “let’s stop here,” but in general you do not need to hold back with AI. You can ask any question, as many times as you want, no matter how basic. That was the starting point.
Briefly Recapping the Earlier Story
For readers who have not read the previous article, here is a short recap up to this point. If you have already read it, feel free to skip to the next section.
For a certain industrial device, I repeatedly questioned an AI called Copilot. I would throw out a naive question, get an answer, and pile on another question — doing this dozens of times. Then I had the thought of using a different AI (Claude) to “summarize this conversation log into a textbook.” When I tried it, content in textbook form was finished in about two days.
I shared the finished textbook with a colleague at work, and they came back with the question, “Do you think this textbook-building approach could be extended to other products?”
This was not a work request to me; it was an exploratory question from a colleague who also uses AI. Receiving that question, I started to abstract the trajectory I had followed and to think about whether the same thing could be done with another similar product.
From there — the abstraction work, the trial and error of horizontal extension, and the eventual completion of a second textbook — is what this article will go into in detail.
What This Article Covers
The article is structured in three chapters.
Chapter 1, “Taking on the Textbook,” covers how I built the first textbook (the textbook on a certain industrial device). It includes the story of repeatedly asking Copilot questions, the story of having Claude turn the result into a textbook, and the story of trying cross-review between AIs and seeing the limits that emerged.
Chapter 2, “Methodology,” is about abstracting that experience into a reproducible procedure. This is where the “seven patterns” and the “four approaches” are found.
Chapter 3, “Horizontal Extension,” is about applying the procedure to a different product, hitting a dead end, and the moment of swapping roles to break out of it.
I will close by introducing four companion materials (the question template, the workflow prompt, the HTML templates, and a sample Smartphone Edition Textbook actually built using this question template) before wrapping up.
Chapter 1: Taking on the Textbook
Repeating Question-and-Answer with Copilot Dozens of Times
The first thing I did was repeated question-and-answer with Microsoft’s Copilot about a certain industrial device (which I will refer to as “Product X” from here on).
The very first question was something extremely basic: “What is Product X? Why does it exist?” Reading Copilot’s reply, I would throw out the next question. “Then how does it differ from Product Y?” “What internal components is it made of?” “If you were to compare it to something familiar, what would it be?” — a process of probing the contour of Product X from many directions.
I repeated this dozens of times. Starting from the definition of Product X, then moving to contrast, coexistence, internal structure, selection criteria, and operational application — I posed questions from every angle, received answers, and posed more questions. The conversation log eventually reached about 30,000 characters in volume.
By that point, my own understanding of Product X was reasonably well-organized. The very act of asking questions is the act of putting into words what you do not yet understand. It felt less like the AI had taught me, and more like I had drawn the contour of my own understanding using the AI as an interlocutor.
Handing the Conversation Log to Claude and Asking for a Textbook
The questions I had been repeatedly asking covered things I did not understand. To someone who knows it, it is utterly basic content; to someone who does not, it is unknown content. Reasoning that there must be others, beside me, who do not know it, I judged it best to write it up properly. If it is in writing, you can refer back to it later, and stored somewhere shared, AI tools can find it — that is the kind of era we are entering.
Beyond just organizing it, since there was a capable AI right there, I decided to give it some textbook-quality presentation. The intention was modest: if you are going to look at it, prettier is better. A plain text file is hard to read; nicer formatting is just better.
I only realized later that the conversation log had reached about 30,000 characters. By having the AI ingest the entire vast log, I figured it could trim out the unnecessary parts — the parts where I was repeating the same question because I did not understand the first time around — and leave only the necessary content. It was a leap, but I asked Claude to “build a textbook on Product X based on this conversation log.”
Side note: the work of obtaining that 30,000-character conversation log was unexpectedly primitive. The Windows desktop version of Copilot did not have a feature to export the entire conversation log, and even scrolling through the screen and copy-pasting did not let me capture the whole thing in one go. I ended up accessing the web version of Copilot and scrolling-and-copy-pasting from there. While we were calling this “cutting-edge AI work,” part of the reality was supported by this kind of unglamorous manual labor — that is something worth recording.
There was one decision I made here. I specified HTML as the output format for the textbook. From past experience, Claude prefers to recommend Markdown by default, but if you send a Markdown file to a colleague, you are guaranteed to get a “How do I open this?” reply. With HTML, they can simply open it in a browser, which lowers the friction of sharing. A small choice, but it had a big effect on later sharing.
From the moment I asked Claude for the textbook to the moment an HTML file in textbook form arrived in my hands, almost no time passed. Counting from the day I started the question-and-answer session, two days. The first version was complete by the day after I started. Of course, I was not working on it the entire time — I would give an instruction, leave it, come back, check the result, give the next instruction, leave it again — so my actual time invested was minimal. The speed of AI-assisted content generation is, frankly, astonishing.
Reading It Through Myself, Finding Discrepancies, and Asking for Fixes
That said, the completion of the first version was not the end but the beginning. I read through the finished textbook, finding spots that felt off, and asked Claude to fix them, again and again.
Claude writes massive amounts of text in a flash, but the speed at which I, the human, can review it was slow — painfully slow. Even in collaboration with AI, I was completely the slow link in the chain. If you do not care about content quality, just letting AI do everything is by far the fastest path nowadays. But because I take responsibility for the writing — and because it would be a problem if it diverged from what I actually wanted to express — my checking is, however limited, essential.
In retrospect, far more of the correction work went into appearance (layout, fonts, spacing, callout-box presentation) than into content. AI is good at consistency-of-text and contextual judgment, but weak at visual judgment. “The space above this heading is too wide,” “the color of this callout box does not match the chapter’s tone” — those kinds of remarks could only come from a human. Because the initial question-and-answer had been thorough, the content was already substantial, so it might have been fine to ignore the appearance. But since Claude had gone to the trouble of producing a clean HTML layout, having parts that looked off would feel disappointing — so I kept pointing them out.
Cross-Review by a Second AI: Discovery and Limits
From here, I started a new experiment. Having a second AI — Copilot — review the finished textbook.
I could have had Claude review what Claude itself had written, but the underlying model would be the same, so I figured I would gain more multi-faceted feedback by using Copilot, which has a different perspective (a different AI model) underneath.
Reading the textbook Claude had written, Copilot returned concrete remarks like “the explanation in this chapter requires factual verification” and “the definition of this term may differ from the standard definition in the field.”
This was a fairly significant discovery. Cross-review by an AI of a different lineage can be an effective means of raising quality in AI-assisted writing — that is the moment I became convinced of it. I would feed Copilot’s review comments back to Claude, ask for revisions, and run it past Copilot again — a cycle.
That said, this had its limits, too. Copilot is good at “factual remarks,” but as you might expect, it is weak at remarks that involve the reader’s experience, like “this is hard to follow for a reader” or “the order of explanation here would land better if you swapped these two.” Cross-review can rescue “factual accuracy”; “readability” is a separate problem.
A Human Makes the Final Call
After several rounds of cross-review, I raised the quality further by pointing out the disconnects I, the human, was feeling.
That the final judgment is made by a human can be read as showing the limits of current AI use, but it can also be read as showing room where humans can still play a role. I lean toward the latter view. AI writes, AI reviews, and at the end a human reads through and finishes it — this workflow seems, as a division of labor between human and AI, to land in a comfortable place.
In this way, the textbook on a certain industrial device (Product X), about 3,256 lines and 190 KB as an HTML file, was completed.
This wraps up Chapter 1, “Taking on the Textbook.” The next chapter, Chapter 2, moves on to abstracting the experience into a methodology. At the very end of the article, I will share, as companion materials, both the workflow itself and the reference deliverable actually built with that workflow. The aim is not “read and done,” but reaching a state where you, the reader, can do the same in your own domain.
Chapter 2: Methodology
Abstracting the Habits of My Own Questions Revealed Seven Patterns
The Product X textbook was complete, and I shared it with a colleague at work. As I wrote at the start, through that sharing came the question, “Do you think this textbook-building approach could be extended to other products?”
I caught that question as a seed of insight. “If it can be done, then I should be able to abstract the trajectory I followed into steps that would work for other products,” I thought. Nobody had asked me to do anything; I just started thinking about the method on my own and started a discussion with Claude on my own. Fully self-driving mode. The colleague could have done it themselves, but I had already boarded the ship, and I was in a state where “AI capability expansion lets me actually do this myself,” so I took it on.
The first thing I did was have Claude read the questions I had thrown at Copilot during my Product X learning, and analyze them. “What patterns are in these questions? Abstract them in a product-independent way,” I asked.
Claude found about seven “patterns” in my questions.
The first is “What is X?” — the pattern of asking the identity of the subject.
The second is “How does X differ from Y?” — the pattern of understanding through contrast.
The third is “Are X and Y compatible, or competing?” — the pattern of asking the relationship.
The fourth is “What does the inside of X look like?” — the pattern of decomposing structure.
The fifth is “What are the criteria for choosing X?” — the pattern of asking the practical sense of selection.
The sixth is “In what kinds of work is X used?” — the pattern of asking applied context.
The seventh is “If you compared X to something familiar, what would it be?” — the pattern of bridging through analogy.
These seven, Claude pointed out, are the cognitive paths a beginner almost always travels when trying to understand an unfamiliar product. If I had thrown 28 questions at Product X, abstracting those 28 would always map onto one of these seven patterns — that was the analysis Claude gave me.
This was a small discovery. It was the moment of noticing that “the path I had been unconsciously following had a structure.”
Why Approaches ① and ④ Were Cultivated as Separate Things
Once the seven patterns were found, I threw the next question at Claude: “Using these seven patterns, what kind of workflow could be set up to build textbooks on other products in the same way?”
Claude proposed four approaches.
- Approach ① is the Expert-Interview type. Hand a product expert a question sheet structured along the seven patterns, have them answer it, and have Claude turn the answers into a textbook.
- Approach ② is the Self-Q&A type. The learner themselves frames questions along the seven patterns, researches, and answers their own questions.
- Approach ③ is the Contrast-Learning type. Use a similar product the learner already knows as the main axis, and learn by filling in the differences.
- Approach ④ is the Fully-AI type. Have AI read the product’s catalog and specifications, have AI itself drive a question-and-answer loop based on the seven patterns, and have a different AI turn the result into a textbook.
Of these, I decided to adopt Approach ① and Approach ④. Approaches ② (Self-Q&A) and ③ (Contrast-Learning) were set aside this time, because in cases like mine — where I am learning the target product as a beginner — I do not have the answers at hand to begin with. Depending on the situation, they could still be effective options. Claude’s reasoning for the proposal was interesting. “① and ④ serve different purposes, so they weaken if mixed. They are better built separately.”
Approach ① is an interview sheet designed on the assumption that humans will read it. It is a document for taking to an expert and saying, “When you have time, please answer along these seven patterns.” Approach ④ is a prompt set that, when given to an AI, automatically launches the textbook-creation workflow. The reader is the AI; it is not designed for human reading.
Combining the two into one document would make it redundant for both humans and AI. So they should be separated and finished as distinct things — that was Claude’s proposal. I was convinced by the design rationale, and prepared the two separately.
These would later become the first and second of the companion materials I will share at the end of this article.
That covers the entirety of the Methodology chapter. It is the shortest chapter, but for me it was a small turning-point — the chapter where I came to “have a reproducible procedure.”
Chapter 3: Horizontal Extension
Both Approach ① and Approach ④ Hit Dead Ends
Having extracted the methodology, I decided to try the same thing with a different similar product (which I will refer to as “the other product” from here on). From here, however, a new round of trial and error began.
First, Approach ① (the Expert-Interview type) was unworkable from the start. It is not that there are no internal experts on the other product, but a person whose time I could secure for an interview as a personal project of mine — that I could not find quickly. Approach ① requires a human expert; it does not function in a situation where you cannot easily access an expert.
So I tried Approach ④ (the Fully-AI type). The plan was to have Claude read the catalog and specifications of the other product, and run the seven-pattern Q&A loop automatically.
This too hit a dead end almost immediately. A bit of thought makes it obvious: Claude can only answer within the scope of what is written in the catalog, and a great many “things not written in the catalog but important on the ground” came up. To questions like “In what kinds of work is this product typically used?” or “What do you look at when selecting?”, Claude would reply, “There is no description in the catalog” or “Additional information is needed on this point.”
As the questions piled up, Claude began turning them around and asking me “tell me about this.” I could answer almost none of them. I am not an expert on the other product. When I launched Approach ④, I had not implicitly positioned myself as the knowledge source — but somehow that was the structure that had emerged.
I had ended up in a state where neither Approach ① nor Approach ④ was usable.
Swapping Roles
Here, I changed direction.
I handed Claude the prompt for Approach ① — the Expert-Interview type — and asked, “Use this prompt and act as the interviewer in my place. Build a question sheet about the other product.”
Approach ① was originally designed as a sheet that a human reads and uses. The structure assumed a human interviewer asking the questions of an expert. I was repurposing it as “let an AI read it, and let an AI build the question sheet.”
At this point, Claude initially started to say, “So you are the knowledge source, and I will throw questions at you as the interviewer.” I replied, “No, the other way around.” When I learned about Product X, I was not the knowledge source; I was on the side asking questions as a beginner. My original role was that of “reader’s representative.” What I wanted Claude to do was the role I had played — “to ask sharp questions on behalf of the reader.”
Of course, since Claude is a capable AI, once you specify a product, generating questions about it is trivial; the interview pattern was prepared, so all that remained was to inject questions along that pattern. With this redefinition of roles, Claude generated 30 to 50 questions about the other product as a question sheet.
Next, I handed Claude’s question sheet to Copilot. The instruction was “as an expert on the other product, please answer these questions in detail.” Copilot produced answers immediately, but here a problem came up.
Copilot showed a tendency to retreat into summaries. The answers came back as 2 to 3 line summaries, far from “detailed explanations suitable as textbook content.” This would not work as textbook material.
There is a backstory here. When I built the Product X textbook, I ran 1-question-1-answer Q&A with Copilot. I would throw one question, read the answer, and throw the next question — that flow. In that case, Copilot returned solid, well-considered answers to each individual question. In the horizontal-extension case, however, I handed Copilot Claude’s 30-50 question sheet all at once. Copilot must have applied some kind of context adjustment, and the answers got compressed into summaries.
I asked, “Please go into more detail here,” but it kept returning at an overview level. I imagine it was returning answers under the constraints of session length and how much context it could handle, but this was not going to produce content I could be satisfied with. When I explicitly demanded “do not summarize; please describe in full text, not at the overview level,” only then did deeper writing finally come out. Suppressing the retreat-into-summary required strong prompting from my side.
The first round of answers I finally obtained was thinner than I had hoped. Tallied up, it was about 17,700 characters — well short of the 30,000 characters of the Product X version. To identify the problem questions, I had the response measured for character count per question. I found about 13 thin questions, each handled in around 400 characters on average.
For those 13 questions, I asked Copilot to dig deeper and give detailed answers. The result was deeper writing for those 13. Combining the additional answers from this second round with the first round, the final answer log reached about 40,000 characters. A density beyond the 30,000 of the Product X version. For a target like a measurement device (= in the case of the other product), where physical principles, materials, and piping design carry a lot of weight, thicker description was needed — that came out clearly in the character count.
I then had Claude ingest this Copilot detailed-answer log and instructed it to build the textbook. Procedurally, this is the same as the “Handing the Conversation Log to Claude and Asking for a Textbook” step in Chapter 1. The only difference is that the one driving the Q&A with Copilot was Claude, not me.
Rather than letting one AI do everything, dividing roles among multiple AIs of different characters and stitching them together to drive the overall workflow produced content with greater depth.
What this approach revealed is one example of an answer to “in scenes where the human is not the knowledge source, what role should the human play?” I was not an expert on the other product. But I had a small but distinct role: “I have the seven patterns,” “I can ask Claude to play the interviewer,” “I can ask Copilot to play the expert,” “I can bridge between the two.” Even a non-expert human can engage with a domain in this way — that became visible through horizontal extension.
The Second Textbook Was Completed
I had Claude ingest the Copilot detailed-answer log of about 40,000 characters and produced the textbook for the other product, inheriting the same format as the Product X textbook (binding, chapter structure, callout style). Visually, it came out looking like a sister volume.
The final version is an HTML file of about 2,614 lines and 184 KB. The Product X version was about 3,256 lines and 190 KB, so the line count is a bit lower, but the density is higher.
If I had had more time, I would have put the content through more review rounds and added more questions. But from the standpoint of “responding to a colleague’s question,” I had reached a form where I could report back, “I extended it horizontally!!”, so I called the work done at this point.
Internally, this was “the moment reproducibility was confirmed.” What had worked for one product worked for another. The procedure was not exactly identical, and the role-swap improvisation was needed, but the core methodology applied to the other product as well — that was confirmed.
Closing
What This Article Provides — A Workflow and Its Deliverable
So far I have written about the trial and error I went through, and the workflow extracted from it. The companion materials I will share at the end are both the workflow itself (the question template, the prompt design, the HTML templates) and a deliverable actually produced using that workflow (a Smartphone Edition Textbook).
Sharing only the workflow would likely leave you wondering, “OK, but what can I actually build with this?” Sharing only the deliverable would likely prompt, “Impressive — but how was it made?” By delivering both together, I aim for a state where you, the reader, can do the same yourself.
Looking Back — What Became Visible Through This Experience
Above, I have walked through everything I did. To close, let me leave just three things that became visible across this whole experience.
The first is that there is a “pattern” to how you pose questions to AI. Many readers may already be reasonably familiar with this idea, but trying once to analyze your own question set and extract the patterns reveals frames of thought you had been using unconsciously. I felt this connects directly to raising AI literacy.
The second is that combining different AI models has its own meaning. Cross-review between the same model may not work as well; combining AIs of different lineages enables review, reinforcement, and division of labor. As incorporating AI into work is expected to become more widespread going forward, an “have one AI do everything” mindset alone may run into limits. The literacy of using multiple AIs in combination feels like it will become important from here on.
The third is that even non-experts have room to enter a specialized domain through AI. I was not an expert on the other product. Even so, I was able to build a textbook on the other product. The notion that “precisely because you are not an expert, you can play the role of asking sharp questions on behalf of the reader” is a small but positive discovery for someone like me — close to the customer in a manufacturer’s sales-promotion role.
These three discoveries will be delivered, through the companion materials at the end of this article (the question template, the prompt design, the HTML templates, and the reference deliverable), in a form you can put into practice in your own domain. The aim is not “read and done,” but to reach a state where “starting tomorrow, you can try it yourself.”
Companion Materials
Companion Material #1 — The Seven-Pattern General Question Template Set
This is the seven patterns, expanded into concrete example questions in a product-independent form. Distributed in Markdown. When you take on a new domain to learn, rewriting this template to match your own subject helps you ask questions efficiently as a beginner.
Three Ways to Use the Seven-Pattern General Question Template Set
There are three ways to use the seven-pattern template set.
A) You yourself answer as the expert
For a domain you are well-versed in, use the question template from Companion Material #1 to interview yourself, and have Claude turn the answer log into a textbook. Effective when you want to systematize your own expertise.
B) You interview an expert
If you are not an expert but have one nearby, hand Companion Material #1 to the expert, conduct an interview, and have Claude turn the answers into a textbook. Effective when you want to leave an expert’s knowledge as organizational know-how.
C) Have an AI build a question sheet as a beginner, and have a different AI answer as an expert
This is the structure of “letting AI represent the beginner” that I did in Chapter 3. Hand the seven-pattern template and the target subject/product to Claude to build a question sheet, hand that to a different AI (Copilot, ChatGPT, etc.) to answer in detail, and finally have Claude turn the result into a textbook. This works when you do not have a knowledgeable person you can casually ask nearby. If you want to minimize effort, this approach is the easiest. You only need to touch the manuscript at the review stage afterward, so this feels like the most modern way to use it.
A Sample Reference for Use Case C — Smartphone as the Subject
As an example of Use Case C actually carried out, I had Claude build a question sheet on “smartphones” and also had Claude answer it, and the result was a Smartphone Edition Textbook of about 150,000 characters across 14 chapters. The actual artifact is shared at the end of this article as Companion Material #4, so please take a look if you’re interested.
Here, I will introduce the workflow concept along with the actual prompts.
Step 1: Have Claude build a question sheet
The prompt I gave Claude to build the question sheet was something like the following:
The attached format is a general-purpose format for asking questions about
some particular subject. The questions in this format are classified into
seven patterns. Using "smartphone" as the subject, please devise
questions along this format's patterns. Please devise many questions a
beginner who does not know smartphones would need in order to understand
smartphones correctly and in depth.
Please output as a code block.
The first question sheet Claude generated in response to this prompt contained about 45 questions.
Step 2: Have Claude itself evaluate whether the question sheet is sufficient (the heart of this workflow)
This is the key step in this workflow. Rather than handing the generated question sheet straight to the answering step, you first have Claude itself assess whether it is enough.
Specifically, I asked:
Is this number of questions sufficient to build a textbook from which a
beginner can adequately grasp the overview and reach proper understanding?
Claude answered candidly: “Sufficient to grasp the overview, but as a textbook for ‘correctly and in detail,’ it is insufficient.” Specifically, the analysis was that areas such as communication and networks, security and privacy, the world of apps, the variety of input/output, troubleshooting and maintenance, and location and payment were thin.
Receiving that analysis, I asked Claude to fully reinforce the missing areas, and the question sheet was expanded from 45 to 108 questions. A 2.4× increase in question count, with the chapter structure also rebuilt. Through this process, in addition to the original seven patterns, an ⑧ Security & Privacy pattern was newly added, becoming an opportunity for the template itself to grow.
If you proceed with the question sheet as initially generated, the content density of the textbook caps out there. On the other hand, by having the AI self-evaluate and then expand, gaps you didn’t see initially become clearly visible, and the overall depth of the textbook shifts dramatically. Running the cycle of “initial generation → self-evaluation → expansion” at least once is, in my experience, the key to making this workflow practically useful.
Step 3: Have Claude answer the questions
Hand the expanded 108-question sheet to Claude and have it produce the answers. The prompt I gave Claude to produce the answers was something like the following:
The attached file is a set of questions a beginner who does not know
"smartphones" would have when learning about smartphones themselves.
Please answer each of these questions. To support accurate understanding
of each question, please describe in full text, in detail, without
summarizing and not at the overview level.
Please output as a code block.
Originally I had planned to have Copilot produce the answers, but the question count seems to have been too large — Copilot exceeded its limits and could not produce a satisfactory response. As a result, I had to have Claude produce the answers as well.
Step 4: Hand the answers back to Claude and have it written out in Parts
Have Claude ingest Claude’s answers and produce the textbook body. Because this case was on the scale of 108 questions across 14 chapters, it could not fit within a single session, and Claude proposed an approach of splitting the output into multiple artifacts.
In the end, the 108 questions were split into 5 Parts (Part 1 to Part 5), and we proceeded by writing out from Part 1 in order. Each Part is roughly 50,000 characters, around 180 KB.
Step 5: Carry across sessions using a per-Part handover prompt
After completing the writeout of each Part, I had Claude generate a “handover prompt for the next session,” which was used as the first message of the next session. The handover prompt includes the project background, the structure of all 108 questions, the writing policy, the completed Parts, and the list of questions to be tackled in the next Part. With this, even when the work spanned multiple sessions, style, density, and progress carried over without breaking down.
Step 6: Pour the Parts into the HTML template to produce the textbook
Once all five Parts were ready, I picked one HTML template from Companion Material #3 that matched the desired atmosphere, had Claude ingest it together with the .md files of the Parts, and issued a request like the following. Companion Material #3 contains six template styles (Japanese binding, minimal, notebook, dark, editorial design, cyberpunk), so please choose one that fits the textbook’s theme and target readership.
The attached template is a textbook-format template.
Please pour the "textbook content derived from questions and answers"
in the project knowledge into this HTML format, and output as HTML.
The targeted contents are the following five files:
- Part 1 .md file
- Part 2 .md file
- Part 3 .md file
- Part 4 .md file
- Part 5 .md file
The presentation is already in place, so the work should be limited
to dropping in the headings and body text. CSS is also embedded;
please make use of it to produce the final HTML.
Because the volume is large, please prepare anchors for each item
in the table of contents, and "back to TOC" links at each section break.
This produces the first version of the HTML.
Step 7: Debugging and decontextualization
When you read through the first HTML version, you find a few spots that need fixing. In this case, dragged in by the context of when the answers were generated, certain proper nouns and industrial-domain terms had slipped into the body of the smartphone textbook. These were addressed as a separate task to decontextualize (generalize) the content. This kind of debugging is worth budgeting for as a necessary final-stage step.
That covers the concept of the actual Use Case C process. Companion Material #4 (the Smartphone Edition Textbook), shared at the end of this article, is the deliverable actually produced through this workflow. I hope you’ll see it as proof that “this much can actually be built, in this kind of process.”
Companion Material #2 — Workflow Design Prompt for Claude
This is the prompt set I described in Chapter 2 as “Approach ④” — when given to an AI, it automatically launches the textbook-creation workflow. In Markdown, structured into four phases (Discovery / Structuring / Drafting / Refinement). Hand it to Claude, and through dialogue it will get a textbook draft started.
Companion Material #3 — HTML Templates for the Textbook Format (6 styles + a template-generator)
Six HTML templates with different bindings for use when building textbooks (Japanese binding, minimal, notebook, dark, editorial design, cyberpunk), plus one prompt scaffold for generating additional patterns: template_custom_prompt.md.
There were originally five HTML templates. To verify that the prompt scaffold for generating additional patterns actually worked, I tried having it generate a “cyberpunk-style” template, and it came out as expected. The set is now six templates.
How to Use Companion Material #3
There are two ways to use Companion Material #3.
(1) When you want to generate an additional template style
Have Claude read the included template_custom_prompt.md, then issue a request like:
Referring to template_custom_prompt.md,
please generate a template in 〇〇 style.
In the “〇〇 style” portion, write the atmosphere you want (e.g., “picture-book style,” “newspaper style,” “academic-paper style”). It may also work with AIs other than Claude (ChatGPT, Copilot, Gemini, etc.), but with no guarantee.
(2) When you want to pour textbook content into a template and produce the final HTML
Have AI read both the textbook content (the body text derived from the questions and answers) and the HTML template file from Companion Material #3 at the same time, and issue a request like:
The attached is a textbook-format template.
Please pour the attached "textbook content derived from questions and
answers" into this HTML format, and output as HTML. The presentation is
already in place, so the work should be limited to dropping in the
headings and body text. CSS is also embedded; please make use of it
to produce the final HTML.
These prompts are starting-point examples; please adjust the details to match your own subject, chapter structure, and content volume. If you say “could you do it more like this” within the AI dialogue, it will, in most cases, accommodate.
Companion Material #4 — Reference Deliverable: Smartphone Edition Textbook
As an example of a deliverable actually produced by applying the workflow described in this article, I am also delivering “Smartphone — A Beginner’s Introduction: 108 Questions Untangled” (14 chapters, about 150,000 characters).
This is the very textbook that was actually built using Companion Materials #1 and #3. If, while reading this article, you find yourself wondering, “OK, what does the result actually look like?”, please take a look at this. It serves both as proof that “this much can actually be built using the methodology in this article” and as a piece of reading material in its own right.
A note: due to the author’s background of long involvement in instrumentation work, parts of the body include comparisons and analogies with PLCs and industrial equipment. Reading it as an “introduction to how smartphones work” may make a few spots feel slightly out of context — please be aware of this in advance.
Terms of Use for the Companion Materials
Please feel free to use Companion Materials #1 through #4 under the following conditions.
What you can do
- Use them freely for your own work, learning, in-organization education, and the like
- Freely modify the contents to suit your own subject
- If you build your own textbook or document using these materials and publish or sell it, please include a “Powered by SRW” credit on the final page or similar
What we ask you to refrain from
- Please refrain from redistributing the companion materials themselves as is (or in substantially similar form) to third parties, or selling them as a paid product
- The materials shared in this article reflect the trial and error of the entire chain of work, including the article itself. The reason we ask you to refrain from redistribution and resale is to ensure that this accumulated effort is treated appropriately
What would make us happy
- If, on the final page of a textbook or document you build using these materials, you leave a small “Powered by SRW” signature, a link to this article, or an SRW introduction blurb, the person inside (= me) would be quietly delighted
Download the Companion Materials Here
After reviewing the terms of use, you can download the full set from the page below.
→ Companion Materials Package INDEX
The INDEX page provides links to each file (#1 through #4) and their respective version information.
Note: The companion materials are currently available in Japanese only. An English version is not provided at this time.
What’s Coming Next
Across these two articles (SP05 and SP06), I have written about building textbooks with AI. If the workflow set and the reference deliverable I have shared as companion materials connect to something for the readers who took the time, I would be glad.
That said, looking back, the six articles from SP01 to here have all been about not the main business of SRW, but byproducts that emerged on the way to the main business. The next thing I plan to write about — DataMigrator — is also a byproduct, not the main business. It seems some more sorting out of byproducts is needed before I can reach the main business itself.
From the next article, I will move into the development record of the first product I started under SRW: DataMigrator. The story is set to begin with “I vented to AI about data-migration hell, and that lit the fire.”
About Soul Resonant Works
Soul Resonant Works is a solo venture developing seven local AI systems. Starting from zero programming experience, the development is progressing through collaboration with AI.
🌐 Soul Resonant Works:
→ https://www.sr-works.net/en/
📝 This blog publishes the entire development process as a serialized journal.
If you found this article useful, please share it.