Past Build Export

Turn any codebase into a compelling portfolio piece for pastbuild.com. This skill extracts what makes your project interesting and formats it for easy import.

When to Use

Users ask things like:

• "Export this to Past Build"
• "Create a portfolio JSON for my project"
• "Generate Past Build format for [project]"

Your job: analyze the codebase, identify the highlights, and output clean JSON.

What Makes a Strong Project Entry

Past Build isn't a resume template. It's a way to showcase why you built something and what makes it interesting. Focus on:

Technical decisions worth talking about - Not just "used React", but "chose React Server Components to reduce client bundle by 40%"

Problems you solved - "I built this after debugging race conditions for three days" tells a story

Unique features - What makes this project different from a generic starter template?

Measurable impact - "Processes 10K requests/second" or "reduced build time from 45s to 8s"

JSON Structure

{
  "version": 1,
  "name": "Project Name",
  "description": "One sentence that captures what this project accomplishes",
  "projectStatus": "ongoing" | "finished",
  "projectDate": "YYYY-MM-DD",
  "sections": [
    {
      "id": "uuid-v4",
      "title": "Feature-focused headline",
      "subtitle": "Why this matters + technical insight",
      "order": 0,
      "media": []
    }
  ],
  "links": [...],
  "exportedAt": "2024-01-01T00:00:00.000Z"
}

| Field | Required | Notes | |-------|----------|-------| | version | Yes | Always 1 | | name | Yes | Project name from package.json or repo | | description | Yes | One sentence, pitch-style | | projectStatus | No | "ongoing" or "finished" | | projectDate | No | When the project was built (git log --reverse helps) | | sections | Yes | 2-5 feature sections work best | | links | No | GitHub, demo, docs | | exportedAt | Yes | Current ISO timestamp |

Extracting Project Info

Where to Find Information

| Source | What to Look For | |--------|------------------| | package.json, pyproject.toml, go.mod | Name, dependencies, tech stack | | README.md | What the project claims to do, features, origin story | | Source files | Architecture patterns, complex logic, interesting solutions | | Git history | When it started, what evolved over time |

Section Strategy

Each section should cover one compelling aspect of the project. Think:

"What would I want to show someone if they only had 30 seconds?"

Good sections answer questions like:

• "What interesting problem does this solve?"
• "What technical challenge did you tackle?"
• "What makes this different from a boilerplate?"

Bad sections just restate generic categories:

• "Overview" (too vague)
• "Tech Stack" (boring, expected)
• "Features" (what doesn't have features?)

Writing Subtitles That Work

The subtitle is where the story lives. Avoid generic placeholders.

Weak: "How authentication works" Strong: "I built custom JWT handling after our team hit session expiration bugs in production - now tokens refresh silently without user disruption"

Weak: "Performance optimizations" Strong: "Reduced TTI from 3.2s to 0.8s by deferring non-critical chunks and preloading only what was above the fold"

Weak: "Database design" Strong: "Schema designed to handle 10M+ rows without sacrificing query speed - I denormalized just enough to make joins practical"

Example: SaaS Dashboard

{
  "version": 1,
  "name": "MetricFlow Analytics",
  "description": "A real-time analytics dashboard helping SaaS teams monitor key metrics without switching between tools.",
  "projectDate": "2026-02-01",
  "sections": [
    {
      "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "title": "Real-time data pipelines over WebSocket",
      "subtitle": "Built to handle 10K+ concurrent connections without dropping updates - I learned the hard way that polling just doesn't cut it for live dashboards.",
      "order": 0,
      "media": []
    },
    {
      "id": "b2c3d4e5-f6a7-8901-bcde-f23456789012",
      "title": "Drag-and-drop widget customization",
      "subtitle": "Users compose their own view by dragging widgets onto a canvas - I used a grid-based layout system to make positioning intuitive yet responsive.",
      "order": 1,
      "media": []
    },
    {
      "id": "c3d4e5f6-a7b8-9012-cdef-345678901234",
      "title": "Multi-tenant RBAC with granular permissions",
      "subtitle": "Each organization gets complete isolation - I implemented row-level security at the database level rather than application level for true data separation.",
      "order": 2,
      "media": []
    }
  ],
  "links": [
    { "id": "l1", "text": "Live Demo", "url": "https://metricflow.example.com" },
    { "id": "l2", "text": "GitHub", "url": "https://github.com/username/metricflow" }
  ],
  "exportedAt": "2026-02-12T01:30:00.000Z"
}

Example: Developer Tool / CLI

{
  "version": 1,
  "name": "GitWip CLI",
  "description": "A developer tool that intelligently groups related git changes into sensible work-in-progress commits.",
  "projectDate": "2026-01-15",
  "sections": [
    {
      "id": "e1f2a3b4-c5d6-7890-abcd-ef1234567890",
      "title": "Smart commit grouping with semantic analysis",
      "subtitle": "Instead of asking 'what files did you change?', it analyzes imports and file patterns to auto-group related changes - this reduced our team's WIP commit noise by 70%.",
      "order": 0,
      "media": []
    },
    {
      "id": "f2a3b4c5-d6e7-8901-bcde-f23456789012",
      "title": "Cross-branch stash management",
      "subtitle": "I built this after losing work twice when stashing on one branch and applying on another - it tracks stash context so nothing ever gets applied to the wrong branch.",
      "order": 1,
      "media": []
    },
    {
      "id": "g3a4b5c6-e7f8-9012-cdef-345678901234",
      "title": "Optimized for monorepos with millions of files",
      "subtitle": "Standard git status is too slow in large repos - I implemented a Rust-based status scanner that cuts status time from 8s to 200ms in our main monorepo.",
      "order": 2,
      "media": []
    }
  ],
  "links": [
    { "id": "l1", "text": "npm Package", "url": "https://npmjs.com/package/gitwip" },
    { "id": "l2", "text": "Documentation", "url": "https://gitwip.dev/docs" }
  ],
  "exportedAt": "2026-02-12T01:30:00.000Z"
}

Quick Reference

UUID Generation:

import uuid
str(uuid.uuid4())
# → a1b2c3d4-e5f6-7890-abcd-ef1234567890

Git date extraction:

git log --reverse --format=%ai | head -1

For project status:

• ongoing: Recent commits, active features planned
• finished: Side project that reached its goals, no active development

More Examples

See EXAMPLES.md for additional examples across different project types.