Render

Student Success Tools · Case study

A student-facing AI career-readiness environment students build across the capstone, and keep after they graduate.

1. Summary

Creative students graduate with strong portfolios and no plan for using them. Canvas access ends at graduation, taking their coursework with it.

Render is a personal learning environment: a student-facing AI career space populated during AVC 248 (Design Self Promotion at the college) and owned by the student afterward. Students do not face a blank AI prompt. They work inside a structured environment anchored to one real reach job they choose on day one.

By graduation a student leaves with a populated career launchpad (goals, saved jobs, resume drafts, a job log with cover letters, a skills gap analysis, networking contacts, interview practice, a weekly schedule, and a 90-day plan), exported as a downloadable package they own: a dashboard, a job tracker, their tailored documents, and their agents and skills as prompt files that run in their own AI tool.

1.1 Build status

Here is the exact state of each part.

Component	Status
The interface and all data panels (profile, goals, job and client log, resume vault, skills, networking, interview prep, launch plan, export)	Built. This is the dashboard that opens at the Render address.
The AI steps in the dashboard (about twenty prompts, one per section)	Built as copy and paste. Each step shows its prompt, the student runs it in their own AI account, and the answer comes back by paste.
The agents (AI mentor, hiring committee, interview panel, the student’s job-search agent)	Built as copy and paste in the Agent Workshop (section 4.9). Tested end to end with an invented student.
Gemini skills, one per AI step and one per agent	In progress. The instructions exist as prompts. They still have to be written as skill files and tested in Gemini, which cannot happen until skills reach the district’s education accounts (section 6.3).
Gemini for student accounts	Not on yet. This is a district decision, not a Render build item.
Login and storage	No sign-in and no name. Work is stored in the browser. Nothing to approve.
The added skills in section 4.8	Designed, not built.
Hosting	Live on a personal GitHub Pages site. A move to a district GitHub organization is an option, not a prerequisite.

2. Goal

A career environment that outlasts the course. The pedagogy is connectivism: a personal learning environment is a space the learner owns where goals, work, skills, and connections live together and keep developing. The export is not an archive, it is a dashboard students keep updating.

2.1 The learning environment to agent arc

Stage	What happens in Render
Day one	The student sets goals, guided by targeted questions, and picks one real reach job as their anchor. Every later module aligns to it.
All semester	Render runs alongside the capstone: profile, goals, job log, resume vault, skills tracker, networking, interview prep.
Capstone	Render analyzes the gap between what the student built and what the reach job requires, then generates a portable learning plan and career agent.
Take with you	The student keeps Render (data and dashboard, exportable) and the agent, which runs in any AI tool.

2.2 Assessment model

Formative all semester: every saved job refreshes a running read of where the student needs to tool up, and the gap analysis, tailoring iterations, interview coaching, instructor feedback, and Diagnose Your Search feed low-stakes signals while there is time to act. Summative at the capstone: that evidence becomes the learning plan and portable agent. Formative again afterward: the Training Plan Agent runs a weekly loop and promotes a skill onto the resume once it is demonstrated.

2.3 Two parts of one tool

Product	Purpose	Status
In-class gathering interface	Structured data-entry tool used during AVC 248, populated week by week. AI assists with analysis, cover letters, search strings, and coaching.	Built
Post-graduation dashboard and career agent	A persistent, updatable dashboard exported from the first product, plus the portable agent and learning plan. Four themes, no login. Students own both.	Built

2.4 Agents and skills

Render is built from two kinds of parts, and the course teaches the difference. A skill is a single focused job: input in, a useful result out, one step (tailor a resume to a posting, draft a cover letter, score a gap). An agent is a role or an orchestrator: it plays a persona, coordinates several skills and personas into one experience, or runs on its own over time. Render’s AI functions are skills. On top of them sit a few agents: a AI mentor that guides the whole journey, a hiring committee and an interview panel that each run a set of named role personas, and the student’s own job-search agent that they build and take with them. Students are told on day one that they are building agents and skills, that Render is training wheels, and that at the end they leave with the agents and skills themselves, exported to run in their own AI tool, plus the understanding to build more.

The words are chosen on purpose. Google’s Gemini now has a feature also called skills: reusable instructions saved once and run on demand. Render’s skills and agents are planned to ship in that form (section 6.3), so what a student learns to call a skill in class is the same thing they will open in their Gemini account.

2.5 The agent chain

The interface is changing from a place where students gather career information to a place where they build agents. Render is the training wheels: the student builds four agents by hand, and each one hands its results on. The gaps the agents find along the way collect into one list, and that list becomes the student’s learning plan.

Two rules shape the chain. The AI mentor follows the student through the whole class: it is built first, the student checks in with it after every step, and it coaches from the first job search to the final plans. It is called a mentor, it says plainly that it is an AI, and one of its standing jobs is to get the student to a human mentor: it raises it in the first conversation and asks about it at every check-in until the student has one. And the panels are aligned to the job: every job the student picks gets its own four people, named and titled for that employer, who first read the application and then run the interview. A different job means a different panel and different questions.

Order	Agent	What the student gives it	What it does	What it hands on
1, then all class long	AI mentor	Goal, strengths, the resume they wrote by hand, their portfolio, the time and money they have, who they already know, and what they want from a mentor. After every step, an update on where each job stands.	Coaches in four stages: choosing which openings to go after, getting the interview, getting ready for it, and planning ahead.	One thing to do this week, every week. At the end: a professional development learning plan, a plan to build a network, and a plan to find a human mentor.
2	Job search agent	Goal, strengths, resume, where to look and what to skip.	Finds real openings and confirms each one is still posted.	Openings to the job log. Gaps it keeps seeing to the learning plan. Both to the AI mentor.
3, once per job	Will I Get an Interview? panel	One saved posting, four panel members who fit that employer, the resume the student aligned to the posting by hand, the cover letter they wrote by hand, and their portfolio.	The four read the whole application, mark each requirement, and agree on the odds: Reach, Possible or Strong.	What to change in the resume, the cover letter and the portfolio, which the student works through with the AI mentor. Gaps an edit cannot fix to the learning plan.
4, once per job	Interview panel	The same posting, application and portfolio, and the same four people.	That job’s panel asks the interview questions one at a time, then coaches every answer.	Answers to practice and what to change in the portfolio before the real interview, both to the AI mentor. More gaps to the learning plan.

The student writes and aligns the resume and the cover letter by hand. The agents do not write them. The panel says whether the application is likely to get an interview and what to change, the AI mentor helps the student decide what to change first, and the student makes the changes and runs the panel again.

What the student takes with them: the AI mentor and job search agent, a panel and an interview for each job, all as plain text files that run in any AI tool; the learning plan; the job log with each aligned resume and cover letter; and a one-page method for building a new agent or a panel for the next job. The method is the durable part.

3. Users and context

