Command a 25-Engineer AI Org in Cursor

Lead a 25-subagent AI org through a full product sprint with DevSecOps.

Introduction

30 Second Summary

Engineering leaders don't just write code. They coordinate teams, manage risk, handle incidents under pressure, and communicate results to stakeholders who have never opened a terminal.

In this project, you will run a 90-minute leadership simulation where you command 25 AI "engineers" organized into 5 teams using Cursor subagents. You will deliver 25 merged PRs across a React + Rust monorepo, handle a security incident mid-sprint, and produce a shareholder-ready executive report.

What You'll Build

You will build "Nexus," a simulated real-time API gateway platform, while simultaneously producing the full artifact package a Senior Program Manager presents to board stakeholders.

By the end of this project, you'll have:

  • A fully operational 5-team Cursor workspace with 25 subagent "engineers," complete with industry-standard planning artifacts like ADRs, architecture diagrams, a sprint plan, and a team charter.
  • A production DevSecOps pipeline with SAST, SCA, secrets scanning, and human-gated deployment, plus 25 merged PRs delivered through automated quality gates and CODEOWNERS governance.
  • A shareholder-ready delivery package including a KPI dashboard, 1-page executive summary, risk register, and sprint retrospective suitable for presenting to a Senior Program Manager.
  • Secret Mission: a P0 security incident drops mid-sprint, and you coordinate all 5 teams for emergency response and produce a board-ready post-mortem.

Are there any prerequisites?

You need a Cursor Pro Plus subscription ($60/month), plus Node.js, the Rust toolchain, Git, Docker Desktop, and a GitHub account already installed and configured.

You should be comfortable with Git basics, have a general understanding of React and Rust syntax, and feel at home in the terminal.

Before We Start

Before We Start...

Pre-flight and Workspace Configuration

Before you can command a 25-engineer organization, you need to confirm your tools are battle-ready.

In this step, you will verify your local toolchain, activate Cursor's subagent capabilities, and set up your GitHub repository with production-grade governance rules.

In this step, get ready to:
  • Verify all four tools (Node.js, Rust, Git, Docker) and enable Max Mode with subagents.
  • Create a public GitHub repository with branch protection and Actions enabled.
  • Clone the repo, open it in Cursor, and start your 90-minute sprint timer.
Verify tools and enable Max Mode

Your engineering org relies on four core tools: Node.js for the React dashboard, Rust for the API gateway, Git for version control, and Docker for containerization.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.
  • Verify all four tools are installed by running these commands one at a time:
node -v
rustc --version
git --version
docker --version

Each command should print a version number (e.g. v22.x.x, rustc 1.x.x, etc.).

One of the commands says 'not found'?

If node -v fails, install Node.js from nodejs.org. If rustc --version fails, install Rust via rustup.rs. If docker --version fails, make sure Docker Desktop is installed and running.

Help me troubleshoot my tool installations

Now you need to activate Cursor's most powerful feature: subagents. These are parallel AI workers that will act as your 25 engineers. Subagents require Max Mode to be enabled.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Cursor and press Enter to open it.
  • Open the agent chat panel by pressing Cmd+Shift+I (macOS) or Ctrl+Shift+I (Windows).
  • Enable Max Mode by typing this in the agent chat:
/max-mode on
  • Verify subagents work by typing this prompt in the agent chat:
Spawn a subagent to check if this directory has a package.json

You should see Cursor spawn a subagent that runs independently and reports back. If it spawns successfully, your org is ready for action.

What are subagents?

Subagents are parallel AI workers that Cursor spawns to handle tasks independently. Each one operates in its own isolated context, like an engineer at their own desk.

When you use /multitask later in this project, Cursor breaks your request into chunks and assigns each chunk to a subagent. This is how you will run 5 teams simultaneously.

Subagent didn't spawn?

Make sure you have an active Cursor Pro Plus subscription ($60/month). Subagents require Max Mode, which is only available on Pro Plus.

If you see a message about usage limits, check your API usage balance in Cursor Settings. Pro Plus includes $70 of API usage per month.

Help me get subagents working in Cursor

Create the GitHub repo with governance

Your engineering org needs a central repository with guardrails that prevent anyone (including subagents) from pushing directly to the main branch. Branch protection enforces code review and automated checks on every change.

  • Open github.com in your browser and sign in.
  • Click the + icon in the top-right corner.
  • Select New repository.
  • Enter nexus-platform as the repository name.
  • Set visibility to Public.
  • Check the box for Add a README file.
  • Click Create repository.

Why public?

Public repos get 2,000 free GitHub Actions minutes per month. Since your DevSecOps pipeline runs on every PR, you want those free minutes. A public repo also means your final artifact is a shareable portfolio piece.

Now set up branch protection to enforce governance on the main branch.

  • In your new repository, click Settings in the top navigation bar.
  • In the left sidebar, click Branches under the Code and automation section.
  • Click Add branch ruleset.
  • Enter main-protection as the ruleset name.
  • Set Enforcement status to Active.
  • Under Target branches, click Add target and select Include default branch.

Now enable the four protection rules that will govern your sprint.

  • Under Branch rules, check Require a pull request before merging.
  • Set Required approvals to 1.
  • Check Require status checks to pass.
  • Check Require linear history.
  • Check Block force pushes.
  • Click Create to save the ruleset.

What does branch protection do?

These four rules create a human-gated governance layer. No code reaches main without a pull request, at least one approval, passing CI checks, and a clean commit history.

You (the TPM and Tech Lead) are the human gate. Your subagent engineers write the code, but you decide what ships.

  • Verify GitHub Actions is enabled by clicking Actions in the top navigation bar of your repository.

You should see a welcome page offering starter workflows. This confirms Actions is enabled and ready.

Open the workspace in Cursor

With the repo created and protected, you need to clone it locally and open it in Cursor. This is where you will build the entire monorepo.

  • In your terminal, move to your Desktop by running this command:
cd ~/Desktop
  • Clone the repository by running:
git clone [[YOUR_REPO_URL="https://github.com/YOUR_USERNAME/nexus-platform.git"]]

Find your clone URL

On your repo page in GitHub, click the green Code button and copy the HTTPS URL.

  • Move into the cloned folder by running:
cd nexus-platform
  • Open this folder in Cursor by running:
cursor .

cursor command not found?

If the cursor command is not recognized, open Cursor manually. Press Cmd+Space (macOS) or the Windows key (Windows), type Cursor, open it, then use File > Open Folder to navigate to Desktop/nexus-platform.

Help me open my project in Cursor

  • Confirm you can see the README.md file in Cursor's Explorer sidebar on the left.
  • Set a 90-minute timer on your phone or computer. The sprint starts now.

Why time yourself?

The constraint is the point. A real TPM delivers under deadlines. Your 90-minute budget forces you to delegate aggressively to your AI org rather than hand-writing code yourself.

