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 Work section of the A Master Artificer theme spans two pages. work.html is the professional timeline — the Past Covens page — where you list employers, roles, dates, and what you accomplished in each position. casestudies.html is the Field Notes page, where you go deeper on specific projects with a narrative structure that explains decisions, obstacles, and outcomes in detail. Together these two pages give a visitor both the shape of your career and the texture of how you actually work.

​
Past Covens — work.html

The work history page maps to the route /work and carries the themed navigation label Past Covens. It is designed to function like a professional timeline: each entry represents a job, contract engagement, or significant professional role.

​
File

work.html
Route: /work
Themed label: Past Covens
Asset: assets/Work.js

​
HTML Structure

work.html uses the same HTML shell as every other page in the theme. The work history content is rendered by the React application from assets/Work.js. 
<!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/Work.js and replace the sample work history entries with your real professional experience.
1

Add your job titles and employers

Each work entry should include your job title and the name of the employer or client. Use the title that accurately reflects your role, even if your official title was different from what you actually did.
2

Add start and end dates

Include month and year for each position. For current roles, use a clear indicator like “Present” instead of a date. Consistent date formatting across all entries makes the timeline easier to read.
3

Write accomplishment-based descriptions

For each role, write two to four bullet points or sentences that describe what you actually accomplished, not just what your responsibilities were. “Reduced build time by 40% by switching from webpack to Vite” is more useful than “Maintained build tooling.” Focus on outcomes, contributions, and decisions.
4

List technologies used in each role

If relevant, note the key technologies you worked with in each position. This helps visitors who are scanning for specific technology experience.
5

Order entries reverse-chronologically

List the most recent role first. This is the standard convention for work history and makes it easy for visitors to quickly see what you are doing now.
6

Update the page title

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

​
Field Notes — casestudies.html

The case studies page maps to the route /case-studies and carries the themed navigation label Field Notes. Where the work history page is a timeline, the Field Notes page is a collection of deeper narratives. Each case study focuses on a single project and gives you space to explain it in full — the problem, your approach, the obstacles, the decisions, and the result.

​
File

casestudies.html
Route: /case-studies
Themed label: Field Notes
Asset: assets/CaseStudies.js

​
HTML Structure

casestudies.html uses the same HTML shell as the rest of the theme. 
<!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/CaseStudies.js and replace the sample case study content with narratives about your own projects. A good case study follows a clear arc.
1

Describe the problem or starting point

Open the case study by explaining the situation before the work began. What was broken, missing, or in need of improvement? Who needed it, and why did it matter?
2

Explain your approach

Walk through how you decided to tackle the problem. What options did you consider? What did you rule out and why? What shaped your thinking at the start?
3

Document the key decisions

The decisions that defined the project are the most useful part of a case study. Describe the moments where you had to choose a direction and explain what you chose and why.
4

Describe the result

Finish by explaining what you shipped, how it performed, and what you would do differently. A case study that ends with honest reflection is more credible than one that presents only success.

​
Work History vs. Case Studies

These two pages serve different purposes and different readers.
Past Covens (work.html)Field Notes (casestudies.html)
FormatTimeline of roles and employersNarrative deep-dives on individual projects
LengthShort entries, two to four points eachLong-form, structured narratives
ReaderRecruiters, hiring managers scanning for fitTechnical reviewers who want to understand how you think
ContentTitles, dates, employers, accomplishmentsProblems, decisions, approaches, outcomes
Best forShowing the shape of a careerShowing the quality of your reasoning
Use both pages together. The work history gives the overview; the case studies give the evidence.

Build docs developers (and LLMs) love

Get started for freeTalk to us