User	Context	Needs from Render
Digital Media Arts students	Finishing AVC 248. Portfolios done. Seeking employment, freelance clients, or both.	Structured guidance, not blank prompts.
Animation students	Targeting studios, production companies, streaming platforms. Reel is the primary job-search tool.	Reel link prominent. Industry-specific job analysis. Animation software tracking.
Photography students	Commercial and fine art. Client-finding as relevant as job-searching.	Freelance client track. Commercial versus editorial distinction.
Film and media students	Agencies, corporate video, broadcast, or a freelance production company.	Both tracks. Reel and portfolio. Spec sheet and contract templates.
UX design students	Pursuing employment at tech companies. Case-study portfolio is critical.	Job-search focus. Case-study links. UX-specific gap analysis.
Instructor	Runs AVC 248, about 24 students.	Instructor settings panel. Career Services pipeline. No FERPA-sensitive data transmitted.
Career Services	Wants employer intelligence to build internship pipelines.	Anonymous aggregated data: employer names, job titles, program areas. No student names or MEIDs.

• Course: AVC 248 Design Self Promotion, 15 weeks, online, asynchronous, roughly 24 students per section.
• Canvas access ends after graduation, so Render must be self-contained after export.
• Student devices are a mix of Mac, Windows, and mobile, so the tool is device-agnostic.

4. How it works

The build status of each part is in 1.1. Only the added skills in 4.8 are not built. Each subsection notes when the capability is used across the 15-week semester.

4.1 AI literacy unit

Weeks 1 to 2

A prerequisite, not an introduction. The Tailor flow is locked until it is complete.

1. How a model produces text. Next-token prediction, why fluency is not evidence. Students run a prompt designed to elicit a fabrication, then verify it.
2. Prompting as specification. Role, task, format, context, constraint. Students compare a weak and a strong prompt on the same model.
3. Verification and disclosure. What must be checked before it enters an application (every employer, date, metric, skill claimed), and how to disclose AI use to an employer who asks.
4. Bias, privacy, and the labor question. What a model was trained on, what a vendor does with a prompt, and how applicant tracking systems read a student’s materials first.
5. Where a model is the wrong instrument. Original voice, situated judgment, anything that must be true. This is what makes the base materials rule intelligible.

Assessment: a short AI use policy the student writes for themselves, stating where they will and will not use a model in their own job search. Graded on the reasoning, not the position.

4.2 The job search loop

Weeks 1 to 15

The home view frames the tool as one repeatable 10-stage system: target, build base materials by hand, find roles, then per job research, tailor, iterate, apply, and log, then follow up, network, prep for interviews, track the pipeline, and diagnose. The student keeps running the loop after graduation with the exported dashboard and agent.

Diagnose Your Search is a rules-based funnel diagnosis. It reads logged activity (applications sent, responses, interviews) and names where the search is stalling and what to change, with an optional AI deeper dive. Every data-entry section opens with directions, so students never face a blank field.

4.3 Profile, goals, links hub, search strings

Weeks 1 to 3

A guided goals builder walks the student through targeted questions (role, industry, setting, location, day-to-day work, timeline, values, pay range) and assembles a specific goals statement. The student picks one real reach job as the anchor for every later module and for the capstone gap analysis.

The profile captures program, employment and freelance tracks (both can be active), weekly commitment sliders, a links hub (LinkedIn, Behance, portfolio, reel, Instagram, GitHub), dream job or client, target market, and a 3-year vision. The current build also has an AI search-string generator (ready-to-paste strings for LinkedIn, Indeed, Glassdoor, and Google), but it is being replaced by the student’s job-search agent (section 4.7), which does far more than produce strings: it takes the resume and goals and actively finds and verifies live roles. Search strings remain only as a simple fallback.

4.4 Job log, base materials, tailoring, and critical AI review

Weeks 2 to 13

On the employment tab, students paste a job description and get an AI skills gap analysis and a cover letter draft, tracked through a status pipeline (saved, applied, interview, offer or pass), with the description, resume edits, and cover letter stored together. On the freelance tab, students describe an ideal client type and AI returns search strategies, 8 to 10 real prospect names, outreach guidance, and a pricing check. On save, Render tells the student what goes to Career Services and why (section 5).

The resume vault holds base resume drafts (first through fourth) and a base cover letter, with instructor feedback fields and an active resume flag. The base materials rule is hard: the first resume and first cover letter are written by the student, by hand, with no AI and no template, then pasted in. The Tailor flow refuses to run until both exist. Resume drafts carry no name, address, or phone number; students add contact details to the version they send.

The Tailor flow shows the job-match read (skills match, gaps, positioning, red flags), then takes the job description plus the active base resume plus the base cover letter and produces tailored first drafts of both, in the student’s voice, plain text only. An iteration loop lets the student re-prompt by naming what to change, and a reflection field captures what they edited. A critical AI review checklist renders under every AI output: accuracy, voice, proof, format, and fit to the specific job. Students never submit a first AI draft.

4.5 Skills, networking, interviews, and application support

Weeks 5 to 14

A software stack checklist by program covers 6 categories and roughly 60 tools. Students build a skills-to-build list by hand or pull gaps from saved job entries via AI. Gap analysis surfaces professional skills and industry workflows (project management, client presentations, creative briefs, production planning, budget management) alongside software, then names free learning resources. A portfolio project idea generator and a professional development log complete the section. This is the formative engine from section 2.2.

A contact log with type tagging (mentor, employer, peer, alumni, industry) and outreach status. AI drafts LinkedIn connection requests under 300 characters, with a redraft option per contact.

Interview prep generates role-specific questions from saved job descriptions plus general questions by role type. Students practice answers and get AI coaching feedback (coach, not cheerleader), saved to a question and answer log. Big Interview is integrated for video practice. AI also drafts a thank-you or follow-up note in the student’s voice, with timing guidance.

Support materials: a references sheet builder matching the student’s resume styling, an online presence audit covering what an employer sees when they search for the student, and a salary research helper covering BLS, Glassdoor, Levels.fyi, and Built In and how to answer the salary question with a researched range.

4.6 Launch plan and career agent, the capstone export

Week 15

Render analyzes the gap between everything the student built and the requirements of their day-one reach job, then generates a career agent and personal learning plan as a Markdown file that runs in any AI tool.

A companion Training Plan Agent sequences the gaps from real saved jobs into a 90-day learning plan, mapping each gap to a specific low-cost resource (named YouTube channels, Coursera and Adobe courses, freeCodeCamp, the AVC 248 AI unit). It runs on a weekly loop after graduation, promoting each skill onto the resume once it is demonstrated.

An AI weekly schedule builder generates a Monday to Sunday time-blocked schedule from committed hours, goals, gaps, and job targets, with a Sunday review block.

