This is a full workflow from idea → shipped code → written-down context. Each stage uses a small, focused assistant plus reusable playbooks (agent-skills, awesome-copilot). The same setup works in Cursor, Claude Code, Codex, or anything that reads the repo’s instruction files.

Standard instruction files committed to the repo root. Every major agent runtime reads at least one - same conventions apply whether you're on Cursor, Claude Code, or Codex.

For language or framework-specific conventions (React, Next.js, Python, etc.), find and install the relevant community skill from skills.sh and reference it in your instruction files alongside the core agent skills.

Idea → Design → Spec → Code → Review → PR/Issues → CI/CD → E2E + debugging → Document/Wiki

Agent: Designer

• Establishes visual direction - branding, UI/UX, design system - before spec or code is written
• Outputs (tokens, component names, screen flows) feed directly into SPEC.md

Tools used:

• Superdesign - UI/UX + branding exploration; exports React/HTML/CSS, design tokens, and component specs

Skills used:

• impeccable - builds on frontend-design with 7 domain references (typography, color/contrast, spatial, motion, interaction, responsive, UX writing).

Key commands:

• /critique (UX review)
• /audit (quality checks like performance, accessibility, etc.)
• /normalize (design system alignment)

Anti-patterns it guards against: overused fonts (Inter/Arial) · gray text on color · pure black/gray neutrals · nested cards · bounce easing

Agent: Planner

• Refines raw idea → writes spec → breaks into atomic tasks with acceptance criteria

Skills used:

• idea-refine - clarify problem, constraints, success criteria
• spec-driven-development - produce SPEC.md before touching code
• planning-and-task-breakdown - atomic tasks with definition of done
• documentation-and-adrs - log architecture decisions inline at decision time
• context-engineering - structure context so downstream agents stay coherent

Agent: Builder

• Implements spec in small, testable slices - never one-shot

Skills used:

• incremental-implementation - thin vertical slices, each commit is a working unit
• test-driven-development - tests written alongside code, not after
• api-and-interface-design - contract-first APIs, validated at every boundary
• frontend-ui-engineering - clean component patterns, accessibility baked in
• Framework/language skill from skills.sh - find the relevant one for your stack and reference it in AGENTS.md

Agent: Reviewer

• Runs a review pass before anything is staged - CI should never catch what this misses
• For UI-facing work: Playwright QA loop on local or preview (Playwright MCP; details in playwright-interactive below) - inventory from spec + shipped behavior + PR claims; functional then visual pass; one persistent session; proof or documented gaps before commit

Skills used:

• playwright-interactive - persistent Playwright, inventory → functional + visual QA
• code-review-and-quality - correctness, readability, security, perf, spec alignment
• security-and-hardening - OWASP basics, input validation, no secrets in code
• performance-optimization - bundle size, render cost, measure-first

Agent: PR Writer (GitHub MCP + awesome-copilot)

• Creates branch, writes PR description from spec, links issues - no manual writing

Skills used:

• git-workflow-and-versioning - small commits, clean branch naming, trunk-based
• awesome-copilot pr-description - structured title, summary, how-to-test, linked issues
• GitHub MCP - creates branch, opens PR, applies labels, requests reviewers, posts preview URL

Issue resolution flow: agent reads open issue via GitHub MCP → generates fix branch → implements fix → opens PR with fixes #N

Agent: PR Reviewer (AI + CI)

• Reviews like a staff engineer, enforces quality gates before merge

Skills used:

• code-review-and-quality - mandatory pre-merge pass
• security-and-hardening - catches issues at the PR diff level
• debugging-and-error-recovery - flags risky changes, suggests patches
• awesome-copilot PR reviewer agent - GitHub-native review comments

Pipeline: GitHub Actions + Vercel.

Skills used:

• ci-cd-and-automation — author and maintain workflows, caches, and log-driven fixes
• deploy-to-vercel — linked projects, preview vs production, git-push vs CLI deploy
• awesome-copilot create-github-action-workflow-specification — formal spec for an existing Actions workflow (good for AI maintenance and onboarding)

Agent: Runner (Playwright MCP + Chrome DevTools MCP)

• Executes real user flows on live preview · captures traces, logs, screenshots

Skills used:

• browser-testing-with-devtools - real browser validation against spec acceptance criteria
• debugging-and-error-recovery - reproduce → isolate → report

Output: Structured test report posted back to PR as a review comment via GitHub MCP. Loop closes - acceptance criteria written in step 2, verified here.

Agent: Debugger

• Investigates CI failures, test regressions, deploy issues autonomously

Skills used:

• debugging-and-error-recovery - reproduce → isolate → hypothesize → fix → verify
• Chrome DevTools MCP - live console + network inspection on the running preview

Agents: Feedback + Documenter — same job from two angles: turn what just happened into durable memory so the next session does not rediscover or undo it. Agents have no cross-session memory; the repo (AGENTS.md, wiki, ADRs) is the substitute.

Skills used:

• context-engineering - structure updates so future agents load signal, not noise
• documentation-and-adrs - decisions, options rejected, reversal cost

Long-form capture (lives in docs/wiki/): specs + drift · ADRs · incident post-mortems · stable patterns · skills/MCP reference

Maintenance model: Inspired by Karpathy's LLM Wiki — raw sources in docs/raw/ (immutable), agent processes them into wiki pages; standing rules stay in AGENTS.md. Knowledge compounds instead of resetting.

• Standard instruction files - AGENTS.md at the repo root so any agent runtime picks up the same conventions without re-prompting
• Skill-driven - each step maps to a proven engineering workflow, not a one-off prompt
• Small agents > one big agent - each phase has a clear input, output, and failure mode
• Structured outputs everywhere - validated contracts at every boundary
• Read before you write - every agent invocation starts with AGENTS.md + SPEC.md