Audience
A page should clearly serve one primary audience: CEO, recruiter, PMO leader, operations leader, founder, or Mina himself.
Engineering mode
Read, understand, then change
1. Inspect the existing codeRead the target file and related scripts, styles, workflows and routes before editing.
2. Search before addingCheck whether similar functionality already exists so the platform does not gain duplicate tools.
3. Change the smallest safe surfacePrefer a focused script, route, copy or metadata change over rewriting a full page.
4. Preserve behaviorDo not remove existing scripts, analytics, routers, assistants, links or proof paths unless the change is intentional.
5. Verify the routeConfirm the next action, sitemap, internal links and validation gates still make sense.
Page standards
The standard for every public page
Purpose
A page should do one main job: prove, explain, route, convert, support outreach, or guide decisions.
Evidence
Strong claims should link to proof, a case study, the claims registry, or the proof room.
Next action
Every page should tell the visitor what to do next: contact, assess readiness, review proof, open a guide, or share.
Before merge
Use this checklist
1. Is the claim safe?Check the Claims Registry before adding stronger wording about scope, credentials, budget, or ownership.
2. Is the route obvious?The page should send a recruiter, CEO, PMO leader or executive decision-maker to the next logical asset without confusion.
3. Does validation pass?The GitHub Action should pass before the page is considered complete.
4. Does it strengthen the growth loop?The page should support publish, route, prove, convert, decide, or improve.
5. Is there duplication?Do not add a page if an existing page can be improved instead.
Maintenance rhythm
Monthly maintenance
Once a month, review claims, broken routes, weak CTAs, outdated status, analytics signals, and the top five pages by useful attention.