Back to task
Task report

Build a reusable multi-board Task Board Engine

Task title

Build a reusable multi-board Task Board Engine for Regular Task Board, Tasks, and Prosperity Works

Short task summary

Create a new canonical Task Board engine repo that centralizes the shared Next.js code, report/task card components, markdown rendering, copy-to-clipboard prompt boxes, and board layout. Migrate the existing regular-task-board, tasks, and prosperity-works boards into project-specific content/config/theme folders so future visual and behavior improvements are implemented once and reused across all boards.

Recommended model

Use a stronger model for this migration, not Haiku, unless the agent is only doing a small mechanical patch. This touches architecture, multiple repos, content migration, Vercel deployment strategy, and markdown rendering behavior. Use Codex with a high reasoning model, or Claude Sonnet. Haiku can be used later for repetitive follow-up patches after the structure is stable.

Agent prompt

You are working with four repositories open in the same workspace:

  1. regular-task-board
  2. tasks
  3. prosperity-works
  4. a new empty repo that will become the shared engine, tentatively named task-board-engine or regular-task-board-engine

The goal is to stop maintaining three copied versions of the same task board app. These repos are all variations of the same board system, but their code is drifting. Recent examples:

  • report cards and task cards needed highlight/hide actions;
  • the same change had to be copied across repos;
  • CSS was accidentally pasted into itself in one repo;
  • Vercel deployments and branch state made it hard to know which board had which version.

Create a reusable multi-board engine where the shared application code exists once, and each board only supplies content, config, and theme.

Core objective

Build a new canonical Next.js app in the new engine repo with this structure or a better equivalent:

task-board-engine/
  app/
  src/
    components/
      tasks/
      reports/
      markdown/
      layout/
    lib/
      boards/
      tasks/
      reports/
      markdown/
    styles/
      globals.css
      themes/
        regular-punks.css
        tasks.css
        prosperity-works.css
  boards/
    regular-punks/
      board.config.ts
      tasks.json
      reports/
      agent-files/
    tasks/
      board.config.ts
      tasks.json
      reports/
      agent-files/
    prosperity-works/
      board.config.ts
      tasks.json
      reports/
      agent-files/
  public/

The exact structure can be adjusted if needed, but the separation must be clear:

shared engine code = one place
board content      = per-board files
board theme        = per-board CSS variables/theme files
board config       = per-board title, copy, routes, repo links, labels

Important source of truth

Use regular-task-board as the main reference for the current best UI/UX and layout. However, inspect all three repos before migrating because:

  • regular-task-board may have the most mature task/report board behavior;
  • tasks is the personal projects board and has its own content;
  • prosperity-works has its own visual theme/content and may already have deployed behavior not present in main.

Do not blindly overwrite content between repos. Migrate each board’s own public/tasks.json, reports markdown, agent files, and theme differences into its own board folder.

Existing behavior that must be preserved

Preserve the current layout and visual language. I like this layout a lot.

Cards:

  • Keep the same card structure and typography.
  • Keep highlight/hide icons on cards.
  • Use the same icons:
    • Star for highlight
    • EyeOff for hide/collapse
    • Eye for show/expand
  • Store card preferences in localStorage.
  • Do not use hover displacement / physical movement on cards. No transform: translateY(...).
  • Hover may change border/shadow subtly, but cards should not move.
  • Highlight should be visible with the board accent color.
  • Collapsed state should preserve enough metadata to remain useful.

Reports:

  • Report cards must support the same highlight/hide behavior as task cards.
  • Report detail pages must continue to render markdown.
  • Existing report/progress/task-report relationships must keep working.
  • The /reports page behavior should remain visually consistent.

Tasks:

  • Task cards must keep the existing behavior from the best current version of regular-task-board.
  • Task detail pages must continue to render markdown.
  • Task reports must still be discoverable from task cards and report pages.

Markdown:

  • The current reports page already supports markdown with special prompt/code boxes and copy-to-clipboard behavior.
  • Add that same markdown/copy-to-clipboard support to task pages too.
  • Specifically, markdown task descriptions should be able to include a boxed prompt/code section with a copy button, so agent prompts can be stored directly inside task markdown.
  • Do not implement this only for reports; it must be a shared markdown renderer used by both task pages and report pages.

Agent files:

  • Each board may have its own agent context files/instructions.
  • Migrate those into a per-board agent-files/ or equivalent folder.
  • Adapt any references so the agent can understand whether a task belongs to regular-punks, tasks, or prosperity-works.
  • The agent-facing docs should explain:
    • which board is active;
    • where its tasks/reports live;
    • which repos/projects its tasks refer to;
    • how to copy prompts from markdown;
    • that shared engine code should not be forked per board.

Board config requirements

Create a board config layer. Each board should be selected by an environment variable:

NEXT_PUBLIC_BOARD_ID=regular-punks
NEXT_PUBLIC_BOARD_ID=tasks
NEXT_PUBLIC_BOARD_ID=prosperity-works

or, if server-only is cleaner:

BOARD_ID=regular-punks

Each board config should define at least:

type BoardConfig = {
  id: string;
  title: string;
  eyebrow?: string;
  description?: string;
  theme: string;
  tasksPath: string;
  reportsPath?: string;
  agentFilesPath?: string;
  sourceRepos?: Array<{
    name: string;
    url?: string;
    role?: string;
    defaultBranch?: string;
  }>;
};

Use the exact type you think is best, but keep it simple and strongly typed.

Theme requirements

Each board should keep its own visual identity through CSS variables or a small theme file, not through copied component code.

Use something like:

