Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/a-master-artificer/llms.txt

Use this file to discover all available pages before exploring further.

The Projects page is the portfolio’s main showcase. In the A Master Artificer theme, it maps to the route /projects and carries the themed navigation label Conjurings. The file responsible for it is projects.html at the repository root, and its companion JavaScript module is assets/Projects.js, which holds the project card content, screenshots, descriptions, and links. This is the page most visitors will spend the most time on. It is where you demonstrate what you actually build — not just what technologies you know, but what you did with them. Replacing the sample content with your real projects is the most important customization step after editing the homepage.

​
File

projects.html
Route: /projects
Themed label: Conjurings
Asset: assets/Projects.js

​
HTML Structure

projects.html shares the same HTML shell as every other page in the theme. The project cards, screenshots, and descriptions are rendered by the React application from assets/Projects.js. The HTML file loads the shared bundle and provides the <div id="root"> mount point. 
<!doctype html>
<html lang="en">

<head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="./vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>A Master Artificer</title>
    <script type="module" crossorigin src="./assets/main.js"></script>
    <link rel="modulepreload" crossorigin href="./assets/proxy.js">
    <link rel="modulepreload" crossorigin href="./components/grimoire/AstrolabeNav.js">
    <link rel="modulepreload" crossorigin href="./components/grimoire/CustomCursor.js">
    <link rel="stylesheet" crossorigin href="./assets/main.css">
</head>

<body>
    <div id="root"></div>
</body>

</html>

​
What to Edit

Open assets/Projects.js and replace the sample project data with your own work. Each project card typically includes a title, screenshot or image, description, technology list, and one or more links.
1

Replace project titles and descriptions

Each project card has a title and a description. Replace the sample text with your real project name and a clear explanation of what the project is. Write descriptions in plain language that a non-technical visitor can follow.
2

Add screenshots or images

Store project screenshots inside the images/ folder or a named subfolder. Update the image paths in assets/Projects.js to point to your new files. Use descriptive filenames so the paths are easy to manage over time.
3

List the technologies used

Include the languages, frameworks, libraries, and tools you used for each project. Keep this list focused — list the technologies that were meaningfully involved in the work, not every tool you touched.
4

Add links

Each project card should link to the live project, the source repository, or both. Check that every link works before publishing. If a project is no longer live, link to the repository instead.
5

Order projects intentionally

Put your best and most relevant work first. Visitors rarely scroll to the bottom of a projects page, so the first two or three cards carry the most weight. Lead with the work you most want potential collaborators or employers to see.
6

Update the page title

In projects.html, update the <title> tag to include your name and the page context — for example, Your Name — Projects.

​
Writing Strong Project Descriptions

A weak project description says what something is. A strong one says what it does, why it was built, what decisions were made along the way, and what the result demonstrates about the person who built it. When writing each description, consider addressing these points:
  • What the project does — Describe the core function in one or two sentences. What problem does it solve? What does a user do with it?
  • Why it was built — Context matters. Was it a personal tool you needed? A class assignment you took further? A freelance client’s request? This shapes how a reader interprets the work.
  • Technologies used — Not just a list, but the reasoning. Why did you choose this framework? What did you learn about it in practice?
  • Decisions that mattered — The most interesting part of any project is the part where you had to choose between options. Describing those decisions shows how you think, not just what you shipped.
  • Outcomes or results — What happened when the project was finished? Did it work as intended? What would you do differently?
Specificity separates a memorable portfolio from a forgettable one. “Built a full-stack web app” is too vague to mean anything. “Built a habit tracker that syncs across devices using a custom REST API and local storage fallback, because I wanted offline support without requiring an account” tells a reader exactly what you made, why you made it, and what tradeoff you navigated. That level of specificity builds trust — it shows you understand your own work.

Build docs developers (and LLMs) love

Get started for freeTalk to us