Your environment is locked and loaded. Next up, you will generate the full planning artifact suite that a Senior Program Manager would present to stakeholders before a single line of code gets written.

Generate Planning Artifacts and Architecture

Your workspace is configured and the clock is running. Before a single line of product code gets written, you need the strategic foundation that separates a "fast coder" from a leader.

In this step, you will generate the planning artifacts that any Senior Program Manager would present before a sprint: Architecture Decision Records, system diagrams, a team charter, a risk register, and a full sprint backlog. Then you will scaffold the actual monorepo that your 25 engineers will ship code into.

In this step, get ready to:
  • Generate architecture decision records, system diagrams, a team charter, and a risk register.
  • Create a sprint backlog with 25 scoped tickets and a CODEOWNERS governance file.
  • Scaffold a monorepo with a React dashboard and a Rust gateway service.
Generate the full planning document suite

Cursor's Plan Mode lets the agent think through a complex task before executing. Instead of immediately writing files, it produces a structured plan you can review and approve.

You will use Plan Mode to generate five documents that form the strategic backbone of your project. These are the same artifacts used at Google, Stripe, and Spotify before engineering work begins.

  • In the Cursor agent chat, activate Plan Mode by pressing Shift+Tab.
  • Paste the following prompt and submit it:
You are a Senior Technical Program Manager. Generate our project planning artifacts for Nexus, a real-time API gateway platform.

Create the following files:

1. docs/architecture/adr-001-rust-axum.md
   - ADR for choosing Axum over Actix-web
   - Standard format: Title, Status (Accepted), Context, Decision, Consequences
   - Context: Axum aligns with Tokio ecosystem, type-safe extractors prevent production bugs
   - Actix-web is 10-15% faster but Axum is the pragmatic default for maintainability

2. docs/architecture/adr-002-monorepo.md
   - ADR for choosing monorepo over polyrepo
   - Context: shared types between frontend and backend, unified CI/CD, atomic changes

3. docs/architecture/system-diagram.md
   - Mermaid diagram showing service topology
   - Components: React Dashboard, Rust Gateway, PostgreSQL, GitHub Actions CI/CD, Docker Registry
   - Show data flow between components

4. docs/team-charter.md
   - 5 teams: Alpha (Dashboard), Bravo (Core/Gateway), Charlie (DevOps), Delta (SecOps), Echo (QA)
   - For each team: ownership scope, model tier assignment, escalation path
   - Alpha and Bravo use mid-tier models for feature work
   - Delta uses senior-tier for security-sensitive work

5. docs/risk-register.md
   - Top 5 risks in likelihood x impact matrix format
   - Include: dependency vulnerabilities, CI pipeline failures, scope creep, security gate false positives, merge conflicts from parallel work
   - Each risk has a mitigation strategy

What are these artifacts?

ADRs document WHY you chose a technology, not just what you chose. They are the standard format at every major tech company for recording architectural decisions with their tradeoffs.

The Mermaid diagram renders natively in GitHub markdown. No external tools needed. The risk register follows a standard likelihood-times-impact matrix that any enterprise program review requires.

  • Review the plan that Cursor generates. It should list the five files and their structure.
  • Approve the plan to let the agent generate all files.
  • Once the agent finishes, confirm the files exist by running:
ls docs/architecture/ docs/

You should see adr-001-rust-axum.md, adr-002-monorepo.md, and system-diagram.md inside docs/architecture/. You should also see team-charter.md and risk-register.md in the docs/ root.

Files missing or in the wrong location?

If the agent placed files in unexpected directories, ask it to move them: "Move the ADR files to docs/architecture/ and the charter and risk register to docs/". Plan Mode occasionally creates flat structures instead of nested folders.

If the agent stalled or produced partial output, re-submit the prompt. Subagents occasionally time out on large generation tasks.

Help me troubleshoot why Cursor's Plan Mode didn't generate all my planning documents.

Generate the sprint backlog and CODEOWNERS

Every sprint needs a backlog. Your backlog will contain 25 tickets distributed across the 5 teams, each sized and prioritized so subagents can execute them independently.

  • In the Cursor agent chat, paste the following prompt and submit it:
Create two files:

1. docs/sprint-plan.md
   - 25 tickets distributed across 5 teams:
     - Alpha (Dashboard): 7 tickets (NEX-001 through NEX-007)
     - Bravo (Core/Gateway): 8 tickets (NEX-008 through NEX-015)
     - Charlie (DevOps): 5 tickets (NEX-016 through NEX-020)
     - Delta (SecOps): 3 tickets (NEX-021 through NEX-023)
     - Echo (QA): 2 tickets (NEX-024 through NEX-025)
   - Each ticket must have: ID, title, team, priority (P1 or P2), size (S or M), acceptance criteria
   - P1 tickets are core functionality, P2 are enhancements
   - S = single component/endpoint, M = multiple files or integration

2. CODEOWNERS (in repo root)
   - apps/dashboard/ @team-alpha
   - services/gateway/ @team-bravo
   - .github/ @team-charlie
   - security/ @team-delta
   - tests/ @team-echo

What is CODEOWNERS?

CODEOWNERS is a GitHub governance file that automatically assigns reviewers to pull requests based on which files are changed. When a PR touches apps/dashboard/, GitHub knows Team Alpha owns that code.

This maps ownership to code paths. It is how Netflix and Spotify enforce accountability across platform teams at scale.

  • Let the agent produce both files.
  • Verify the sprint plan has all 25 tickets by running:
grep -c "NEX-" docs/sprint-plan.md

You should see 25 (or a number close to it) confirming all tickets are present. Also confirm the CODEOWNERS file exists in the repo root by running:

cat CODEOWNERS

You should see five lines mapping directory paths to team names.

Sprint plan has fewer than 25 tickets?

The agent sometimes generates fewer tickets when it hits output limits. Ask it to continue: "The sprint plan is missing tickets. Add tickets up to NEX-025, following the same format."

If the CODEOWNERS file is missing, ask: "Create a CODEOWNERS file in the repo root with the team mappings I specified."

Help me get my sprint plan to include all 25 tickets.

Scaffold the monorepo structure

With the strategy documented, it is time to create the actual codebase. Your monorepo will house a React dashboard, a Rust gateway service, and a shared types package in one repository.

Cursor's /multitask command spawns multiple subagents that work in parallel. Each subagent gets its own isolated worktree so they cannot step on each other's files. You will use this to scaffold the frontend and backend simultaneously.

  • In the Cursor agent chat, type /multitask followed by this prompt:
/multitask

Task 1 - Frontend Dashboard:
Create apps/dashboard using: npx create-next-app@latest --typescript --tailwind --app --src-dir
Project name: dashboard
After scaffolding, add placeholder pages:
- src/app/page.tsx (home/overview page)
- src/app/routes/page.tsx (route management page)
- src/app/analytics/page.tsx (analytics page)
Each page should export a default component with the page title as an h1.

