Claude Project · Portfolio Architecture

GitHub Portfolio Rebuild

The project manager instructions used to keep two GitHub profiles, personal and Techbase, consistently modernised: a distinct visual identity for every repo, and one strict rule for how any project is allowed to link to any other.

2
GitHub profiles
3
Allowed footer links
1
Repo per session
0
Cross project links
Overview

Every repo can trace back to who made it and which org it belongs to, nothing more

This is the source of truth for how repos across babatundeawo and techbaseng get rebuilt: a full modernisation pass per repo, never a cosmetic tweak, and a linking rule that overrides any older habit of cross linking projects to each other.

Every individual project repo points to exactly three places: the personal portfolio, the personal GitHub profile, and the Techbase org profile. No repo links to any sibling project, and no repo links directly to the Techbase company website, that link lives one level up on the Techbase org profile itself.

What rebuilding a repo means

A full pass, not a coat of paint

Distinct visual identity

Each repo gets its own tailored colour palette and typography direction, no two repos should look like reskins of each other, while still reading clearly as personal or Techbase work.

A modern README per repo

Clear description, live demo link, screenshot if relevant, tech stack, setup instructions where applicable, and the standard three link footer, nothing else linking out.

The redirect stub exception

A small set of personal profile repos are not rebuild targets, they are simple redirect stubs pointing to the canonical Techbase versions of the same project, since the personal links were already shared publicly before the move.

One repo, or a small batch, per chat

A genuine modernisation pass needs real attention. Uploading a dozen repos into a single conversation degrades quality and burns context fast, so work happens one repo, or one closely related batch, per session.

Session workflow

Six steps for every rebuild

01

Receive the repo

A zip is unzipped in the chat, or a small batch of related repos is uploaded together.

02

Check the directory file

Confirm which profile the repo belongs to, and check its current status, existing theme, and whether it is a redirect stub.

03

Propose a palette

A distinct colour palette and typography direction is proposed before any major change, unless one is already established.

04

Rebuild

Modernise structure and design, rewrite the README with the three link footer rule, and strip any other outbound links.

05

Summarise and flag

What changed is summarised, and anything needing a decision, like a new repo type or unclear ownership, is flagged rather than assumed.

06

Update the directory

Once pushed live, the directory file’s status column is updated, and new additions get added to the All Projects section on both the portfolio and the profile README.

Get this project

Copy the exact files used to run this Claude Project

The short instructions go in the Claude Project’s instructions field. The detailed workflow file and the repo directory template are uploaded as knowledge files, and the directory should be adapted to your own repos.

Custom instructions

Goes in the Claude Project's instructions field
File: files/custom-instructions.md
Open raw file ↗

Detailed workflow (knowledge file)

The full rebuild workflow, theming rules, and linking architecture
File: files/project-instructions.md
Open raw file ↗

Repo directory template

Example structure for tracking every repo, its live link, and its rebuild status
File: files/github-repo-directory.md
Open raw file ↗