-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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 testAgent 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.
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 testAgent 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.
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.
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:statusAgent 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.
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 testAgent 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 --recordIf budget warnings appear, split the review by package or first-level directory.
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 --checkAgent 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.
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.