src/styles/themes/regular-punks.css
src/styles/themes/tasks.css
src/styles/themes/prosperity-works.css

or config-driven CSS variables.

Themes should control:

  • accent color;
  • background texture/colors;
  • card border color;
  • muted text colors;
  • maybe project-specific labels.

Themes should not duplicate React components.

Vercel deployment goal

This should work with multiple Vercel projects pointing to the same engine repo, changing only the board env var.

Example:

Vercel project: regular-task-board
Repo: task-board-engine
Env: NEXT_PUBLIC_BOARD_ID=regular-punks

Vercel project: tasks
Repo: task-board-engine
Env: NEXT_PUBLIC_BOARD_ID=tasks

Vercel project: prosperity-works
Repo: task-board-engine
Env: NEXT_PUBLIC_BOARD_ID=prosperity-works

If a monorepo/deploy setup is better, document it. But prefer the simple Vercel model above.

Migration plan

Do this in careful phases.

Phase 1 — Inventory and comparison

Inspect:

  • regular-task-board
  • tasks
  • prosperity-works

Identify:

  • shared components;
  • different components;
  • current task/report routes;
  • markdown renderer;
  • copy-to-clipboard implementation;
  • CSS variables/theme definitions;
  • public data files;
  • reports folder structure;
  • agent instruction files.

Write a short MIGRATION_NOTES.md in the new engine repo summarizing:

  • what was copied from where;
  • which repo is the source of truth for each feature;
  • any differences that were intentionally preserved as board theme/content.

Phase 2 — Create the engine app

Initialize the new engine repo as a working Next.js app based on the best current version of regular-task-board.

Migrate shared code:

  • app routes;
  • task components;
  • report components;
  • markdown renderer;
  • formatting utilities;
  • types;
  • layout;
  • global CSS/tokens.

Keep shared components generic. Do not hardcode regular-task-board, Regular Punks, tasks, or prosperity-works inside components unless it comes from config.

Phase 3 — Create board content folders

Create:

boards/regular-punks/
boards/tasks/
boards/prosperity-works/

Migrate the correct content into each:

  • tasks JSON;
  • reports markdown/content;
  • progress reports;
  • agent files/instructions;
  • board-specific metadata.

Make sure each board can load only its own content.

Phase 4 — Add board selection

Implement board selection from env var.

Expected behavior:

  • if NEXT_PUBLIC_BOARD_ID or BOARD_ID is missing, default to regular-punks or fail with a clear error;
  • invalid board IDs should fail clearly;
  • all pages should read from the active board config/content;
  • build should work for at least one board locally.

Phase 5 — Shared markdown renderer with copy prompt boxes

Find the current copy-to-clipboard prompt/code block behavior used in report pages.

Extract it into a shared renderer/component, for example:

src/components/markdown/MarkdownRenderer.tsx
src/components/markdown/CopyPromptBlock.tsx

Then use that renderer in:

  • report detail pages;
  • task detail pages.

Markdown should support fenced prompt/code blocks that render as a styled box with a copy button.

Example markdown format to support:

```prompt
You are working in ...
Do X, Y, Z.
```

or, if the current system already uses another convention, preserve that convention and document it.

Phase 6 — ReportCard and TaskCard standardization

Standardize card behavior:

  • same highlight/hide interaction;
  • same localStorage strategy, but scoped by board ID to avoid collisions.

Use storage keys like:

const storageKey = `task-board:${boardId}:report-card-collapsed:${report.slug}`;
const highlightStorageKey = `task-board:${boardId}:report-card-highlighted:${report.slug}`;

Do not keep the old regular-task-board:... prefix globally unless there is a migration reason.

Important:

  • no hover displacement;
  • no transform: translateY(-2px) on cards;
  • icons must look correct in resting state and hover state;
  • no malformed duplicated CSS blocks.

Phase 7 — Validation

Run whatever scripts exist:

  • install dependencies;
  • lint;
  • typecheck;
  • build.

If scripts differ between repos, document what was run.

Manually inspect or reason through:

  • /tasks
  • /reports
  • task detail page
  • report detail page
  • hidden/collapsed card state
  • highlighted card state
  • markdown prompt copy block in report page
  • markdown prompt copy block in task page
  • theme differences between all boards

Phase 8 — Documentation

Create docs in the new engine repo:

README.md
docs/ADDING_A_BOARD.md
docs/DEPLOYING_TO_VERCEL.md
docs/BOARD_THEMES.md
docs/AGENT_WORKFLOW.md

These docs should explain:

  1. How to add a new board.
  2. How to create a new theme.
  3. How to deploy the same engine to Vercel for a specific board.
  4. How to add tasks/reports.
  5. How to write markdown prompt blocks with copy buttons.
  6. How agents should work in the centralized engine without forking shared code.

Important constraints

  • Do not redesign the app.
  • Do not change the core visual layout unless necessary for the engine abstraction.
  • Do not remove existing content.
  • Do not merge the three boards into one visible board; they must remain selectable/deployable as separate boards.
  • Do not duplicate shared React components per board.
  • Do not create three separate versions of ReportCard.
  • Do not create three separate versions of TaskCard.
  • Do not leave hardcoded references that make one board accidentally show another board’s tasks/reports.
  • Do not touch unrelated source repos except to read/migrate content.
  • Do not commit generated build artifacts.
  • Keep the current aesthetic and board-specific colors.

Final deliverable

At the end, provide a concise implementation report with:

Summary
Files/structure created
Boards migrated
How to run each board locally
How to deploy each board on Vercel
Validation performed
Known limitations / follow-up tasks

Also include a short note explaining whether the old repos should remain archived/read-only after the new engine is validated.