It helps you turn the things you’ve done into checked notes you can reuse for applications and interviews.
After that, the same records feed role research, applications and interview practice, so you stop re-remembering your own history every time.
A set of notes on your experiences, each checked against what you actually remember.
Nobody reads a guide like this cover to cover. This page is the version for people who won’t, and it tells you exactly where to dip in.
Read page 2, then Bear’s journey (page 23) and the two interview cards (page 31 and page 32). That’s what the method produces.
Work through Stages 1 to 4 with one experience, pages 9 to 15. You finish with one checked record you can reuse.
Jump straight in. Open a new AI chat, attach the prompt pack and paste Prompt 1 from page 9. Have your CV handy if you want to use it.
Prompt pack: leviathan3307.github.io/frog-framework/Frog_framework_prompt_pack.md
Reading on a phone? Web version, with one-tap copy for every prompt: leviathan3307.github.io/frog-framework
Everything is clickable. The bar in the top-right corner of every page shows which stage you’re on, and you can jump from it too.
Reading the bar. Numbers 1 to 4 build your records. Letters A to D use them. Black means done, yellow is where you are.
Bear is the fictional applicant you’ll follow through every stage. Two of Bear’s experiences get the full treatment, so you can see the method work on very different material.
Bear is a postgraduate with an earlier analyst job and a recent group project at university. Bear is weighing up operations, business analysis and consulting, and opens with this:
“I have some analyst experience and a group project, but I don’t know which things are worth mentioning.”
Most people start here. The experiences exist, but on a CV they shrink to one line each, and those lines don’t tell an interviewer what you actually decided or did.
“Helped automate a monthly reporting process.”
“Completed a university group project analysing several companies.”
Short Bear notes run through the instructions. The full story, start to finish, is the case study in Part 4 (page 22).
An evidence bank is a set of notes on your experiences, each checked against what you actually remember.
Every application asks you to reflect again: a CV bullet, a cover letter, a motivation answer, a competency question. Without a record, you rebuild the story from memory each time and it drifts, usually towards sounding bigger than it was.
A record lets you do the hard remembering once, check it once and reuse it everywhere. It also keeps the honest limits attached, so an estimate stays an estimate when you’re nervous in an interview.
Bear’s E02 is a university assignment with no number attached, and it still makes a strong story. Coursework, internships, part-time jobs, volunteering and society roles all work.
You don’t need a performance number. You need a moment where you made a decision.
Bear isn’t a real person or test participant. The stories are invented illustrations based on how this method works in practice. Nothing in them is a measured result of using the guide.
Ten minutes of setup saves you rewriting the same story in three different chats.
Don’t paste confidential employer or client documents, private customer records, other people’s personal details or anything under a confidentiality agreement. Describe the decision and your part in it in general terms instead. Bear’s E01 uses synthetic (made-up, not real customer data) test cases for exactly this reason. Check your AI tool’s privacy and data settings before you start.
Any mainstream chat assistant can run these prompts. Some can create files you can download; many can only show text in the conversation.
Every prompt in this guide covers both cases. If the AI can’t make a real file, it returns the complete text and you save it yourself. If it says it has saved something and you can’t open or download it, treat it as not saved.
Attach the prompt pack to your first message so the AI uses the same file structure. Get it at leviathan3307.github.io/frog-framework/Frog_framework_prompt_pack.md, or paste its text into the chat.
If your AI has a voice mode, answering aloud often brings back detail that typing doesn’t. Read the transcript before you accept it, because speech-to-text gets names and numbers wrong.
Read the headline, the grey intro line under it, and the prompt. That’s enough to do each stage.
One index, one record per experience and a few task notes. You keep the files. The AI only borrows them.
IDs never change. E02 is always E02, even if you later add something older.
| Same chat | New chat | |
|---|---|---|
| Files you attached earlier | Usually still there, but ask for the current version before relying on it in a long chat | Gone. Attach them again |
| What you said earlier | Available | Gone. That’s why the records exist |
| Always attach | Career_bank.md, the prompt pack and the record you’re working on. For A to D, also the relevant note and the job description | |
If you didn’t say it, it doesn’t go in the record. The interview, the check and the approval step all exist to protect that.
A CV lists what you held. This part gets you a direction and a list of experiences worth exploring, before you write a single answer.
Two CV lines and a vague sense that operations, business analysis or consulting might fit.
Stage 1 of 4
Say which roles you’re curious about, or admit you aren’t sure. Both give the AI something to work with.
The AI asks up to five questions, one at a time, then writes a short direction note split into what you’ve confirmed, what’s possible and what’s still open.
I’m using the Frog framework to explore my experiences before making career decisions. The goal is a short, honest direction note, not a career diagnosis. If I attach Career_bank.md or my CV, read them first, and treat the CV as incomplete context rather than proof of what I did. Ask me up to five questions, one at a time, about roles I’m considering, what interests me and any constraints I choose to share. I may be unsure, and that is a valid answer. Do not infer my personality or abilities from my degree, CV or job titles. Create or update Career_bank.md. If I attach the Frog templates, follow them. Otherwise keep these sections in this order: Version and Approval lines, Direction note (Confirmed, Possible, Open), Experience index, Next actions, Change history. Raise the version number each time the file changes. Show me the note and ask me to approve or correct it. If you cannot create or edit files, return the complete Career_bank.md as Markdown for me to save, and do not say it has been saved. Finish by suggesting the next step: listing my experiences.
“I have some analyst experience and a group project, but I don’t know which things are worth mentioning. I’m considering operations, business analysis and consulting.”
The AI doesn’t push Bear to pick one. Uncertainty goes in the note as an open question.
Stage 2 of 4
List short headings, not impressive stories. Your best example might not be on your CV at all.
Think across coursework, jobs, part-time work, internships, volunteering, society roles, side projects and moments you changed direction. The AI walks back through your timeline, most recent first, then asks about gaps one area at a time. Once the list is complete, each heading gets an ID that never changes (E01, E02 and so on). Nothing detailed is written yet.
Read my latest Career_bank.md and, if I have chosen to share it, my CV. Help me list short experience headings across coursework, jobs, part-time work, internships, volunteering, society roles, personal projects and changes of direction. Start by walking backwards through my timeline, most recent first, one period at a time, then ask about gaps one area at a time. Do not invent experiences, and use only headings I confirm. Give each heading a stable ID (E01, E02 and so on) in rough chronological order, and never renumber existing IDs. For each one, add the status Heading only and one useful question to explore later. Do not create detailed experience files yet. Once all the headings are listed, update the Experience index in Career_bank.md, show me the changes for approval and only then ask which experience I want to explore first. If you cannot edit files, return the complete current Career_bank.md as Markdown for me to save.
“Volunteering and events” is enough for now. Three to six headings is a good first list.
| ID | Heading | Record | Status |
|---|---|---|---|
| E01 | Monthly exception-processing improvement (employment) | E01_monthly_process.md | Heading only |
| E02 | Comparative company analysis (group assignment) | E02_group_analysis.md | Heading only |
| E03 | Student volunteering and events | None yet | Heading only |
This is where the method earns its keep. An AI chat interviews you about one experience until the real decisions surface, then you check the write-up against what you actually said.
A direction note and three headings. E01 and E02 are listed but not explored.
Stage 3 of 4
Pick one experience and let the AI question you until you can say exactly what you did, what you decided and what you can back up.
This is a conversation, not a form. The AI asks one focused question, waits and follows your answer. When something is vague, it asks for a specific moment. When you give a number, it asks where the number came from. It won’t write polished interview answers yet, because the evidence isn’t checked.
I’m using Frog to explore one experience before deciding which career and interview stories it can support. Read the latest Career_bank.md, my CV if supplied and the latest record for [E##], if one exists. The experience I want to explore is [heading].
Start with what actually happened and what I personally did. Ask one focused question at a time, wait for my answer and probe the parts that remain vague. Follow the evidence, not a fixed STAR template. Ask about a particular decision or disagreement, the alternatives I saw, my responsibilities versus other people’s, what changed, what I can substantiate and what I still do not know. If I mention a number, ask what it measures, the period, the source and whether it is observed, reported or estimated. If I have no number, do not invent or require one. Let me say ‘skip’, ‘not sure’ or ‘pause’. If I correct something you said, follow my correction.
Create or update one detailed record named [E##]_short_name.md, marked Draft for review. Start it with Version, Approval and Privacy lines, following the record template if I attach it, and raise the version each time it changes. Keep the chronology, dates if known, my actions separately from others’, evidence strength, open questions and corrections. Update its status in Career_bank.md and show me the material changes. Do not write polished interview answers yet. If you cannot edit files, return the complete current Markdown for both files for me to save.
Stage 4 of 4
The risky moment isn’t the conversation. It’s when a confident summary reads well and you approve it without noticing it says more than you did.
Before you approve a record, ask the AI to check it line by line. It has to find the exact answer behind each claim and put each one in a category. It should flag stretched wording itself, not wait for you to spot it.
Audit the current [E##_short_name.md] line by line before I approve it. Read it alongside our conversation and any documents I supplied. For each ownership claim, outcome, figure, causal claim, tool and motivation, quote the exact answer or document that supports it. Classify each as directly supported, self-reported, estimated, interpretation or unsupported. Flag wording that makes a team result mine alone, turns an estimate into a realised result or widens the scope beyond what I described, even if I have not questioned it. Show the risky wording beside a narrower alternative and ask me to resolve each uncertainty. Do not quietly substitute your interpretation for my memory, and keep anything we cannot resolve visible as an open question. Show the full audit in the chat. In the record, keep only the corrected wording, open questions, a one-line change history entry and a short evidence list: one line per kept claim giving its category and where it came from, such as ‘my answer in this session’ with the date, or a document name and section. Return the updated draft. Mark it Approved, in the record and in Career_bank.md, only when I confirm. If you cannot edit files, return complete current Markdown for both files.
Stage 4, final step
Only now, with an approved record, does the AI write answers. It adds them inside the same file so the evidence and the answer travel together.
The card is a short navigation section at the bottom of the record. It tells you which questions the story can answer, how to start it and where its limits are.
First check the record’s Approval line. If it is not Approved, stop and tell me to finish Prompt 4 before building the card. Using my approved [E##_short_name.md], prepare a compact interview-navigation section inside that same record. Include a memory cue, four to six interview questions this evidence can genuinely answer, a natural 30-second summary, a natural 60-second answer, three to five likely follow-up probes and any source limits I must remember. Write the answers in plain spoken English I would actually say, not a polished script. Use only confirmed or explicitly qualified evidence, and do not force the story into a role or question where it does not fit. Show the new wording to me for approval, then update this record and the Career_bank.md index. If files cannot be updated, return complete current Markdown for both.
| ID | Heading | Record | Status |
|---|---|---|---|
| E01 | Monthly exception-processing improvement (employment) | E01_monthly_process.md | Approved |
| E02 | Comparative company analysis (group assignment) | E02_group_analysis.md | Approved |
| E03 | Student volunteering and events | None yet | Heading only |
Stage 4, any session
A new chat remembers nothing from the last one. Your files remember everything, as long as you take them with you.
End every session with a handover, even a short one. It forces the AI to give you the complete current files and to say what’s still unresolved. Start the next session with the resume prompt and the files attached.
We’re ending this session. Create a handover from the latest documents. List every file that changed, its current version and approval status, unresolved questions and the next recommended action. Ask me to check any material factual change before it is finalised. Then return the complete current Career_bank.md and every experience, role, application or interview file touched in this session. If you can create real downloadable files, do so and tell me exactly which ones exist. Otherwise supply complete Markdown under each filename and tell me which files to save. Do not assume the next chat will remember this one.
I’m continuing Frog framework work in a new chat. Read the attached latest Career_bank.md and [E##_short_name.md]. Do not assume you have any file I have not attached, or that you remember earlier chats. Summarise the experience’s current version and approval status, the last approved changes and the most useful next question, then ask it. Ask one question at a time. Keep confirmed facts unless I correct them, and mark new material as Draft for review. When I say ‘save this session’, prepare complete updated versions with changes and approval status. Create files only if your tools genuinely support it; otherwise return complete Markdown for me to save.
Replace the old file with the new one each time, rather than keeping both. If you do end up with two, ask the AI to compare them and list the differences, decide which is right and save one.
Copy the complete Markdown the AI returns into a text file named exactly as shown. Once per session is enough.
The records are the groundwork. Now put them to work. Pick the use you need today and skip the rest.
Two approved records, each with an interview card. Neither has been used for a real application yet.
Use A
Put your approved records next to a real job description. The AI separates what you’ve shown from what the role demands, and keeps formal requirements out of the guesswork.
Help me investigate [role A] and [role B]. Read Career_bank.md, my approved experience records, my CV if I provide it and the current official job descriptions I paste in. For each role, separate confirmed interests, demonstrated evidence (cite the experience ID), transferable examples, hard requirements such as qualifications or eligibility, unknowns and gaps. Do not treat an attractive story as proof that I meet a formal requirement, and do not diagnose my personality or suitability. Ask me up to three questions where my preferences are unclear. Create or update Role_note.md with a short comparison and the questions I should investigate next, and show it to me for approval. If you cannot edit files, return the complete Role_note.md as Markdown.
Illustrative role with hypothetical requirements, not a real vacancy.
A strong example doesn’t meet a hard requirement like a qualification, a visa condition or a specific skill test. The note lists those separately.
E01 is the stronger match for a business-analyst role. For a consulting role, E02 shows the structured analysis, but it was a course project, not client work. The note says so.
Use B
Start from the job description, your own draft and your approved records. Everything the AI suggests is material for you to decide on.
I want to improve my own [CV bullet, cover letter or application answer] for [role and employer]. Read my draft, the official job description, Career_bank.md and the relevant approved experience records, plus my CV if supplied. Map the vacancy’s actual requirements to evidence IDs. Suggest specific changes and explain each one, and ask me for my genuine motivation and any missing facts rather than inventing them. Do not introduce metrics, tools, tenure, scope or ownership the records do not support, and keep estimates labelled as estimates. I will review, revise and control the final wording. Remind me to follow the employer’s rules on AI use. Create or update Application_note.md with the requirement map and the edits I choose. If you cannot edit files, return the complete Markdown. Do not apply on my behalf.
The AI can ask why you want this role, but it can’t know. Bear’s reason, liking to make scattered evidence comparable, came from Bear’s own reflection on E02.
Use C
Preparing for the stage you actually have beats rehearsing a generic list. Start from the invitation and the employer’s own pages.
Help me prepare for [employer, role, interview stage, date]. Read the invitation, the official role description, my CV if supplied, Career_bank.md and my approved records. Tell me what is known about this stage and what is uncertain. Use current first-party employer information for factual claims and treat candidate forums as unverified practice leads. Create Interview_plan.md covering motivation and CV walkthrough questions, likely behavioural questions with the experience IDs that can answer them, gaps where I have no strong story yet, and case, technical or group tasks only if relevant. Include a short priority list and preparation plan. Do not invent official interview questions or scoring. Show the plan for my approval, and if you cannot edit files, return the complete Markdown.
Motivation, knowledge of the role and your CV walkthrough need their own preparation. So do case, technical or group tasks if the employer uses them.
Bear will use E01 for process and stakeholder questions and E02 for teamwork and feedback. Using the same story for everything is a common way to sound rehearsed.
Illustrative: a competency interview for an analyst role. No real employer.
Use D
A record is reference material, not a script. The real test is what you can explain naturally when someone pushes back.
Act as a practice interviewer for [role and stage]. Read Interview_plan.md, the job description, my CV if supplied and my approved experience records. Ask one realistic question at a time and wait for my spoken or typed reply. After each answer, give specific feedback on clarity, reasoning, my actual ownership, accuracy against the record and whether I answered the question. Tell me if I claimed more than the record supports. Ask one follow-up probe on the weakest point, then let me retry once. Record gaps you observed and any new details I confirm in Interview_plan.md, and change a story record only after I approve a new fact. Never invent official scores. If you cannot edit files, return the complete Markdown at the end.
The inflated version comes back when you’re nervous. Practising with a checker is how the honest version becomes the one you say by default.
Speaking shows awkward pacing and missing steps that typing hides. Check transcripts before treating them as evidence.
Want to see the whole thing done properly? Follow Bear from a vague CV line to two interview-ready stories, stage by stage.
Read it straight through, or jump to the stage you’re stuck on. Every page here matches a stage you’ve already seen.
Case study overview
From two flat CV lines to two stories Bear can use for different questions. Each step left a file behind, and each one links to the page where it happens.
Unsure what’s worth mentioning. Considering operations, business analysis and consulting.
“Helped automate” became a rule mismatch, three synthetic test cases, a shared decision and a team estimate.
“Group project” became mismatched definitions, a reference sheet and a team conclusion.
“Led”, “company-wide”, “eliminated errors” and “consulting” removed. The estimate stays labelled.
Questions each story can answer, memory cues, 30 and 60-second answers, follow-ups.
A role comparison, two CV bullets, an interview plan with a gap to fix, and a mock with feedback.
Stage 3, worked example
A work example. Watch the CV line turn into a decision, and watch the AI get something wrong.
Stage 3, worked example
The AI follows the disagreement, the evidence and the number, and leaves gaps as gaps.
Stage 3, worked example
A university example, and shorter. No job, no client and no number, and it’s still a real story.
Stage 3, result
Same person, same two experiences. The difference is detail Bear can stand behind.
“Helped automate a monthly reporting process.”
“Completed a university group project analysing several companies.”
| ID | Heading | Record | Status |
|---|---|---|---|
| E01 | Monthly exception-processing improvement (employment) | E01_monthly_process.md | Draft for review |
| E02 | Comparative company analysis (group assignment) | E02_group_analysis.md | Draft for review |
| E03 | Student volunteering and events | None yet | Heading only |
Stage 4, worked example
The draft record suggested a CV line. It sounds great, and three of its four claims fail the check.
Led a company-wide automation programme, eliminated processing errors and saved six hours every month.
| Wording in the draft | What Bear actually said | Category | Keep as |
|---|---|---|---|
| Led | “My lead suggested reducing the manual work with me … My lead and a senior colleague agreed the scope.” | Unsupported | Helped develop and test |
| a company-wide automation programme | Bear described one monthly process in one team. | Unsupported | an updated monthly exception-checking routine |
| eliminated processing errors | Nothing. Error rates are listed as unknown in the record. | Unsupported | Remove |
| saved six hours every month | “The team estimated ten hours … about four hours … We did not independently measure a consistent six-hour saving.” | Estimated | a team planning estimate suggested around six staff hours |
| after identifying a rule mismatch (added) | “I … found three test cases where the classifications no longer lined up.” | Self-reported | Keep |
Helped develop and test an updated monthly exception-checking routine after identifying a rule mismatch; a team planning estimate suggested around six staff hours of monthly work could be reduced.
“The record lists error rates as unknown. Do you have anything that shows errors went down? If not, I’ll remove ‘eliminated processing errors’.” Bear had nothing, so it went.
In a spoken answer, Bear explains the collaboration and calls the figure an estimate when asked about it.
Stage 4, worked example
A university project gets inflated too. Here the AI turned a course assignment into consulting, and added a personality reading for good measure.
Led a four-person strategy consulting team to transform four companies’ investment plans.
| Wording in the draft | What Bear actually said | Category | Keep as |
|---|---|---|---|
| Led a four-person … team | “Each student researched one company. I made the shared comparison workbook …” | Unsupported | Built the common analysis workbook and ratio definitions |
| strategy consulting | “No, it was a course assignment.” | Unsupported | a four-person comparative assignment |
| to transform four companies’ investment plans | “I don’t have a measured business outcome.” | Unsupported | Remove |
| completed one company’s analysis (added) | “… completed the research on my assigned company.” | Self-reported | Keep |
| Reflection: “Bear is a natural leader.” | Nothing. Bear never described leading the group. | Interpretation | Remove. Use Bear’s own reflection instead |
Built the common analysis workbook and ratio definitions for a four-person comparative assignment, completed one company’s analysis and helped integrate the group’s presentation.
Personality labels, invented scope and “transformed” outcomes slip into drafts because they sound like CV language. Prompt 4 tells the AI to flag them before you’re asked to approve.
Stage 4, worked example
Here’s E01 itself, not just the CV line. The changes are small, and they’re what make the story safe to tell.
Struck through removed in the check. Marked added or narrowed.
It means Bear checked every line against what Bear remembers and said so. It doesn’t mean anyone else has verified it. E02 went through the same check and is also at v0.2, Approved.
Each month a team worked through recurring exceptions with spreadsheet checks and database extracts. Before automating, Bear questioned whether the inherited rules still matched an updated category definition.
Compared the current procedure with the old logic; prepared three synthetic boundary cases; took them to the senior colleague; built and tested the revised routine; added an exception log for reviewers.
Others: Lead supported scoping and approval. The senior colleague agreed the revised rule. Others owned quality assurance and release sign-off.
Handed over for monthly use after testing. Team planning estimate: about 10 staff hours a month before, about 4 after, so around 6 a month. Estimated, not measured after release. No audited baseline.
“At a previous analyst job, I worked on a monthly process that involved a lot of repeat checking. When we considered automating it, I noticed that some of the old rules no longer matched an updated procedure. I brought a few test cases to the senior colleague who owned the original checks, and we agreed the revised logic. I built and tested the routine and added exception logging. What I learnt was to check whether a process still makes sense before making it faster.”
“In an analyst role, our team spent time every month working through recurring exceptions using spreadsheets and database extracts. My lead and I discussed automating the repetitive checks. As I compared the existing logic with the current procedure, I found a category change that the original checks did not fully cover. I made three synthetic test cases to show the difference and went through them with the senior colleague who maintained the old process. We agreed the correct handling before I wrote the revised routine. I tested the normal and boundary cases, added exception logging for the reviewers and handed it over for the team’s release checks. Our planning estimate suggested a reduction of around six staff hours per month, although we hadn’t measured consistent post-release savings. The useful lesson for me was that automation starts with understanding the process, not copying it.”
For a pure teamwork question, E02 is the better choice.
Four students compared four consumer-goods companies from public reports for a management module. Early ratios used different definitions and periods, so the first chart looked comparable but wasn’t.
Owned the shared comparison workbook; built a reference sheet with each ratio’s definition, source and financial period; asked teammates to check their inputs; analysed one assigned company.
Others: Each teammate analysed one company. The conclusion and presentation were developed jointly, and the team changed Bear’s over-absolute closing line.
Assignment completed and presented. Lecturer feedback: state the central conclusion earlier. No grade, client or business outcome recorded.
“In a four-person university project, we compared four consumer-goods companies. I built the common workbook and realised our initial ratios weren’t comparable because we had used different definitions and reporting periods. I made a reference sheet, checked the inputs with the others and completed my assigned company analysis. We then developed the conclusion together. It showed me how much the quality of a recommendation depends on agreeing what the numbers actually mean.”
“For a management assignment, my group of four had to compare the performance of several consumer-goods companies. We divided the initial research, but when we brought it together I spotted that our ratios used different reporting periods and definitions. I owned the common workbook, so I built a reference sheet recording each ratio’s formula and source, and worked with the others to make the comparisons consistent. I also completed the analysis for my assigned company. During the presentation preparation, the team challenged a conclusion I’d suggested because it sounded too absolute, so we changed the wording without losing the evidence. We delivered the presentation, and the lecturer’s main feedback was that we should have stated the conclusion earlier. I learnt to check comparability before drawing a conclusion, and to explain it in language the audience can use.”
For a question about working with someone senior, E01 fits better.
The usual snags, and what to do about each one.
Paste these into your first chat if your AI doesn’t create the files itself. The same text is in the Markdown prompt pack.
# Career bank Version: v0.1 Approval: Draft for review Privacy: Private by default ## Direction note Confirmed: Possible: Open: ## Experience index | ID | Heading | Record | Status | Useful question | | --- | --- | --- | --- | --- | | E01 | | E01_short_name.md | Heading only | | ## Next actions - ## Change history - v0.1:
Statuses: Heading only, In progress, Draft for review, Approved.
# E01: [Exact title] Version: v0.1 Approval: Draft for review Privacy: Private by default Dates: [if known] ## Context and timeline Confirmed: Not remembered: ## My actions and decisions What I did: What others did: Key decision or disagreement: Alternatives considered: ## Outcomes and evidence Observed or reported: Estimated (how and by whom): Unknown: ## Evidence list (one line per kept claim) - [claim] | [category] | [source] ## Reflection What I learnt, in my words: ## Open questions - ## Privacy boundaries Keep private: Never include: real client names, private records, confidential documents ## Interview navigation (added after approval) Memory cue: Questions it can answer: 30-second answer: 60-second answer: Likely follow-ups: Source limits to remember: ## Change history - v0.1:
About this guide
Frog comes from how I prepared for my own career applications. I used an extended form of this process to go back through my experiences, build a detailed story bank and prepare for several different types of interview. The questioning turned up decisions and examples my CV had flattened into one line.
This public guide is a portable version for you to try and adapt. It’s a method, not a promise. It hasn’t been independently tested, and it doesn’t guarantee interviews or offers.
Bear and both of Bear’s stories are fictional. The organisations are unnamed and the figures are invented for illustration.
Keep your latest approved files somewhere safe, and bring them to every new chat.
Kushagra Gupta
© 2026 Kushagra Gupta. All rights reserved. You’re welcome to use this guide and copy or adapt the prompts and templates for your own career preparation, and to share the link. Please don’t republish, host, sell or build this guide, its design or its prompts into a website, product or course without written permission.
Web version: leviathan3307.github.io/frog-framework