START FROM ZERO
Learn how to describe what you want, before you build it.
Six short explanations for someone who has never written a prompt, chosen a kind of software, or read a licence. Nothing here is a Skill, and nothing here is for sale.
About ten minutes, end to end. Every section works on its own.
Reviewed Skills LuluSkill has formally published: 17. Each is pinned to one version of its author’s repository, with its licence, author and scan result recorded. LuluSkill links to their instructions and does not host or run them. Other third-party projects appear as directory listings, and the pages below are written by LuluSkill.
See the published SkillsWhat a prompt is, and why the same request gets two different answers
A prompt is the instruction you give an AI tool. That is the whole definition. It is text you type or paste, and the tool on the other end decides what to do with it.
Two people can ask for "a website for my club" and get two very different results, and the difference is almost never the tool. It is what the instruction leaves unsaid: who it is for, what the reader of the site should be able to do, what must not be built yet, and how the two of you will agree that it works.
An AI tool cannot see your situation. It sees the text. So a prompt that would be obvious to a colleague standing next to you is usually incomplete on the screen, and filling that gap is the entire skill this guide teaches.
Three words this page will keep using
In plain words
- Prompt
- The instruction text you hand to an AI tool. In this product it is a written brief for an assistant, and you can always edit it before you use it.
- Assistant
- Any tool that accepts a pasted message and answers it. This page names no product, because which one you already have is a fact about you, not about the prompt.
- Shape
- Which kind of thing you are making: a website, a web app, a mini-program, or a tool that runs on your own machine. It decides what the first version needs.
What a usable prompt states
- The goal in one sentence, in your own words, with the outcome you want rather than the technique you have heard of.
- Who it is for. One audience, named. "Everyone" produces a design decision that fits nobody.
- What already exists — nothing, some notes, or a folder you already have. This is what stops the assistant from inventing material you never had.
- The limits: what must not be built yet, what must not be collected, and anything you are not willing to change.
- How you will know it is done, phrased as something you can check by using it.
- An instruction to state its assumptions and ask its questions before building further. This single line prevents more invented requirements than any other.
The same request, twice
Example
Why one of these produces something you can use
- First attempt: "make me a website for my club events".
- What comes back: a generic page with placeholder text, a sign-up form nobody asked for, and questions about colours.
- Second attempt: "I run a small club. I want one page that lists the next three events with date, place and a short description, so a member can read it on a phone. I have nothing yet. Do not add sign-up, payments or a login for the first version. It is done when I can add an event by editing one file and the page shows it."
- What comes back: a page you can read on a phone, one place to edit, and a list of the assumptions it made so you can correct them.
The second attempt is not longer because it is more polite. It is longer because it answers the five questions the tool cannot answer by itself.
The short version: how to write your first prompt
You do not need a template to start, and you do not need to know any special wording. You need to answer a few questions about your own situation, in ordinary language, and then put the answers in one place.
The order below matters more than the wording. Each step makes the next one easier, and a step you cannot answer is itself useful information: it is usually the thing you have not decided yet.
Seven steps, in this order
- Write the goal as one sentence about the result: "I want a page where a member can see the next three events." A sentence about a technique ("use a database") is a decision, and it belongs later.
- Name the one person it is for first. A member reading on a phone is a different product from an organiser editing on a laptop.
- Say what you have now: nothing, some notes, or an existing folder. Then say what you do not have, so it is not invented for you.
- Describe the one path that has to work end to end. Not every feature — the single path. For the club page: open the page, read the next event, know where it is.
- Write down what must not be included yet. A first version with a login, a payment form and a newsletter signup is a first version that is never finished.
- Say how you will check it. "It is done when I add an event and see it on my phone" is a check; "it looks good" is not.
- Add one line asking it to list its assumptions and the questions it would ask before going further. Then answer those questions in the same conversation.
Four habits that make a prompt usable on the second read
- Write it as instructions to a person who has just joined and has not seen your notes. That is the situation the tool is actually in.
- Prefer a stated gap over a guess. "I have not decided the colours yet" is more useful than a plausible guess you will have to undo.
- Keep the reader's own words. Your phrase for the thing ("member", "session", "the board") is part of the requirement; a synonym you did not choose makes the result subtly wrong.
- Never put a password, an API key, a token or a private key in a prompt. Instructions are text that travels; secrets are not instructions.
From one sentence to a first version
Example
The same idea, first as the reader said it, then as a prompt
- What you said: "I want to keep track of who signed up for the club events."
- The shape that fits: a web app, because the records have to be kept per person and only the organiser should change them.
- The goal sentence: "I want an organiser-only list of who signed up for each event, so I can check names the day before."
- The hard limit: "First version is one event and one list. No payments, no automatic email, no member accounts."
- The check: "It is done when I can add a name by hand and see it under the right event, and a member cannot open the list at all."
Nothing here is a technique. It is the same idea, with the decisions that were already in your head written down.
Read the full article:From a vague idea to a prompt you can use
The short version: which of the four shapes to build first
The four shapes are not skill levels and none of them is the "real" one. Each is a different answer to where the thing lives, who can reach it, and where the data stays.
Pick the shape from the situation, not from ambition. The cost of choosing too large is that the first version never ships; the cost of choosing too small is a rebuild you can plan for. That asymmetry is why the deciding fact in each row below is about your audience, not about the technology.
| Shape | Choose it when | Typical first release | The trade-off you are accepting |
|---|---|---|---|
| Website | Information anyone should be able to read: an announcement, a schedule, a small public service, one form. Nobody signs in. | A few responsive pages and one working action. | Lowest friction to share: a link works for everyone, and there is nothing to install or sign into. The cost is that it cannot remember anything about a visitor. |
| Web app | People must sign in, records have to be kept, or somebody needs a dashboard. Repeated work rather than a single reading. | Roles, one stored record, one complete path, and the error states that path needs. | Per-person data and permissions fit repeated work, and cost you the account question immediately: who may see what, and how they get in. |
| Mini-program | Your audience already lives inside one messaging platform, and the thing genuinely needs that platform's own sharing, payment or location behaviour. | One platform-native core flow, not a copy of the whole product. | Convenient for that audience, and expensive for you: platform review, platform rules and platform versions become part of your maintenance. |
| Local tool or script | One person or one team needs to do repeatable work on files that are already on a computer, and the work should not leave that machine. | One input, one review step, one output — with a way to see what it would do before it does it. | Access stays scoped and no public system is created that nobody asked for. The cost is that it helps exactly the people who have that computer, and nobody else. |
Example
How to choose in one minute
- If nobody needs to sign in and nothing has to be remembered per person, start with a website.
- If the value is in the record — who signed up, what was paid, which item is where — start with a web app, and expect the account question in the first version rather than later.
- If the audience is in one platform and the platform feature is the point, a mini-program can be right. If the platform feature is only convenient, it is not.
- If the material must not leave a machine, or the work is about files on a disk, choose a local tool and keep the first version to one input and one output.
- If two shapes both seem right, choose the smaller one for the first version and write down what you would need to see before growing it.
Read the full article:Website, web app, mini-program or local tool: how to choose
The short version: pages, data, permissions and one flow for a first version
A first version is not a smaller copy of the finished product. It is the smallest thing that answers the question "does this help the person I had in mind?". Everything below is in service of answering that question once.
Four answers are enough: which pages exist, what data is kept, who may do what, and the one flow that has to work from start to finish. If you cannot answer all four, the first version is not defined yet — and writing a prompt will not define it for you.
Pages the first version needs
Start with the fewest screens that let the main action happen. Every screen you add is a screen somebody has to keep working.
- For a website: the reading page, plus one page per distinct thing a visitor needs to read, and a way to reach them from the first page.
- For a web app: a sign-in screen, the list of records, one record's detail, and the form that creates or changes a record.
- For a mini-program: one entry screen and the single native flow, with the platform-required permission screens reached only when the flow needs them.
- For a local tool: the input selection, the review of what it will do, and the result — three states of one screen is usually enough.
- In every shape: one written sentence for what the reader sees when there is nothing to show yet, and one for when the thing they asked for fails.
Data it has to keep
Keep only what the main action needs, and be able to say why each field exists. A field you cannot justify is a field you will have to protect, migrate and explain later.
- A public reading page needs to keep nothing about the visitor. That is the point of choosing it.
- A record that belongs to a person needs an owner, and the owner is the whole permission model for the first version.
- A local tool may keep nothing at all beyond the files the person already has. If it cannot say that, the first version is collecting more than it needs.
- Write down the one piece of data you would delete if you had to, and how. A first version with no answer to that is a first version with an unplanned liability.
Permissions and access
Decide who may do what before you build it, because it is cheap now and structural later.
- For a website: everybody may read, and nobody may change anything. Administration happens outside the public page.
- For a web app: at least two roles — the person whose record it is, and the person who can see all of them. Write both down, even when the first version has one user.
- For anything that runs on a machine: say what it may read, what it may write, and what it must never touch. The default is nothing, and access is granted one thing at a time.
- Never let a first version hold a password, a key or a token that belongs to somebody else. Say in the prompt that secrets are out of scope.
The one flow that has to work
One path, written as steps somebody can follow with a finger on the screen. If you cannot narrate it, it is not defined yet.
- Write it as: what the person does, what they see, and what tells them it worked.
- Name the failure for each step, and what the person should do instead. "It shows an error" is a state nobody can recover from.
- Say what happens at the very first use, when there is no content and no record yet. That is the state every real person meets first.
- If the flow needs a decision you have not made, write it down as an open question rather than choosing silently inside the prompt.
What a first version should leave out
- Accounts, when nothing has to be remembered per person yet.
- Payments, which bring legal, refund and fraud questions that dwarf the feature.
- Notifications and automatic email, which need a sending identity and a way to stop them.
- Search, sorting and filters, until there is enough content for them to matter.
- Importing or copying somebody else's material — including a third-party Skill — before you have read what it does and what it is licensed under.
Read the full article:From a prompt to a first version: pages, data, permissions and the key flow
The short version: When you should not use — or publish — a third-party Skill
A third-party Skill is somebody else's packaging of instructions, and sometimes of code, that you would run or follow. It can save a week, and it can also import a licence you did not read, a permission you did not intend to grant, and a dependency that will be abandoned next year.
None of the guidance below is a claim about any particular Skill, and this guide checks none for you — which is exactly why the rules have to come from you rather than from a rating.
Do not reach for a Skill at all when
- The work involves secrets, credentials or personal data of people who did not ask to be in your experiment.
- The thing would run with more access than you can supervise — file writes, shell commands, network calls, or deletion — and you cannot review what it does first.
- You cannot state the licence it is under, or the licence forbids what you want to do with it. "Free to use" is not a licence, and a repository with no licence file is not permission.
- You cannot identify the exact version you are relying on. Something that changes under you is not a dependency, it is a surprise.
- You would have to hand over your own users' data, or the Skill would send it somewhere you cannot name.
- The task is small enough to describe yourself in one paragraph. Describing it is faster than evaluating somebody else's answer to a slightly different problem.
- Nobody is maintaining it, and you are not willing to maintain it yourself. An unmaintained dependency is a decision to own it later, without choosing when.
Do not publish a Skill into a shared place when
- It contains material you did not write and cannot license — a copied prompt, a scraped page, somebody else's example data.
- You have not run it against the case it claims to handle, on a version you can name.
- Its permissions are broader than its stated purpose, and you have not said why.
- It handles secrets, credentials or personal data, and you have not written down what it does with them.
- It would be published without the facts a reader needs to judge it: what it does, what it touches, what version, what licence, what it does not do.
What to do instead
- Describe the task yourself and start from the shape that fits, exactly as this guide does above. Most first versions do not need anybody else's Skill.
- Read the source before you decide it is small. Its size is a fact you can check, and the first file you read is usually the one that tells you.
- Check the licence text itself. If there is no licence, treat the default as "no permission", not as "probably fine".
- Keep a note of what you evaluated and why you said no. The next person — often you, in six months — will need it.
Read the full article:Before you use someone else's AI Skill: licence, permissions and source
Where advertising may appear on this site, and where it never will
This page states the advertising boundary rather than only describing the product, because a boundary that is written down only after an advertisement exists is a boundary that was fitted to the advertisement.
Public discovery and reading pages may carry clearly labelled advertising after the main task entrance or at natural content breaks. AdSense retains at most one on this overview, and at most two on a long article. Adcash manual Display placements have configurable trial limits of one to two on mobile and two to three on desktop, with fewer on short pages. Missing Zone configuration, empty results and failed reads produce no advertising. A single baseline Zone is used at most once per document.
Pages that may never carry advertising, in any state
- The guided start and every result it produces: the questions, the prompt and the plan.
- Projects, saved work, matching and selection.
- Anything to do with running, approving or reviewing a workflow or its permissions.
- Sign-in, sign-out, access gates, account and preference screens.
- Error states, empty results, loading states, legal notices and documents carrying URL parameters.
- Security review and moderation, technical documentation, file previews and private input tools. Signed-in visits also stay free of third-party advertising.
The rules an advertisement has to satisfy here
- It is labelled as an advertisement and as a sponsored placement — the two visible words are Sponsored and Advertisement — in the reader's own language, above the unit and outside it.
- It never looks like a product action: no button styling, no Skill-card styling, no call to action that resembles a control on this site.
- It reserves its own space, so that nothing below it moves when it appears.
- It is never a recommendation, never influences which Skill is suggested, and never sits beside a task the reader is in the middle of.
- It is not tracked with this product's own data. Your goals, prompts, plans and identity are not advertising data and are not sent to anybody for advertising.
What a real advertisement would also require here
- Approval from Google is required before Google AdSense advertising can be enabled. Google AdSense is not enabled here; an authorized ads.txt file does not mean the site has AdSense approval.
- For AdSense, an allowlist entry that names this exact deployment, written in the code and reviewable in a diff. It has not been added. Adcash has its own reviewed runtime configuration and serving switch; enabling it suppresses AdSense on the same page.
- The owner has authorized the Adcash Display launch on public pages, subject to explicit visitor permission. This launch decision does not claim platform approval or income.
- A verified advertising account identifier supplied by the deployment runtime. Public Zone identifiers travel in official ad requests only after consent. Provider secrets stay on the server and never enter source, browser storage, logs or downloads.
- A consent mechanism — Google's own consent message for visitors in the European Economic Area, the UK and Switzerland, with a way to refuse and a way to withdraw — and an answer from it before any advertising script loads. It is not live yet.
- A file published at the root of the real public domain, holding exactly the line the advertising account provides. That file is now published from the server's configuration; a guessed identifier must never be.
- No outbound link written by this site. A unit would carry its own destination, and this product would neither wrap it nor redirect it through anything of its own.
Adcash Display is available on eligible public reading pages after explicit permission. No Adcash advertising script loads before consent; rejection and withdrawal remain available in Advertising privacy settings. Google AdSense is disabled. If Google AdSense is enabled after its required checks, this page would show at most one clearly labelled Google advertisement, after the content, and a long article at most two: one between two sections partway through and one after the content. It would never appear in Studio, in projects, in your account or on sign-in pages.
Where to go next
Choose a Skill thoughtfully
Check fit and limits for a pinned version: LuluSkill’s own judgement, not the project’s documentation.
Development
- Review API changes from the consumer’s point of viewThe reviewed API-design entry emphasizes contracts and observable behavior. A clearer server implementation is useful only if callers can still interpret its responses.
- Pick one specialist before adopting the workflow suiteA broad engineering collection is most useful when narrowed to your framework and task. Project-management integrations are separate dependencies, not automatic capabilities.
- Choose the next engineering decision, not every workflowThe reviewed entry routes between problem discovery, design, planning and implementation. Treat the route as a decision aid rather than evidence that work has been done.
- Use staged development when the decisions justify itDesign discussion, planning, implementation and review can prevent premature coding. They still need real deliverables and a host that supports the selected workflow.
- Review SwiftUI against the app you actually shipModern API advice needs a deployment-target check. Use a prioritized review to improve existing views without silently changing supported devices.
Research
- Multiple search providers still need one evidence standardProvider routing can widen discovery, but repeated search hits are not independent confirmation. Keep source provenance and service permissions explicit.
- Keep source verification separate from polished reportingA journalism toolkit can organize evidence and drafts. It cannot turn an unconfirmed claim into a publishable fact or supply missing interview consent.
- Separate research orchestration from scientific evidenceA broad AI-research library can route between technical disciplines. Its coverage claims are not evidence that an experiment, result or paper has been validated.
- Agree on the research outline before expanding the searchA staged research workflow is useful when scope is the main uncertainty. Approval of an outline establishes a question, not the truth of the eventual answer.
Writing
- Keep marketing advice tied to one user actionShared product context can connect copy, conversion and measurement work. A recommendation becomes useful when the action, evidence and limits are explicit.
- Improve prose without losing the facts or the writer’s voiceA style edit should preserve claims, uncertainty and useful personality. Natural-sounding prose is not evidence of factual accuracy or original authorship.
- Before you adopt it: an independent controlled-language rewrite passWhat this writing skill enforces, why it is not the aerospace standard it is named after, where its hard limits help and where they damage good prose, and how to check a rewrite kept every fact.
- Choose the technical document before choosing the wordingA runbook, decision record and interface contract have different obligations. Structure helps only when conclusions remain grounded in the supplied evidence.
- Define campaign evidence before asking what to scaleCampaign analysis and conversion audits need real inputs with comparable units. A marketing workflow is not permission to spend, publish or change a live campaign.
Data
- Choose the comparison before simplifying the chartA chart can look cleaner while becoming harder to interpret. Use these design rules after defining the question, units and audience.
- Before you adopt it: one skill from an ML pack, and the installer that comes with itWhy the per-skill judgement matters more than the pack, what the data-cleaning skill actually enforces, the installer that writes into your agent folders, and how to verify a cleaned table did not leak.
- An ML audit needs an existing experiment and an unresolved-use warningThe reviewed entry audits an existing evaluation report rather than training a model. This reading note does not resolve the pending licence variant or approve execution.
Design
- Decide whether a diagram adds informationUse a diagram to expose relationships, not to decorate a list. Separate the semantic structure from the visual style and export format.
- Before you adopt it: interface copy standards with the numbers attachedWhat this skill fixes, what it does not, which parts are cited research and which are house opinion, and how to run it against an existing product instead of starting from nothing.
- Before you adopt it: a design-token method, and two skills that want a live siteHow the palette skill derives a full system from one brand colour, why the tone of the rules is the real product, which two skills reach out to the network, and how to check a derived palette for contrast.
- Treat a generated design system as a proposalA matching style recommendation is a starting hypothesis. Your content, existing components and interaction checks decide whether it belongs in the product.
- Choose a design mode before changing an interfaceAn audit, a redesign and a reference study require different permissions and outputs. Use that distinction to keep visual ambition within the task.
- Turn your real component documentation into an agent entryThe reviewed file is an illustrative design-system entry. Its value is the routing pattern; its example imports are not proof that your project has those components.
Productivity
- Connect one personal workflow before connecting everythingMeeting notes, voice input and a knowledge vault cross different privacy boundaries. Start with a small, reversible flow using non-sensitive material.
- Build a source-linked study vault before trusting the quizSetup and tutoring solve different problems. Correct extraction and source links matter more than a convincing explanation or a high generated quiz score.
- Before you adopt it: planning documents for a project that has not startedA reading guide to the planning skill: what it asks before it writes, what four documents it produces, which parts are interactive only, and how to tell a real plan from a plausible-looking one.
- Distinguish vault file editing from controlling ObsidianMarkdown, database views and canvas files are different artifacts. File guidance does not automatically provide application access or web extraction.
- Keep durable task state without confusing it with completed workFiles can preserve plans and findings between sessions. They help only when observations, decisions and unfinished tasks are recorded accurately and ownership is clear.
- Turn product assumptions into decisions you can testA product-management framework can structure uncertainty. It cannot supply missing customer evidence, validated demand or a reliable forecast.