Portfolio case study
61 indexable pages. 42 catalog tool‑ettes. 7 branches. 25 non‑placeholder external destinations. One shared design language, a client‑side search engine, a Python CI gate, and a governance model built to keep everything coherent as it grows — all without a single framework or npm install. This is what it proves.
Most AI tools feel cold. They launch with a blank prompt box, a generic voice, and zero context about who you are or why you showed up. They're powerful in theory and exhausting in practice — because figuring out how to talk to them is a skill most people don't have time to develop.
The design starts with everyday tasks: household planning, career changes, pantry notes, and trips. The catalog aims to make focused AI ideas easier to approach through clear categories, an authored voice, and concrete examples. User research and external GPT testing would be needed to establish how well that intention works.
The deeper problem is structural: building one personalized AI tool is easy. Building forty‑two that share a voice, a taxonomy, a visual language, and a navigation system — without a team or a budget — is a design and architecture problem, not just a prompting problem.
The answer wasn't to build a better blank box. It was to give every tool a home, a name, a personality, and a clear place in a system visitors could understand in three seconds.
"Toolbox" frames the whole system immediately: these are things you reach for when you need them, organized by the kind of job they do. Not a "platform," not a "suite" — a toolbox. Familiar, physical, purposeful. The metaphor does orientation work before the visitor reads a word.
A three-tier taxonomy organizes the catalog: the Toolbox hub, seven branches, and individual Tool-ette pages. Each detail page has a description and publication state; some destinations are unavailable. Breadcrumbs and related-page links connect the levels.
The catalog uses a warm, approachable voice across its descriptions. Breadcrumbs, related-page links, and keyboard search provide ways to explore. External GPT personalities and behavior have not been independently verified by this site.
Glee-fully uses a shared stylesheet foundation with its sibling brands, OverKill Hill P³ and AskJamie. The 7,825-line theme.css contains four named scopes (GLOBAL, OVERKILL, GLEE, ASKJAMIE), plus scoped overrides. Color tokens support consistent styling, while browser checks test selected rendered states.
Every technical decision has a legible reason. Static GitHub Pages, client‑side search, a Python validation toolchain, and structured data — each one chosen because it fits the constraints and outlasts the trend.
GitHub Pages serves HTML, CSS, JavaScript, and assets without a first-party application server. Shared browser scripts handle interactive features. Page speed still depends on asset size, the network, the device, and optional third-party resources.
A Python script builds a JSON index from public page content. The modal and inline search share a browser search engine with weighted fields, category filters, publication labels, and query history. Search uses local site data without a hosted search-service dependency.
The Ecosystem page renders an authored Mermaid map of the brands and their relationships. Maintainers must update it as the ecosystem changes. The site validator checks that Mermaid pages retain their referral credit.
The 42 Tool-ette detail pages use WebPage and BreadcrumbList structured data to describe the catalog pages. Concept illustrations remain images, not application screenshots. The validator checks JSON-LD structure; the catalog makes no claim of Google rich-result eligibility.
The visitor site has no webpack, Vite, or Rollup build. The shared app.js and a Glee-specific adapter provide browser behavior. A package.json supports optional QA tooling. Google Fonts loads separately; analytics loads only after consent, and Ko-fi is an outbound link. Mermaid is served from local assets.
GitHub Actions runs metadata, structured-data, link, and browser checks before the Pages deployment job. The public artifact is staged and checked separately from development files. A passing workflow is release evidence; confirming the live site remains a separate step.
A site with 61 pages and two maintainers — one of whom is an AI agent — needs explicit rules. The governance system makes the right action obvious and the wrong action hard.
The project root carries replit.md with site architecture, maintenance guidance, and dated records. Current instructions must be distinguished from historical audit notes and archived script descriptions. Maintainers also read AGENTS.md and the site-specific agent guidance.
AGENTS.md defines the repository operating rules. Site-specific guidance covers the static architecture, evidence requirements, brand scope, trunk-to-branch-to-Tool-ette taxonomy, and Mermaid referral credit. These documents guide both human and AI contributors.
Periodic multi‑pass audits cover metadata, links,
assets, accessibility, and performance across all 61+
pages. Each audit produces machine‑readable JSON in
assets/audit/ and a human‑readable
Markdown report. The audit cycle is the feedback loop that
keeps the site honest between feature additions.
Generated blocks such as breadcrumbs and related-page trays carry <!-- AUTOGEN:BLOCK --> markers. Maintained generators have focused checks; archived mutators are historical references, not the active release sequence. Structural templates are excluded from the public page inventory and may have their own checks.
Maintainers rebuild the search index after content edits, synchronize portfolio statistics and asset references, then run the applicable validators and browser checks. The active script inventory distinguishes current tools from archived generators. The checked-in Atom feed has a separate publication policy; archived feed generation is not part of this sequence.
Glee‑fully isn't just a product — it's a proof of methodology. Six capabilities, documented in a live system that anyone can click through and verify.
The Toolbox hub, branch hubs, and Tool-ette details give visitors stable levels to explore. Breadcrumbs and related-page trays connect catalog pages, while structured data describes their identity and hierarchy.
Each catalog Tool‑ette has an intended personality, canon, and voice without blurring into the others. Consistency at that scale is an information‑architecture problem, not just a writing problem. Named characters, domain‑scoped tool‑ettes, and a shared canon document solve it structurally. The external GPT behavior behind those authored pages remains outside this repository's audit boundary.
One stylesheet contains four named brand scopes and local overrides. Tokens such as var(--color-rust) and var(--color-teal) support light and dark themes. Fredoka headings, paper-cream surfaces, and rust-and-gold accents express the authored visual style.
The static site includes search, theme controls, image loading, mobile navigation, and structured data. QA uses Python and optional npm tooling. Deployment gates check defined regressions before Pages receives the public artifact; live behavior still needs release verification.
AI agents participate in repository maintenance under human direction. AGENTS.md, site-specific guidance, focused tests, and code review define scope and reduce regression risk. Dated evidence records distinguish verified outcomes from remaining questions.
The catalog aims to make domain-specific AI ideas approachable through named categories, a warm voice, familiar toolbox metaphors, and clear navigation. That is a design intention; ease of use and the behavior of linked GPTs require separate user and product evidence.