The export is a single downloadable package (a zip) the student owns and keeps. It contains: a self-contained HTML dashboard (four color themes, opens in any browser with no login or software) carrying goals, the job-search agent, links, the mentor list, the skills map with gaps and resources, the professional development plan, the 90-day plan, the weekly schedule, and semester stats; a spreadsheet job tracker (their living record of what they applied for, with the job description, status, and mentor contacts); their real application documents (each tailored resume and cover letter as an editable file plus a ready-to-send PDF, filed with its job description); and their agents and skills as clearly labeled prompt files with a one-page plain-English readme showing how to paste each one into their own ChatGPT, Claude, or other AI tool. The Render editing interface does not have to live on; this package does.

4.7 The agents: AI mentor, hiring committee, interview panel, and the student’s job-search agent

Built as copy and paste

These agents are never generic, and they are not the same for every student. They are shaped by the individual student’s goals, which is what guides that student toward the right jobs to research and save in the first place. Each committee and each interview is then built from one specific saved posting. Two students never get the same committee or the same interview, because both are instantiated from that student’s own goals and the exact job in front of them, grounded only in that posting’s real requirements. Nothing here runs until the student has real target jobs saved in the job log, and the committee and interview attach to each saved job rather than existing on their own.

The agents are built in the order in section 2.5. The AI mentor comes first and stays for the whole class. The job-search agent comes second. The Will I Get an Interview? panel and the interview panel are built once for each job the student picks, with four people who fit that employer.

AI mentor. The agent that holds the whole picture and follows the student through the class as coach. It is named a mentor and it is honest that it is an AI. It does not let the student treat it as a replacement for a person in their field. At every check-in it looks at whether the student has a human mentor yet, and if not it gives one small step toward finding one. It is built first. After every step the workshop gives the student an update to paste into the same AI mentor conversation: where each job stands, what each panel asked for, and the gap list so far. It coaches in four stages. It helps the student choose which openings to go after. It helps them get the interview, by working through the panel’s changes to the resume, cover letter and portfolio without writing them. It helps them practice what the interview panel flagged. At the end it builds three plans: a professional development learning plan that starts with the gaps that showed up most (one free or low-cost way to learn each, a small project that proves it, and when it moves onto the resume); a networking plan (the kinds of people to meet, where to find them, one outreach a week); and a human mentor plan. The human mentor is a real person in the student’s field, so the plan describes who to look for, where to look, how to ask, and what to bring to the first conversation (this serves competency 4 and the Module 5 and 6 mentor work). It asks before it advises, it never invents a person, a group or a course, and it ends every reply with one thing to do this week.

Hiring committee (in the interface, the Will I Get an Interview? panel). The panel is aligned to the job: each saved job gets its own four people, with names and job titles that fit that employer, and that panel exists for that job only. It reads the whole application: the resume the student aligned to the posting by hand, the cover letter they wrote by hand, and their portfolio. It tells the student what to change in each, and it does not rewrite the resume or the letter for them. A panel of named role personas, each with a department and a lens: an HR specialist, the hiring manager for the job, a peer who does the same job, and a peer in the department doing a different job. Each scores the student’s application against the specific pasted posting on a rubric. An orchestrator returns one report: the rubric scoring, an interview-likelihood band (Reach, Possible, Strong), and a roadmap of what the student would need to do to land a job like this. Grounded only in the posting, coaching in tone, never “you will not get in.”

Interview panel. Also aligned to the job. Once the student clears the committee for a job, that job’s four personas interview them one question at a time, rotating and introducing themselves by name and department. Eight questions: open with “tell me about yourself” and “why are you a good fit,” about six drawn from the posting’s minimum qualifications and work-culture cues, and close with “do you have any questions for me.” One question asks the student to walk through a piece in their portfolio. An orchestrator runs the experience and coaches afterward, and the coaching includes what to change in the portfolio before the real interview (this deepens competency 7 and the Module 7 mock interview).

The student’s job-search agent. This replaces the old search-string helper. Rather than Render running the search itself, which would need a server that runs on a schedule with open web access, Render writes the agent for the student. It takes their resume (or master resume), goals statement, and the kinds of jobs they want, and assembles a ready-to-run agent, the full directions plus the student’s own parameters, that the student pastes into their own Gemini. Gemini then does the work in the student’s hands: it scours widely on keywords and other signals across job boards and company career pages, and, importantly, verifies each posting is still live on the employer’s own careers page before listing it, so the student is not chasing dead links or aggregator reposts. The results come back as a job feed the student reviews and pulls into their job log, where the hiring committee and interview attach. Because the agent runs in the student’s own AI, it is truly theirs and keeps working after graduation, and Render needs no backend to make it go. A fully automated weekly feed that runs itself inside Render is possible later, but that version needs a server-side worker and is not part of the pilot.

Master resume. The resume vault evolves toward one long master document the student keeps adding to, like a CV, then draws down from to align to each specific job, the way a working professional tailors from a master.

4.8 Skills to add (from the competitive scan and the course competencies)

Reviewing Render against the competitor tools and the eight AVC 248 competencies surfaced a few skills worth adding so the tool fully covers what students are taught:

• Elevator pitch. Helps the student build and refine a short self-introduction, feeding both the Module 3 elevator-pitch assignment and the interview panel’s opening “tell me about yourself.”
• LinkedIn profile builder. Beyond the existing online-presence audit and connection-message drafts, a skill that helps optimize the actual LinkedIn profile (headline, about, experience), matching Module 6 and competency 4. Competitor tools score LinkedIn; students are taught it, so Render should let them practice it.
• Freelance contract and spec-sheet coach. Walks a freelance-track student through the points of discussion for a client contract and a spec sheet, directly serving competency 6 and the Module 5 Project Brief with Contract, and deepening the freelance track.
• Explicit application match check. The Tailor flow already tailors to a posting’s keywords; a clear, readable match read (met, partly met, missing against the posting) gives students the ATS-style signal the commercial tools sell, taught here as a coaching moment rather than a black-box score.

Scope note: the design deliverables in the competencies (business card, identity package, leave-behind) are studio production work students make in their design tools, not AI functions, so Render supports them through the portfolio review rather than generating them.

4.9 The Agent Workshop interface

Built

The Agent Workshop is where students build their agents. It opens from the dashboard’s sidebar, under Your Agents, and it reads the goal, resume, portfolio link and saved jobs, with their postings, from the dashboard, so nothing is entered twice.

