Kiro = VS Code + AI Agent

• IDE - Integrated Development Environment. Where you write code.
• AI Agent - A built-in assistant that can read your files, run terminal commands, create scripts, and explain anything.
• Key difference from ChatGPT: Kiro sees your actual project files, can edit them directly, and runs commands in your real terminal.

Prompt = Your instruction to the AI

• A prompt is NOT a question — it is a specification. The more precise your spec, the better the output.
• Think of it like ordering food: "food" gets you something random. "Pasta carbonara, no mushrooms, al dente, extra parmesan" gets you exactly what you want.
• In this program, prompt quality IS your productivity. A developer who prompts well produces 5x more than one who prompts poorly.

5 Elements of an Effective Prompt

1. CONTEXT — What project, what tech stack, what existing patterns. Without context, AI guesses blindly.
2. TASK — What specifically you want done. Be precise. Not "make a form" but "create a login form with email and password fields with validation."
3. CONSTRAINTS — Rules to follow. "Use CSS variables." "No hardcoded values." "Follow BEM naming."
4. FORMAT — How you want the output structured. "Separate files." "Include comments." "Use TypeScript."
5. EDGE CASES — What about errors, empty states, limits? "Handle loading state." "Show error message if API fails."

Experiment (do together, live on screen)

Prompt 1 (bad):

make a button component

Prompt 2 (good):

Create an Angular standalone component called PrimaryButton. It accepts a label input (string) and emits a clicked output event. Style: background var(--color-primary), white text, border-radius 8px, padding 12px 24px, hover darkens by 10%. Disable state: opacity 0.5, cursor not-allowed. Include aria-label that matches the label input.

Compare the two outputs side by side. Which one is production-ready?

Markdown — the language between humans and AI

• .md stands for Markdown — a simple text format with minimal formatting
• Headings use # symbols: # Big heading, ## Smaller heading
• Bold uses double stars: **bold text**
• Lists use dashes: - item one
• Code uses backticks: `code here`
• Why .md for AI work? Because AI reads and writes Markdown perfectly. It is the universal language between humans and AI tools.
• You will use .md files for: steerings, READMEs, documentation, notes — everywhere in this program.

Hook = An automatic action triggered by an event

• Kiro has a feature called Hooks - scripts that run automatically when something happens
• We use the UserPromptSubmit trigger - fires every time you send a message in the AI chat
• The hook runs a bash script (type: command) - zero AI credits consumed
• The script receives your prompt as JSON on stdin, extracts it, and saves it to a file
• Files are organized by day: prompts/2026-08-10.md

Script = A file with commands that the terminal runs in order

• Instead of typing 5 commands one by one, you put them in a file and run it once
• File extension: .sh
• First line is always: #!/bin/bash (tells the system to use bash to run it)
• You make it executable with: chmod +x script.sh

Three Ways to Configure Kiro

