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.

Every page in A Master Artificer ships with placeholder names, sample project cards, and dummy text so the theme looks complete from the first load. Personalizing the theme means working through those files in a sensible order — starting with the pages that establish your identity and voice, then filling in the supporting content around them. Following a clear editing sequence keeps each update purposeful and reduces the risk of broken links or mismatched references between pages.

​
Recommended editing order

1
Start with index.html — your name and headline
2
Open index.html at the repository root. Replace the sample name, headline, and short introductory paragraph with your own. This page is what GitHub Pages loads first, so it sets the tone for every visitor. Getting the homepage right before touching anything else makes it much easier to align the rest of the pages with the same voice.
3
Update the About page — biography and background
4
Open about.html at the repository root. This is the right place to explain your background, education, career direction, creative influences, and the path that led to your current work. The design gives the biography its own dedicated space so visitors can understand you as a person without the homepage becoming overloaded. Write in your own voice; this page works best when it sounds genuinely personal rather than like a résumé summary.
5
Replace project cards — projects.html
6
Open projects.html and replace each sample project card with your real work. For each project, include:
7
  • What the project does — one clear sentence on its purpose
  • Why you built it — the problem it solves or the motivation behind it
  • What technologies you used — languages, frameworks, tools, APIs
  • What decisions mattered — trade-offs, architectural choices, design decisions
  • A link to the live site or repository — so visitors can see the finished result
    • 8
    Strong project descriptions are specific. Avoid vague phrases like “a full-stack application” without explaining what it actually does.
    9
    Fill in the Skills page — skills.html
    10
    Open skills.html and replace the sample skill entries with the languages, tools, frameworks, and technologies you actually use. Group them in whatever way makes the most sense for your background — by category, by proficiency level, or by domain.
    11
    Update Work and Experience — work.html
    12
    Open work.html and replace the sample job titles, employer names, and date ranges with your real professional history. Include brief role descriptions that connect the employer context to specific contributions or accomplishments. Keep the entries concise — the Work page supports the rest of the portfolio rather than replacing a full résumé.
    13
    Add Case Studies — casestudies.html
    14
    Open casestudies.html for deeper project breakdowns that go beyond what fits in a project card. Case studies are the right place for process documentation, sketches, iterations, before-and-after comparisons, or extended written reflection on a significant project. Use this page for two to four pieces of work where the story behind the outcome is as interesting as the outcome itself.
    15
    Add Writing — blogindex.html and article.html
    16
    Open blogindex.html to update the writing index with your real article titles and summaries. Open article.html to replace the sample article body with your own writing. If you do not have existing long-form writing, this section also works well for short technical notes, project retrospectives, or explanations of concepts you have worked through recently.
    17
    Update Testimonials — testimonials.html
    18
    Open testimonials.html and replace the sample quotes with real feedback from colleagues, collaborators, clients, or instructors. Include the name, role, and context for each person who provided the recommendation. If you do not have testimonials yet, this page can be left minimal or omitted from the navigation until you do.
    20
    Open contact.html and replace every placeholder link with your real contact paths. Common updates include:
    21
  • Email address
  • GitHub profile URL
  • LinkedIn profile URL
  • Portfolio or personal site URL
  • Résumé or CV download link
    • 22
    Double-check that every link opens to the correct destination before publishing.
    23
    Replace screenshots in images/screenshots/
    24
    After customizing the site visually, replace the theme preview screenshots stored in images/screenshots/ with screenshots of your personalized version. Keep the same filenames as the originals, or update the README.md image paths at the same time so the repository preview stays accurate.

    ​
    Theme-specific editing checklist

    Use this checklist to confirm everything is in place before publishing:
    • Update the homepage name, headline, and introduction
    • Replace About content with your real background and career direction
    • Replace project cards with real projects and accurate descriptions
    • Replace case studies, writing, skills, testimonials, and work history where those pages are included
    • Update contact details and all external profile links
    • Replace screenshots in images/screenshots/ after customizing the site
    • Review the color palette only after the content is in place — content length can change how the design feels
    • Test navigation from every page, not only from the homepage
    • Open the site at a phone-width screen and check spacing, headings, buttons, and screenshots
    • Confirm that index.html and .nojekyll are both at the repository root
    • Publish through GitHub Pages and check the live URL after deployment finishes
    Test every navigation link from multiple pages, not just from the homepage. All HTML files live at the repository root, so a link that resolves correctly from index.html may be written with a path relative to a different location. Open each page directly and click every navigation item to confirm all routes resolve correctly.
    GitHub Pages file paths are case-sensitive. projects.html and Projects.html are treated as two different files. If you rename any HTML file, update every link that points to it at the same time. Broken links on a live site are easy to avoid by keeping filenames consistent with the casing used in the existing theme.

    Build docs developers (and LLMs) love

    Get started for freeTalk to us