workflow

Invoke the `builder` agent defined in `agents/builder.md`.

Invoke the `impact` agent defined in `agents/impact.md`.

Invoke the `planner` agent defined in `agents/planner.md`.

Save current session state for resuming later.

Invoke the `shipper` agent defined in `agents/shipper.md`.

Use this agent for all NestJS backend work across CampX microservices. Trigger on: entity, migration, service, controller, DTO, module, TypeORM, repository, guard, decorator, interceptor, NestJS, backend, server, database, schema, API endpoint, REST API, campx-exams-server, campx-admin-server, campx-api-gateway, campx-lms-server, campx-hrms-server, campx-paymentx-server, campx-tenant-server, campx-square-server, campx-scheduler-server. <example> Context: User wants to add a backend feature. user: "Add a new endpoint to get student GPA history in campx-exams-server" assistant: "I'll use the backend-agent to implement this NestJS endpoint." <commentary> User wants backend work. backend-agent handles NestJS entities, services, controllers, DTOs, and migrations. </commentary> </example> <example> Context: User asks about a database entity. user: "How does the StudentMarks entity work? What are its relations?" assistant: "I'll use the backend-agent to read and explain the entity structure." <commentary> User is asking about a TypeORM entity. Use backend-agent. </commentary> </example> <example> Context: User wants to write a migration. user: "Write a migration to add a remarks column to the exam_results table" assistant: "I'll use the backend-agent to write this TypeORM migration." <commentary> User wants a DB migration. backend-agent handles schema changes via migration files. </commentary> </example>

Use this agent when the user wants to implement an approved plan. Trigger on: build it, implement, let's build it, start building, start coding, go ahead and implement, proceed with implementation, approved go ahead, execute tasks. Do NOT use when no plan exists (run planner first). Do NOT use for shipping (use shipper). <example> Context: User has an approved plan and wants to implement it. user: "build it" assistant: "I'll use the builder agent to implement the approved plan." <commentary> User wants to implement a plan. Use the builder agent. </commentary> </example> <example> Context: User approves a plan. user: "looks good, go ahead and implement this" assistant: "I'll use the builder agent to execute the implementation." <commentary> User approved a plan. Use the builder agent. </commentary> </example>

Use PROACTIVELY when the user wants to debug or fix a bug. Trigger on: debug this, fix the bug, what's wrong, why is this failing, crash, error, broken, not working, help me debug, trace the issue, investigate this error, something's wrong, what went wrong, fix this issue, test is failing, page crashes, endpoint returns error.

Use this agent for all React frontend work across CampX microfrontends. Trigger on: React, component, page, UI, frontend, microfrontend, hook, context, MUI, Material UI, form, table, modal, drawer, button, layout, routing, campx-exams-web, campx-admin-web, campx-evaluator-web, campx-lms-web, campx-hrms-web, campx-payments-web, campx-tenant-web, campx-ums-web, campx-student-central-web, shared component, @campxdev/shared, @campxdev/react-blueprint. <example> Context: User wants to build a React page. user: "Build a student GPA history page in campx-exams-web" assistant: "I'll use the frontend-agent to build this React page." <commentary> User wants frontend work. frontend-agent handles React components, pages, hooks, and UI. </commentary> </example> <example> Context: User asks about a component. user: "How does the GradeCard component work?" assistant: "I'll use the frontend-agent to find and explain this component." <commentary> User is asking about a React component. Use frontend-agent. </commentary> </example> <example> Context: User wants to add a UI feature. user: "Add a filter dropdown to the marks table in the evaluator portal" assistant: "I'll use the frontend-agent to add this UI feature." <commentary> User wants a UI addition. Use frontend-agent. </commentary> </example>

Use this agent when the user wants to understand the blast radius of a code change. Trigger on: before I change X, what breaks if, blast radius, check impact, is it safe to change, what's affected, will this break anything, what breaks if I modify, safe to refactor, before refactor, before I delete. Also trigger when user mentions changing: moderation, grace, grafting, grading, GPA, memo, transcript. <example> Context: User wants to check impact before a change. user: "Before I change the grading logic, what's the blast radius?" assistant: "I'll use the impact agent to trace what's affected by this change." <commentary> User wants blast radius analysis. Use the impact agent. </commentary> </example> <example> Context: User wants to know what breaks. user: "What breaks if I modify the moderation stage entity?" assistant: "I'll use the impact agent to analyze downstream pipeline effects." <commentary> User wants impact analysis on an exam pipeline entity. Use the impact agent. </commentary> </example>

Analyzes blast radius and downstream impact of code changes across the CampX exam pipeline. Use PROACTIVELY when user says: 'before I change', 'what breaks if', 'blast radius', 'check impact', 'is it safe to change', 'what's affected', 'will this break anything', 'safe to refactor', 'before I delete', 'before I modify'. Also trigger when user mentions changing: moderation, grace, grafting, grading, GPA, memo, transcript, exam pipeline stages.

Use PROACTIVELY at the start of every new CampX feature, task, or bug fix. Trigger on: 'new feature', 'new task', 'I want to build', 'start work on', 'new bug fix', 'I need to', 'we need to add', 'build X', 'fix X in campx'. Asks branch + repos + env before brainstorming. Outputs orbit new command. Waits for workspace to be up before reading code.

Runs quality gate then commits, pushes, and creates a PR for CampX repos. Use PROACTIVELY when user says: 'ship it', 'ship this', 'done push it', 'commit and push', 'create a PR', 'ready to ship', 'push this', 'let's merge this', 'done coding', 'create pull request', 'merge this'. Runs tsc + lint + tests before committing. Never ships without passing quality gate.

Switches CampX backend environment config using merge-env.sh. Use PROACTIVELY when user says: 'switch env', 'switch to staging', 'switch to prod', 'switch to dev', 'change environment', 'use staging', 'use production', 'point to prod', 'point to staging'. Do NOT use for frontend env changes or Docker config.

Investigates and resolves CampX support tickets and data issues. Use PROACTIVELY when user says: 'I got a ticket', 'support ticket', 'student can't see', 'wrong data', 'wrong marks', 'wrong grades', 'wrong branch', 'someone reported', 'client reported', 'data fix', 'data issue', 'triage this', pastes a campx.frappe.cloud link, or reports any student/tenant data problem. Fetches ticket from Frappe or GitHub, classifies severity, finds matching z-migration, reads affected entities, generates verification SQL queries — all in one pass.

2 hooks across 2 events