Requirement	How the tool meets it
Students build agents, they do not fill in forms.	Every agent is the same five parts: role, context, task, rules and handoff. The student answers questions grouped under those parts and watches the agent file assemble beside them.
One step at a time, in order.	Six steps across the top: you and your goal, the four agents, and take it with you. Each agent step has the same moves: build it, run it, bring back what it found, check in with the AI mentor.
The AI mentor encourages a human mentor.	Its role, task and rules all say so. The student records “my human mentor so far,” that line goes into every update, and the AI mentor asks about it until it is filled in.
The AI mentor follows the student through the class.	It is Agent 1. Every later step ends with a button that copies an update for the AI mentor, written from the student’s current jobs, panel results and gap list, with the right request for that stage.
The panels are aligned to the job.	Each job in the log carries its own four panel members, posting, aligned resume, cover letter, odds, changes and interview coaching. New jobs start with a different four people, and the student retitles them to fit the employer. Both panel steps begin by choosing the job.
The student’s own writing goes in.	The resume written by hand is pasted once. For each job, the student aligns a copy of it to the posting and adds the cover letter they wrote. The portfolio is a link plus one line per piece, since some AI tools cannot open a link.
The agents run in the student’s own AI account.	The page makes no AI call and holds no key. The student copies the agent file into Gemini, Claude or ChatGPT, then pastes the reply back.
Results pass from one agent to the next.	Each agent is told to answer under exact headings. The page reads those headings: openings go to the job log, the odds and the changes show beside the application, and gaps go to the learning plan.
The learning plan grows from real jobs.	One gap list, visible on every step. A gap found by more than one agent is counted, so the AI mentor’s plans start with what showed up most.
Students can outgrow the training wheels.	Any agent file can be switched to hand editing. From then on the student’s own wording is what is copied and downloaded.
Students leave owning it.	One download: the AI mentor and job search agent, a panel file and an interview file for each job, the learning plan, the job log with each aligned resume and cover letter, a readme, and the method for building a new agent.
No personal information.	No sign-in. Students are told to leave name, address and phone number off what they paste. Work is kept in the browser on that computer.

Not built yet: reading the remaining dashboard panels (links hub, references, salary, networking), saving work so it survives a wiped lab computer (section 5.1), the freelance version of each agent, and the elevator pitch, LinkedIn and contract skills from section 4.8. The workshop has been run end to end with an invented student, and three of the agent files from the first version were run through an AI model to confirm the page reads a real reply. It has not been used by students.

4.10 How the dashboard and the workshop fit together

No step from the dashboard is dropped. The dashboard and the workshop are one tool: the dashboard holds every step, and the workshop is its agent-building section. The table shows where each dashboard step meets an agent, and what the workshop reads today.

Step in the dashboard	Agent step it meets	Today
Profile, goals and creative identity	Start: you and your goal	Goal and creative identity are read from the dashboard.
Links hub	Start: you and your goal	In the dashboard. Not yet read by an agent.
Online presence audit	AI mentor, getting the interview	In the dashboard. Not yet read by an agent.
Search strings	Job search agent	Replaced. The agent searches and confirms each posting is open.
Career Services employer row	Job search agent	In the dashboard. Saving a job sends one anonymous row to a Google Sheet through Apps Script (section 5.3).
Job and client log	Job search agent	Saved jobs are read from the dashboard, each with its posting and the date it was saved. Client entries stay in the dashboard.
Salary research	Job search agent	In the dashboard. Not yet read by an agent.
Resume vault, drafts and instructor feedback	Will I Get an Interview?	The active resume draft is read from the dashboard and aligned per job in the workshop. Draft history and instructor feedback stay in the dashboard.
Cover letters	Will I Get an Interview?	The base cover letter is read from the dashboard, then written by hand for each job.
References sheet	Will I Get an Interview?	In the dashboard. Not yet read by an agent.
Interview prep	Interview panel	In the workshop, for each job.
Thank-yous and follow-ups	Interview panel	In the dashboard. Not yet read by an agent.
Skills and software stack	AI mentor, learning plan	Gap list is in the workshop. The stack inventory is in the dashboard.
Networking tracker	AI mentor, network plan	Network plan is in the workshop. The contact log is in the dashboard.
Diagnose Your Search	AI mentor, check-ins	In the dashboard. Not yet read by an agent.
Launch plan, 90 days and weekly schedule	AI mentor, final plans	Learning, network and mentor plans are in the workshop. The 90-day plan and weekly schedule are in the dashboard.
Dashboard export, four themes	Take it with you	Agent files download from the workshop. The dashboard export is in the dashboard.

Requirements and acceptance criteria

Each requirement is one behavior. The checks beside it are what a builder or tester confirms before that requirement is called done. Status reflects what this document records as built.

