gilde

← All craftbooks

Portfolio Site

Build: interactive and webevalv1.0.0released 2026-06-05workflow: build-loop

Build a personal or professional portfolio site that showcases projects, an about/bio, and contact links in a single polished page. Locks the content inventory — which projects, what bio, which links — first, then a clean gallery-style visual design, then builds responsive HTML with a project grid and real CSS. Scoping the content before designing prevents a small model from inventing fake projects or building a layout the real content does not fit; the portfolio's job is to present a finite set of real work cleanly.

Steps

Entry step: content-scope. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Content scopeplannerentry

    inventory projects, bio, links, sections

    Show working prompt
    Inventory the real content. (1) List the projects to feature (title, one-line description, role, link/repo, and whether an image exists) — use only what the user provided; if details are missing, leave placeholders the user must fill, do NOT fabricate. (2) Draft the bio focus (who, what they do, what they want). (3) List contact/social links to include. (4) Order the sections: hero/intro, project grid, about, contact. (5) Write an acceptance-criteria checklist of 5-8 items, e.g. 'every listed project has a card', 'the hero states name and role', 'an about section is present', 'contact links are present and clickable', 'responsive at 375px and 1280px', 'no fabricated projects'. Write to notes/content-scope.md and via write_task_note. No design or HTML yet.
  2. Visual designvisual-designer

    gallery layout, project card, palette, type

    Show working prompt
    Design the showcase look. (1) Pick a restrained palette (hex) and type pairing that lets the work shine, not the chrome. (2) Design the project card (image/placeholder, title, description, link) and how cards lay out in a responsive grid. (3) Lay out the hero/intro and the about/contact sections. (4) Specify hover/focus states for cards and links and the overall spacing rhythm. (5) Self-contained CSS, no external assets beyond any provided images. Write the visual spec to notes/visual-design.md and via write_task_note. No HTML yet.
  3. Builddeveloper

    implement index.html with the project grid

    Show working prompt
    Implement index.html with inline CSS to the visual spec, using only the scoped content. (1) Palette as CSS variables and the chosen type. (2) Hero with name and role. (3) A responsive CSS-grid project gallery, one card per scoped project with its real (or placeholder) details and a clickable link. (4) About and contact sections with clickable links. (5) Responsive at 375px and 1280px; vanilla HTML/CSS, no CDN. Keep placeholders explicit where the user must supply content — never invent projects. On a loop-back, fix only the named gaps without regressing passing criteria. write_task_note the path and passing criteria.
  4. Evaluatereviewer

    Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

    Show working prompt
    Evaluate the portfolio. Open/render index.html and resize to 375px and 1280px. Check EACH criterion from notes/content-scope.md and write PASS/FAIL with a reason: does every scoped project have a card, does the hero state name and role, is there an about section, are contact links present and clickable, is it responsive, and crucially are there ZERO fabricated projects? Any invented project or missing scoped project is a FAIL — loop back to build.

Then route — this is the whole point of the loop:

- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`.
- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "build" })` to loop back. The builder fixes exactly those gaps.

Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.
  5. Finishdeveloper

    All acceptance criteria met. Stamp a short summary and report DONE.

    Show working prompt
    Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

Source

View this craftbook on GitHub · MIT license