Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/sys-witch/llms.txt

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

The caseStudies.js data file exports the content rendered on the Case Studies page under the heading Ritual Reports — deep-dive write-ups that walk through the technical and design decisions behind a featured project. Each case study is a structured array of sections rather than a single prose blob, which lets the component layer handle consistent visual formatting (headings, spacing, sigil icons) while you focus only on the written content. Location: data/caseStudies.js

​
Data Shape

A case study is composed of two nested interfaces: 
interface CaseStudy {
  id: string;        // URL-safe slug, e.g. "nexus-rebuild"
  title: string;     // Displayed heading, e.g. "RITUAL REPORT: NEXUS DASHBOARD REBUILD"
  sigilId: string;   // References a named sigil key for the decorative icon
  sections: Section[];
}

interface Section {
  heading: string; // Section title rendered as a sub-heading
  content: string; // Full paragraph text for the section
}

​
Field Reference — CaseStudy

​
id
string
required
A URL-safe slug that uniquely identifies the case study, e.g. "nexus-rebuild". Used as a React list key and must be unique across the array. Lowercase, hyphen-separated convention matches projects.js.
​
title
string
required
The display heading for the case study. By convention, titles follow the pattern "RITUAL REPORT: [PROJECT NAME IN CAPS]" to reinforce the theme’s aesthetic. The component renders this in the display font.
​
sigilId
string
required
A key referencing one of the named sigils in data/sigils.js. The named page sigils — "home", "about", "projects", "skills", "writing", "case-studies", "contact" — are the conventional choices here, as case studies typically correspond to a page or project. The component looks up this key to render the decorative SVG icon in the case study header.
​
sections
Section[]
required
An ordered array of section objects. Sections are rendered in array order, so place the most important narrative context first. There is no enforced minimum or maximum number of sections.

​
Field Reference — Section

​
heading
string
required
The section sub-heading, e.g. "Problem" or "Dev Decisions". Rendered in a styled heading element above the section content.
​
content
string
required
The full paragraph text for the section. Write in plain prose — no Markdown formatting is applied inside the component. Aim for one to four sentences that are focused and specific.

​
Standard Section Headings

The following headings represent the canonical structure used in the existing case studies. Sections can be presented in any order and any subset may be omitted when not applicable to the project being described:
HeadingPurpose
ProblemWhat was broken, slow, or missing before the work began
GoalThe measurable or qualitative target the work aimed to hit
ProcessHow the problem was investigated and approached
Design DecisionsVisual and UX choices made and the reasoning behind them
Dev DecisionsTechnical implementation choices and trade-offs
Testing & DebuggingSpecific bugs encountered and how they were resolved
ResultConcrete outcome — metrics, scores, or observable improvements
Skills DemonstratedA comma-separated list of skills exercised during the work
Not every case study needs all eight sections. A purely technical refactor may have no Design Decisions section. A visual redesign may have no Testing & Debugging section. Include only what is genuinely relevant.

​
Current Case Studies

Two case studies are currently defined in data/caseStudies.js:

RITUAL REPORT: NEXUS DASHBOARD REBUILD

id: nexus-rebuild · sigilId: case-studiesSections: Problem, Goal, Process, Design Decisions, Dev Decisions, Testing & Debugging, Result, Skills Demonstrated

RITUAL REPORT: ACCESSIBLE ALCHEMY UI

id: accessible-alchemy · sigilId: projectsSections: Problem, Goal, Process, Dev Decisions, Result

​
Complete Example Structure

The following is the full structure of a new case study object, ready to be appended to the array: 
{
  id: "new-project-slug",
  title: "RITUAL REPORT: NEW PROJECT NAME",
  sigilId: "projects",
  sections: [
    {
      heading: "Problem",
      content:
        "Describe the specific issue, bottleneck, or gap that made this project necessary.",
    },
    {
      heading: "Goal",
      content:
        "State what a successful outcome looks like — be as measurable as possible.",
    },
    {
      heading: "Process",
      content:
        "Walk through how you investigated the problem and settled on an approach.",
    },
    {
      heading: "Design Decisions",
      content:
        "Explain the visual and UX choices made and why they best served the project.",
    },
    {
      heading: "Dev Decisions",
      content:
        "Detail the key technical choices, libraries selected, and trade-offs accepted.",
    },
    {
      heading: "Testing & Debugging",
      content:
        "Describe notable bugs encountered during development and how they were resolved.",
    },
    {
      heading: "Result",
      content:
        "Quantify the outcome where possible — performance gains, scores, or user impact.",
    },
    {
      heading: "Skills Demonstrated",
      content: "Skill One, Skill Two, Skill Three.",
    },
  ],
}

​
Adding a Case Study

Append a new object conforming to the shape above to the exported array in data/caseStudies.js. There are no component changes required.
The sigilId for a case study does not need to correspond to the same project referenced by id. It is purely a decorative icon lookup. Use whichever named sigil best fits the visual context — the "case-studies" sigil is a safe default.
Sections are rendered in the exact order they appear in the sections array. There is no automatic sorting or reordering by heading name — structure the array in the narrative order that best tells the story.

Build docs developers (and LLMs) love

Get started for freeTalk to us