#	Area	Requirement	Done when	Status
R1	AI literacy unit	Render must keep the Tailor flow locked until the student has completed the AI literacy unit.	A tester opens the Tailor flow on a new profile with the unit incomplete and sees it locked, with a message naming the unit as the reason. After the unit is marked complete, the tester opens the Tailor flow and it is no longer locked for that reason. The lock state is unchanged after the page is reloaded.	To verify
R2	The job search loop	Render must show the 10-stage job search loop on the home view.	The home view lists all ten stages in the order given in section 4.2, from target through diagnose. Every data-entry section reached from the home view opens with written directions above its first field.	Built
R3	The job search loop	Render must run Diagnose Your Search from the student’s logged applications, responses and interviews without an AI step.	With applications logged and no responses logged, the diagnosis names the stage where the search is stalling and one thing to change. The diagnosis appears without the student copying a prompt into an AI tool. An optional deeper dive hands the student a prompt to run in their own AI account.	Built
R4	Profile, goals, links hub, search strings	Render must walk the student through the goals questions and assemble one goals statement.	The builder asks about role, industry, setting, location, day-to-day work, timeline, values and pay range. After the last question, a single goals statement containing the student’s answers is shown and saved. The student can record one reach job, and that job is shown as the anchor on the launch plan.	Built
R5	Profile, goals, links hub, search strings	Render must let the student record a profile with program, tracks, weekly commitment and a links hub.	The tester can turn on the employment track, the freelance track, or both at once. The links hub accepts and saves LinkedIn, Behance, portfolio, reel, Instagram and GitHub links. The profile has no field for a last name, email, student ID, address or phone number.	Built
R6	Job log, base materials, tailoring, and critical AI review	Render must let the student save an employment job with its pasted description and move it through the status pipeline.	A tester pastes a job description, saves the entry, and sees it in the log with the status saved. The status can be changed to applied, interview, and offer or pass, and the change remains after a reload. Opening the entry shows the description, the resume edits and the cover letter together.	Built
R7	Job log, base materials, tailoring, and critical AI review	Render must send one anonymous row to the Career Services Google Sheet each time an employment job is saved.	Saving one employment job adds exactly one row to the sheet. The row holds the date, employer name, job title, job URL, interest level, program area and the first 300 characters of the posting. No AI summary is sent. At the moment of saving, the student sees a notice stating what is sent to Career Services and why. Saving a freelance client entry adds no row.	Built
R8	Job log, base materials, tailoring, and critical AI review	Render must give a freelance-track student a prompt that returns search strategies, prospect names, outreach guidance and a pricing check for a described client type.	On the freelance tab the tester enters an ideal client type and receives a ready prompt to copy. The prompt asks for search strategies, 8 to 10 real prospect names, outreach guidance and a pricing check. The pasted reply is saved with the client entry and is still there after a reload.	Built
R9	Job log, base materials, tailoring, and critical AI review	Render must store base resume drafts one through four and one base cover letter in the resume vault, with one draft flagged as active.	The tester can paste and save four resume drafts and one base cover letter. Only one draft can carry the active flag at a time. Each draft shows an instructor feedback field. The vault shows a direction telling the student to leave name, address and phone number off the drafts.	Built
R10	Job log, base materials, tailoring, and critical AI review	Render must refuse to run the Tailor flow until a base resume and a base cover letter both exist in the vault.	With no base resume saved, the Tailor flow does not run and states that a hand-written resume is required. With a base resume but no base cover letter, the Tailor flow does not run and states that a hand-written cover letter is required. With both saved, the Tailor flow opens.	Built
R11	Job log, base materials, tailoring, and critical AI review	Render must build the tailoring step from the job description, the active base resume and the base cover letter, and let the student iterate on the result.	The flow shows the job-match read with skills match, gaps, positioning and red flags before the tailoring step. The tailoring prompt contains the job description, the active base resume and the base cover letter. The student can name what to change and run the step again. A reflection field accepts and saves what the student edited.	Built
R12	Job log, base materials, tailoring, and critical AI review	Render must show the critical AI review checklist under every AI output.	Under each AI output the checklist lists accuracy, voice, proof, format and fit to the specific job. The checklist appears under the job-match read, the tailored drafts, the cover letter draft and the interview coaching.	Built
R13	Skills, networking, interviews, and application support	Render must let the student build a skills-to-build list by hand or from the gaps in saved jobs.	The software stack checklist shows 6 categories for the student’s program. The tester can add a skill to the list by typing it. The pull-gaps step uses no more than 6 saved job descriptions and adds the returned skills to the same list.	Built
R14	Skills, networking, interviews, and application support	Render must let the student log networking contacts with a type and an outreach status.	A contact can be tagged as mentor, employer, peer, alumni or industry. The outreach status of a contact can be changed and the change remains after a reload. The connection request step asks for a LinkedIn message under 300 characters and offers a redraft for the same contact.	Built
R15	Skills, networking, interviews, and application support	Render must generate interview questions only from the job description the student entered for that job.	Each question set is tied to one saved job and can be traced to that job’s description. The set contains an opener, a behavioral (STAR) question, a situational question, a competency-based question and a closing question, each labeled by type. Two saved jobs with different descriptions produce different questions. A job with no description entered produces no questions and a message asking for the description.	To verify
R16	Skills, networking, interviews, and application support	Render must have the interview agent list what a strong answer includes and never write the answer for the student.	For each question, the coaching lists the elements a strong answer includes. No coaching reply contains a full model answer or a rewritten version of the student’s answer. The agent file states the rule against writing the answer in its rules part.	To verify
R17	Launch plan and career agent, the capstone export	Render must produce a 90-day learning plan and a Monday to Sunday weekly schedule from the student’s saved gaps, goals and committed hours.	The 90-day plan lists gaps taken from the student’s saved jobs, each with a named low-cost resource. The weekly schedule covers Monday through Sunday in time blocks and includes a Sunday review block. Changing the committed hours and running the step again changes the schedule.	Built
R18	Export	Render must let the student download a package they own that opens with no login and no connection to Canvas.	The exported dashboard opens in a browser on a device that has never opened Render, with no sign-in. The exported dashboard offers four color themes. The package contains the job tracker, the tailored documents filed with their job descriptions, and the agent files with a readme. The student can run the export at any point in the semester, not only in week 15.	Partly built
R19	The agents	Render must assemble an AI mentor agent file that states it is an AI and asks about a human mentor at every check-in.	The assembled file says in plain words that the mentor is an AI. The student can record a human mentor so far, and that line appears in every update copied for the AI mentor. Every later workshop step ends with a button that copies an update built from the current jobs, panel results and gap list. The file’s rules tell the agent to end every reply with one thing to do this week and never to invent a person, a group or a course.	Built
R20	The agents	Render must assemble a job search agent file from the student’s goal, strengths, resume, and where to look and what to skip.	The assembled file contains the student’s goal, resume text and search parameters. The file instructs the agent to confirm each opening is still posted on the employer’s own careers page before listing it. When the student pastes the reply back, the openings can be added to the job log.	Built
R21	The agents	Render must give each saved job its own Will I Get an Interview? panel of four members who read the resume, cover letter and portfolio for that job.	Both panel steps begin by choosing a job from the log. Each job carries four panel members whose names and titles the student can edit. The pasted reply shows a band of Reach, Possible or Strong beside the application, with the changes listed for the resume, cover letter and portfolio. The panel file tells the agent not to rewrite the resume or the cover letter.	Built
R22	Skills to add	Render must show an application match check that marks each requirement of a posting as met, partly met or missing.	For one saved job, the check lists the requirements taken from the posting. Each requirement carries exactly one of the three marks. The check shows no single numeric score in place of the marks.	Designed, not built
R23	The Agent Workshop interface	Render must build every agent from the same five parts and show the agent file assembling as the student answers.	Each agent step groups its questions under role, context, task, rules and handoff. Typing an answer updates the agent file shown beside the questions. The workshop shows six steps across the top in the order given in section 4.9. After the student switches a file to hand editing, the copied and downloaded file contains the student’s own wording.	Built
R24	The Agent Workshop interface	Render must read the exact headings in a pasted agent reply and route the results to the job log, the application and the gap list.	A pasted job search reply adds its openings to the job log. A pasted panel reply shows the odds and the changes beside that job’s application. Gaps from any reply appear in one gap list that is visible on every step. A gap returned by more than one agent shows a count above one.	Built
R25	How the dashboard and the workshop fit together	Render must open the Agent Workshop from the dashboard and fill it with the goal, resume, portfolio link and saved jobs already entered there.	The workshop opens from the dashboard sidebar under Your Agents. The goal and the active resume draft entered in the dashboard appear in the workshop without being typed again. Each job saved in the dashboard appears in the workshop with its posting and the date it was saved. The portfolio link entered in the dashboard appears in the workshop.	Partly built
R26	Data and privacy	Render must collect no personally identifiable information and send nothing that identifies a student to an AI tool or to the Google Sheet.	No screen asks for a last name, email, student ID, address or phone number. A network inspection during a full session shows one outbound request type only, the Career Services row, and it holds no student identifier and no AI-written text. The dashboard and the workshop hold no AI key and make no AI call; every AI step is a prompt the student copies into their own account. Prompts copied from Render contain no name, address, phone number or email.	Built
R27	Sign-in and data storage	In this version, Render must open with no sign-in, ask for no name, and keep the student’s work in their own browser.	A tester opens Render on a computer that has never used it and reaches the dashboard without creating an account or entering a password. No screen in the dashboard or the workshop has a field for a first name, a last name or an email, and no export or file name contains one. The tester saves a goal, closes the browser, reopens Render on the same computer and sees the goal. The tester uses Save to File, opens Render on a second computer, uses Load from File and sees the same work. With the network inspector open, saving a goal or a resume draft sends nothing to any server.	Built
R28	Sign-in and data storage	In the next version, the student signs in with an invented handle and a PIN, and their work is kept in a backend owned by the district or the department.	A tester creates a handle and PIN without being asked for a name or an email. The tester signs in on a second device with the same handle and PIN and sees the same work. The stored record holds the handle and the student’s career content and no field that names the student. The backend account is owned by the district or the department, and the district has approved it for student work.	Designed, not built
R29	AI delivery	Render must run every AI step through the AI bridge: show the finished prompt, let the student copy it, and save the answer the student pastes back.	Each AI button in the dashboard opens the bridge with a complete prompt, with no blank fields left for the student to fill in. Pasting an answer and saving puts it in the place that step owns (the job, the plan, the contact) and it is still there after a reload. Closing the bridge without an answer saves nothing and shows a message saying so. With the network inspector open, no AI step sends a request to any AI service. The Tailor flow asks for its prompts one at a time, never two at once.	Built
R30	AI delivery	Each AI step and each agent must also be available as a Gemini skill the student runs in their own Gemini account.	There is one skill file per AI step in section 6.5 and one per agent, each in Google’s skill file format. A student signed in with a district account opens a shared skill, gives it their Render file, and gets a result with the same headings the copy-and-paste prompt returns. Each skill has been run against the invented test students and its result compared with the copy-and-paste result. No skill asks for a name, email, student ID, address or phone number. Copy and paste still works for a student who is not using Gemini.	In progress. Not built, not tested in Gemini

