Portfolio Content

Portfolio Content

Use this skill when creating or updating content for Byron Wall's portfolio site.

Site map

• Repo: /Users/byronwall/Projects/wall-portfolio
• Projects: content/projects/*.mdx
• Blog posts: app/blog/posts/*.mdx
• Local images: public/images/...
• Shared content loader: app/blog/utils.ts
• Project index/detail pages: app/projects/page.tsx, app/projects/[slug]/page.tsx
• Blog index/detail pages: app/blog/page.tsx, app/blog/[slug]/page.tsx

Workflow

1. Work in /Users/byronwall/Projects/wall-portfolio, not the caller's current repo.
2. Inspect nearby MDX examples before writing. Match their frontmatter and tone.
3. Choose the target:
   • Project entry: create content/projects/<slug>.mdx.
   • Blog post or placeholder: create app/blog/posts/<slug>.mdx.
4. Connect posts and projects whenever the relationship is known:
   • Inspect content/projects/*.mdx before creating or editing a post.
   • Add project: <project-slug> to the post frontmatter using the exact project filename slug.
   • Add a controlled type: update, feature, debugging, experiment, tooling, failure, reflection, or reference.
   • Do not guess a relationship. If it is unclear, leave project unset for later review.
   • When creating a project, check existing posts for obvious matches and backfill their project and type fields in the same change.
   • Project detail pages automatically use this metadata to render related-post cards; preserving the exact slug is therefore important.
5. Prefer concise content that can publish immediately. For placeholders, state what exists now and what will be expanded later.
6. Never run pnpm run build or another production build command during portfolio-content work. The build shuts down or disrupts the active development server and is annoying to recover. Use pnpm exec tsc --noEmit when validation is appropriate.
7. Preserve an already-running development server. Use pnpm run dev only when the user explicitly wants a local preview and no suitable preview server is already running.
8. After content is done and validation status is clear, ask whether to commit and push. Do not commit or push unless the user explicitly says yes.

Frontmatter

Project entries should normally use:

---
title: "Project Name"
description: "One sentence description for project lists"
date: "YYYY-MM-DD"
publishedAt: "YYYY-MM-DD"
summary: "One sentence summary for metadata"
tags: ["Tech", "Category"]
image: "https://raw.githubusercontent.com/byronwall/repo/main/path/image.png"
status: "active"
repo: "https://github.com/byronwall/repo"
demo: "https://example.com"
---

Blog posts can be lighter:

---
title: Post title
publishedAt: YYYY-MM-DD
summary: 'Short summary for metadata and previews.'
image: "/images/posts/slug/image.png"
project: project-slug
type: update
---

The parser is simple and line-oriented. Keep frontmatter values on one line. Use array syntax for tags.

Project metadata may also include featured, package, docs, and logo. Use explicit lifecycle values such as active, shipped, paused, experimental, or archived only when the source material establishes them; use a visible content placeholder instead of inferring status from a publication date.

Images

• Prefer GitHub raw URLs for project screenshots when available: https://raw.githubusercontent.com/byronwall/<repo>/<branch>/<path>
• Look for likely images in the source repo first, especially docs/, public/, assets/, screenshots/, and README references.
• If a GitHub image is not easy to use, create or copy an image into the portfolio repo under:
  • public/images/projects/<slug>/... for projects
  • public/images/posts/<slug>/... for blog posts
• Reference local images with root-relative URLs such as /images/projects/<slug>/screenshot.png.
• If frontmatter image is omitted, the site uses the first markdown or HTML image in the MDX body as the thumbnail.

Content Pattern

For project entries, usually include:

• One opening paragraph explaining what the project is.
• Links such as Source: [byronwall/repo](https://github.com/byronwall/repo) when known.
• An ## Interface section with the main screenshot when available.
• ## How it works and ## Highlights sections for published entries.

For quick placeholders, keep it short:

• Frontmatter with title, date, publishedAt, summary, and tags if known.
• A paragraph describing the intended project or post.
• A source/demo link if available.
• A note about what will be added later only if useful.

Validation and Publishing

• Never run pnpm run build, next build, or any equivalent production build command. Do not use a build as validation in these sessions because it disrupts the active development server.
• When validation is useful, run pnpm exec tsc --noEmit from the portfolio repo. For content-only changes where TypeScript validation adds no value, inspect the MDX and assets directly.
• If the user wants a local preview, reuse the existing development server when available. Otherwise, run pnpm run dev from the portfolio repo; the configured port is 3010.
• Final response should include changed paths, validation result, and whether a local preview is running.
• Always ask: "Do you want me to commit and push this so it can publish, or would you rather review the local preview first?"