Factory's autonomous droids. Briefed on your repo.
Factory's droids ship code with minimal hand-holding. ChooChoo writes the AGENTS.md every droid reads at session start so each one acts within your team's stack, conventions, and guardrails. No project re-explanation per task.
Factory droids follow the cross-vendor AGENTS.md spec for repo context. ChooChoo compiles the file from your real linting config, ADRs, and key files so every droid run starts with the same accurate picture of the codebase, instead of a stale wiki snapshot.
AGENTS.md with stack, standards, boundaries, and ADR pointers
Same file works for every droid type: code, review, refactor, fix
Stays in sync with your codebase as it evolves
# AGENTS.md
# Generated by ChooChoo. Do not edit by hand.
# Run: choochoo context generate
## Project: payments-api
Stack: Python 3.12 · FastAPI · PostgreSQL · Redis
Style: Ruff (line-length=100) · strict mypy
Tests: pytest · coverage ≥ 85% enforced on CI
## Standards
- Validate all inputs with Pydantic at API boundaries
- No raw SQL; use SQLAlchemy ORM
- Never log secrets, tokens, or payment data
- Annotate all public functions with types
## Boundaries
READ: src/** · tests/** · docs/**
WRITE: src/** · tests/**
NEVER: .github/** · migrations/** · infra/**
## Architecture Decisions
ADR-001 JWT (RS256) for auth
ADR-004 Event-driven webhooks via Redis Streams
ADR-007 API versioning under /v1/, /v2/ namespaces
# SKILLS.md
# Generated by ChooChoo. Do not edit by hand.
## auth
JWT token lifecycle: creation, validation, refresh.
Entry: src/auth/service.py
Tests: tests/auth/
## payments
Stripe integration: charges, subscriptions, webhooks.
Entry: src/payments/processor.py
Note: Never log STRIPE_KEY or card numbers
## database
SQLAlchemy sessions and query patterns.
Entry: src/db/session.py
Rule: Always use get_db() dependency injection
## notifications
Email (SendGrid) and SMS (Twilio) dispatch.
Entry: src/notifications/dispatch.py
# PLAN.md
# Generated by ChooChoo. Do not edit by hand.
## Goal
Refactor the authentication service to support
multi-factor authentication (MFA) via TOTP.
## Steps
1. [ ] Add TOTP secret column to users table
migration: src/db/migrations/0023_add_totp.py
2. [ ] Implement TOTP validation in auth service
src/auth/service.py → verify_totp()
3. [ ] Add /auth/mfa/setup and /auth/mfa/verify routes
src/api/auth.py
4. [ ] Write unit tests for new MFA paths
tests/auth/test_mfa.py (≥ 90% coverage)
5. [ ] Update AGENTS.md with new ADR-012
## Constraints
- Do not break existing JWT flow (ADR-001)
- TOTP secrets encrypted at rest (AES-256)
- Rate-limit /auth/mfa/verify to 5 attempts / 15 min
# ARCHITECTURE.md
# Generated by ChooChoo. Do not edit by hand.
## System Overview
payments-api is a stateless FastAPI service.
All state lives in PostgreSQL (primary data) and
Redis (sessions, rate limiting, event streams).
## Request Flow
Client → API Gateway → FastAPI → Service Layer
→ Repository Layer
→ PostgreSQL / Redis
## Key Modules
src/auth/ JWT issuance + TOTP (ADR-001, ADR-012)
src/payments/ Stripe integration (charges, webhooks)
src/db/ SQLAlchemy sessions + migration runner
src/api/ Route definitions (v1 + v2 namespaces)
## ADR Index
ADR-001 RS256 JWT for authentication
ADR-004 Redis Streams for webhook event bus
ADR-007 URL versioning (/v1/, /v2/)
ADR-012 TOTP-based MFA (in progress)
## Deployment
Docker → ECS Fargate (app)
RDS PostgreSQL 15 (primary)
ElastiCache Redis 7 (cache + streams)
# GOAL.md
# Generated by ChooChoo. Do not edit by hand.
## Current Sprint Goal
Implement MFA support without breaking existing
single-factor authentication flows.
## Success Criteria
- All existing auth tests continue to pass
- New /auth/mfa/* endpoints return correct responses
- TOTP validation rejects tokens older than 30 s
- Coverage for src/auth/ stays above 90%
## Out of Scope
- SMS-based MFA (deferred to ADR-013)
- Admin UI for MFA management (separate ticket)
- Recovery codes (phase 2)
## Definition of Done
- PR reviewed and approved
- CI green (lint + test + coverage)
- AGENTS.md updated with ADR-012 summary
- Deployed to staging and smoke-tested
flowchart TD
A([Client Request]) --> B[API Gateway]
B --> C{JWT Valid?}
C -- Yes --> D[FastAPI Router]
C -- No --> E([401 Unauthorized])
D --> F[Service Layer]
F --> G[Repository]
G --> H[(PostgreSQL)]
G --> I[(Redis)]
F --> J[Stripe API]
J --> K[Webhook Event]
K --> L[(Redis Streams)]
Why use ChooChoo with Factory droids?
Autonomous droids need firm context. ChooChoo writes it from your real code, every time.
Consistent Output
Generated code follows your linting rules from the start, reducing cleanup work before code review.
Fewer Iterations
The AI understands your standards upfront, producing acceptable code faster and with less back-and-forth.
Team Alignment
Everyone's AI assistant generates code that matches your team's style guide, automatically.
Zero Configuration
Get started instantly with sensible defaults that work out of the box for most projects.
Type-Safe Code
Strict linting rules catch potential bugs and enforce type safety before they reach review.
AI-Ready Rules
Purpose-built rules that AI models understand and follow consistently, session after session.
Ready to brief your droids?
Compile AGENTS.md from your codebase so every Factory droid acts within your team's standards from session zero.