Redmargin Career Agent

The career lab, not the hype lab: an honest, voice-enabled agent that reviews your GitHub repo for a target role and tells you exactly what to fix. No fake praise, just receipts.

Comment

Inspiration

Career advice for developers is either vague ("improve your projects") or flattering. Neither tells you whether your GitHub repo actually proves what an employer expects for the role you want. We wanted a tool that gives receipts instead of hype: what your work demonstrates, where the evidence is thin, and what to fix next.

What it does

Redmargin Career Agent reviews a GitHub repository against a target role and gives honest, actionable feedback.

  • Repository review: repo URL + role → what the repo proves, what's missing, what to be ready to defend in an interview
  • Career guidance: prioritized next steps for a target role
  • Resume verdict: how well your profile communicates fit for a role
  • Interview prep: practice explaining your projects
  • Voice: talk to it through browser speech recognition and spoken responses
  • Alexa skill: ask Alexa to "review my repo for data scientist" (include only if working)
  • MCP server: other AI clients can call review_repository and get_supported_roles

Supported roles: Software Engineer, Data Scientist, NLP, and Forward Deployed Engineer.

How I built it

  • Backend: Python + FastAPI, with endpoints for review, help, resume verdict, and interview
  • Frontend: custom HTML/CSS/JavaScript served by the same FastAPI app, with browser Speech APIs for voice
  • MCP: a separate Model Context Protocol server exposing the review workflow as tools
  • AI: optional LLM integration with a mock mode so the demo works without credentials (add: "Amazon Bedrock as the model provider" if done)
  • Alexa: an Alexa-hosted custom skill (AWS Lambda) that calls the same /api/agent/review endpoint (include only if working)
  • Quality: Pytest suite and GitHub Actions CI
  • Hosting: Render

The key design choice was one review engine behind three interfaces (web, voice, MCP), so improvements show up everywhere.

Challenges I ran into

  • Keeping feedback evidence-based. It's easy for an AI reviewer to praise everything, so the review logic is built around what the repo actually shows.
  • Voice and URLs don't mix. Nobody wants to speak a GitHub URL, so the voice flow reviews a preset repo for a role the user says aloud.
  • Latency limits. Voice platforms expect quick replies, and free-tier hosting can cold-start, so we keep spoken summaries short and added a mock mode.
  • Being honest about scope. Browser voice is not a native Alexa skill, and we say so plainly in the README.

Accomplishments that I am proud of

  • One review engine reachable by typing, speaking, and through MCP
  • An automated test suite and CI from the start
  • A README that separates what works from what's planned

What I learned

  • How MCP exposes tools to other AI clients as a separate process
  • Designing for voice means short answers, forgiving input, and graceful failure
  • Feedback that cites evidence is more useful than a score

What's next

  • Feedback that cites specific files and commits
  • Deeper role-specific rubrics
  • Multi-turn interview practice with follow-ups
  • Private-repo support

Built With

  • alexa-skills-kit
  • aws-lambda
  • css3
  • fastapi
  • github-actions
  • html5
  • javascript
  • model-context-protocol
  • pytest
  • python
  • render
  • uvicorn
  • web-speech-api
Share this project:

Updates

Submission history