5. Data, privacy, and governance

Render collects nothing that identifies a student: no name, no email, no student ID, no address, no phone number. There is no sign-in in this version. No identifying information enters any AI step: every AI feature runs on the student’s goals, their resume text with contact details left off, and the job descriptions they paste.

5.1 Sign-in and data storage

	This version	Next version, planned
Sign-in	None. The tool asks for no name.	An invented handle and a PIN. Never a name or an email.
Where work is kept	In the student’s own browser, on the computer they use.	In a backend owned by the district or the department, keyed to the handle.
Keeping and moving work	Save to File and Load from File, and the export package (section 4.6).	Work follows the student to any device. The export package stays.
Known limit	Clearing the browser or using a wiped lab computer loses unsaved work, so students save to a file as they go.	A forgotten handle cannot be recovered. This is low stakes, because grades live in Canvas and not in Render.
What it needs	Nothing. No account, no server, no approval.	District approval of where student work is stored, and an owner for that backend. See Dependencies in section 6.

This version runs on browser storage by design. An earlier plan depended on district infrastructure that was not available, so the tool was rebuilt to need none. The handle and PIN are the planned next step, and they are not built. The platform is not chosen: the candidates are a Google Sheet with Apps Script inside the district’s Google tools, or a hosted database. District sign-in was considered and set aside, because it ties a student’s work to their identity and ends when they leave the college.

Grading runs entirely through Canvas. Students submit screenshots of their results to the Canvas assignment, so Render never needs to know who a student is.

5.2 FERPA

Data type	Where it goes	Status
Goals, saved jobs, resume text (no name or contact details)	Stored in the student’s browser, exportable by the student at any time	Stays in the browser, except the employer row below
Date, employer name, job title, URL, interest level, program area, and the first 300 characters of the posting	Google Sheet via Apps Script (Career Services pipeline)	No student identifiers
Full data export (JSON)	A file the student saves wherever they choose	Student owns the data
Future: full cloud sync	district Google infrastructure or a school server	Requires a FERPA agreement, not yet implemented

5.3 Career Services pipeline

Saving an employment job entry sends one anonymous row to a Google Sheet via Apps Script: date, employer name, job title, job URL, interest level, program area, and the first 300 characters of the posting. No AI summary is sent. Career Services uses it to identify companies students target, build employer relationships, and pursue internship and placement opportunities. Students are told this at the moment they save an entry.

6. Build and portability

6.1 Current stack

• Frontend: a single HTML file, vanilla JavaScript and CSS, no framework.
• Sign-in: none in this version, and no name is collected. A handle and PIN are planned (section 5.1).
• Storage: the student’s own browser, with Save to File and Load from File. A backend owned by the district or department is planned and not built (section 5.1).
• AI: Render holds no key and makes no AI call. Every AI step goes through one function, the AI bridge, which shows the prompt and waits for the student to paste the answer back. Currently that is copy and paste into any AI account the student has. Gemini skills are the planned delivery once student Gemini accounts are on (section 6.3).
• Career Services pipeline: a Google Apps Script web app (POST endpoint, no-cors mode), moving to a department account.
• Hosting: static frontend on GitHub Pages. A move to a district-owned organization is a post-pilot option.
• Export: a downloadable zip package the student owns (section 4.6).

6.2 Running on district infrastructure

Nothing about Render requires district infrastructure to run. The AI runs in each student’s own AI account, so there is no key, no proxy, and no institutional AI account in the path. The static frontend can be served from any web host. The changes below are portability improvements available whenever the district wants them, not prerequisites for the pilot.

Change required	Why	Scope
Host the frontend on a district GitHub organization	District student traffic should sit under district control, not a personal account.	Repo move, no code change.
Stand up the handle, PIN and storage backend	Browser storage loses work on a wiped machine. A backend keeps each student’s work and follows them across devices. Until then, students save to a file.	New build, after the pilot. Needs district approval of where student work is stored.
Move the Apps Script endpoint to a department account	The pipeline currently runs on a personal account.	Account transfer, no code change.

6.3 How the AI is delivered: copy and paste now, Gemini skills next

An early prototype of Render called an AI service directly from the page. That design is retired. It needed a shared key in the browser, a budget, and an institutional account, and none of those belong in a student tool run by one instructor. Every AI step now goes through one function, the AI bridge. Render builds the prompt from what the student has entered, and the student is the one who runs it.

Stage	How a student runs an AI step	Status
Now, the pilot phase	Copy and paste. Render shows the finished prompt. The student copies it into their own AI account (Gemini, or any other tool they have), then pastes the answer back into Render, where it is saved with the job, the plan, or the contact it belongs to.	Built and working for every AI step in the dashboard and the workshop.
Planned, the full-tool phase	Gemini skills. Each AI step and each agent is written once as a skill, a reusable set of instructions in Google’s skill file format. The instructor shares the skills with the class. The student opens a skill in their own Gemini account and gives it their Render file. The instructions no longer travel by copy and paste.	In progress. Not built, not tested in Gemini.

Why skills. Copy and paste works, and it is slow: a prompt out and an answer back for every step, about twenty steps and four agents. A skill removes the first half. It also keeps the property that matters most here: the AI runs in the student’s own account, under the district’s agreement with Google, so there is still no shared key, no cost to the department, and nothing to provision. Students keep the skills after the course ends, which is the point of the tool.

What has to happen first.

1. Google finishes rolling skills out to education accounts.
2. The district turns on Gemini for student accounts. Until then students cannot open a skill with a district account.
3. Each prompt is rewritten as a skill file. The workshop already builds every agent from the same five parts (role, context, task, rules, handoff), so the content exists. The format change is the work.
4. Each skill is tested in Gemini against the same invented students used to test the prompts, and the results are compared with the copy-and-paste results.

