Capstone with Iskin: an interview, a site and a critical review

An interview with Iskin is a conversation where an AI asks about the brief’s fields and builds a site and a service from the answers; a person checks it.

From a prompt to someone who asks

Recall the path of this part. First you described a site to a builder and got a template. Then you learned to set a task as a brief, to check the output and to assemble a pipeline with checks. A logical step remains: not to wait for a prompt, but to ask. We saw it in the lesson on prompts as briefs as the technique “let the model ask back”: if data is missing, let it ask questions instead of making things up.

That is how Iskin works: the name this textbook gives to such a conversation partner. It doesn’t take one long prompt but conducts an interview on the brief’s fields, writes down the answers, and then builds from them a site and a service “turnkey”: the structure, the text, the code and whatever the main action needs (a form and a receiver of requests, a booking, an order). In the prologue you saw it in the last frame: Echo asks the next question of the interview.

A caveat about what is real here. In the textbook the interview and the build are shown in a teaching mode: the questions are written in advance, no model runs, and the page shows what the interviewer would do with your answers. For the real abilities of the Iskin project, see the NoeticEcho site. But you can apply the principle right now with any model: ask it to put questions about the fields of your brief before it writes a single line.

Eight questions

Every question of the interview has a reason, and it is tied to a field of the brief. What you do: from it come the heading and the first paragraph (otherwise there would be a slogan). For whom: it decides the words and the order. What the visitor must do: this is the main action the page is built around. Which sections: the structure and the menu. What you offer: the content of the cards (offers must not be invented). What you back it up with: proof is taken only from here, and if there is none, there is no block. How to reach you and what must not be published: contacts and prohibitions you decide. And in what voice you speak, by two of your own sentences.

A good answer is specific and honest. And the main rule of the interview is: “I don’t know” is an acceptable answer. A good interviewer won’t fill a gap for you: in that place there will be an empty field with a note for you, and it won’t be on the page.

Go through the interview in the diagram. Your own brief is filled in, and it can be edited. Press “I don’t know” on any question and see what changes in the result.

This is a demonstration. The questions are written in advance and no model runs: the page shows what an interviewer would do with your answers. Your own brief is filled in, and you can edit it.

Question 1 of 8

What do you do, in a sentence or two?

Why: From this come the heading and the first paragraph. Without your substance, Iskin will write a slogan.

Your answer

Next I don’t know Back

The brief is filled in: 0 of 8. Still empty: who, forWhom, action, sections, items, proofs, contacts, tone.

Check yourself: what does Iskin do if you answered “I don’t know” to the question about proof?

It leaves the place empty and doesn’t invent proof. There will be no block of proof on the page, and in the list for you there will be a note that it needs to be added.

What gets built, and what stays with you

From the answers a site is built (the structure from your sections, the text from your facts and in your tone, the code) and a service for the main action: for booking, a form, a calendar and emails; for a request, a form, a receiver and a notice; for an order, a catalog and payment through a ready-made service. The same things you built by hand in the parts on servers, data and infrastructure.

But Iskin doesn’t decide everything, and that is right. What stays with you: the truth of the facts (only you know it), the policy and consent (you agree the text with an attorney), money (you connect payment deliberately, through a ready-made service), publishing (whether to go live is for you to decide after the review). And above all the review. Any build made by an AI is only a draft until a person has checked it.

The final review: four areas

The review from the lesson on checking AI output becomes wider here. After the facts, security and law that you can already check come four areas that you learned about in the parts on HTML, CSS and quality.

Accessibility. A meaningful image has alt, every field has a label, the text has enough contrast (at least 4.5 to 1 for ordinary size), and the page can be gone through with the Tab key. This is what separates a “button” made of a div and gray text on white from a real page.

Meaningful markup. One h1, the section names as h2, and no jumps of level (after h2 comes h3, not h4). Offers in a real ul list, not in lines with br. If a page looks right but is built as a heap of div, then for screen readers and for agents it is empty.

Text. No empty formulas (“we’d be glad to help you reach new heights”), no exclamation marks, no faceless “Read more” (a link should say where it leads). The button’s label names your project’s action. It is the same plain, informative style as in the part on text.

Speed. Every image has width and height (otherwise the page “jumps” when the image loads). loading="lazy" goes only on images below the first screen, while the main image is visible at once and should load at once: if it is deferred, the most visible element appears later and the LCP figure (the time the main content appears) gets worse. And no outside scripts or fonts without need: each is one more server, one more request and a question for the policy.

Check yourself: why isn’t the main image deferred with lazy loading?

It is visible at once, and deferring its load delays the most visible element of the page: LCP gets worse. Deferred loading is for images below the first screen.

Practice

The capstone. In front of you is your project’s site, as an AI would build it: a heading, a button, two images, the sections, the offers, a note and a form. It has mistakes of all four kinds, and something has to be fixed in the styles. Fix everything in the code and in styles.css, and in the log write at least six finds (what you found and how you fixed it) and say which areas you checked. At the end, answer honestly: is the site ready to launch, and what is left for a person?

The check reads the code and the styles: it will find whether any h4 is left, images with no alt, empty formulas, outside resources, and whether the contrast is enough. But it won’t go through the page with the Tab key and won’t read the text the way you do. After it, do that yourself: press Tab and look at where the focus goes, and then read the text aloud.

What was wrong with 2025

In 2025 an AI’s draft was taken for a finished site: it looked modern, and that was enough. Now it is clear that the real work begins after generating: to check, to fix, to answer for the result. Someone who has been through this book can do it: you know how a page should be built and why. That is the human part of the work.