--- name: handoff-summary description: Use this when the current Coding Agent session context window is getting full and the user needs a clean handoff summary to continue in a new Coding Agent session. --- # Handoff Summary Skill Create a complete markdown handoff summary for a new Coding Agent session. Do not modify files. ## Companion skills Use this skill when a session is ending, context is full, or work needs to move to another agent. The handoff must name the recommended next skill chain, for example: ```text Recommended next skills: 1. Primary: module2-frontend-ide-coder 2. Companion: fullstack-integration-coder for API alignment 3. Review: strict-code-reviewer ``` ## Shared Project Rules ### Authoritative document priority Follow this priority order when documents or implementation choices conflict: 1. `SPEC.md` - Main product/system requirements specification. - Defines goals, non-goals, stakeholders, user stories, REQ/NFR statements, constraints, MVP clarifications, and acceptance criteria. 2. `Architectural Design and Module Specification for an AI-Assisted Online Coding Assessment Platform.pdf` - Architecture and module-boundary specification. - Defines the four-module architecture and security boundaries. 3. `complete_frontend_api_list_and_backend_alignment.md` - Frontend/backend API contract and integration alignment document. - Defines endpoint names, request/response shapes, status values, error format, MVP API decisions, mock/TODO(API) rules, and frontend-backend boundaries. 4. `ui-style-reference.md` - Visual style reference only. - It must not override requirements, architecture, authentication behavior, database schema, existing routes, assessment/submission/reporting behavior, or API contracts. ### Do not modify specification documents unless explicitly asked Do not modify these files unless the user explicitly asks for documentation/spec changes: - `SPEC.md` - `Architectural Design and Module Specification for an AI-Assisted Online Coding Assessment Platform.pdf` - `complete_frontend_api_list_and_backend_alignment.md` - `ui-style-reference.md` If a coding task conflicts with these documents, stop and report the conflict before editing implementation files. ### Current project architecture assumption The project is an AI-assisted online coding assessment/interview platform. Known current implementation context may include: - Frontend: Next.js App Router in `src/` - Backend: ASP.NET / .NET backend in `Backend/` - Database: PostgreSQL via EF Core - Auth: JWT/token-based login/register Do not assume these blindly. Inspect the repository first and report what you find. ### Four-module architecture The architecture has four non-overlapping modules: 1. **Module 1 - Identity and Assessment Management** - Authentication, RBAC, users, assessments, questions/test cases, attempt/session lifecycle, workspace persistence, submissions, results, reports, and database-backed authoritative state. 2. **Module 2 - Interactive Browser-Based Workspace / Frontend IDE** - Browser UI, student/admin pages, Monaco/editor, workspace state UI, autosave UI, run/submit UI, AI assistant UI, frontend API clients, and visual interaction layer. 3. **Module 3 - Sandboxed Code Execution and Evaluation Engine** - Isolated execution of untrusted code, resource limits, hidden test evaluation, stdout/stderr capture, execution result schema, workers/queues, cleanup. 4. **Module 4 - AI Telemetry and Assistance Service** - Secure AI backend/proxy, LLM provider calls, server-side prompts, AI interaction logging, telemetry, semantic tagging, structured AI responses, rate/error handling. ### Global security boundaries - Student frontend must never receive hidden test case input/output or grading implementation. - Frontend must not directly access the database. - Frontend must not directly call the sandbox/execution engine. - Frontend must not directly call external LLM/AI provider APIs. - Do not expose provider API keys, database credentials, JWT secrets, or other secrets. - Do not execute untrusted student code outside the intended isolated execution architecture. - Do not use `eval`, `child_process`, or unrestricted local runtimes for student submissions. - Do not weaken authentication or role-based access control. - Do not invent API contracts that conflict with the API alignment document. - Do not collapse module boundaries for convenience. ### Important session/attempt clarification The architecture PDF contains older schema examples using `session_id`. However, the current requirements/API alignment decision says: - The frontend must not create, store, or trust a real `session_id`. - Backend should identify the user from auth context, such as JWT or another secure token. - Backend should resolve the active attempt from authenticated user + `assessment_id`. - Frontend-only first-MVP attempt/session state may be mock-only; backend-connected work may use backend-returned attempt identifiers only as transient in-memory compatibility values. When implementing current frontend/backend integration, follow the newer requirements/API alignment decision unless the user/team explicitly changes it. ## User workflow The user often works with three Coding Agent chat sessions: 1. Prompt Commander 2. Coder 3. Reviewer This handoff must allow a new session to continue safely. ## Required output sections 1. Project goal 2. Current session role: - Prompt Commander - Coder - Reviewer - Other / unknown 3. Current module(s) involved: - Module 1 - Module 2 - Module 3 - Module 4 - Cross-module integration 4. Authoritative specs and priority 5. Files/docs already read 6. Completed work 7. Files created/modified 8. Current implementation status 9. Current repo state, if known 10. Commands run and results 11. Known bugs/risks/TODOs/open questions 12. API contracts touched 13. Architecture decisions made 14. What the next session should do first 15. Exact next prompt to paste into Coding Agent 16. What the next session must not change ## Style - Concise but complete. - Use exact file paths when known. - Separate verified facts from assumptions. - Do not invent information.