What skills do not solve. The student’s work lives in Render, in their browser, and the skill runs in Gemini. A skill cannot read the browser. So the student still hands their work to the skill (the Render file from Save to File), and an answer that Render needs to keep still comes back by paste. Closing that gap would mean a direct connection between Render and the student’s Google account, which needs a Google Cloud project owned and approved by the district. That is out of scope for this version and listed as an open question in section 10.

Portability. The prompts are plain text with no vendor-specific features, and a skill file is plain text too. A student on a different AI tool is not blocked, because the copy-and-paste path stays in the tool as the fallback. No personally identifiable information is sent to any model on either path.

6.4 Cost and access

Render costs the department nothing to run. There is no API key, no metered usage, no proxy to host, and no budget line, on either delivery path. The AI runs in an account the student already has.

What the full tool needs:

• Gemini turned on for student accounts by the district and confirmed for every student in week 1 alongside the other tool logins the course already checks.
• The skills written, tested, and shared with the class (section 6.3).
• A short AI-literacy unit in weeks 1 to 2, which the course already includes (section 4.1).

6.5 AI functions

Each function below builds one prompt and hands it to the AI bridge (section 6.3). None of them calls a model. Every prompt includes the student’s anonymous profile and goals as context. Each one is a candidate Gemini skill, and the last column of work is the same for all of them: rewrite as a skill file, then test.

Function	Input	Output
analyzeWithAI	Profile, goals, job description	Skills match, gaps, positioning advice, red flags
generateCoverLetter	Profile, job description, analysis	Tailored 3-paragraph cover letter
getResumeEdits	Active resume, job description	Specific resume edits for this job
pullGapsFromJobs	Saved job descriptions (up to 6)	8 to 12 skills: software, professional, workflows
getRecommendations	Profile, skills gap list	Named free learning resources
getProjectIdeas	Profile, targets, gaps	5 portfolio project ideas with time estimates
draftLinkedInMessage	Contact info, notes	Connection request under 300 characters
redraftMessage	Contact, previous message	Fresh message for an existing contact
generateInterviewQuestions	Profile, job description	10 role-specific questions
generateGeneralQuestions	Profile, role type	8 questions for any creative role
getFeedback	Question, student answer	What is working, what to improve, what a strong answer includes
generatePDPlan	All student data, hours, focus	Personalized 90-day plan
generateSearchStrings	Goals, dream job, market	Copy-paste strings for LinkedIn, Indeed, Glassdoor, Google
buildWeeklySchedule	Hours, goals, gaps, targets	Monday to Sunday time-blocked schedule
generateCareerAgent	All student data, day-one goals, reach job	Portable career agent and learning plan (Markdown)
tailorApplication	Job description, base resume, base cover letter, match read	Tailored first drafts in the student’s voice, plain text
generateFollowUp	Job, interview or application context	Thank-you or follow-up note with timing guidance
generateSalaryResearch	Role, market	Realistic pay range and how to state expectations
diagnoseDeeper	Logged funnel activity	Deeper read on where the search is stalling

Dependencies

What has to be in place, and who provides it.

Needed	Provided by	Needed for
Gemini turned on for student accounts and confirmed for every student in week 1	District, as the provider of student Gemini access; course instructor for the week 1 check	R30 and the full-tool phase. Not needed for copy and paste (R29), which works in any AI account.
Gemini skills available in the district’s education accounts, including sharing a skill with a class	Google, for the announced rollout; district Workspace administrators for any setting that controls it	R30. Skills cannot be tested until this is in place.
The Google Apps Script web app and the Google Sheet that receives the employer rows, moved from a personal account to a department account	Academic department	R7 and the section 8 success condition on endpoint ownership
A decision on whether Career Services manages the Google Sheet or receives a report, and ongoing feedback on whether the rows are usable	Career Services office	R7 and the section 8 success condition on employer data
Static hosting on GitHub Pages, with a move to a district GitHub organization as a post-pilot option	Product owner now; district IT after the move	All requirements; the move is not required for the pilot
Canvas submissions for all graded work	College learning management system administrators and the course instructor	Grading outside Render, which lets R26 hold
Big Interview access for video interview practice	The college office that holds the Big Interview license	Interview practice alongside R15 and R16
District approval of where student work is stored, and a backend owned by the district or the department	District information technology, with the academic department	The handle and PIN sign-in planned for the next version (R28). Not needed for the pilot.
A FERPA agreement	District	Any future full cloud sync on district infrastructure or a school server

7. Pilot and testing

Usability testing ran with 4 students, using think-aloud sessions on the core flows: setting goals on day one, saving a real job, running the gap analysis, and tailoring an application against hand-written base materials. Career Services has been consulted on whether the anonymous employer rows are useful for building internship pipelines.

The dashboard and the Agent Workshop have both been tested end to end with invented students.

Render is written into the AVC 248 course competencies, so the pilot is not an add-on. The full-tool phase is one full semester in the capstone, week 1 through the week 15 capstone export.

What the pilot measures: whether students complete the AI literacy unit before the Tailor flow unlocks, whether the base materials rule holds, whether saved job entries accumulate enough data for the capstone gap analysis to be meaningful, whether the exported dashboard works on a student device after the semester ends, and whether Career Services receives usable employer data.

7.1 How the pilot runs, step by step

A pilot is not “try it and see.” It is a small, bounded test with the questions and the yardstick set before any student starts, so the result can actually be trusted. This is the sequence, and it is the same shape every tool in this portfolio uses.

1. Frame the question first. Name the one or two things the pilot has to answer (here: does the environment produce a real, populated career plan a student keeps, and does the base-materials-plus-review structure keep students from submitting first AI drafts). Everything measured traces back to a question; anything that does not is noise.
2. Set a baseline. Decide what “better” is measured against before the semester starts. For Render that is the prior norm: students finishing the capstone with a portfolio and no plan, and no artifact after Canvas closes. A short start-of-term readiness self-rating gives a pre-point to compare the exit against.
3. Choose the cohort and get consent. The AVC 248 capstone sections are the whole pilot. Students are told at entry what is collected (no name, and anonymous employer rows to Career Services) and why, which is the consent step, not a checkbox afterward.
4. Instrument lightly, at fixed checkpoints. Because the tool stores no telemetry by design, evidence comes from three planned touchpoints: setup (week 1 to 2), midpoint (week 8), and the capstone (week 15). At each, capture a short survey plus a look at the actual artifacts (saved jobs, hand-written base materials, the export). Measure the behaviors from 7, not satisfaction.
5. Run one full semester without moving the target. Fix only what is broken during the run; save redesign ideas for after. Changing the intervention mid-pilot means you can no longer tell what produced the result.
6. Analyze against the baseline, then decide keep, iterate, or kill. Compare exit evidence to the baseline and the success thresholds in section 8. Be willing to conclude it did not work: if students will not maintain the environment or the base-materials rule collapses in practice, that is a finding, not a failure, and it changes the next build.

