Prompt file imported from ShalomDeitch1/AgentGroup (
.github/prompts/start-impl.prompt.md). Copyright stays with the author.
I want to implement the .github\prompts\backend.prompt.md and .github\prompts\frontend.prompt.md while getting help from all the skills in .github\skills and considering .github\copilot-instructions.md
IT IS IMPORTANT TO IMPLEMENT ALL Requirements.md
I got the following appraisal (between lines) My answers are indented afer each appraisal, the questions are at the end of the appraisal.
Plan: Requirements & Repo Completeness Review The repo has strong requirement docs and prompt/skill scaffolding, but most “real implementation” pieces (backend auth/JWT, Bedrock router, UI pages, env vars docs, tests, and provisioning automation) are still missing or example-only. This plan walks through closing the gaps without changing Requirements.md, and ends with targeted questions so we can avoid rework and align on architecture choices.
Steps 6–12 steps, 5–20 words each Reconcile gaps against Requirements.md and README.md expectations. Prefer Requirements.md as source of truth. Audit .github skills/prompts vs actual code; list contradictions and broken examples. Use code that works, these only give some direction, are not required Fill EnvironmentVars.md from env-var usage across repo. these need to be filled as code is written Align CDK/provisioning story: scripts vs required idempotent setup. provisioning should be CDK as much as possible, setup script should support CDK. Later admins can change infra as needed Validate backend/UI skeleton completeness: src and src. they need to be implemented as per the two prompt files Identify security/ops must-haves: secrets, IAM scope, logging CORS/CSRF. security should be demo-grade but with clear doc on how to improve it, e.g. rate limiting, auditing etc. Ensure no problems with CORS/CSRF no use of secrets, use env vars where needed, define so use can copy&paste Further Considerations 1–3, 5–25 words each What’s missing today (important gaps you likely missed)
Backend is largely empty: index.js, agents, authentication, external UI is still default shell; required screens/flows aren’t implemented: page.tsx, layout.tsx We need to implement Env var documentation is empty: EnvironmentVars.md document as code is written Tests are missing (backend package.json placeholder, no UI tests): package.json, package.json add Provisioning/setup requirement unmet: CDK only provisions example IAM role, not DynamoDB/resources: bedrock-role-stack.ts there should be a role for the normal user and one for admin, setup script should support CDK and ensure all needed resources are available Doc/example inconsistencies to fix (so people don’t copy broken code) examples on indication of what may help - follow Requirements.md as source of truth
Bedrock examples reference config paths/files that don’t exist or are empty: configuration, .github/skills/Bedrock/skills/create-agents.md config files need to be created as code is written Example Bedrock code mixes alpha vs stable constructs; doesn’t match scripts stack: CDK-Create-Agents.md, bedrock-role-stack.ts examples are only an indication, ensure code works as per Requirements.md and is stable Auth prompt contradicts “no refresh token” requirement; also uses username vs required email: backend.prompt.md, Requirements.md do not implmement refresh tokens, when needed the user will login again. However add the refresh tokens in posibbile improvements doc Questions for you (to improve and lock architecture)
Backend runtime: Express server, Lambda/API Gateway, or hybrid? “Setup script”: should it create DynamoDB tables, or should CDK own infra? RSA signer lifecycle: in-memory only (tokens die on restart) vs persisted (KMS/Secrets)? Admin creation: direct DynamoDB write (AWS CLI/SDK) vs a protected endpoint? DynamoDB modeling: single-table design vs separate tables (users, history, agents/tools)? Bedrock MAC: are you targeting Bedrock Agents collaboration or app-level orchestration? Tavily: will Lambda call Tavily directly, and should the key live in Secrets Manager? Streaming: SSE only, or should WebSockets be supported too? Security bar: demo-grade or production-ish (rate limiting, audit logs, IAM conditions, WAF)? Deployment target: local dev only, or AWS-hosted end-to-end (CDK deploy)?
answers to questions in appraisal:
- Backend runtime: Express server (use Bedrock for the Multi-Agent Collaboration and lamda for tavili and Bedrock's Code Interpreter)
- CDK should own as much data as possible, the setup script should support the CDK and there should be a single bash file that ensures everything needed is available
- RSA signer lifecycle: in-memory only (tokens die on restart), all tokens will fail if server restarted, users will have to login to continue.
- Admin creation: the registration endpoint should support admin creation but can only be called using a curl command as described in README
- DynamoDB modeling: separate tables users, history, agents, tools
- Bedrock MAC: Bedrock Agents collaboration, context is provided by app
- Tavily: will Lambda call Tavily directly, key provided in an env var, explained in README with example of export (can be placed in ~/.bashrc)
- Streaming: SSE only
- Security bar: no need for rate limiting, though should be mentioned in a file describing how we could improve the product, refered to in README auditing - especially if there is something malacious in a prompt, but also for all registrations and login/logout on console and attempt to use a bad JWT or other attempt to bypass security, with details of who called, including IP
- Deployment target: local dev only
Please implement the backend and frontend as per the two prompt files mentioned, while respecting all the requirements in Requirements.md and the answers to the questions in the appraisal.