Task 2 - Rust Gateway:
Create services/gateway using: cargo init --name nexus-gateway
Update Cargo.toml with dependencies:
- axum = "0.8"
- tokio = { version = "1", features = ["full"] }
- serde = { version = "1", features = ["derive"] }
- tower-http = { version = "0.6", features = ["cors", "trace"] }
- tracing = "0.1"
- tracing-subscriber = "0.3"
Create src/main.rs with:
- A health check endpoint at GET /health returning JSON { "status": "ok" }
- Bind to 0.0.0.0:3001
- Basic tracing subscriber initialization

After both tasks complete, also create:
- packages/shared/types.ts with a shared Route interface (id, path, target, rateLimit)

Why Axum over Actix-web?

Axum 0.8 is the pragmatic default for Rust web services in 2026. Actix-web is 10-15% faster in raw requests per second, but Axum's type-safe extractors and tight integration with the Tokio ecosystem make it easier for teams to maintain long-term.

Companies like Cloudflare, Discord, and Figma use Rust in production for similar gateway and proxy workloads.

  • Let the subagents complete both tasks. This may take 1-2 minutes as Next.js scaffolding installs dependencies.
  • The create-next-app wizard may trigger interactive prompts inside the subagent. The agent handles these automatically based on your prompt flags.
  • Once both tasks finish, verify the monorepo structure by running:
ls apps/dashboard/src/app/ services/gateway/src/ packages/shared/

You should see page.tsx (plus routes/ and analytics/ folders) in the dashboard, main.rs in the gateway, and types.ts in shared.

One of the tasks failed or stalled?

If only one task completed, run the other manually. For the dashboard: ask the agent "Create apps/dashboard with Next.js 15, TypeScript, Tailwind, App Router, and src-dir." For the gateway: ask "Create services/gateway with cargo init --name nexus-gateway and add Axum 0.8 dependencies."

If packages/shared/ is missing, ask the agent: "Create packages/shared/types.ts with a Route interface containing id, path, target, and rateLimit fields."

Help me fix my /multitask scaffold that only partially completed.

Now commit everything to main. This includes all planning documents, the CODEOWNERS file, and the monorepo scaffold.

  • Stage and commit all files by running these commands:
git add -A
git commit -m "chore: initial monorepo scaffold"
git push origin main

What does this commit include?

This single commit bundles your entire foundation: 2 ADRs, 1 system diagram, 1 team charter, 1 risk register, 1 sprint plan, the CODEOWNERS file, the Next.js dashboard, the Rust gateway, and the shared types package. Every file your 25 engineers will build on starts here.

  • After the push completes, open your GitHub repository in a browser.
  • You should see the docs/, apps/, services/, and packages/ folders in your repository root.

Push rejected due to branch protection?

As the repository admin, you can bypass branch protection for this initial commit. Go to your GitHub repo's Settings, then Branches, then edit the main protection rule. Make sure Do not allow bypassing the above settings is unchecked. Admins can then push directly.

Help me push to a branch-protected main branch as the repo admin.

✔️ Awesome, I see everything in GitHub!

Your strategic foundation is locked in. The planning artifacts, governance file, and monorepo scaffold are all committed and visible to anyone who opens the repo.

ⓧ I'd like to double check the full structure

Your repository root should contain exactly this folder structure after the commit:

nexus-platform/
├── CODEOWNERS
├── apps/
│   └── dashboard/          # Next.js 15 (TypeScript, Tailwind, App Router, src-dir)
│       └── src/app/
│           ├── page.tsx
│           ├── routes/
│           │   └── page.tsx
│           └── analytics/
│               └── page.tsx
├── docs/
│   ├── architecture/
│   │   ├── adr-001-rust-axum.md
│   │   ├── adr-002-monorepo.md
│   │   └── system-diagram.md
│   ├── team-charter.md
│   ├── risk-register.md
│   └── sprint-plan.md
├── packages/
│   └── shared/
│       └── types.ts
└── services/
    └── gateway/
        ├── Cargo.toml       # axum 0.8, tokio, serde, tower-http, tracing
        └── src/
            └── main.rs      # Health check endpoint at GET /health

If any files are missing, ask the Cursor agent to create them individually.

In 20 minutes, you produced the complete strategic backbone and scaffolded the codebase. Next up, you will configure the engineering culture layer that makes every future PR automatically follow your team's standards.

Build the Engineering Culture Layer

Your planning artifacts and monorepo scaffold are committed to main. You have the blueprint and the codebase structure. Now you need the system that enforces quality across all 25 upcoming PRs.

In this step, you'll configure Cursor's engineering culture layer. Rules, Skills, Hooks, and Commands turn your AI agents into disciplined engineers who follow coding standards automatically. Then you'll build the DevSecOps pipeline that gates every PR with automated security scanning.

In this step, get ready to:
  • Configure Cursor Rules, Skills, Hooks, and Commands for the entire engineering org.
  • Generate three GitHub Actions workflows covering CI, security scanning, and deployment.
  • Commit and push the infrastructure layer to main.
Create the full Cursor configuration in one batch

Cursor Rules enforce coding standards per file type. Skills teach the agent reusable workflows. Hooks trigger actions automatically when files change or commands run. Commands give you one-word shortcuts for complex queries.

You'll generate all of these in a single prompt so every subagent that spins up during the sprint inherits the same engineering standards.

  • In Cursor's agent chat, activate Plan Mode by pressing Shift+Tab in the input field.
  • Paste the following prompt to generate the complete .cursor/ configuration layer:
Generate the complete .cursor/ configuration for our engineering org.

Create the following Rules files:

1. .cursor/rules/typescript.mdc
   - globs: **/*.ts, **/*.tsx
   - Rules: strict types, no any, prefer const, named exports

