Skip to content

Common Stack Examples

Cory Ebert edited this page Sep 11, 2026 · 3 revisions

Common Stack Examples

Examples use Claude Code slash commands. In Codex use $discuss, $research, $plan, $consult, $implement, $forge-review, $quick, and $ship as appropriate. /fleet is a Claude workflow, not a promised Codex skill. See Workflow Commands for helper paths.

Use these as starting points for choosing the right Forgeflow entry command and validation checks. Adjust package manager commands to match the repo.

Next.js Or React App

Good entry points:

/discuss add keyboard navigation to the settings page
/plan implement the new billing summary panel
/review app/settings/page.tsx components/billing-summary.tsx

Typical validation:

npm run typecheck
npm run lint
npm test

Agent emphasis:

  • Designer for UX, accessibility, interaction states, and responsive layout
  • Guardian for auth, API calls, client/server boundaries, and validation
  • Builder for data modeling and server-side logic

For UI-heavy changes, ask /review to include screenshots or route paths when available.

Node API Or Express Service

Good entry points:

/consult add idempotent webhook processing for Stripe events
/implement execute the webhook processing brief
/review src/routes/webhooks.ts src/services/payments.ts

Typical validation:

npm run typecheck
npm run lint
npm test

Agent emphasis:

  • Guardian for auth, input validation, rate limits, secrets, and external integrations
  • Builder for service decomposition, database access, error handling, and testability
  • Architect for tradeoffs when security and implementation simplicity conflict

For webhook or job processing work, explicitly mention retry behavior and idempotency in /consult.

Python API

Good entry points:

/research compare options for background job retries in this codebase
/plan add organization-level API keys
/review app/api_keys.py app/auth.py tests/test_api_keys.py

Typical validation:

pytest
ruff check .
mypy .

Agent emphasis:

  • Guardian for auth, permissions, request validation, dependency risk, and secret handling
  • Builder for module boundaries, ORM usage, migrations, and test design
  • Product Lead for requirements coverage when behavior is policy-heavy

For Django, include migrations and permission classes in the review scope. For FastAPI, include Pydantic models, dependencies, and route handlers together.

Rails App

Good entry points:

/consult add account-level audit logging
/implement execute the audit logging brief
/review app/models/audit_event.rb app/controllers/admin/users_controller.rb db/migrate

Typical validation:

bundle exec rspec
bundle exec rubocop
bin/rails db:migrate:status

Agent emphasis:

  • Builder for ActiveRecord associations, migrations, callbacks, and transaction boundaries
  • Guardian for authorization, strong parameters, session handling, and sensitive logs
  • Coordinator for rollout sequencing when migrations and backfills are involved

For migrations, ask /review to check rollback safety, deploy order, and backfill behavior.

Monorepo

Good entry points:

/plan split the account settings work across web, api, and shared packages
/fleet --spec docs/plans/account-settings.md --shards 3
/review HEAD~4..HEAD

Typical validation:

pnpm -r typecheck
pnpm -r lint
pnpm -r test

Agent emphasis:

  • Coordinator for shard ownership, sequencing, and cross-package dependencies
  • Architect for integration decisions between packages
  • Builder, Guardian, and Designer for their domain-specific slices

For large changes, build context packets first:

scripts/forgeflow/build-context-pack.js --json
scripts/forgeflow/check-context-budget.js --root .forgeflow --warn-only
scripts/forgeflow/advise-context.js --root .forgeflow --record

If budget warnings appear, split the review by package or first-level directory.

Documentation Or Config-Only Change

Good entry points:

/quick update the installation docs for the new repair flag
/review README.md docs/wiki/Quick-Start.md

Typical validation:

node scripts/forgeflow/test-doc-links.js
git diff --check

Agent emphasis:

  • Product Lead for requirement clarity and user intent
  • Coordinator for docs completeness and consistency
  • Designer only when the change affects user-facing UI or visual docs

Docs-only changes often route to skip-mode or thin-mode. That is expected.

Release Prep

Before tagging Forgeflow itself:

/forgeflow-release-check

Or run the equivalent terminal checks listed in Demos.

For product repositories using Forgeflow, run the project’s normal tests first, then use /review and /ship.

Clone this wiki locally