• Steerings (.kiro/steering/*.md) — Permanent rules Kiro follows in every interaction. Like company policies for your AI assistant.
• Hooks (.kiro/hooks/*.json) — Automations that trigger on events. "When X happens, do Y automatically."
• Skills (.kiro/skills/) — Specialized capabilities. Modes Kiro can switch into for specific tasks.

The Prompt (type in Kiro chat)

Create a steering file at .kiro/steering/coding-standards.md with these rules:
- Use camelCase for variables and functions
- Use PascalCase for classes and components
- All code comments must be in English
- No magic numbers — use named constants
- Maximum function length: 20 lines
- Prefer const over let, never use var
- Every public method needs a JSDoc comment

Kiro creates the file. Verify it exists. Read its contents. From now on, every piece of code Kiro generates follows these rules automatically.

The Prompt

Create a Kiro hook that fires on SessionStart. The hook type must be "agent" (not command). The prompt should say: "This is the DevLaunch training project. We use Angular 19 with standalone components, PHP 8 backend, MySQL database, SCSS for styles. Follow all rules in .kiro/steering/." Save it as .kiro/hooks/session-context.json

Now every time you start a new chat session, Kiro already knows your project context. You never repeat yourself.

The Prompt

Create a Kiro hook that fires on PreToolUse with a matcher for "fs_write|str_replace". Type must be "agent". The prompt should say: "Before writing, verify: no hardcoded color values (use CSS variables), semantic HTML tags, proper TypeScript types (no any), and meaningful variable names." Save as .kiro/hooks/quality-check.json

This hook checks quality BEFORE Kiro writes any file. Automatic code review on every change.

The Prompt

Create a steering file at .kiro/steering/git-rules.md with these rules:
- Commit messages use Conventional Commits format: feat:, fix:, docs:, refactor:
- Never commit directly to main branch
- Branch naming: feature/short-description or fix/short-description
- Each commit should be one logical change
- Always write a meaningful commit message that explains WHAT and WHY

Git in 60 Seconds

• Git - Tracks changes to your files. Like save game for code.
• Repository (repo) - A project folder tracked by Git.
• Commit - A snapshot. Here is what my project looks like right now.
• Push - Upload your commits to GitHub (online).
• Pull - Download changes from GitHub to your machine.
• GitHub - A website that stores your repos online. Free for everyone.

Git = Save Game for Your Code

• Git tracks every change you make. Like unlimited undo history for your entire project.
• GitHub stores your code online. Backup + collaboration + portfolio.
• Commit = one save point. A snapshot of your project at a specific moment.
• Push = upload your saves to GitHub. Pull = download changes from GitHub.

Today we just need: init, add, commit, push. Kiro handles the actual commands.

Step 1: Configure Git identity

Ask Kiro:

Configure git globally with my name "[YOUR NAME]" and email "[YOUR EMAIL]". Then initialize a git repository in the current project folder.

Step 2: Create a GitHub repo (manual step)

Do this in your browser — NOT in Kiro:

1. Go to github.com, click + button, New Repository
2. Name: prompt-log
3. Visibility: Private
4. Do NOT check any boxes (no readme, no gitignore)
5. Click Create Repository
6. Copy the HTTPS URL

Step 3: Connect and push (via prompt)

Back in Kiro, type:

Connect this git repo to my GitHub remote at https://github.com/[USERNAME]/prompt-log.git. Set the branch to main. Stage all files, commit with message "feat: initial setup with Kiro steerings and hooks", and push to origin main.

Every day / every session:

1. Use Kiro to work - prompts are logged AUTOMATICALLY (hook is active)
2. At end of session: run ./sync.sh to push everything to GitHub

What We Are Building

• A Kiro Hook that fires on UserPromptSubmit (every time you send a message)
• It runs a bash script (type: command) — zero AI credits used
• The script saves your prompt text + timestamp to a daily markdown file
• Files organized as: prompts/2026-08-10.md, prompts/2026-08-11.md, etc.
• Completely automatic. You use Kiro normally and everything is recorded.

Quick explanation

• A script is a text file with commands inside. Run the file = run all commands in order.
• First line: #!/bin/bash — called a shebang. Tells the OS: use bash to run this.
• Make it runnable: chmod +x filename.sh — gives execute permission.
• They will NOT write scripts manually — Kiro does it. But they need to READ what Kiro generates.

The Prompt

I need an automatic prompt logging system. Create two things:

1. A bash script called log-prompt.sh in the project root that:
   - Receives JSON on stdin from a Kiro UserPromptSubmit hook event
   - Extracts the user prompt text from the JSON payload
   - Creates a "prompts" directory if it does not exist
   - Appends the prompt to a markdown file named with today date (YYYY-MM-DD.md)
   - Each entry has the time (HH:MM:SS) as a heading and the prompt in a code block
   - If the file is new (first entry of the day), adds a "# Prompts — YYYY-MM-DD" header first
   - Make the script executable (chmod +x)

2. A Kiro hook file at .kiro/hooks/prompt-logger.json that:
   - Triggers on UserPromptSubmit
   - Action type is "command" (NOT agent — this must not consume AI credits)
   - Runs: bash ./log-prompt.sh

Important: the hook type MUST be "command" not "agent".

After Kiro creates the files:

1. Type anything else in Kiro chat (that prompt itself got logged!)
2. Ask Kiro: Show me the contents of the prompts folder. Is there a file for today?
3. You should see today date as a filename with your prompts inside
4. If it does not work, ask: The prompt logger hook is not working. Check if log-prompt.sh has correct permissions and if the hook JSON is valid.

Your turn to write the prompt (try first!)

Think about what Kiro needs to do: stage all files, commit with a meaningful message, push. Write the prompt yourself. Try for 1 minute.

Example:

Add all new and changed files to git, commit with the message "feat: add automatic prompt logger and initial prompts", and push to origin main.

• Learned what prompt engineering IS and why it is the #1 skill (5 elements)
• Created 2 steerings — permanent rules Kiro follows forever
• Created 2 hooks — session context + quality check automations
• Connected to Git and GitHub using only prompts
• Built an automatic prompt logger — real tool, zero manual coding
• Pushed everything to GitHub for backup and review

Required (due before next session):

1. Use Kiro daily — At least 10 meaningful questions (not just "hi"). Logged automatically.
2. Push daily — End of day: "Commit all changes and push to GitHub with today date."
3. Create README.md — Ask Kiro to write one explaining the project, the logging system, and what steerings/hooks are.
4. Reflect — Read your prompts file. Which were clear? Which were vague? Rewrite 2 vague ones with all 5 elements.

Session 02: Terminal fundamentals — file system, navigation, creating/moving/deleting, paths. Git and logging already set up so everything is tracked from here.

Everything is Folders Inside Folders

• Your computer is one giant tree of folders. At the very top is the root (on Mac: /)
• Inside root there are system folders, and somewhere in there is YOUR home folder: /Users/yourname/
• Inside your home you have Desktop, Documents, Downloads, and your projects.
• Every file has a unique ADDRESS called a path: /Users/alex/projects/prompt-log/log-prompt.sh

Two Ways to Describe Location

• Absolute path — The FULL address from root. Always starts with /. Like: /Users/alex/projects/prompt-log/prompts/2026-08-10.md
• Relative path — Address relative to WHERE YOU ARE NOW. Like: ./prompts/2026-08-10.md (if you are already in prompt-log folder)
• . = the current folder (here)
• .. = one folder UP (parent)
• ~ = your home folder (shortcut for /Users/yourname)

The Invisible Files

• Files starting with a dot are hidden: .kiro/, .gitignore, .env
• They do not show in Finder/Explorer by default. They exist but are invisible to casual browsing.
• Why hidden? Because they are configuration — you set them once and forget them. They should not clutter your view.
• Permissions (rwx): r = can read, w = can write, x = can execute (run as program)
• Your log-prompt.sh has x permission — that is why it can run. Without x, the computer refuses to execute it.

Skill = Specialized Mode for Specific Tasks

• A steering is always active — general rules for everything.
• A skill is activated ON DEMAND — specialized instructions for a specific type of work.
• Think of it like modes on a camera: Auto mode (steering) works for everything. Portrait mode, Night mode, Macro mode (skills) are activated when you need them for a specific shot.
• Skills live in .kiro/skills/ folder. Each skill has a SKILL.md file with instructions.

The Prompt

Create a Kiro skill at .kiro/skills/html-builder/SKILL.md with these instructions:

When this skill is active, you are helping build HTML pages. Follow these rules:
- Always use semantic HTML5 tags (header, main, section, nav, footer, article)
- Never use div when a semantic tag exists for that purpose
- Every page must have: DOCTYPE, html lang attribute, meta charset UTF-8, meta viewport, title
- Every image must have a descriptive alt attribute
- Every form input must have an associated label
- Use proper heading hierarchy: h1 only once per page, h2 for sections, h3 for subsections
- Include comments marking major sections
- Output clean, indented, readable HTML

The Prompt

Create a Kiro skill at .kiro/skills/code-explainer/SKILL.md with these instructions:

When this skill is active, you are explaining code to a complete beginner. Follow these rules:
- Explain every single line, do not skip anything
- Use simple analogies from everyday life
- No jargon without immediately defining it
- Format as numbered list: line number, the code, then the explanation
- After explaining all lines, give a one-paragraph summary of what the whole thing does
- If the code has a bug or bad practice, mention it at the end

HTML = The Skeleton of Every Web Page

• HTML stands for HyperText Markup Language
• It is NOT programming — it is LABELING. You tell the browser: this is a heading, this is a paragraph, this is a link, this is an image.
• The browser reads your labels and displays the content accordingly.
• Every website you have ever visited — Google, YouTube, Instagram — is HTML underneath.
• Without HTML, the web does not exist.

Every HTML Page Has This

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My Page Title</title>
</head>
<body>
  <!-- Your content goes here -->
</body>
</html>

• <!DOCTYPE html> — Tells the browser: this is a modern HTML5 page
• <html lang="en"> — The container for everything. lang tells screen readers what language.
• <head> — Invisible stuff: page title, character encoding, settings
• <body> — Visible stuff: everything the user actually sees

Building Blocks

• <h1> to <h6> — Headings. h1 is biggest (page title), h6 is smallest. Only ONE h1 per page.
• <p> — Paragraph. A block of text.
• <a href="url">text</a> — Link. Click to go somewhere.
• <img src="photo.jpg" alt="description"> — Image. alt is for blind users and broken images.
• <ul> / <ol> — Lists. ul = bullets, ol = numbers. Items inside use <li>
• <header>, <main>, <section>, <footer> — Semantic sections. They describe WHAT the content IS.

The Prompt (activate your html-builder skill first!)

Create an HTML file called index.html with a personal page about me. Include:
- A header with my name as h1
- A section "About Me" with a short paragraph
- A section "My Hobbies" with an unordered list of 4-5 hobbies
- A section "Links" with a link to my GitHub profile
- An image placeholder (use https://placehold.co/300x200 as src with alt text)
- A footer with "Made with DevLaunch 2026"
- Use semantic HTML: header, main, sections, footer
- Add proper meta tags and page title

After Kiro creates it:

1. Open the file in your browser: File → Open → select index.html
2. You see your page! Your FIRST web page!
3. Change something in the HTML (edit a heading text), save, refresh browser
4. The change appears. That is the development cycle: edit → save → refresh.

Chrome DevTools = See the Code Behind Any Page

• Right-click anything on a webpage → click Inspect (or press Cmd+Option+I on Mac)
• The Elements panel shows the HTML structure of the page
• Hover over elements in the panel → they highlight on the page
• You can EDIT text and styles live (temporarily — disappears on refresh)
• This works on ANY website: Google, YouTube, your own page, anything

Do these steps on YOUR page:

1. Open DevTools (right-click → Inspect)
2. Find your h1 in the Elements panel. Double-click the text. Change it to something funny. See it update live.
3. Find your image. Look at the src attribute in the panel. That is where the image comes from.
4. Now go to google.com. Open Inspect there. Look at how THEY structure their page. Find their logo img tag. Find their search input.

Quick verbal check:

1. What is a steering? What is a hook?
2. What is the difference between command and agent hook types?
3. Show me your GitHub repo — do you have prompts logged?
4. Show me your README — does it explain the system?

Ask Kiro:

Add all new files including index.html and the skills folder, commit with message "feat: add HTML page, skills, and session 2 work", and push to GitHub.

Verify on GitHub: you should see index.html and .kiro/skills/ folder.

• Understand file paths: absolute, relative, dot, double-dot, tilde
• Understand hidden files and permissions (why .kiro is invisible, why scripts need +x)
• Created 2 Kiro Skills — HTML builder and Code explainer
• Built your FIRST HTML page and saw it in a browser
• Used DevTools to inspect and modify pages live

Required (due before session 3):

1. Extend your HTML page — Add at least 3 more sections: a table (your skills with level), a "projects" section with descriptions, and a contact form (name, email, message inputs with a submit button). Use your html-builder skill.
2. Create one custom skill — Something YOU think would be useful. Maybe "README writer", maybe "Bug finder", maybe "Study notes maker". Your choice. Write a one-sentence explanation of why you created it.
3. Prompt reflection — Open today prompts log. Pick your best prompt and your worst prompt. Rewrite the worst one using the 5 elements (Context, Task, Constraints, Format, Edge Cases).
4. Push daily — End of each day: commit and push.
5. Explore with DevTools — Pick 2 websites you use regularly. Inspect them. Find: where is their logo? What tag is their navigation? What font do they use? Write a few observations in a file called devtools-notes.md

Session 03: CSS — making your HTML page actually look good. Colors, fonts, spacing, layout. Your page goes from plain text on white background to something that looks professional.

HTML is structure. CSS is appearance.

• HTML says WHAT things are: this is a heading, this is a paragraph, this is a list.
• CSS says HOW things look: this heading is blue, this paragraph has spacing, this list has no bullets.
• Without CSS, every website looks like a plain text document from 1995. With CSS, you get colors, fonts, layouts, animations — everything visual.
• CSS stands for Cascading Style Sheets. Cascading means: rules flow down and can be overridden by more specific rules.

The Rule Structure

selector {
  property: value;
  property: value;
}

• Selector — WHAT you want to style (which HTML element)
• Property — WHICH aspect you want to change (color, size, spacing)
• Value — The specific setting (red, 16px, 20px)
• Every rule ends with a semicolon. Curly braces wrap the properties.

Example:

h1 {
  color: #6366f1;
  font-size: 2rem;
  margin-bottom: 1rem;
}

This says: find all h1 elements, make them purple, size 2rem, with spacing below.

Where to Put Your Styles

1. Inline (worst — avoid):

   <p style="color: red; font-size: 20px;">Red text</p>

   Styles directly on the element. Hard to maintain. Cannot reuse.
2. Internal / Embedded (OK for single pages):

   <head>
     <style>
       p { color: red; }
     </style>
   </head>

   Styles inside a style tag in the head. Works but mixes HTML and CSS in one file.
3. External file (best — always use this):

   <head>
     <link rel="stylesheet" href="style.css" />
   </head>

   Separate .css file linked to HTML. Clean separation. Reusable across pages. Cacheable by browser.

How to Tell CSS Which Elements to Style

• h1 — Element selector. Targets ALL h1 tags on the page.
• .card — Class selector (dot prefix). Targets all elements with class="card". MOST USED.
• #main — ID selector (hash prefix). Targets the ONE element with id="main". Use sparingly.
• * — Universal selector. Targets EVERYTHING. Used for resets.

HTML:

<h1 class="title">Hello</h1>
<p class="intro">Welcome</p>
<p>Normal paragraph</p>

CSS:

h1 { color: blue; }        /* all h1 elements */
.title { font-size: 3rem; } /* elements with class title */
.intro { font-weight: bold; } /* elements with class intro */
p { line-height: 1.6; }     /* all paragraphs */

Getting More Specific

• header nav a — Descendant: links inside nav inside header
• .card .title — Title elements inside card elements
• h1, h2, h3 — Group: same styles for multiple selectors (comma separated)
• a:hover — Pseudo-class: styles when mouse is over the link
• input:focus — Pseudo-class: styles when input is focused/clicked
• .btn:disabled — Pseudo-class: styles when button is disabled

Simple Rule

• Classes (.name) — For STYLING. Can be reused on many elements. Use 99% of the time.
• IDs (#name) — For UNIQUE identification. Only one per page. Use for JavaScript targets or anchor navigation.
• Never use IDs for styling. Classes are always better because they are reusable and have lower specificity (easier to override).

Controlling How Text Looks

.text-example {
  color: #f1f5f9;              /* text color */
  font-family: "Inter", sans-serif; /* font */
  font-size: 1rem;             /* size (1rem = 16px) */
  font-weight: 600;            /* thickness: 400=normal, 700=bold */
  line-height: 1.6;            /* space between lines */
  text-align: center;          /* left, center, right */
  text-decoration: none;       /* remove underline from links */
  letter-spacing: 0.05em;      /* space between letters */
}

The Box Model — Space Inside and Outside

• Padding = space INSIDE the element, between content and border. Like bubble wrap inside a box.
• Margin = space OUTSIDE the element, between it and neighbors. Like distance between boxes on a shelf.

.card {
  padding: 1.5rem;           /* same on all 4 sides */
  padding: 1rem 2rem;        /* top/bottom  left/right */
  margin: 0 auto;            /* top/bottom 0, left/right auto = centered */
  margin-bottom: 2rem;       /* only bottom */
}

Color Formats

.colored {
  color: #6366f1;                    /* hex: most common */
  color: rgb(99, 102, 241);          /* rgb: same color */
  color: rgba(99, 102, 241, 0.5);    /* rgba: with 50% transparency */
  background: #0f1117;               /* solid background */
  background: linear-gradient(135deg, #6366f1, #06b6d4); /* gradient */
  border: 1px solid #2a2f42;         /* border: width style color */
  border-radius: 12px;               /* rounded corners */
  box-shadow: 0 4px 12px rgba(0,0,0,0.3); /* shadow: x y blur color */
}

How Big Things Are

.box {
  width: 100%;              /* full width of parent */
  max-width: 900px;         /* never wider than 900px */
  height: auto;             /* as tall as content needs */
  display: block;           /* takes full width, new line */
  display: inline;          /* flows with text, no width/height */
  display: flex;            /* flexbox container (next session) */
  display: none;            /* completely hidden */
}

Custom Properties You Define

:root {
  --color-primary: #6366f1;
  --color-bg: #0f1117;
  --color-text: #f1f5f9;
  --color-border: #2a2f42;
  --font-body: "Inter", sans-serif;
  --radius: 12px;
  --spacing-md: 1rem;
}

.button {
  background: var(--color-primary);
  color: var(--color-text);
  border-radius: var(--radius);
  padding: var(--spacing-md);
  font-family: var(--font-body);
}

• Define with double-dash prefix: --name: value;
• Use with var() function: var(--name)
• :root makes them available EVERYWHERE on the page
• Change the variable once = changes everywhere it is used

The Prompt

Create a file called style.css for my index.html page. Use CSS variables for all colors and spacing. Apply a dark theme:
- Background: #0f1117
- Text: #f1f5f9
- Primary color: #6366f1
- Surface/cards: #1c2030
- Border: #2a2f42
- Font: Inter from Google Fonts
- Border radius: 12px for cards, 8px for smaller elements

Style the page with:
- Body: dark background, light text, Inter font, good line-height
- Header: centered name, gradient text on the h1
- Sections: card-like appearance with surface background, border, border-radius, padding
- Lists: remove default bullets, custom spacing
- Links: primary color, no underline, underline on hover
- Image: border-radius, max-width 100%
- Footer: smaller text, muted color, centered, border-top

Also add the Google Fonts link tag for Inter in the HTML head.
Link the style.css file in the HTML head.

Make these changes MANUALLY in style.css (not via prompt):

1. Change the primary color variable to a different color of your choice. See everything update.
2. Add a hover effect on the section cards: slightly lighter background and a subtle shadow.
3. Make the h1 larger. Try different font-weight values: 400, 600, 700, 900. See the difference.
4. Add padding to the body so content does not touch screen edges.

Save your work:

Commit all changes with message "feat: add CSS styling with dark theme and variables" and push to GitHub.

Required (due before session 4):

1. Style a second page — Create an about.html with different content (bio, timeline, fun facts). Style it using the SAME style.css file. Both pages should look consistent because they share variables and base styles.
2. Hover effects — Add at least 3 different hover effects across your pages: color change on link, background change on card, scale/transform on image or button.
3. Experiment with properties — Try at least 5 CSS properties we did NOT cover today. Ask Kiro: "What are 10 interesting CSS properties I have not used yet?" Try them out.
4. Create a color scheme — Pick a brand color you like. Define a full set of CSS variables: primary, primary-hover, background, surface, text, text-muted, border, accent, success, error. Use them consistently.
5. Push daily.

Session 04: CSS Layout — Flexbox and Grid. How to arrange elements on the page. Side by side, centered, responsive. The tools that make real layouts possible.

You are the creative director. Kiro is your developer.

• Today you build a complete landing page for a niche you choose — live, through prompts.
• You will not write CSS by hand. You describe what you want, watch it appear, and refine.
• The skill of the day: break one big scary task into small, clear steps and prompt them one at a time.

Choose ONE. The niche does not matter — the skill does.

• Coffee shop, tattoo studio, indie game, dog grooming, vinyl records, padel club, a bakery...
• Pick something you can picture. You will build a one-page site to promote it.

One "build a website" becomes 6 promptable steps

1. Skeleton — the top-to-bottom structure (flexbox)
2. Grid — a section with cards laid out in a grid
3. Responsive — looks right on phone and desktop
4. Motion — animations and hover transitions
5. Color — a real palette that fits the niche
6. Ship — push it to GitHub

Think of a single shelf of books

• display: flex turns a container into a flexible shelf.
• justify-content spaces items along the shelf (left, right, center, space-between).
• align-items positions items across the shelf (top, center, bottom).
• flex-direction sets the shelf direction: row (side by side) or column (stacked).

Flexbox is a shelf. Grid is a chessboard.

• Grid lays items out in rows and columns at the same time — ideal for cards.
• display: grid turns on the board.
• grid-template-columns defines the columns.
• gap sets the space between every cell — no more fiddly margins.

grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));

In plain words: "make as many equal columns as fit across the row, each at least 250px wide." This gives you a grid that reflows on its own — a taste of responsive design, which is the next step.

A tidy convention so class names never turn into spaghetti

• Block — the thing itself: card
• Element — a part inside it, with double underscore: card__title, card__icon
• Modifier — a variation, with double dash: card--featured

Anyone reading the class instantly knows what belongs to what. We will ask Kiro to name our card classes this way.

One page that looks right on phone, tablet, and desktop

• The HTML stays the same. Only the CSS adapts based on screen size.
• Mobile-first: design for the small screen first, then enhance for larger screens.

1. The viewport tag

<meta name="viewport" content="width=device-width, initial-scale=1"> — without it, phones pretend to be desktop-wide and everything looks tiny. It is already in your file.

2. Relative units (not fixed pixels)

• % and 1fr for widths that flex.
• rem for scalable text and spacing.
• clamp(min, preferred, max) for fluid type: never too small, never too big.

3. Media queries

@media (max-width: 640px) { ... } = "apply these rules only on screens up to 640px wide." This is how the layout changes by screen size.

Two ways to add motion

• Transition = a smooth change between two states, usually on hover/focus. "From normal to hovered, over 0.2s."
• Animation (@keyframes) = a scripted sequence that can run on its own, e.g. on page load. "Frame 0: invisible and low → Frame 100: visible and in place."
• transform (translate, scale, rotate) is the smooth, performant way to move things — prefer it over animating width/top.

A palette is simpler than you think

• Primary — your brand color (buttons, links, highlights).
• Accent — one or two supporting colors for contrast.
• Neutrals — backgrounds and text (near-white, near-black, greys).
• 60-30-10 rule: 60% neutral, 30% primary, 10% accent → instantly balanced.

Color sets the mood — match it to your niche

• Blue → trust, tech, calm
• Green → natural, health, growth
• Warm orange / brown → cozy, food, friendly
• Black + gold → premium, luxury

• Flexbox — the nav row and the centered hero (one-direction layout).
• CSS Grid — the reflowing card section (two-direction layout).
• BEM naming — tidy, predictable class names (block, element, modifier).
• Responsive design — viewport, relative units, clamp(), media queries — works on every screen.
• Animations & transitions — hover micro-interactions and a hero entrance.
• Color theory — a real palette wired into CSS variables, 60-30-10, contrast.
• Developer mindset — you broke one big task into small promptable steps and directed each one.

1. Add one more section to your niche site using ONLY prompts — a testimonials strip, a pricing table, a contact form, or an image gallery. Keep it responsive, on-palette, and name the classes with BEM.
2. One hover effect you did not use today. Experiment.
3. Prompt reflection: open today's prompt log, pick your best and worst prompt, and rewrite the worst one using the 5 elements (Context, Task, Constraints, Format, Edge cases).
4. Push daily.

A site = several pages that link together

• Last session: one page. Today: multiple pages that connect into one website — built by the two of you at the same time.
• Two questions every team must answer: how do we not overwrite each other, and how do we keep one consistent look?

One file, one owner at a time

• Git only conflicts when two people edit the same lines of the same file.
• So we split the pages — each of you owns your own pages — and build the few shared parts together, once.

Decide as a team before anyone builds

1. One shared theme — it is ONE site, so agree on the business/topic together.
2. List the pages — e.g. Home, About, Services, Contact.
3. Split ownership — write down who owns which page. Nobody touches a page they do not own.
4. Shared parts — the design tokens, header, and footer are built together (next blocks).

Consistency comes from shared rules, not talent

• A design system = one shared set of style rules everyone follows.
• Two parts, both built together now: design tokens (a shared style.css) and a design steering (shared Kiro rules).

Build them once, reuse on every page

• Every page shares the same header (with navigation) and footer.
• Build them together now; each of you pastes the same markup into your own pages.

Relative links connect files in the same folder

• <a href="about.html">About</a> → the about page in the same folder.
• <a href="index.html">Home</a> → the home page.
• The active link (the current page) is highlighted so visitors know where they are.

Each of you owns your pages from the PLAN

• Paste in the shared header and footer, use the shared style.css, follow the shared steering.
• Only touch the pages you own. Never edit a teammate's page — that is how you stay conflict-free.
• Each page: same header + footer, then its own unique main content.

The mental model

• main — the official version of the site that should always work.
• branch — your own private copy to build on, without affecting anyone else.
• pull request (PR) — "here is my work, please review and merge it into main".
• You each work on your own branch, open a PR, merge, then pull the updated main.

Why it stays conflict-free

Because you split the pages by owner, your branches touch different files — so merges are clean. If a conflict ever appears, it just means two edits hit the same lines; read the markers and resolve them (Kiro can help).

1. Click through every link

• Visit every page via the nav — no dead links, header/footer identical everywhere, active link correct.
• Broken link? Almost always a filename mismatch (e.g. service.html vs services.html).

2. Design review together

• Look at the whole site side by side and hunt for small inconsistencies (spacing, heading sizes, card styles).
• Fix them by pointing back to the shared style.css variables — not by inventing new values.

• A multi-page website — separate HTML pages linked by a shared nav.
• A shared design system — one style.css of tokens + one Kiro design steering, so both halves look like one site.
• Reusable header & footer — built once, used everywhere, with an active nav state.
• Real collaboration — page ownership, Git branches, and pull requests, with clean merges.

1. Add one more page to the shared site on your OWN branch (e.g. a gallery, pricing, or FAQ page), then open a pull request to merge it. Practice the full branch → PR → merge flow yourself.
2. Polish: pick two inconsistencies from the design review and fix them using the shared variables.
3. Individual practice: keep doing small exercises with everything so far (flexbox, grid, responsive, animations, color, BEM) and push them to your project folder.
4. Prompt reflection: pick your best and worst prompt from today and rewrite the worst using the 5 elements (Context, Task, Constraints, Format, Edge cases).

Good design is learned by looking, not by luck

• Every designer you admire started by studying other people's work on purpose.
• Starting from a blank page produces generic results. Starting from great references produces great results.
• We are not copying pixel-for-pixel — we are studying patterns: spacing, type scale, whitespace, one accent color, hero feel.

When a site looks good, name the reason

• Is it the generous whitespace? The strong contrast? A single bold accent color? A big confident heading?
• Once you can name WHY it works, you can ask Kiro to reproduce that reason in your own site.

Behance vs ThemeForest

• Behance — designers showing off finished concepts. Beautiful, idea-rich, sometimes not built for real browsers.
• ThemeForest — real templates for sale. What you see there actually ships and works in a browser.

Don't scroll randomly — hunt for YOUR niche

1. Search close to your project: [YOUR NICHE] landing page (e.g. "coffee shop website", "travel landing page").
2. Save 3–5 references you genuinely like.
3. For each one, write down the specific element you want to borrow: "the hero with photo left", "rounded cards with soft shadow", "this footer".

The workflow

1. Find an element you love (a card, navbar, hero, footer).
2. Screenshot just that element — on Mac, Cmd+Shift+4 drags a box around exactly the part you want.
3. Drag the image straight into the Kiro chat.
4. Tell Kiro what to build from it.

A picture alone gives a rough clone — add your design system

Example prompt to pair with a screenshot:

Recreate this [PRICING CARD] layout from the screenshot.
Use MY existing style.css variables — my colors, my fonts, my spacing.
Match the structure and the shadow feel, but use my accent color, not theirs.
Keep it fully responsive.

• Kiro reproduces the structure from the image but dresses it in your design tokens, so it fits your site instead of looking pasted-in.

Design is a conversation, not one perfect prompt

• The first result is supposed to be rough. Do not give up — refine it.
• Beginners quit after the first try. Pros expect to iterate.

Be surgical, not vague

• Bad: "make it better" — Kiro can't read your mind.
• Good, small, testable steps:
  • "make the [GLOBE] a bit bigger and remove the text in front of it"
  • "move the [TRANSLATOR DROPDOWN] to the right corner"
  • "keep the country borders visible when it zooms in"
• Look at each result, decide, then give the next small instruction.

Precise visual words get precise results

bigger / smaller · more / less spacing · tighter / looser · softer / harder shadow · move left / right · more / less contrast · calmer / bolder

From a broken map to a rotating 3D globe

• The first map option didn't work — so instead of forcing it, we asked for a different approach.
• Result: a rotating globe that zooms into Europe, pins each available country with its flag and name, and flies country-to-country like a plane landing.
• Then: a language translator added to the navbar.

Three senior habits you used without realizing

1. Abandon dead ends. When option A failed, you asked for alternatives instead of hammering the broken idea.
2. Layer requirements gradually. Rotate → remove background → make bigger → add borders → add flags & names. One layer at a time, checked each.
3. Hit real constraints honestly. A live translator needs a real domain/hosting/service — it can't fully run from a local file. Noticing that is progress, not defeat.

Design review checklist

• Is spacing consistent, or are some gaps random?
• Is there one clear accent color, or a rainbow?
• Does every section breathe, or is anything cramped?
• Is text easy to read — enough contrast, not too small?
• Does it look intentional on mobile, not just squished?

• Study real designs on Behance & ThemeForest — and name WHY they work.
• Screenshot-to-code — show Kiro an element, pair it with your design tokens, get a block that fits your site.
• Fine-tuning — small, precise, one-change-at-a-time prompts turn rough into polished.
• Abandon dead ends — when an approach isn't working, step back and ask for a different option.

1. Collect 5 references for your niche on Behance or ThemeForest. For each, write one sentence: what specifically you want to borrow.
2. Screenshot-to-code: pick one element from your references, screenshot it, and recreate it on your site using YOUR design tokens.
3. Fine-tune one section until you are proud of it — track how many small prompts it took. Aim for 5+ precise, one-change-at-a-time prompts.
4. Design review: run the checklist on your whole site and write down the top 3 things still to polish.

The three layers of every web app

• Frontend — what the user sees (HTML/CSS today; Angular soon). The restaurant dining room.
• Backend — the logic the user never sees (PHP, new for us). The kitchen.
• Database — where data is stored permanently (MySQL). The pantry/fridge.

[Browser / Frontend]  --HTTP request-->  [Server / Backend]  --SQL query-->  [Database]
     (Angular)             (API call)           (PHP)          (read/write)     (MySQL)

Click "Login" → frontend sends email + password → backend checks the database → returns success/failure → frontend reacts.

From today we use tools you've never touched. Here's what each is, why we use it, and what it does for you — no code yet, just the map. New names are normal. Nothing here is scary.

• What it is: the programming language of the browser (you've already seen tiny bits of it).
• Why we use it: it makes a page do things — buttons react, menus open, search filters live.
• What it does for us: turns a static page into something interactive.

• What it is: a language that runs on the server, not the browser. Users never see it — only its results.
• Why we use it: it talks to the database, checks passwords, prepares data. Our hosting already runs it, and the AI writes it well.
• What it does for us: gives our site a brain and a memory behind the scenes. Brand new today — we read it, we don't memorize it.

• What it is: a framework — an organized toolkit for building real, bigger apps without the code becoming spaghetti.
• Why we use it: plain HTML + JavaScript gets messy once an app has many screens; Angular gives structure, reusable pieces, and a clean way to talk to a backend.
• What it does for us: it's how we build the admin panel next session — think LEGO for interfaces. The biggest new thing — we take it slowly.

The only vocabulary you need

• Table — one spreadsheet (e.g. posts).
• Row — one record (one blog post).
• Column — one field (title, body, author, created_at).
• Primary key — a unique id for each row.
• Foreign key — a column that links to another table (a post stores its author's user id).

• Create · Read · Update · Delete
• A blog admin panel is just CRUD on posts. Most apps are CRUD dressed up.

SELECT * FROM posts WHERE author = 'Ana';   -- Read
INSERT INTO posts (title, body) VALUES ('Hello', '...');  -- Create
UPDATE posts SET title = 'New title' WHERE id = 3;  -- Update
DELETE FROM posts WHERE id = 3;             -- Delete

You need to READ a query the AI writes and sanity-check it — not write it from memory.

• MAMP — a whole backend on your own computer: Apache (runs PHP) + MySQL (the database). Runs on localhost, no internet needed.
• Node.js — installed for next session's Angular; today it means npm is available.

1. Start MAMP → Start Servers.
2. Open phpMyAdmin from MAMP's start page (the visual tool for MySQL — same kind we use on the real server).
3. Create a database, e.g. blogadmin. This is your empty pantry.

Example prompt

Create a project folder for a blog with an admin panel.
Add an /api folder for a PHP backend and a README explaining the structure.
Keep it flat and simple. Don't add code yet — just the skeleton.

Notice how specific that is. Being specific is the skill.

• PHP runs on the server. The browser never sees the code — only the result, usually as JSON.
• A backend endpoint does four moves: connect to the DB → query → shape the data → respond with JSON.

<?php
header('Content-Type: application/json');
$pdo = new PDO('mysql:host=localhost;dbname=blogadmin', 'root', 'root');
$stmt = $pdo->query('SELECT * FROM posts ORDER BY created_at DESC');
echo json_encode($stmt->fetchAll());

Connect → query → respond. The connection line is where the DB name, user, and password live.

Name the endpoint, the table, the return, and the rules

Create a PHP file posts.php that connects to my MySQL "blogadmin" database,
selects all rows from the "posts" table ordered by newest first,
and returns them as JSON.
Use PDO with a prepared statement.
Handle connection errors gracefully.

Every phrase here is a decision you now understand from blocks 1 & 2.

Opening it in the browser only tests the simplest reads

• Postman and Insomnia are free tools built for poking at an API.
• Type your endpoint address → pick the method (GET to read, POST to send data) → hit Send → see the JSON, the status code, everything.
• Point it at your posts.php: a GET returns your posts; a POST with JSON creates a new one.
• This is how you confirm a backend works before any frontend exists.

You don't need to be a security expert — but you MUST know the basics, because the AI sometimes writes insecure code and YOU have to catch it.

• Anything a user types can be an attack. Gluing input straight into a query is the wound.
• The fix: prepared statements — that's why we always tell the AI "use PDO with prepared statements".
• Review skill: if AI output glues input into a query, say "use a prepared statement instead".

• Store a one-way hash, never the real password.
• PHP: password_hash() to save, password_verify() to check. We use this in the login next.

• DB passwords and API keys live on the server — never in code the browser downloads, never committed to a repo.
• Same principle as keeping our own project secrets in a git-ignored file.

Only an admin should reach the panel. The login uses everything from today: a users table, a PHP endpoint, and hashed-password security.

1. A users table with email and password_hash, plus one seeded admin user.
2. A login endpoint receives email + password, looks up the user (prepared statement), and checks with password_verify() against the stored hash.
3. Match → success. No match → reject.

Create a PHP login endpoint login.php for my "blogadmin" database.
It receives email + password as JSON, looks up the user in the "users" table
with a prepared statement, verifies the password with password_verify()
against the stored hash, and returns JSON success or error.
Don't reveal whether the email or the password was wrong.

That last rule is a real security touch — don't help an attacker guess.

• A mental map of the three layers (frontend / backend / database).
• Enough database + SQL to read a design and a query and sanity-check the AI.
• A scaffolded blog project with MAMP (Apache + MySQL).
• A real PHP backend endpoint returning JSON.
• A working admin login with hashed passwords and prepared statements.

1. Make the backend run cleanly under MAMP — no errors when you open your endpoints in the browser.
2. Finish posts.php: make sure it returns all posts, and can create a post via POST (ask the AI, using the pattern from today — name the endpoint, table, return, and rules).
3. Test it in Postman or Insomnia: a GET that returns your posts, and a POST that creates one. Confirm the JSON and status codes look right.
4. Seed 3–5 blog posts in the posts table so we have data to display next time.
5. Security check: read every query the AI wrote and confirm each uses a prepared statement. Fix any that don't.

• A database + a PHP backend + posts.php returning JSON + a login.
• You tested it all in Postman — before any interface existed.

1. Secure the login with a JWT token — the professional way to remember "this user is logged in".
2. Install Angular and take the first real steps building the admin panel.

Login says "yes, correct password" — but the next page, the backend has forgotten who you are. The web works one request at a time. So how do sites keep you logged in? A token.

• JWT = JSON Web Token: a small piece of text carrying info about you (user id, admin flag) in JSON form, digitally signed by the server.
• The signature lets the server instantly know: I created this, and nobody tampered with it. Change one letter → rejected.

• Anyone holding a JWT can read what's inside — so never put a password or anything private in it. Just harmless things like the user id.
• Like a festival wristband: visible to all, proves you got in, but has no bank details on it.

1. Log in with email + password.
2. PHP checks them → if correct, creates a JWT and sends it back.
3. Your app stores the token, then sends it with every protected request (e.g. delete a post).
4. The backend verifies the signature → confirms you're a logged-in admin → only then does the work.

Angular runs on Node (that's why we installed it) and comes with a CLI tool that does the setup. We don't memorize commands — we ask Kiro and Kiro runs them. Knowing how to ask beats knowing the command by heart.

1 — Install the Angular CLI

Install the Angular CLI globally on my machine
and tell me the version once it is done.

2 — Create the project

Create a new Angular project called blog-admin in my current folder,
using routing and CSS, and don't start the server yet.

3 — Run it

Start the Angular development server for the blog-admin project
and tell me which address to open in the browser.

Kiro runs each one and reports back. You open the address (usually localhost:4200) — and there's your app, live.

• Change the code and save — the browser updates by itself. No manual refresh.
• If install fails, paste the error back to Kiro: "this failed with this error, fix it." That's the loop.

Component and Service. Get these two and the rest of Angular follows over time.

• A self-contained block owning three things: HTML (looks), CSS (style), a bit of code (behavior).
• Like LEGO bricks — a page is small bricks snapped together.
• Our panel's bricks: login-form, post-list, post-item, add-post.

• The component shows; the service fetches (mostly: talks to our PHP backend).
• Kept separate to stay clean: the list component shouldn't also worry about how to fetch over the internet.
• The component asks the service "get me the posts" and shows what comes back.

post-list asks the post service → the service calls posts.php → gets JSON → hands it to the component → the component displays it. Components show, services fetch.

We won't finish the whole panel today. We build the front door — the login — which ties together everything from today: an Angular component, a service, and the JWT from the backend.

1. A component with email + password fields and a button.
2. On click, it asks a service (not the backend directly).
3. The service sends the credentials to the PHP login endpoint.
4. Correct → backend returns the JWT; the app stores it and shows the admin area.
5. Wrong → show a friendly error and let them retry.

Create an Angular login component with email and password fields and a login button.
On submit, call a service that sends them to my PHP login endpoint.
If it succeeds, store the JWT token it returns and show the admin area.
If it fails, show an error message.

Start the blog-admin app and open the login screen so I can test it.

• Open DevTools → Network, click login, watch the request go out and the answer come back.
• Copy what you see and hand it to Kiro:

My Angular login calls the PHP endpoint but I get this error
in the Network tab — [paste it] — please find the cause and fix it.

Usually it's the two apps being on different addresses (CORS), and Kiro fixes it in the backend. Look, then prompt — that's the whole loop.

• JWT: a signed pass the backend gives you at login; your app shows it on every request so the site remembers you. Signed, not secret — nothing private inside.
• Installed Angular: a real app running with live reload.
• The two words: a component is a brick of the interface; a service talks to the backend.
• Built the front door: an Angular login screen calling your PHP backend and receiving a JWT.

1. Tidy the login — apply your design tokens so it looks like your brand, not a raw form.
2. Login end to end: correct password logs in and stores the token; wrong password shows an error.
3. Explain it simply: write, in your own words, what a JWT is and why we never put a password inside it.

Idea → jump straight in → ask the AI to build it. Fine for small things. Today we learn the habit that makes real projects calmer: plan it in writing first.

• Before building anything real, write down what it is, what it should do, what it must remember, the screens, and the build order.
• We don't write it by hand — the AI writes it, one piece at a time, while we read and correct.

• "Build me an online shop" → the AI guesses a thousand things (products? cart? payments?) and you find out it guessed wrong after it built the wrong thing.
• Write clear docs first, then "build this, following the documentation" → almost nothing left to guess → you get what you actually meant.

Documentation-driven development (working from a spec): write down what you'll build before you build it. That written thing becomes the source of truth everyone follows. It's how serious software has been made for decades.

• Nobody pours a house's foundation then wonders how many rooms it has — there's a blueprint first.
• Changing a line on paper is free. Moving a wall after it's built costs a fortune.
• Software is the same: fixing a doc takes seconds; fixing it after the AI built 100 files around it takes an afternoon.

• AI is astonishingly fast — but speed in the wrong direction just reaches the wrong place faster.
• The plan points that speed the right way. "Weeks of coding can save you hours of planning" — a joke, and a warning.

• Tells the AI what to build.
• Lets you check that what got built is what you asked for.
• Is the project's memory — code says what the program does; docs say what it was supposed to do, and why.

People browse products, add to a cart, and place an order. Nothing exotic.

• No card forms, no payment provider — too much complexity for today.
• When a customer orders: the order is saved and emailed — to the owner (a sale came in) and to the customer (a confirmation).
• Paying happens offline afterwards (transfer, cash…). The journey ends at "order placed", not "paid".

Small enough to fully understand, but it has every real ingredient: products, categories, cart, checkout, stored orders, emails, and an admin area. Plan this and you can plan almost any small business app — booking, catalogue, inventory. Same shape.

Don't ask for "all the documentation" at once — you'll never read the wall of text. Write one piece, read it, fix it, then move on.

1. No code yet — "we're planning, not building; don't write code until I say so."
2. One piece at a time — the AI writes a part, shows it, waits for "good" or "change this". The pause is where you do the real work.
3. Let it ask — a lot — encourage questions; a good planning session is a conversation, not a delivery.

• The AI should ask: what products, what currency, what language, where the order emails go, how delivery works.
• Every question answered = a hole in the plan filled before it becomes a bug in the code.
• We'll tell it outright: don't hold back, ask anything, even small questions — the more you ask, the better the docs.

1. Short description — what the shop is, who it's for, and the key line: orders by email, no online payment for now.
2. What it should do — for the visitor (browse, search, view a product, add to cart, order) and the owner (manage products, categories, see orders). Plus the basics (fast, safe, mobile, findable on Google) and what's left for later.
3. What to remember — products, categories, and orders (customer details + what they bought).
4. How an order works — from "add to cart" to the email in the inbox; what the emails say; the order's journey: new → confirmed → delivered / cancelled.
5. How the pieces fit — what people see, the server part, where data lives, the email — and the key choices and why.
6. The screens — home, product list, single product, cart, checkout, thank-you page, admin — and how you move between them.
7. A simple build plan — the real order of building, in small steps you can finish and see working.

You'll send a real prompt to Kiro that starts the planning conversation. Read it together first — never send a prompt you don't understand.

• States the intention: building an online shop, but plan in writing first, no code yet.
• Explains the shop + the twist: orders saved and emailed, no online payment, ends at "order placed".
• Sets the rhythm: step by step, wait for approval, and ask lots of questions.
• Lists the seven pieces to write, in order.
• Ends firm: documentation only, no code — start with piece one and your questions.

1. Open Kiro, paste the prompt, send it.
2. Have the conversation — answer what products, currency, language, where emails go.
3. Read each piece. Missing or wrong? Tell it to fix it. You're the owner and the boss of this chat.
4. Keep going until all seven pieces are written and you're happy.
5. Save them into a docs folder — now they're the single source of truth.

Today doesn't end with just a plan and a promise. On screen now: a real, working online shop — browse products, fill a cart, checkout, and a real order email lands in the owner's inbox (plus a confirmation to the customer). Exactly the shop we described.

• Not a clever guess or a lucky prompt — built from the same seven pieces you just planned.
• Give the AI the plan, tell it to follow it → it builds this. Compare it to the docs: it matches, because the docs told it what to make.
• No "that's not what I wanted, start over" — the surprises were argued out on paper, while they were cheap.

• Learned the habit: plan in writing with the AI first, build second.
• Met a real project — an online shop that emails its orders, no online payment yet.
• Learned the seven pieces of the plan and the rhythm: no code, one piece at a time, questions flowing.
• Sent the prompt to Kiro and had the planning conversation yourself.

1. Finish the plan — all seven pieces, saved in your docs folder.
2. Prove you were the boss: write 3 questions Kiro asked that made you think, or 3 things it got wrong that you corrected.
3. Start the build — send the final short prompt and get the first step done or clearly started.

The habit — plan in writing with the AI first, build second — the online-shop example (orders emailed, no online payment yet), and the first prompt sent to Kiro.

No new theory. We do the thing, start to finish: run the planning conversation, answer every question, read and fix each piece, and save it all.

You'll live inside this prompt for two hours. Never send a prompt you can't explain.

• Answer its questions concretely — not "products" but "handmade candles", "second-hand books".
• Check the key rule is there, hard and clear: orders emailed, no online payment, ends at "order placed".

• Let the questions flow: search or browse only? can the owner edit products? show out-of-stock?
• List both sides — what the visitor can do and what the owner can do in admin.
• Write down what you're leaving for later (no payment, no accounts) — as valuable as what you are building.

• Product: name, price, description, photo, category, in stock?
• Order: who placed it, how to reach them, where to deliver, which products and how many.
• Ask: "if a real order came in, is anything missing I'd wish I had stored?" Add it now — one sentence on paper vs. an afternoon later.

• Add to cart → checkout → name + address → confirm. Then: order saved + two emails (owner: a sale came in; customer: confirmation).
• Decide what those emails actually say.
• The order's states: new → confirmed → delivered / cancelled. Writing them now = the right admin buttons later.

• Plain language: what people see, the part on the server, where data lives, the email. That's the whole machine.
• If it says frontend / backend / database — fine, but make it explain each in one normal sentence.
• Every choice gets a "why". You don't need to be an expert — you need the reasons written down for later.

• Customer: home, product list (by category), single product, cart, checkout, thank-you.
• Owner: admin login, manage products, see orders.
• Draw the arrows: list → product → cart → checkout → thank-you. Screens + arrows = the shop already exists in your head.

• Small steps, sensible order: setup → data → show products → cart → checkout + emails → admin → polish.
• Golden rule: every step ends with something you can look at and say "yes, that works". No giant "build the shop" step.

1. Read the docs → build one step → it stops and shows you.
2. Check it against your build plan: is this step done and does it work?
3. Yes → "good, next step". Off → fix the doc, not the chat, then try again.

• Ran the planning conversation end to end and answered Kiro's questions instead of letting it guess.
• Read and corrected all seven pieces, then saved them into docs — the single source of truth.
• Sent the short prompt and watched the AI build step one from your plan, not a guess.

1. All seven pieces saved in docs — and you can explain each one.
2. Walk the build plan: do the next 2–3 steps, one at a time, checking each against the docs.
3. Write a short note: one place the docs saved you from building the wrong thing, and one question Kiro asked that made you decide something new.

Only on your computer — you open it at localhost and nobody else can see it. Great for building, but a shop nobody can reach isn't a shop yet.

• You built furniture in your garage. To open the shop you need a building + a street address + movers.
• Building + address = the server and domain you rent from a hosting company.
• Movers = FTP, and the van we drive is a free program called FileZilla.

The control room for your hosting — one web page of icons where you manage your site. Log in with the username/password from your host.

• Files — your website's files live here, in a special folder. FileZilla drops them here.
• Databases — where we create the database and its user.
• Email — where we make the shop's email address.

The shop must keep its records — products, orders — on the server, not your laptop, so real customers' orders are stored safely.

1. Create the database — name it simply (e.g. shop); the host adds a prefix → youraccount_shop. Write the full name down.
2. Create a user — username + strong password. Write both down exactly.
3. Add the user to the database, ALL privileges — the handshake everyone forgets. Without it, nothing works.

The shop sends order emails (owner notice + customer confirmation). They should come from orders@yourshop.ro — professional, trusted, and separate from your personal mail.

1. Click Create.
2. Choose the part before the @ (orders / hello / contact); the domain is already yours.
3. Set a password. Done — a real mailbox in under a minute (read it via webmail).

FTP = copying files between your computer and the server over the internet. FileZilla is the free tool we drive.

• Left = your computer (the garage). Right = the server (the new building).
• Moving a file = drag from left to right. That's the whole concept.

• Host (e.g. ftp.yourshop.ro) · Username · Password · Port 21 → Quickconnect.

Header, product list, cart, footer all jumbled in one enormous file. It works — but changing one thing means scrolling hundreds of lines holding your breath.

• A component = a self-contained piece that does one job and can be reused.
• Header block, product-card block, cart block, footer block — small, independent, reusable.
• Header on every page? Make it once; fix it in that one place → fixed everywhere. Change in one place, not twenty.

• Took the shop from your computer to a real server the whole world can reach.
• Toured cPanel (Files · Databases · Email), created the database + loaded it via phpMyAdmin, made a professional email.
• Uploaded with FileZilla / FTP into public_html and pointed the config at the live database + email.
• Improved it: asked Kiro to split one messy page into clean, reusable components.

1. Confirm the shop is reachable — open it on your phone and place a test order to check the emails arrive. (If broken: usually the config file or files outside public_html.)
2. Finish the component split — one at a time, checking the shop looks identical after each.
3. Write a short note: one thing that broke during the upload and how you fixed it.

No single project today. We zoom out to three ideas under almost everything on the front end, and we hop between a shop, a dashboard, a landing page and a blog to see each idea in different clothes.

You build on a laptop, it looks great, someone opens it on a phone and it falls apart. Nothing in the code "broke" — only the size of the glass changed. That gap is the number one reason a project looks amateur.

• A poster is one fixed size. Water takes the shape of its container.
• A good page pours into a phone and arranges for a phone; into a wide monitor and spreads out.
• You don't design one picture — you design the rules by which it flows.

Write styles for the phone first, then add complexity for bigger screens. Beginners do it backwards (build desktop, then cram onto a phone) — and cramming always hurts.

1. Most users are on phones — the phone is the main event, not an afterthought.
2. It forces honesty — a small screen fits the essentials; extras come later on bigger screens.
3. It's easier work — adding space as you grow is pleasant; squashing to shrink is miserable.

A media query says "when the screen is at least this wide, apply these extra rules." That "at least" is what makes the design grow upward from the phone. Three honest break points cover most of the world: phones, ~768px (tablets), ~1024px (desktops).

• Blog: one scrolling column on a phone → adds a sidebar on desktop.
• Dashboard: a vertical stack of cards → a grid with a fixed sidebar.
• Shop: 1–2 products per row → 4–5 per row.
• Landing page: sections stacked → placed side by side.

Eyeballed colours drift: eleven almost-blues, nine almost-greys, spacing that's 16px here and 17px there. Nothing looks broken — it just looks cheap, and nobody can say why.

• A token is a named value you decide once and reuse everywhere (primary colour, spacing steps, font sizes, radius, shadows).
• Everything points at one source → automatic consistency.
• Client says "warmer brand colour"? Change one line, the whole product updates.

Amateur cook: a pinch of this, a splash of that — different every time. Professional kitchen: exact measurements, every plate identical. Tokens are your measurements.

Tokens can themselves respond to screen size — a heading token is smaller on a phone, larger on desktop, defined once. A dashboard, a shop and a marketing site sharing one token vocabulary feel like a family. That shared feel is what a brand is, under the hood.

One giant stylesheet: endless scrolling, repeated code, and fear of changing anything in case it breaks something 3,000 lines away. SCSS sits on top of CSS and gives you structure; a build step turns it back into normal CSS.

• Nesting — write styles inside styles, mirroring the page so related rules live together.
• Partials — split one giant file into small files that each do one job (tokens, buttons, layout) + a main file that ties them together.
• Mixins — a reusable chunk of styling, defined once, dropped in anywhere (like a little function).

SCSS does nothing CSS can't eventually do — it just keeps it organised and readable as the project grows. One messy drawer vs a place for everything. A tiny landing page may not need it; a dashboard, a shop, or any team app over months does. Matching the tool to the size of the job is a senior instinct.

• Flexbox thinks in one direction (a row or a column) → navbars, button rows, items inside a card.
• Grid thinks in two directions (rows and columns) → whole-page skeletons: header / sidebar / main / footer.
• They're friends, not rivals: Grid for the page skeleton, Flexbox for the arrangements inside each region. You'll use both on the same page — that's correct.

• Public marketing page: the polish is the product → lean pixel-perfect.
• Internal admin tool: five users getting work done → good-enough, shipped on time.
• Startup testing an idea: ship fast and rough — polishing something nobody wants is software's most expensive mistake.

1. Context before task — tell Kiro about your tokens, mobile-first rule, the style you're matching. No context → it invents its own conventions and you fix the mismatch.
2. Ask it to explain changes — add "list what you changed and why." You catch bad decisions early and you learn.
3. One change at a time, then look — tokens → check, responsive → check, component by component. Small steps are faster because you skip the debugging mysteries.
4. You're the designer, Kiro is the hands — it's great at typing and tedious consistency; taste and judgement are yours.

• Responsive — a page is water; get there mobile-first (small screen first, grow up).
• Design systems & tokens — decide colours/spacing/sizes once, name them, reuse them; consistent and easy to change.
• SCSS — nesting, partials, mixins keep styling organised when the job is big enough to deserve it.
• Two debates — Grid vs Flexbox, pixel-perfect vs fast: "it depends, and knowing which situation you're in is the skill."

1. Take any page (yours or one you admire) and run two of today's prompts: the mobile-first one and the token-extraction one.
2. Read what Kiro changed. Write three sentences: what it did, one thing you agreed with, one thing you'd have done differently.

1. Nobody can find it → SEO. Page nine of search results doesn't exist to humans.
2. Some people can't use it → accessibility. Unlabelled buttons, no contrast, mouse-only = people locked out (and often it's the law).
3. It feels broken even when it works → UX polish. No feedback, no loading sign, no error message = untrustworthy.
4. It's slow → performance. People leave in a couple of seconds, before they see your work at all.

A search engine is a machine trying to understand what your page is about and how trustworthy it is. All of SEO is making the page easy to understand and giving it reasons to trust you. No dark arts.

• It reads your HTML, not your design. Use semantic structure: one main heading, real section headings in order, a clear page title and description, image descriptions.
• None of it is clever — it's just being clear, and clarity is 90% of SEO.

Keyword-stuffing is dead. The machine matches a question to a page that answers it. Be the best answer to something someone actually types.

• Blog: every article is a fishing line for a search topic.
• Local business: local SEO — "bakery near me," maps, address, reviews.
• SaaS landing page: rank for a few high-value problem terms.
• Shop: every product page findable for the thing it sells.

First question is never "what tricks?" — it's "who is searching, for what, in what situation?"

A screen reader (for a blind user) and a search crawler are both machines reading your HTML without seeing the visuals. Make the page clear for one and you've mostly done it for the other. Accessibility and SEO are largely the same job.

• Buttons that all say "click here" → a screen reader user hears nonsense.
• No image descriptions → they just hear "image" and miss the content.
• Fake headings (bold text, not real tags) → they can't jump around the page.
• Mouse-only → a keyboard user hits a locked door.

Label buttons/links so they make sense out of context · describe images · real headings in order · enough colour contrast · everything reachable and visible by keyboard.

Trust is everything — a user who doesn't trust your software stops using it, however clever it is underneath. Trust is won or lost in four moments.

1. Feedback — a click/submit must be acknowledged immediately, or people think it's broken and click again.
2. Loading — show that something is coming (spinner, skeleton). People wait happily when they know they're waiting.
3. Empty — the first impression is usually an empty screen. Say "nothing here yet, add the first thing" instead of a blank void.
4. Error — a clear human message ("that email looks incomplete") beats a frozen screen or a scary technical dump.

People leave slow sites in seconds; search engines also rank them lower. A few things cause most slowness in beginner projects — you don't need to be an expert.

• Images — the biggest culprit. A phone photo can be several MB; shrinking to a sensible size and modern format is the highest-impact fix.
• Loading everything up front when you could load as the user scrolls (lazy loading).
• Making users wait on things that could happen in the background.

When something feels slow, look at images first.

• Yes camp: build it in from the start — retrofitting SEO/a11y/performance into a finished product is painful and never happens.
• No camp: for an unproven idea, validate first — weeks of SEO on a product nobody wants is polishing a car with no engine.

1. Found — can a search engine understand the page? (structure, title, headings)
2. Usable — can everyone operate it? (labels, contrast, keyboard)
3. Trustworthy — are the unhappy paths handled? (loading, empty, error states)
4. Fast — will people wait for it? (images, what loads up front)

Out the other end: a prioritised list, not a vague "something's off."

Reviewing by feeling misses exactly what doesn't show at a glance — SEO gaps, accessibility locks, missing error states, slow images — because none are visible on your own fast laptop with a mouse. A checklist protects you from your own blind spots.

• Found (SEO) — clear, structured HTML; be the best answer to a real question.
• Usable (accessibility) — mostly the same work as SEO; labels, contrast, keyboard.
• Trustworthy (UX polish) — the four states: feedback, loading, empty, error.
• Fast (performance) — images first.
• Wrapped in an honest debate: it depends on what you're building and why.

1. Run the one-pass review prompt on a real page you did not build. Bring the three findings you think matter most, and why.
2. Use any website for two minutes with keyboard only, no mouse. Notice how it feels — that's how some of your users live.

The happy path is the one perfect route where everything goes right — the user types exactly what you expected and clicks in the order you imagined. You built it, tested it, it works. You are not done. You tested one road out of a thousand.

• Submit a half-empty form · paste a phone number into the email field · type text where a number goes.
• Double-click because they're impatient · lose their connection halfway.
• Open the app with no data, too much data, or weird data.

Software that only handles the happy path falls apart on contact with reality.

You build in love with your software, so you use it gently. Testing needs the opposite: become a chaotic, slightly malicious user whose goal is to make it fall over. Every break you find in private is one that won't happen in front of a customer.

• Every input: empty? far too long? wrong type? weird edge (zero, negative, past/future date)?
• Every action: done twice fast? out of order? with no connection?
• Every screen: with nothing, with one item, with a thousand items?

• Manual — a human clicking through a checklist. Catches what feels wrong; irreplaceable for judging the experience.
• Automated — code that tests your code, every time you change something. Superpower: catching the thing you broke in a far corner (a regression) that humans miss.

Any data from outside your code — a user, another system, the internet — is guilty until proven innocent. Check it, clean it, then use it. Trusting input is the root of a huge share of bugs and security disasters.

• Required field empty? Say it's needed — don't crash or silently ignore.
• Nonsense email format? Catch it before you try to use it.
• Letters where a number goes? Reject it kindly.
• Out-of-range value (quantity of −5, age of 800)? Guard against it.

Each check is tiny; the discipline is remembering to do all of them.

Front end (browser) = instant friendly feedback, a politeness for honest users. Back end (server) = the real guard, because front-end checks can be bypassed. Doing only the first feels safe and isn't.

You don't need to be an expert — but you must know the handful of attacks that sink real projects. They're shockingly common and shockingly preventable.

1. SQL injection — user input pasted into a database command lets an attacker read/delete your database. Fix: parameterised queries that keep data and command strictly separate. Standard, not advanced.
2. Cross-site scripting (XSS) — malicious code sneaks in via an input and runs in other users' browsers. Fix: treat displayed user content as text, never code.
3. Secrets — never store passwords as plain text (scramble them one-way); never put keys in code or a public repo; always use HTTPS.

The theme is identical to validation: don't trust input; keep data and code separate.

• Ship fast: perfect is the enemy of done; for a new idea the biggest risk is building something nobody wants. Excessive early testing can be hiding from that scary question.
• Test first: a bug in front of a customer destroys trust; a breach can end a company; fixes get costlier the later you catch them.

• Wrong label, fixed in an hour → cheap & reversible → ship and iterate.
• Double-charged card or leaked data → expensive & sometimes irreversible → test hard first.

You don't apply the same rigour to a comment box and a payment flow. Spend your limited testing effort where being wrong costs the most.

1. Unhappy paths tested? Empty, wrong, too much, out of order, offline — not just the happy one.
2. Every input validated, in both places (browser for friendliness, server for protection)?
3. Common security holes closed? No raw input in queries, no user content shown as code, no plaintext passwords or leaked secrets, HTTPS on.
4. Right amount of testing given what a mistake here would cost? Not too little for a payment flow, not wasteful for a toy.

In the real world you'll be tired, rushed and pushed to ship — exactly when instincts fail. Professionals aren't people who never err; they have systems that catch errors first. A pilot with 1,000 flights still runs the pre-flight checklist. The trust pass is yours.

• Killed the happy-path illusion; built the testing mindset (be mean to your own software).
• Handled weird input with validation — never trust input, guard in two places.
• Faced the malicious user: injection, XSS, secrets, HTTPS.
• Debated how much is enough → the lens is reversibility × cost.
• Turned it into a reusable trust pass.

• S12 — looks right on every screen, stays consistent.
• S13 — gets found, usable by everyone, fast.
• S14 — actually works, and is safe.

The same spine throughout: Kiro makes you fast, your judgement makes you valuable, and you never ship what you don't understand.

1. Take one feature of anything you've built. Run all three core prompts on it: the tester, the validation finder, the security review.
2. Write an honest paragraph: what surprised you, and what you'll fix now vs later, and why.