8. Definition of success

Version 1.0 means Render has passed its first full-tool semester, which requires all of the following.

• Students finish with a populated environment: real goals, a real reach job, real saved jobs, hand-written base materials, and a capstone export.
• The exported dashboard and career agent open and run on a student device after Canvas access ends.
• Students report the tool told them what to do next rather than handing them a blank prompt.
• The base materials rule and the critical AI review checklist hold in practice, so no student submits a first AI draft.
• Career Services can act on the anonymous employer data, with at least one employer relationship or internship conversation traceable to it.
• No name is stored, and nothing identifying reaches AI or the Google Sheet.
• The Career Services endpoint is owned by a department account.
• Every AI step runs as a Gemini skill in the student’s own account, with copy and paste kept as the fallback, and each skill has been tested against the copy-and-paste result.

Anything short of that keeps the tool labeled a pilot.

9. Rollout

1. Phase 1, pilot in phases. Pilot with capstone students by copy and paste, starting with resume alignment. Write the Gemini skills as skills reach education accounts. Move the Apps Script endpoint to a department account.
2. Phase 2, full tool on Gemini skills. Starts once the district turns on Gemini for student accounts. Test each skill in Gemini, share the skills with the class, and run the full tool for one semester in the AVC 248 capstone, with feedback at the midpoint and at the capstone.
3. Phase 3, revision. Fix what the semester exposed, then decide what wider use needs.
4. After that, expansion inside the college. Offer Render to the other digital media programs, then to other career-oriented programs at the college. The architecture is already program-agnostic.
5. Beyond, district conversation. Bring a tested tool with real semester data to the district, and extend it beyond digital media to other disciplines whose students enter the workforce (business, information technology, allied health, trades and career-technical programs, and the liberal arts), rather than pitching an untested one.

Out of scope

• Render does not call an AI model itself; there is no shared key, no district proxy and no institutional AI account.
• Render does not run the job search on a schedule; an automated weekly feed needs a server-side worker and is not part of this version.
• Render does not write the student’s first resume or first cover letter; both are written by hand with no AI and no template.
• Render does not generate the design deliverables in the course competencies, such as the business card, identity package and leave-behind.
• Render does not handle grading; grading runs through Canvas submissions and there is no instructor view of class-wide progress.
• Render does not send student names or student IDs to Career Services, and it stores no telemetry.
• Google Drive auto-sync, the industry news feed, district Google sign-in and district-wide deployment are post-pilot work.
• The freelance version of each agent and the elevator pitch, LinkedIn profile and contract skills are not in the current build.
• A direct connection between Render and the student’s Google account, so a skill could read from or write to Render, is not part of this version; it needs a Google Cloud project owned and approved by the district.

10. Open questions and risks

Question or risk	Priority	Notes
When does the district turn on Gemini for student accounts?	High	A district decision, outside this project. Until it does, the pilot runs on copy and paste and the skills wait.
Do Gemini skills behave in education accounts the way Google describes, including sharing a skill with a class?	High	Cannot be tested until the rollout reaches the district. Copy and paste stays in the tool as the fallback either way.
Does a result need to come back into Render, or can it live in Gemini?	Medium	A skill cannot write to the student’s browser. Steps whose result Render keeps (the job-match read, the gap list) still need a paste back. A direct connection needs a district-owned Google Cloud project.
Do all students have working Gemini access on day one?	High	Verified in week 1 alongside the other tool logins, the same way every other platform in the course is checked.
Consistency of output when every student runs the prompt in their own account.	Medium	Prompts are written to be self-contained, so results vary in wording rather than in structure. Worth watching across the pilot.
Model dependence. About twenty AI steps depend on one kind of tool.	Medium	Prompts are model-agnostic and run in any capable AI tool, so a student on a different tool is not blocked.
Should the tool be shared across the district or stay college-specific?	Medium	The architecture is already abstracted. District deployment is viable after the pilot.
Does Career Services want to manage the Google Sheet, or just receive a report?	Medium	Determines how the pipeline is structured and whether notifications are needed.
Should there be an instructor view showing class-wide progress?	Low	Useful for grading, but it would require explicit student consent for FERPA compliance.

Questions to settle before the next build

1. Which steps beyond resume alignment have capstone students opened in the pilot, and which are tested only with invented students?
2. Does the Tailor flow still return AI-written drafts of the resume and cover letter, or does the hand-written rule in section 2.5 now govern, and how does Render know the AI literacy unit is complete so it can unlock the flow?
3. For interview practice, how many questions of each type does a job get, what does it mean for a student to clear the committee before the interview, and does the dashboard interview prep with general questions and the question and answer log remain?
4. What does the pilot export contain and in what form: one zip or separate downloads from the dashboard and the workshop, and are the spreadsheet tracker, PDF documents and JSON export all required?

11. Roadmap

Milestone	Target	Notes
Full tool built	Done	Profile, goals, search strings, job and client log, resume vault, skills and professional development, networking, interview prep, launch plan, the Tailor flow, the base materials rule, the critical AI review checklist, references sheet, online presence audit, salary research, Diagnose Your Search, and the export with 4 themes.
Usability testing	Done	4 students. Career Services feedback ongoing.
Phase 1: pilot in phases	Now	Capstone students, starting with resume alignment. Every AI step runs through the AI bridge by copy and paste.
Gemini skills	Phase 1 into Phase 2	In progress. One skill per AI step and per agent, written in Google’s skill file format, tested once skills reach the district’s education accounts.
Phase 2: full tool on Gemini skills	Once student Gemini accounts are on	First full-tool semester in AVC 248. Department-owned Apps Script endpoint in place first.
Agents and skills build	Phase 1 onward	The Agent Workshop (section 4.9) covers the four agents and the download package. Joined to the dashboard: it reads the goal, resume and saved jobs (section 4.10). Still to build: reading the remaining panels, the added skills in 4.8, and the master-resume model.
Google Drive auto-sync	Post-pilot	Cross-device data transfer without manual export and import.
Industry news feed	Post-pilot	Curated RSS per program track, roughly 8 to 12 sources each, using the Cultivate architecture.
District adaptation	Post-pilot	Deployment across the district, starting with digital media programs and extending to other disciplines that prepare students for work, business, information technology, allied health, trades and career-technical programs, and the liberal arts, since career readiness and the no-PII design are program-agnostic.

Key references

• Render tool: singletrackmom.github.io/render/
• Render overview: singletrackmom.github.io/render/overview.html
• Training Plan Agent: singletrackmom.github.io/render/training-plan-agent.html
• Sample exported dashboard: singletrackmom.github.io/render/sample-dashboard.html
• AVC 248 course site: singletrackmom.github.io/canvas/avc248/
• Big Interview: www.biginterview.com
• Career Services: gccaz.edu/student-life/career-services