# Portfolio Content > Add or update project entries, blog posts, placeholders, and related images for Byron Wall's personal portfolio site at /Users/byronwall/Projects/wall-portfolio. Use when asked to create portfolio content, post a project, draft a blog page, add a placeholder page, or prepare portfolio content for auto-publishing. - Skill: `byronwall/portfolio-content` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add byronwall/portfolio-content` - Raw SKILL.md: https://api.skillmd.com/api/skills/byronwall/portfolio-content/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: byronwall (https://skillmd.com/u/byronwall) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/byronwall/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/.mdx`. - Blog post or placeholder: create `app/blog/posts/.mdx`. 4. Connect posts and projects whenever the relationship is known: - Inspect `content/projects/*.mdx` before creating or editing a post. - Add `project: ` 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: ```mdx --- 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: ```mdx --- 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///` - 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//...` for projects - `public/images/posts//...` for blog posts - Reference local images with root-relative URLs such as `/images/projects//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?"