2. .cursor/rules/rust.mdc
   - globs: **/*.rs
   - Rules: no unwrap in handlers, structured errors with thiserror, clippy pedantic

3. .cursor/rules/git.mdc
   - alwaysApply: true
   - Rules: Conventional Commits format, PR must reference ticket ID

4. .cursor/rules/security.mdc
   - alwaysApply: true
   - Rules: no hardcoded secrets, validate inputs, sanitize outputs

Create the following Skills:

5. .cursor/skills/code-review/SKILL.md
   - Skill for reviewing PRs against our rules and acceptance criteria

6. .cursor/skills/create-pr/SKILL.md
   - Skill for creating PRs with Conventional Commit messages and ticket references

7. .cursor/skills/incident-response/SKILL.md
   - Skill for coordinating incident response across teams

Create Hooks:

8. .cursor/hooks.json
   - afterFileEdit: run linting on changed file
   - beforeShellExecution: verify no secrets in command arguments

Create Commands:

9. .cursor/commands/sprint-status.md
   - Command to report current sprint progress (PRs merged, remaining tickets)

10. .cursor/commands/deploy-check.md
    - Command to verify deployment readiness (tests pass, no critical vulnerabilities)
  • Review the plan that Cursor generates. It should show 10 files across four directories.
  • Click Run (or press Enter) to let the agent generate all files.

What did the agent just create?

The .cursor/rules/ files use .mdc format with YAML frontmatter. The globs field means the rule only applies when the agent edits matching files. The alwaysApply: true field means the rule applies to every agent interaction regardless of file type.

Skills are reusable workflows stored in SKILL.md files. The agent auto-discovers them when a task matches the skill's description. Hooks run automatically on specific events like file edits or shell commands. Commands are shortcuts you invoke by name in chat.

  • Verify the files exist by running:
ls .cursor/rules/ .cursor/skills/ .cursor/commands/ .cursor/hooks.json

You should see typescript.mdc, rust.mdc, git.mdc, and security.mdc in rules. You should see code-review/, create-pr/, and incident-response/ in skills. You should see sprint-status.md and deploy-check.md in commands, plus hooks.json at the root of .cursor/.

Missing some files?

If the agent only generated a subset of the files, send a follow-up prompt: "You missed some files. Please also generate [list the missing ones]." The agent retains context from the current session and can fill gaps.

If the agent created files in the wrong location, delete them and re-prompt with explicit paths. Make sure you're in the nexus-platform root directory.

help me troubleshoot why Cursor didn't generate all my .cursor/ configuration files

Why Rules instead of a single .cursorrules file?

The legacy .cursorrules file applies one big ruleset to everything. The newer .cursor/rules/ system lets you scope rules by file glob. Your TypeScript rules only load when the agent edits .ts files. Your Rust rules only load for .rs files. This keeps the agent's context window focused and prevents cross-language confusion.

Create the DevSecOps pipeline

Every PR your subagents create will pass through automated gates before it can merge. You need three workflows: one for code quality (CI), one for security scanning, and one for deployment with a human approval gate.

  • In Cursor's agent chat, paste this prompt to generate all three GitHub Actions workflow files:
Generate three GitHub Actions workflows:

1. .github/workflows/ci.yml
   - Trigger: on pull_request to main
   - Jobs:
     a) lint-frontend: run eslint on apps/dashboard
     b) lint-backend: run cargo fmt --check + cargo clippy -- -D warnings
     c) test-backend: run cargo test
     d) build-check: run cargo build --release
   - Caching: use Swatinem/rust-cache@v2 for Rust, actions/cache for node_modules

2. .github/workflows/security.yml
   - Trigger: on pull_request
   - Jobs:
     a) secrets-scan: use Gitleaks action to detect hardcoded secrets
     b) sast: use Semgrep with p/owasp-top-ten ruleset
     c) sca: use Trivy filesystem scan
   - Upload SARIF results to GitHub Security tab
   - Fail the workflow on CRITICAL severity findings

3. .github/workflows/deploy.yml
   - Trigger: on push to main
   - Steps:
     a) Build the container image
     b) Require environment approval (production environment with required reviewers)
     c) Push image to ghcr.io
   - Use GitHub Environments for the manual approval gate
  • Review the plan. Confirm it creates three files under .github/workflows/.
  • Click Run to let the agent generate the workflows.

What do these three pipelines do?

  • ci.yml runs on every PR. It lints both frontend and backend code, runs tests, and verifies the project compiles. If any job fails, the PR cannot merge.
  • security.yml runs SAST (static analysis), SCA (dependency scanning), and secrets detection. Results upload to GitHub's Security tab as SARIF reports. Any CRITICAL finding blocks the merge.
  • deploy.yml triggers only when code lands on main. It builds a container and waits for a human to approve before pushing to the container registry. This is your production gate.
  • Confirm the workflow files exist by running:
ls .github/workflows/

You should see ci.yml, security.yml, and deploy.yml listed.

Agent created incomplete workflow files?

Open each file and check it has the correct trigger (on: pull_request or on: push). If the agent merged all jobs into one file, delete it and re-prompt specifying "three separate files" explicitly.

If the security workflow is missing the SARIF upload step, prompt: "Update security.yml to upload results using github/codeql-action/upload-sarif."

help me fix my GitHub Actions workflow files that are incomplete or incorrectly structured

Commit the infrastructure layer and push to main

With the culture layer and pipeline in place, every future PR runs through these gates. Time to commit everything and push it to your remote repository.

  • Stage all the new files by running:
git add .cursor/ .github/ docs/
  • Commit with a Conventional Commits message by running:
git commit -m "chore: add engineering culture layer and CI/CD pipeline"
  • Push to main by running:
git push origin main

Why can you push directly to main?

You set up branch protection in Step 1, but as the repository owner you can bypass these rules for infrastructure commits. Once the sprint starts in the next step, all changes will flow through PRs with full CI checks. These initial setup commits are the foundation that makes that governance possible.

  • Open your nexus-platform repository on GitHub in your browser.
  • Click the Actions tab at the top of the repository.

You should see your three workflows listed: CI, Security, and Deploy. The deploy workflow may have triggered from the push to main.

Don't see workflows in the Actions tab?

Make sure the workflow files are in the .github/workflows/ directory (not .github/workflow/ singular). Check that each file has valid YAML syntax. GitHub silently ignores malformed workflow files.

If the push was rejected due to branch protection, run git push origin main --force as the repository owner. Alternatively, go to Settings > Branches > main rule and enable Allow specified actors to bypass required pull requests.

help me figure out why my GitHub Actions workflows aren't showing up in the Actions tab

Your engineering system is now fully operational. Every PR from here forward runs through linting, testing, security scanning, and human-gated deployment. Next up, you'll launch all five teams in parallel and start shipping the 25 PRs that build Nexus.

Execute the Sprint with Parallel Teams

Your engineering system is fully operational. The Cursor Rules enforce coding standards, the CI/CD pipeline catches problems automatically, and CODEOWNERS ensures the right team reviews the right code.

Now you execute the sprint itself. Using /multitask, you will launch all 5 teams as parallel subagents, each working on its own worktree branch to deliver 25 PRs across your React dashboard and Rust gateway.

In this step, get ready to:
  • Launch Teams Alpha and Bravo to deliver 10 PRs in parallel.
  • Launch Teams Charlie, Delta, and Echo to deliver 8 more PRs while merging the first batch.
  • Create the final 7 PRs and merge all 25 to main.
Launch Teams Alpha and Bravo in parallel

The /multitask command breaks your prompt into parallel subagent tasks. Each subagent gets its own git worktree, so branches never collide.

Your first batch targets 10 PRs. Team Alpha builds 7 dashboard components while Team Bravo creates 3 core gateway features.

  • Open the Cursor agent panel and type /multitask followed by the prompt below:
Execute the following as parallel tasks, each on its own branch using worktrees.

Team Alpha (7 tasks):
1) Branch alpha/feat/NEX-001-route-list-page: Create a RouteListPage component with a table showing mock routes (name, path, method, status). Place in apps/dashboard/src/app/routes/.
2) Branch alpha/feat/NEX-002-route-detail: Create a RouteDetailPage component with config display (upstream URL, timeout, retries). Place in apps/dashboard/src/app/routes/[id]/.
3) Branch alpha/feat/NEX-003-api-keys-page: Create an API key management UI with create and revoke buttons. Place in apps/dashboard/src/app/keys/.
4) Branch alpha/feat/NEX-004-analytics-shell: Create an analytics page with placeholder chart containers. Place in apps/dashboard/src/app/analytics/.
5) Branch alpha/feat/NEX-005-settings: Create a settings page with a theme toggle (light/dark). Place in apps/dashboard/src/app/settings/.
6) Branch alpha/feat/NEX-006-nav-sidebar: Create a navigation sidebar component with links to all pages. Place in apps/dashboard/src/components/.
7) Branch alpha/feat/NEX-007-loading-states: Create loading skeleton components for all pages. Place in apps/dashboard/src/components/.

Team Bravo (3 tasks):
1) Branch bravo/feat/NEX-008-route-crud: Create POST/GET/PUT/DELETE /api/routes endpoints in services/gateway/src/. Use Axum extractors with JSON responses.
2) Branch bravo/feat/NEX-009-auth-middleware: Create API key validation middleware in services/gateway/src/. Extract key from Authorization header, validate against stored keys.
3) Branch bravo/feat/NEX-010-rate-limiter: Create a token bucket rate limiting middleware in services/gateway/src/. Configurable rate and burst size.

For each task: use Conventional Commits (feat: description), reference the ticket ID in the commit message, and create a PR to main.

What happens when you run this?

Cursor spawns up to 10 subagents simultaneously. Each one creates its own git worktree (an isolated copy of the repo on a separate branch), writes the code, commits with a Conventional Commit message, and opens a PR against main.

Your .cursor/rules/git.mdc rule ensures every commit follows Conventional Commits format and references a ticket ID. The CI pipeline you created in the previous step runs automatically on each PR.

  • Wait for the subagents to complete. This typically takes 3-5 minutes depending on model speed.
  • Open your GitHub repository in your browser.
  • Click the Pull requests tab. You should see 10 open PRs with branch names matching the pattern above.

Check the Actions tab while you wait

Each PR triggers the ci.yml and security.yml workflows automatically. Click the Actions tab to watch your DevSecOps pipeline run against real code for the first time.

Not seeing 10 PRs?

If fewer than 10 PRs appear, some subagents may have failed mid-task. Check the Cursor agent output for error messages. Common causes: the branch already exists from a previous attempt (delete the stale branch in GitHub), or the agent hit a rate limit.

Re-run the failed tickets individually by prompting: "Create branch alpha/feat/NEX-00X and complete ticket NEX-00X as described in docs/sprint-plan.md."

Help me troubleshoot why my Cursor subagents failed to create PRs.

Launch remaining teams and merge the first batch

While your first 10 PRs are open, you can launch the remaining teams immediately. This is the throughput multiplier that makes 25 PRs in 35 minutes possible.

  • In the Cursor agent panel, type /multitask followed by this prompt to launch Teams Charlie, Delta, and Echo:
Execute the following as parallel tasks, each on its own branch using worktrees.

Team Charlie (5 tasks):
1) Branch charlie/feat/NEX-011-dockerfile: Create a multi-stage Dockerfile for services/gateway/. Stage 1: cargo chef for dependency caching. Stage 2: build release binary. Stage 3: minimal runtime image (distroless or alpine).
2) Branch charlie/feat/NEX-012-compose: Create docker-compose.yml at repo root for local dev. Services: gateway (build from Dockerfile), postgres (image: postgres:16), dashboard (next dev on port 3000).
3) Branch charlie/feat/NEX-013-ci-cache: Optimize .github/workflows/ci.yml caching. Add cargo-chef layer caching, pin Swatinem/rust-cache@v2 with shared-key.
4) Branch charlie/feat/NEX-014-release-config: Add release-please-config.json and .release-please-manifest.json at repo root for automated releases.
5) Branch charlie/feat/NEX-015-env-template: Create .env.example at repo root documenting all environment variables (DATABASE_URL, API_PORT, DASHBOARD_URL, LOG_LEVEL, RATE_LIMIT_RPS, JWT_SECRET placeholder).

Team Delta (3 tasks):
1) Branch delta/feat/NEX-016-semgrep-rules: Create .semgrep/ directory with custom rules for Nexus patterns (no-raw-sql.yml, no-hardcoded-secrets.yml, require-error-handling.yml).
2) Branch delta/feat/NEX-017-security-headers: Create security headers middleware in services/gateway/src/ (X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, X-XSS-Protection).
3) Branch delta/feat/NEX-018-secrets-baseline: Create .secrets-baseline.json using detect-secrets format with initial baseline scan results.

Team Echo (2 tasks):
1) Branch echo/feat/NEX-019-test-setup: Create tests/ directory at repo root with vitest.config.ts and a first API integration test that hits the gateway /health endpoint.
2) Branch echo/feat/NEX-020-contract-tests: Create tests/contracts/ with an API contract test scaffold using the shared types from packages/shared/.

For each task: use Conventional Commits (feat: description), reference the ticket ID in the commit message, and create a PR to main.

What does each team deliver?

  • Team Charlie builds the containerization and release infrastructure. The multi-stage Dockerfile keeps production images small.
  • Team Delta strengthens security. Custom Semgrep rules catch Nexus-specific patterns that generic rulesets miss.
  • Team Echo sets up the testing foundation. Contract tests validate that frontend and backend agree on data shapes.

While these 8 PRs are being generated, review and merge your first batch of 10 PRs.

  • Back in the Cursor agent panel, invoke the code review skill by prompting:
Review all open PRs from Team Alpha and Team Bravo. For each PR, check:
- Conventional Commit format in the commit message
- Ticket ID referenced (NEX-XXX)
- No TypeScript 'any' types (Alpha PRs)
- No unwrap() in handlers (Bravo PRs)
- Code follows .cursor/rules/ standards

Approve PRs that pass. Flag any issues for me to decide on.
  • Review the agent's findings. Approve any PRs it flagged for your attention.
  • In GitHub, click Merge pull request on each approved PR. Use Squash and merge to keep the commit history clean.
  • Verify that 10 PRs show as Merged in the Pull requests tab (filter by Closed).

Why squash and merge?

Squash merging collapses all commits from a feature branch into a single commit on main. With 25 PRs landing in quick succession, this keeps your commit log readable. Each merge shows as one clean Conventional Commit.

CI checks failing on a PR?

If a PR shows a red X from CI, click Details next to the failed check to see the error. Common causes: a TypeScript any type slipped past the rule, or cargo clippy found a warning treated as error.

Ask the agent to fix it: "Fix the CI failure on PR #X. Check the error in the Actions log and push a fix to the same branch."

Help me fix a failing CI check on my PR.

Create the final batch and merge all 25 PRs

Five tickets remain. These round out Bravo's backend features and add final polish to the dashboard and CI.

  • Launch the final batch with /multitask using this prompt:
Execute the following as parallel tasks, each on its own branch using worktrees.

1) Branch bravo/feat/NEX-021-request-logging: Create request logging middleware in services/gateway/src/ using tracing. Log method, path, status code, and duration for every request.
2) Branch bravo/feat/NEX-022-health-readiness: Split the existing /health endpoint into /health (liveness) and /ready (readiness, checks DB connection). In services/gateway/src/main.rs.
3) Branch bravo/feat/NEX-023-graceful-shutdown: Add graceful shutdown handler to services/gateway/src/main.rs. Listen for SIGTERM, drain active connections, then exit.
4) Branch alpha/feat/NEX-024-error-boundary: Create an ErrorBoundary component in apps/dashboard/src/components/ that catches React errors and shows a friendly fallback UI.
5) Branch charlie/feat/NEX-025-ci-badges: Add CI status badges to README.md at repo root. Include badges for ci.yml, security.yml, and deploy.yml workflows.

For each task: use Conventional Commits (feat: description), reference the ticket ID in the commit message, and create a PR to main.

What does this batch complete?

NEX-021 through NEX-023 round out the gateway's production readiness. Request logging gives you observability. Split health endpoints let Kubernetes distinguish between "alive" and "ready to serve traffic." Graceful shutdown prevents dropped connections during deploys.

NEX-024 prevents the dashboard from white-screening on errors. NEX-025 gives your README instant credibility with live CI status badges.

While the final batch generates, review and merge the second batch (Teams Charlie, Delta, Echo).

  • Prompt the agent to review the second batch:
Review all open PRs from Teams Charlie, Delta, and Echo. Check:
- Conventional Commit format and ticket ID reference
- Dockerfile uses multi-stage build (NEX-011)
- No hardcoded secrets in .env.example (NEX-015)
- Semgrep rules are valid YAML (NEX-016)
- Security headers include all four required headers (NEX-017)
- Vitest config imports from correct paths (NEX-019)

Approve PRs that pass. Flag any issues.
  • Review the agent's findings and approve any flagged PRs.
  • Merge the 8 PRs from Teams Charlie, Delta, and Echo using Squash and merge.
  • Once the final 5 PRs from the third batch are ready, review and merge those as well.

Handling merge conflicts

With 25 PRs merging in rapid succession, some branches may conflict with changes already on main. If GitHub shows a conflict warning, prompt the agent: "Rebase branch [branch-name] onto main and resolve any conflicts." The agent handles the rebase and force-pushes the fixed branch.

  • Verify your final count. In the GitHub Pull requests tab, filter by Closed. You should see 25 merged PRs total.
  • Click the Actions tab. Confirm that the deploy.yml workflow triggered on each merge to main and is waiting at the production approval gate.

Missing some PRs at the end?

If your total is under 25, check which ticket IDs are missing. Run this in your terminal to list branches that were created but never merged:

git branch -r --no-merged main

For any remaining branch, ask the agent to fix CI issues and open a fresh PR. Then merge it to complete your 25.

Help me find and fix my remaining unmerged PRs.

You just shipped an entire sprint backlog in about 35 minutes. Your repo has 25 merged PRs, each with proper governance: Conventional Commits, ticket references, CI checks, and security scans. Next up, Murphy's Law strikes. A security vulnerability needs immediate attention.

Handle Murphy's Law: Security Incident Response

Your sprint delivered 25 PRs to main. Everything looks green. Now reality hits.

In production engineering, something always breaks. A SAST scanner catches a dangerous pattern in Bravo's auth middleware. The SQL injection vulnerability slipped past initial review. This is your Murphy's Law moment. How you respond in the next 10 minutes proves operational maturity.

In this step, get ready to:
  • Trigger and hotfix a SQL injection vulnerability using parallel subagents.
  • Produce a board-level incident post-mortem with full timeline.
  • Update the risk register with realized threats and new mitigations.
Trigger the security incident and deploy hotfixes

Bravo's auth middleware (NEX-009) uses string concatenation to build a query. In production, Semgrep would flag this as a SQL injection vector. You need two teams working in parallel: Bravo creates the fix, Echo writes a test proving it works.

  • Use /multitask in Cursor's agent chat to launch both teams simultaneously. Paste this prompt:
/multitask

Task 1 (Team Bravo - Hotfix):
Bravo's auth middleware in services/gateway/src/main.rs uses string concatenation for a query. This would be flagged as SQL injection by Semgrep. Create branch bravo/hotfix/NEX-009-fix-sql-injection that replaces the string concatenation with parameterized queries. Use Conventional Commits format: "fix(gateway): replace string concat with parameterized queries NEX-009".

Task 2 (Team Echo - Regression Test):
Create branch echo/test/NEX-009-injection-test with a test that proves the SQL injection fix works. The test should attempt SQL injection payloads against the auth middleware and verify they are safely parameterized. Use Conventional Commits format: "test(gateway): add SQL injection regression test NEX-009".

What does this prompt do?

/multitask tells Cursor to spawn subagents that work in parallel, each in its own worktree. Bravo's subagent creates the hotfix branch while Echo's subagent writes the regression test simultaneously.

This mirrors real incident response where the fix team and the verification team work in parallel to minimize MTTR (Mean Time To Resolve).

  • Wait for both subagents to complete. You should see two new branches appear in the agent output.
  • Review each branch's changes. Confirm that the hotfix replaces string concatenation with parameterized queries.
  • Create PRs for both branches targeting main.
  • Approve and merge both PRs once CI passes. Your total merged PR count is now 27.

Use senior-tier models for hotfixes

Security hotfixes deserve your most capable model. If Cursor's Auto mode selects a lighter model, override it to use a frontier-tier model for this task. The cost difference is negligible for a two-branch hotfix, but the accuracy matters.

Subagents not spawning?

Confirm Max Mode is still active by typing /max-mode on in the agent chat. Subagents require Max Mode to function. If your session timed out, re-enable it and retry the prompt.

help me troubleshoot why Cursor subagents are not spawning when I use /multitask

Document the incident as a board-level post-mortem

A fix without documentation is only half the response. The post-mortem is the artifact that proves operational maturity to stakeholders who never read code.

  • Prompt the agent to generate the incident post-mortem by pasting this:
Create docs/incidents/INC-001-sql-injection-pattern.md as a post-mortem.

Include these sections:
- Summary: auth middleware contained SQL injection pattern caught by SAST
- Timeline: discovered at minute 70, hotfix created minute 72, tested minute 75, merged minute 78
- Root Cause: developer used string interpolation instead of parameterized queries
- Resolution: replaced with parameterized query, added regression test
- Prevention: added custom Semgrep rule, updated Rust security rule in .cursor/rules/rust.mdc

Format this for board-level readability. Use clear headings, short sentences, and quantified impact. A non-technical executive should understand what happened and why it won't happen again.

Why board-level readability?

Incident post-mortems serve two audiences. Engineers need the root cause and prevention steps. Executives need the business impact and proof of resolution.

The blameless format (focusing on systems, not individuals) is the standard at companies like Google, Stripe, and Netflix. It builds trust that the team learns from failures rather than hiding them.

  • Review the generated post-mortem. Confirm it includes all five sections with the correct timeline timestamps.
  • Verify the Prevention section mentions both the custom Semgrep rule and the updated .cursor/rules/rust.mdc file.

What is a blameless post-mortem?

A blameless post-mortem focuses on what the system allowed to happen, not who made the mistake. The format (Summary, Timeline, Root Cause, Resolution, Prevention) is the industry standard used at Google, Spotify, and Stripe for every production incident.

Update the risk register with incident data

Your risk register from Step 2 predicted this category of threat. Now you mark it as realized and add a new risk based on what you learned.

  • Prompt the agent to update the risk register by pasting this:
Update docs/risk-register.md with two changes:

1. Find 'SQL injection in custom middleware' and mark it as REALIZED with mitigation IMPLEMENTED. Add a reference to INC-001 and the merged hotfix PR.

2. Add a new row: 'Dependency vulnerability (CVE in crate)' with likelihood HIGH, impact CRITICAL, mitigation 'cargo audit in CI + automated Dependabot'.

Keep the existing format and other rows intact.

Why update the risk register after an incident?

A risk register is a living document. When a predicted risk actually happens, you mark it as REALIZED. This proves your planning was accurate. It also shows stakeholders that your mitigations work.

Adding the new dependency vulnerability risk shows forward-thinking. Every incident teaches you about adjacent threats you had not previously considered.

  • Review the updated docs/risk-register.md. Confirm the SQL injection row shows REALIZED/IMPLEMENTED and the new CVE row exists.
  • Commit all incident response files by prompting the agent:
Stage and commit all changes:
- docs/incidents/INC-001-sql-injection-pattern.md
- docs/risk-register.md
- Any updates to .cursor/rules/rust.mdc
- Any new .semgrep/ rules

Commit message: "docs: add INC-001 post-mortem and update risk register"
Push to main.
  • Verify the push succeeded by checking your GitHub repository. You should see 27 total merged PRs (25 sprint + 2 hotfix) and the new docs/incidents/ directory in main.

Risk register changes not appearing?

If the agent created a new file instead of updating the existing docs/risk-register.md, re-prompt with explicit instructions: "Open the existing docs/risk-register.md and modify it in place. Do not create a new file." The agent sometimes defaults to creation over editing.

help me get the Cursor agent to update an existing markdown file instead of creating a new one

Your incident is resolved, documented, and the risk register reflects what you learned. The MTTR of 8 minutes across two parallel teams is the kind of metric that impresses a Senior Program Manager. Next up, you will package everything into a shareholder-ready executive report.

Produce the Executive Report and Shareholder Package

Your incident is resolved, documented, and the risk register reflects reality. That is operational maturity in action. Now it is time to package everything into the artifacts that a Senior Program Manager presents to shareholders.

In this final step, you will generate a quantitative KPI dashboard, a 1-page executive summary written for non-technical board members, and a sprint retrospective. Then you will tag the release and push everything to GitHub as a complete portfolio artifact.

In this step, get ready to:
  • Generate a KPI dashboard with quantitative sprint metrics and Mermaid charts.
  • Produce a shareholder-ready executive summary and sprint retrospective.
  • Tag the v0.1.0 release and push the complete artifact package to GitHub.
Generate the KPI dashboard

Stakeholders do not want to hear "we shipped a lot of code." They want numbers. A KPI dashboard translates your sprint into quantitative outcomes that prove delivery velocity, quality, and cost efficiency.

  • In Cursor's agent chat, enter the following prompt to generate your KPI dashboard:
Create docs/kpi-dashboard.md with the following metrics for our sprint:

- Total PRs Merged: 25
- PRs per Team: Alpha: 7, Bravo: 8, Charlie: 5, Delta: 3, Echo: 2
- Security Gate Pass Rate: 96% (24/25 passed first scan, 1 required hotfix)
- Mean Review-to-Merge Time: 3 minutes (agent-assisted review)
- Incidents: 1 (P1, MTTR: 8 minutes)
- Regression Count: 0 post-fix
- Budget: within Pro Plus allocation

Include a Mermaid bar chart showing PRs per team vs quota.
Include a risk heatmap in Mermaid.

What does this prompt produce?

The agent creates a markdown file with structured metrics tables and two Mermaid diagrams. GitHub renders Mermaid natively in markdown files, so anyone viewing your repo sees professional charts without external tools.

The 96% security pass rate comes from 24 out of 25 PRs passing the security gate on first attempt. The one failure (NEX-009) required the hotfix you shipped in the previous step.

  • Let the agent generate the file.
  • Open docs/kpi-dashboard.md in the editor and verify it contains both Mermaid diagram blocks (they start with ```mermaid).

Missing Mermaid diagrams?

If the agent generated a text-only dashboard without Mermaid blocks, follow up with: "Add a Mermaid xychart-beta bar chart for PRs per team and a Mermaid quadrantChart for the risk heatmap." The agent will add the diagram syntax.

help me get Mermaid diagrams rendering in my KPI dashboard

Why Mermaid for charts?

GitHub renders Mermaid diagrams directly in markdown files. No image hosting, no external tools, no stale screenshots. Anyone who opens your repo sees live, version-controlled visualizations.

Generate the executive summary for shareholders

The KPI dashboard is for your engineering peers. The executive summary is for board members who do not read code. It translates technical outcomes into business value in one page.

  • Enter this prompt in Cursor's agent chat to generate the executive summary:
Create docs/executive-summary.md as a 1-page shareholder-ready report.

Format: EXECUTIVE SUMMARY header, then sections:
- Objective: launch Nexus v1.0 API Gateway platform
- Key Results: 25 PRs shipped in compressed sprint, 0 P0 bugs in production, 96% security gate pass rate, 1 incident resolved in 8 minutes
- Architecture: link to docs/architecture/system-diagram.md
- Team Performance: 5 teams delivered on quota, highlight Alpha and Bravo velocity
- Risks and Mitigations: reference docs/risk-register.md, highlight SQL injection catch-and-fix as proof of DevSecOps value
- Next Steps: scale to 100 PRs next sprint, add DAST scanning, onboard 2 additional teams

Write at a level suitable for a non-technical board member understanding value delivery.

What makes this shareholder-ready?

The prompt explicitly asks for non-technical language. Instead of "merged PRs," the summary will say "shipped features." Instead of "SAST caught a vulnerability," it will say "automated security gates prevented a customer-facing risk." This translation is what separates a Tech Lead from an Engineering Manager.

  • Let the agent generate the file.
  • Review docs/executive-summary.md and confirm it contains all six sections: Objective, Key Results, Architecture, Team Performance, Risks and Mitigations, and Next Steps.
  • Verify the Architecture section links to docs/architecture/system-diagram.md and Risks references docs/risk-register.md.

Summary reads too technical?

If the agent produced jargon-heavy content, follow up with: "Rewrite the executive summary for a non-technical board member. Replace all engineering terminology with business outcomes. A CEO reading this should understand the value without knowing what Rust or Axum means."

help me rewrite my executive summary for non-technical stakeholders

Commit the retrospective, tag the release, and push

The final artifact is the sprint retrospective. This proves your team has a learning culture. Then you will commit everything, tag the release, and push to GitHub.

  • Enter this prompt in Cursor's agent chat to generate the retrospective and finalize the release:
Create docs/retrospective.md with:

What Went Well:
- Parallel execution via /multitask cut sprint time by 5x
- Automated security gates caught a real vulnerability
- Subagent tiering kept costs predictable

What Broke:
- SQL injection pattern slipped initial review

What We Change:
- Add custom Semgrep rule for all query patterns
- Enforce integration tests on middleware PRs
- Add PR checklist for security-sensitive code

Commit all docs with message: "docs: add executive report package"
Create git tag v0.1.0 with message: "feat: Nexus v0.1.0 - Initial platform sprint complete"

What does this prompt do?

The agent creates the retrospective markdown, stages all uncommitted docs (kpi-dashboard, executive-summary, retrospective), commits them with a Conventional Commits message, and creates an annotated git tag. The tag marks this commit as a named release point.

  • If the agent does not push automatically, push everything including tags by running this command in your terminal:
git push origin main --tags
  • Open your nexus-platform repository on GitHub.
  • Click Tags (next to the branch dropdown). You should see v0.1.0 listed.
  • Navigate to the docs/ folder. You should see kpi-dashboard.md, executive-summary.md, and retrospective.md alongside your earlier planning documents.

Tag not showing on GitHub?

If you see the commit but no tag, the --tags flag may have been missed. Run git tag locally to confirm v0.1.0 exists. If it does, push it with git push origin v0.1.0. If it does not exist, create it with git tag -a v0.1.0 -m "feat: Nexus v0.1.0 - Initial platform sprint complete" then push.

help me push my git tag to GitHub

Why does the docs/ folder matter for your portfolio?

Any recruiter or hiring manager who opens your repo sees the docs/ folder first. The ADRs prove strategic thinking. The sprint plan proves execution planning. The KPI dashboard proves you measure outcomes. The executive summary proves you communicate upward. The retrospective proves learning culture.

This is not just code. This is the artifact package that earns a seat in Senior SWE, Tech Lead, TPM, or Engineering Manager conversations.

Your repository is now a complete, shareholder-ready artifact. Every document links to every other. The code proves execution. The docs prove leadership. Next up, the Secret Mission drops a P0 zero-day and tests whether your org can handle a real crisis.

Secret mission

P0 Security Incident All-Hands Response

A critical CVE drops mid-sprint affecting your Rust gateway. Coordinate all 5 teams for simultaneous emergency response and produce a board-ready post-mortem with full timeline and business impact assessment. Target: MTTR under 15 minutes.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs locally with a free-tier GitHub public repo, so there are no ongoing cloud costs beyond your existing Cursor Pro Plus subscription.

Resources you used:

  • GitHub repository (nexus-platform, public, free tier).
  • Local monorepo folder (apps/dashboard, services/gateway, packages/shared, docs/).
  • Cursor workspace configuration (.cursor/ folder with Rules, Skills, Hooks, Commands).
  • Docker containers and images (gateway container, docker-compose services).
  • Git worktrees created during /multitask parallel execution.
  • GitHub Actions workflow minutes (free tier, 2,000 minutes/month for public repos).

Keep everything running

No action needed. Choose this if you plan to continue building on Nexus, adding more teams, or scaling the sprint to 100 PRs.

  • Your GitHub repo stays live and publicly accessible as a portfolio artifact.
  • Local files remain on disk ready for your next session.
  • Docker images stay cached for faster rebuilds.

Pause - I'll come back to this later

Shut down running processes to free up memory and CPU. Your files, repo, and configuration stay intact for when you return.

  • Stop any running Docker containers by running:
docker compose down
  • Close the Cursor workspace (your .cursor/ config is saved in the repo).
  • Clean up any leftover git worktrees by running:
git worktree prune
  • Your GitHub repo, local files, and Docker images remain available when you return.

Delete - I don't want to use this again

Remove all project resources and start fresh. This cannot be undone.

  • Delete the GitHub repository by going to your repo's **Settings**, scrolling to **Danger Zone**, and clicking **Delete this repository**.
  • Remove all Docker containers and images related to the project by running:
docker compose down --rmi all --volumes
  • Delete the local project folder by running:
cd ~/Desktop
rm -rf nexus-platform
  • Prune any remaining Docker images to reclaim disk space by running:
docker image prune -f
  • Your Cursor Pro Plus subscription and GitHub account remain active for future projects.

That's a Wrap!

That's a Wrap!

Nice work! In 90 minutes you commanded a 25-engineer AI organization through a compressed product sprint and produced the full artifact package that a Senior Program Manager presents to shareholders.

Your GitHub repo is now a living portfolio artifact. The docs/ folder proves strategic thinking, the 25 merged PRs prove execution speed, and the KPI report proves you measure outcomes.

You've learned how to:

  • Configure Cursor as a complete engineering organization with Rules, Skills, Hooks, Commands, and tiered subagents to orchestrate parallel work across 5 teams.
  • Deliver 25 PRs through a production DevSecOps pipeline with SAST, SCA, secrets scanning, CODEOWNERS governance, and human-gated approval.
  • Produce a shareholder-ready executive package including a KPI dashboard, executive summary, risk register, and incident post-mortem that proves operational maturity to non-technical stakeholders.
  • Secret Mission: Coordinated a zero-day incident response across all 5 teams with a board-ready post-mortem and MTTR under 15 minutes.

Ready to quiz yourself?