Rollins CollegeCollege of Liberal Arts

SE 395-2: AI Tools for Social Impact

Lab 6

Project Plan Creation. Your proposal said what to build. Now create the plan for how. Interview, generate, audit, finalize. Four people, one plan, 75 minutes.

"We ought to be more ambitious. Not because the models demand it. Because we are the bottleneck."

Felix Rieseberg, Anthropic

Student Access

Token provided in class or on Canvas.

Professor Meirelles van Vliet

Fall 2026 · T/R 3:30-4:45 PM · KWR 310

SE 395-2
06

Week 10 · Thursday · AI Lab

Project Plan Creation

Your proposal said what you would build. Now create the plan for how you build it. By the end of today, your team has a project plan you can start executing next week.

Time
75 minutes in class
Tools
Claude (Code tab) or ChatGPT (Codex) + Team Workspace
Output
project-plan.md pushed to GitHub

Start Here

This lab has five steps. You will spend most of class working in the Team Workspace tab above. The workspace walks you through each step, saves your work, and generates prompts for you. Read the overview below first (3 minutes), then switch to the Team Workspace tab and go.

Overview

What This Lab Is For

Your proposal described what you would build and why. A proposal is not a project plan. A proposal says "we will build an AI-powered grant research tool." A project plan says "Task 1: build the keyword extraction prompt. Inputs: sample grant listing. Acceptance criteria: extracts at least 5 relevant keywords. Estimated time: 2 hours."

Today you create that project plan: interview, generate, audit. All four team members work in parallel. The plan you leave with today is the one you start executing next week.

"Do not start by listing features. Give AI a one-sentence description of what you are building. Let it ask you questions. Five minutes of back and forth gives AI more clarity than a two-page spec."

From Tuesday's slides: Building a Project Plan with AI
Upload your proposal and slides. Before you start the interview, upload your project proposal document and any presentation slides directly into the AI conversation. AI can read these files and extract the details, which makes the questions it asks you far more relevant than if you just describe things from memory. The proposal is the input. The project plan is the output. Start by giving AI everything you have.
Use the right tool. If you are using Claude, use the Code tab inside the Claude app (claude.ai). If you are using ChatGPT, use Codex (inside the ChatGPT app). These modes create artifacts — documents that live alongside the conversation — so you can see each version of your plan as a separate file. Do not use the plain chatbot interface. Every prompt in this lab tells AI to save its output as an artifact. This means you will have a clear trail of documents: your interview plan, the council evaluation, the unified plan, and your audit findings. Each one is a file you can download, paste into the workspace, and submit.
How You Work Today

Four People, One Plan

This lab is designed so all four team members are productive at the same time. Some steps are individual (everyone works in parallel with their own AI conversation). Some steps are team (you come together to merge and decide).

TimeStepMode
3:30 - 3:35Step 1: Align on scopeTeam (5 min)
3:35 - 3:55Step 2: AI interviewsIndividual parallel (20 min)
3:55 - 4:10Step 3: Council review and mergeTeam (15 min)
4:10 - 4:25Step 4: Parallel auditIndividual parallel (15 min)
4:25 - 4:40Step 5: Finalize and commitTeam (15 min)
4:40 - 4:45BufferCatch up or push to GitHub (5 min)
Use the Team Workspace tab. This lab has a live workspace where you can save your work at each step. Your teammates can see what you saved, and the workspace generates merge and audit prompts automatically. Click the "Team Workspace" tab above to get started.
The Exemplary Plan tab is reference material. You do not need to read it to complete the lab. If you get stuck on what a good interview or project plan looks like, skim it. Otherwise, go straight to the Team Workspace.

Ready? Switch to the Team Workspace tab now.

Everything below is reference. The workspace walks you through each step.

Reference: The Exercise

Five Steps (Detail)

1 Align on Scope

Team, 5 minutes. Before anyone opens an AI tool, answer three questions together:

  1. What is the first component from your proposal timeline? (Not the whole project. The first deliverable.)
  2. What does "done" look like for that component? How would your partner know it works?
  3. Who on your team owns which part?

Write these answers down. You will use them in Step 2.

Start smaller than you think. If your proposal says "Week 8-10: build the grant research tool," your first component is not the whole tool. It is the smallest piece that works on its own.

2 The AI Interview

Individual, 20 minutes. All team members work in parallel.

Each person opens their own AI conversation. Give it a one-sentence description of what your team is building. Then let AI interview you. Each team member takes a different angle:

The Builder

Focus on technical implementation. What tools, what architecture, what connects to what.

The Partner Advocate

Focus on the partner's needs. What would make them say "this is useful"?

The Skeptic

Focus on what could go wrong. What are the risks? Where does the plan break?

The Scoper

Focus on what is in and what is out. What is the MVP vs. the full vision?

Teams of 3: Each person picks one role. Then one person picks a second role and runs a second interview from that angle. All four perspectives must be covered.

Starting Prompt (same for everyone, then diverge by role)

I have attached our project proposal document and presentation slides. Read them first.

My team is building [one sentence describing your project] for [partner name]. We have [X weeks] left to build and deliver.

Interview me so we can create a detailed project plan. Ask me one question at a time. Wait for my answer before asking the next question. After 8-10 questions, generate a project plan with:

  • Tasks broken into subtasks
  • Build order and dependencies (what has to be done before what)
  • Acceptance criteria for each task (how do you know it is done)
  • Time estimates
  • Who owns each task

I am focusing on the [builder / partner needs / risks / scope] angle. Ask me questions from that perspective.

When you generate the plan, save it as an artifact called plan-interview-[your first name].md. Include a summary of the questions you asked and my answers at the top, followed by the full project plan.

Do not skip the interview. The temptation is to paste your proposal and say "make a project plan." That gives you a generic plan. The interview gives AI the context it needs to create a plan that actually fits your project.
After the interview: ask AI to save the full conversation as an artifact called interview-log-[your first name].md. Then upload both artifacts (the interview record and the generated plan) into the Team Workspace.

3 Council Review and Merge

Team, 15 minutes. Come back together. Each person shares the best question AI asked that you did not expect and the project plan AI generated.

This step has two phases. First, AI evaluates all the interview plans as a council of expert reviewers. Then your team reviews the council's recommendations and creates the unified plan.

Phase A: Council Review

One person pastes all interview plans into Claude with the council review prompt. AI spawns four reviewer agents that independently evaluate every task as KEEP, MODIFY, or CUT with justification.

Council Review Prompt

Here are project plans generated from different perspectives on the same project: technical build, partner needs, risks, and scope.

[Paste all plans here, or upload the plan artifacts generated by each student]

Act as a council of expert reviewers. Spawn the following agents and have each one independently evaluate the plans:

  1. Technical Reviewer - evaluates feasibility, architecture, and implementation quality
  2. Partner Advocate - evaluates alignment with partner needs and real-world usefulness
  3. Risk Analyst - evaluates risks, dependencies, and failure points
  4. Scope Guardian - evaluates whether each task fits the timeline and MVP definition

For every task or subtask that appears in any plan, the council must decide: KEEP, MODIFY, or CUT. For each decision, provide:

  • The task name and which plan(s) it came from
  • The council's recommendation (KEEP / MODIFY / CUT)
  • A one-sentence justification

Output the result as a structured evaluation. Save it as an artifact called council-evaluation.md. Do NOT produce a merged plan yet. Just produce the council's recommendations. My team will review these and make the final decisions.

Phase B: Team Review and Unified Plan

Read the council's evaluation together. Go through each recommendation. Agree or push back. Then tell AI to generate the final unified plan based on your decisions.

Unify Prompt

Here is the council evaluation of our project plans:

[Paste the council evaluation]

Our team has reviewed the recommendations. Here are our decisions: [list any disagreements or overrides]

Now generate a unified project-plan.md that incorporates these decisions. For each task include: task name, subtasks, dependencies, acceptance criteria, time estimate, and owner. Organize by build order. Format with checkboxes. Save it as an artifact called project-plan.md.

The council review is where judgment matters. AI evaluates each task independently from four angles. But your team makes the final call. Push back on any recommendation you disagree with before generating the unified plan.

4 Parallel Audit

Individual, 20 minutes. All team members work in parallel.

Take the unified project plan from Step 3 and audit it from different angles:

Audit A: Missing Tasks

What did we forget? What happens between tasks that nobody accounted for?

Audit B: Wrong Dependencies

Is the build order right? Are there tasks marked sequential that could run in parallel?

Audit C: Vague Criteria

For each acceptance criterion: could an outside observer tell if you hit it?

Audit D: Scope Creep

Is any task bigger than it looks? What can we cut without losing core value?

Teams of 3: One person runs two audit lenses. All four must be covered between the team.

Audit Prompt (adjust the focus line for your role)

Act as a senior project reviewer. Here is our project plan for an AI tool we are building for [partner name].

[Paste the unified project plan from Step 3, or upload the project-plan.md artifact]

Audit this plan for [missing tasks / wrong dependencies / vague acceptance criteria / scope creep]. Be specific. For each issue you find, name the task, explain the problem, and suggest a fix.

Do not rewrite the plan. Just list the problems and fixes. Save it as an artifact called audit-[your focus]-[your first name].md.

After the audit: ask AI to save the full audit conversation as an artifact called audit-log-[your first name].md. Then upload both artifacts (the audit record and the findings) into the Team Workspace.

5 Finalize and Commit

Team, 15 minutes. Come back together. Each person shares their audit findings. Go through the issues one by one: accept the fix and update the plan, or disagree and explain why.

Save as project-plan.md. One person downloads the team files ZIP from the workspace and uploads project-plan.md to your team's GitHub repo. Before you push, for each of the first three tasks, answer:

  1. What exactly do I build?
  2. What do I need before I can start?
  3. How do I know when it is done?

If you cannot answer all three for every task, the plan is not specific enough.

This plan is your compass for the rest of the semester. Every session starts by opening this file. Every build decision checks against it. If priorities shift, the plan shifts with you. But you always have a plan.
What Happens Next

This Plan Is Live Starting Today

The plan you leave with today is the one you start executing between now and next week. This is not a document you submit and forget. Open it tomorrow and start building.

Next Thursday's hands-on session is about removing blockers. You will come in with your plan open, show what you have built so far, and surface the issues, roadblocks, and challenges you ran into while executing it. We will work through those together in class.

On token limits. Most of you are using free or lower-tier AI plans. That is fine. Your project plan is a shared document. The moment one team member runs out of tokens, the next person picks up right where they left off and continues building. This is why the plan has clear task owners, acceptance criteria, and build order. Anyone on the team can read the plan, see what is next, and keep going. The plan is the continuity, not the AI account.
Deliverables

What to Submit

GitHub (one person uploads for the team)

  • One person downloads the team files ZIP from the workspace and uploads project-plan.md to your team's GitHub repo
  • This counts for everyone on the team

Canvas (everyone submits individually, both files)

  • project-plan.md — same file for everyone on the team. Download from the workspace.
  • Two-paragraph reflection — written by you, no AI. How did the lab go for you and your team? What worked well about the interview → council review → audit pipeline? What surprised you or did not go as expected? What challenges did you not foresee? If you ran this lab again, what would you do differently? Be specific and honest.
That is it. Two files on Canvas per person: the team plan and your reflection. One upload to GitHub for the team. Everything else (interviews, audits, AI logs, timestamps) I can see directly through the lab website.

Grading Rubric (100 points)

CriteriaPointsWhat I am looking for
AI Interview25You ran a real interview from your assigned role. The plan AI generated reflects that perspective, not a generic copy-paste.
Audit20You ran a real audit from your assigned lens. Findings are specific (name the task, name the problem, suggest a fix).
Final Plan Quality35Tasks have subtasks, dependencies, acceptance criteria, owners, and time estimates. Build order makes sense. A new team member could read this and know what to build first.
Participation and Reflection20Timestamps show you contributed during the lab. Your two-paragraph reflection is honest and specific about what worked and what did not in this lab format. Generic or AI-written reflections score lower.
Teams of 3: One person covers two interview roles and/or two audit lenses. This is noted in the submission report and graded accordingly. No penalty for smaller team size.
On honesty. If your plan is still largely hypothetical because it depends on information you do not have yet (partner data, user feedback, technical feasibility answers), that is fine. I am not going to punish you for that. But the plan should be thorough regardless. If you know there are unknowns, include early sprints dedicated to securing the information you need: schedule the partner meeting, run the user test, build the proof-of-concept. A plan that says "we need to find out X before we can build Y" and includes a task for finding out X is a good plan. A plan that pretends you already know everything is not.
Running behind? If your team only has 3 of 4 interviews or audits, merge or finalize with what you have. A plan built from 3 perspectives is much better than no plan. The workspace saves your progress so you can come back and finish after class. Due by end of day Tuesday.
SE 395: AI Tools for Social Impact · Rollins College · Fall 2026 · Professor Meirelles van Vliet

Instructor Example

Exemplary Project Plan

A model project plan created for the fictional Sunrise Community Kitchen partner. Study the structure: specific tasks, testable criteria, clear dependencies, realistic estimates.

View below or download as a file.

Project Plan: Sunrise Community Kitchen AI Distribution Assistant

Team Ripple Consulting: Jordan Blake, Alex Chen, Priya Sharma, Marcus Williams | October 30, 2026

Note from Professor Meirelles: This is a 5-week plan for a fictional four-person team. It is intentionally thorough to show you what a professional-grade plan looks like. Your plan today will be simpler. Focus on the structure (test cases, acceptance criteria, dependencies, owners) not the length. A plan with 4-6 well-defined tasks is better than a plan with 15 vague ones.

Project Overview

Build an AI-powered tool that processes the weekly food bank manifest, generates a distribution plan respecting dietary restrictions and household sizes, and produces a post-distribution report. Reduce Maria's weekly coordination time from 6-8 hours to under 2 hours. Deliver a working prototype by Week 14 partner demo.

DetailValue
PartnerSunrise Community Kitchen (Maria Sandoval)
TimelineWeek 10 through Week 14 (5 weeks)
Demo DateWeek 14, Thursday, December 4
Core MetricTime to produce distribution plan drops from 3+ hours to under 30 minutes

Task Breakdown

Phase 1: Foundation (Week 10-11)

## Task 1: Collect and prepare sample data - [ ] 1.1 Email Maria requesting 3 past weekly manifest PDFs (different weeks, different formats) - [ ] 1.2 Request current family database export from Google Sheets (all columns: name, household size, dietary restrictions, address, phone, notes) - [ ] 1.3 Request 2 past Thursday run-of-show volunteer emails from Maria - [ ] 1.4 Request 2 past post-distribution reports sent to food bank and United Way - [ ] 1.5 Manually categorize every line item in Manifest #1 by hand (protein, produce, dairy, pantry) as ground truth - [ ] 1.6 Create a format variation table documenting differences across the 3 manifests (column order, abbreviations, spacing, units) - [ ] 1.7 Create synthetic test data: 1 fake manifest with known edge cases (items with no category, misspelled items, zero-quantity lines, expired items) - [ ] 1.8 Store all sample data in team GitHub repo under /data/samples/ with a README explaining each file Depends on: Nothing (first task) Owner: Alex Acceptance criteria: ✓ 3 real manifest PDFs in repo ✓ 1 family database CSV export with 200+ rows ✓ 1 hand-categorized ground truth manifest with every item tagged ✓ 1 synthetic edge-case manifest with at least 8 known tricky items ✓ Format variation table with at least 5 documented differences ✓ All files in /data/samples/ with README Time: 3 hours (plus wait time for Maria) Risk: Maria may be slow to respond. Send request Friday Oct 31. Follow up Monday. If no response by Wednesday, create synthetic data from manifest format description and proceed.
## Task 2: Build and test manifest parser prompt - [ ] 2.1 Extract raw text from Manifest #1 PDF (test if copy-paste works or if OCR needed) - [ ] 2.2 Write v1 parser prompt: input = raw manifest text, output = structured JSON array with fields: item_name, category, quantity, unit, expiration_date - [ ] 2.3 Define test cases before running (test-driven): TEST A: Standard items parse correctly (chicken breast → protein, 24 cases) TEST B: Abbreviations resolve ("chk thgh" → chicken thighs, protein) TEST C: Items with no clear category get flagged as "uncategorized" not silently assigned TEST D: Zero-quantity or negative-quantity lines are flagged, not included in totals TEST E: Expired items (expiration before distribution date) are flagged with warning TEST F: Total quantities in output match total quantities in input (no items lost or invented) TEST G: Output JSON is valid (parseable, consistent field names, no missing fields) - [ ] 2.4 Run v1 prompt against Manifest #1. Record pass/fail for each test case - [ ] 2.5 Fix failures. Write v2 prompt. Re-run all tests - [ ] 2.6 Run passing prompt against Manifest #2. Record results. Fix regressions - [ ] 2.7 Run against Manifest #3. Record results. Fix regressions - [ ] 2.8 Run against synthetic edge-case manifest (Task 1.7). All edge cases must be handled - [ ] 2.9 Compare parser output for Manifest #1 against hand-categorized ground truth (Task 1.5). Calculate accuracy: correct items / total items - [ ] 2.10 Document final prompt version in /prompts/manifest-parser.md with: the prompt text, input format expected, output format, known limitations, test results summary Depends on: Task 1 (need sample data and ground truth) Owner: Jordan Acceptance criteria: ✓ All 7 test cases (A-G) pass on all 3 real manifests ✓ All edge cases from synthetic manifest handled correctly ✓ Accuracy vs. ground truth: 95%+ items correctly categorized ✓ Zero hallucinated items (no items in output that do not exist in input) ✓ Zero silently dropped items (every input line accounted for in output) ✓ Output JSON validates (can be parsed by a script without errors) ✓ Prompt and test results documented in /prompts/manifest-parser.md Time: 6 hours Note: If PDF text extraction fails (scanned PDFs), document the failure and fall back to manual text copy-paste as input. Add OCR as a stretch goal for Phase 2.
## Task 3: Build and test allocation engine prompt - [ ] 3.1 Define allocation rules from Maria's process (documented in Lab 4): RULE 1: Protein portions by household size (1 chicken per 4 people, 2 per 6+, scale linearly for other proteins) RULE 2: Pork products excluded from 34 halal families (zero tolerance, not just deprioritized) RULE 3: Short-shelf produce prioritized for large households (distributed first, largest households first) RULE 4: Diabetic families (count TBD from database) flagged for low-sugar item substitutions RULE 5: When supply is short, flag affected families for Maria's manual priority decision (do NOT auto-prioritize) RULE 6: Every family gets a minimum basket (at least 1 protein, 1 produce, 1 dairy, 2 pantry) before extras are distributed - [ ] 3.2 Write v1 allocation prompt: input = parsed manifest JSON (from Task 2) + family database CSV, output = family-by-family allocation list as structured table - [ ] 3.3 Define test cases before running: TEST A: No halal family receives pork (check all 34 families against all pork items) TEST B: Portions scale correctly (family of 2 gets ~half what family of 6 gets for divisible items) TEST C: Short-shelf produce goes to large households first TEST D: Every family gets minimum basket or is flagged as "insufficient supply" TEST E: Total allocated quantities ≤ manifest quantities (cannot distribute more than available) TEST F: Short supply triggers flags, not silent omissions (Maria sees which families are affected) TEST G: Diabetic families do not receive high-sugar items in primary allocation TEST H: Output includes bag label format: family name, bag contents, special notes - [ ] 3.4 Run v1 against Manifest #1 + full family database. Record pass/fail for each test - [ ] 3.5 Fix failures. Write v2. Re-run all tests - [ ] 3.6 Create a "short supply" test scenario: reduce manifest quantities by 50%. Verify RULE 5 and TEST F work - [ ] 3.7 Create a "new family" test: add 5 families to database that were not there before. Verify they get allocated correctly - [ ] 3.8 Partner checkpoint: email Maria the allocation output for Manifest #1 and ask "does this look right?" (15-min review, not a meeting) - [ ] 3.9 Document final prompt in /prompts/allocation-engine.md with: rules, prompt text, test results, Maria's feedback Depends on: Task 2 (need parsed manifest JSON as input) Owner: Priya Acceptance criteria: ✓ All 8 test cases (A-H) pass on Manifest #1 + family database ✓ Short supply scenario handled: families flagged, not silently skipped ✓ New family scenario handled: no errors on unseen families ✓ Maria reviews output and confirms allocation logic matches her process ✓ Zero pork to halal families (verified by script or manual check of all 34) ✓ Total distributed ≤ total available for every item ✓ Prompt documented in /prompts/allocation-engine.md Time: 7 hours Partner checkpoint: Maria reviews after 3.8. Schedule email for Week 12 Monday.
## Task 4: Build and test volunteer communication generator - [ ] 4.1 Collect and analyze 3 past Thursday run-of-show emails from Maria (Task 1.3) - [ ] 4.2 Document Maria's writing patterns: greeting style, sign-off, tone markers, personal touches, typical structure - [ ] 4.3 Identify required content blocks: arrival time, station assignments (sorting, packing, loading, delivery), item summary for the week, weather/parking notes, special instructions, personal note to specific volunteers - [ ] 4.4 Write v1 email generator prompt: input = allocation plan summary + volunteer confirmed list + any special notes, output = complete Thursday email in Maria's voice - [ ] 4.5 Define test cases: TEST A: Email contains all required content blocks (arrival time, stations, items, etc.) TEST B: Tone matches Maria's voice (compare sentence structure and word choice against real emails) TEST C: Station assignments are logical (correct number of people per station based on volunteer count) TEST D: Item summary matches allocation plan (no items mentioned that are not in the plan) TEST E: Email is under 500 words (Maria's emails are concise) TEST F: No AI artifacts (no "as an AI," no "I'd be happy to," no markdown formatting in email body) TEST G: Personal touches preserved (volunteer names, "looking forward to seeing you" type language) - [ ] 4.6 Run v1 against Manifest #1 allocation + 15 confirmed volunteers. Check all tests - [ ] 4.7 Fix failures. Iterate until all tests pass - [ ] 4.8 Run against a scenario with only 8 volunteers (understaffed Saturday). Verify station assignments adjust - [ ] 4.9 Maria reviews generated email: "Does this sound like me? What would you change?" - [ ] 4.10 Revise prompt based on Maria's feedback. Re-run all tests to prevent regression - [ ] 4.11 Document in /prompts/volunteer-email.md with: prompt, style guide, test results, Maria's feedback Depends on: Task 3 (needs allocation plan for item summary and station context) Owner: Marcus Acceptance criteria: ✓ All 7 test cases pass ✓ Maria says "this sounds like me" or needs fewer than 5 edits ✓ Understaffed scenario generates adjusted station plan (not just fewer names per station) ✓ No AI artifacts in any generated email ✓ Documented in /prompts/volunteer-email.md Time: 5 hours

Phase 2: Integration and Reporting (Week 12-13)

## Task 5: Build and test post-distribution report generator - [ ] 5.1 Analyze 2 past reports Maria sent to food bank (Task 1.4). Document exact format: - What fields does the food bank require? (families served, pounds distributed, items not distributed, issues, etc.) - What fields does United Way require? (may differ from food bank) - What tone and length are these reports? (formal? bullet points? narrative?) - [ ] 5.2 Define report input schema: manifest totals, actual distribution counts, leftover inventory (estimated), issues log (damaged goods, families turned away, complaints), volunteer count, weather/conditions - [ ] 5.3 Write v1 report generator prompt: input = report data schema, output = complete report matching food bank format - [ ] 5.4 Write separate v1 prompt for United Way format (if different from food bank) - [ ] 5.5 Define test cases: TEST A: Report contains all required fields for food bank TEST B: Report contains all required fields for United Way TEST C: Numbers are internally consistent (distributed + leftover = manifest total, within 5% tolerance for estimation) TEST D: Families served count matches allocation engine output TEST E: No hallucinated statistics (every number in report traces back to an input) TEST F: Issues section handles zero issues gracefully ("No issues reported" not blank) TEST G: Issues section handles multiple issues (damaged goods AND families turned away in same week) TEST H: Report is professional tone matching Maria's past reports TEST I: Report handles edge case: no leftovers (everything distributed) TEST J: Report handles edge case: significant leftovers (30%+ undistributed, needs explanation) - [ ] 5.6 Create mock distribution data for testing: normal week, short supply week, surplus week, problem week (3 damaged pallets) - [ ] 5.7 Run prompt against all 4 mock scenarios. Test all cases - [ ] 5.8 Fix failures. Iterate - [ ] 5.9 Cross-check: run report generator on same data as allocation engine. Verify numbers match - [ ] 5.10 Document in /prompts/report-generator.md with: both prompts, input schema, test results, edge case handling Depends on: Task 1 (need report format samples). Can run parallel with Tasks 3-4 Owner: Alex Acceptance criteria: ✓ All 10 test cases pass for food bank format ✓ All applicable test cases pass for United Way format ✓ Numbers consistent across all 4 mock scenarios ✓ Zero hallucinated statistics in any generated report ✓ Edge cases (zero leftovers, surplus, problems) handled gracefully ✓ Documented in /prompts/report-generator.md Time: 6 hours
## Task 6: Build pipeline connector and end-to-end integration - [ ] 6.1 Define pipeline flow and data contracts between components: Stage 1: Raw manifest text → Task 2 parser → JSON inventory Stage 2: JSON inventory + family CSV → Task 3 allocator → allocation table Stage 3: Allocation table + volunteer list → Task 4 email gen → Thursday email Stage 4: Manifest totals + distribution data → Task 5 report gen → food bank + United Way reports - [ ] 6.2 Write a connector script (Python or shell) that chains prompts: output of Stage 1 feeds into Stage 2, etc. - [ ] 6.3 Define integration test cases: INT-TEST A: Full pipeline runs on Manifest #1 without manual intervention between stages INT-TEST B: Total time from raw manifest to all outputs: under 30 minutes INT-TEST C: All individual task acceptance criteria still pass when run as pipeline (no regression) INT-TEST D: Pipeline handles a manifest with 400+ items (stress test for prompt length limits) INT-TEST E: Pipeline produces consistent output on same input (run twice, compare results, key facts match) INT-TEST F: Each stage's output is saved to a file (audit trail for Maria) INT-TEST G: Pipeline fails gracefully if one stage fails (error message, not silent corruption) - [ ] 6.4 Run full pipeline on Manifest #1. Record all test results - [ ] 6.5 Fix any integration failures (data format mismatches between stages are the most likely issue) - [ ] 6.6 Run full pipeline on Manifest #2 and #3. Fix regressions - [ ] 6.7 Run full pipeline on synthetic edge-case manifest. Verify edge cases propagate correctly through all stages - [ ] 6.8 Performance log: record time for each stage and total pipeline time - [ ] 6.9 Document pipeline in /docs/pipeline.md with: flow diagram (text), data contracts, how to run, performance benchmarks, known limitations Depends on: Tasks 2, 3, 4, 5 (all components) Owner: Jordan + Priya Acceptance criteria: ✓ All 7 integration test cases pass ✓ Pipeline runs end-to-end on all 3 real manifests without errors ✓ Total pipeline time under 30 minutes ✓ Output files saved to /output/ with timestamps ✓ Pipeline documented in /docs/pipeline.md Time: 6 hours

Phase 3: Partner Testing, Polish, and Handoff (Week 14)

## Task 7: Partner testing session - [ ] 7.1 Schedule 45-min session with Maria (Week 14 Tuesday or Wednesday, in person at the kitchen) - [ ] 7.2 Prepare test session materials: fresh manifest (most recent week), printed instructions, laptop with pipeline ready - [ ] 7.3 Pre-test: team runs pipeline on the fresh manifest internally first. Verify it works before Maria sees it - [ ] 7.4 Maria runs the tool herself with the fresh manifest. Team observes silently. Do not help unless Maria is stuck for 2+ minutes - [ ] 7.5 Record every friction point: where Maria hesitates, asks a question, makes an error, or says "this is not right" - [ ] 7.6 After run-through, ask Maria 5 debrief questions: Q1: Would you use this next Saturday? Why or why not? Q2: What is the most useful part? Q3: What is confusing or wrong? Q4: What is missing that you need? Q5: Would you trust this output without checking it yourself? - [ ] 7.7 Categorize findings: MUST-FIX (blocks adoption), SHOULD-FIX (reduces trust), NICE-TO-HAVE (polish) - [ ] 7.8 Fix all MUST-FIX issues. Re-run pipeline tests to verify no regressions - [ ] 7.9 Fix SHOULD-FIX issues if time allows - [ ] 7.10 Document session results in /docs/partner-testing.md with: friction log, debrief answers, fix list, what was resolved Depends on: Task 6 (pipeline must work end-to-end) Owner: Full team Acceptance criteria: ✓ Maria completes full pipeline run (with or without minor help) ✓ All MUST-FIX issues resolved before demo ✓ Maria answers Q1 with "yes" or "yes, with [specific change]" ✓ Session documented in /docs/partner-testing.md Time: 2 hours session + 4 hours fixes
## Task 8: Documentation and handoff package - [ ] 8.1 Write step-by-step user guide for Maria: - How to extract text from the manifest PDF (with screenshots) - How to run each prompt (copy-paste instructions for Claude/ChatGPT) - How to read and check the output at each stage - How to make manual corrections (edit the allocation before generating the email) - How to run the full pipeline end-to-end - [ ] 8.2 Write "What to do if it breaks" troubleshooting section: - "Output has wrong categories" → re-run parser with [fix] - "Family is missing from allocation" → check if family is in database - "Email tone is off" → edit the style guide section of the prompt - "Report numbers don't add up" → check leftover estimates - "PDF won't paste cleanly" → try different PDF reader, or type items manually - [ ] 8.3 Write quick-reference card (1 page) Maria can print and keep at her desk - [ ] 8.4 Write guide section for Dani: how to use the volunteer email generator, how to update the volunteer confirmed list - [ ] 8.5 Write 2-3 page partner summary for Maria and the food bank: - What was built and what it does - What Maria needs to run it (Claude account, the prompts file, her existing Google Sheet) - Known limitations (does not handle scanned PDFs, does not auto-prioritize in short supply) - Recommended next steps (add OCR, automate volunteer RSVP tracking, build a simple web form) - Team contact info for questions after the semester - [ ] 8.6 Organize all deliverables in repo: /prompts/ — all prompt files with documentation /data/samples/ — sample data and ground truth /docs/ — pipeline docs, partner testing results, user guide, troubleshooting /output/ — example outputs from test runs README.md — project overview, how to get started, team members - [ ] 8.7 Have someone NOT on the team (another student or the professor) attempt to follow the user guide. Note where they get confused - [ ] 8.8 Fix guide based on outside tester feedback Depends on: Task 7 (need final state of tool after partner fixes) Owner: Marcus + Alex Acceptance criteria: ✓ A person not on the team can follow the guide and produce output from a sample manifest ✓ User guide is under 6 pages with screenshots ✓ Quick-reference card fits on 1 printed page ✓ Troubleshooting covers at least 5 failure scenarios ✓ Dani section covers her specific workflow ✓ Partner summary is 2-3 pages, professional, no jargon ✓ Repo organized with clear folder structure and README Time: 5 hours

Timeline Summary

WeekTasksMilestoneHours
10Task 1 (data collection + ground truth)All sample data in repo. Ground truth manifest categorized. Synthetic edge cases created.3
11Tasks 2, 3 (parser + allocator)Both core prompts pass all test cases on all sample data. Maria reviews allocation output.13
12Tasks 4, 5 (email gen + report gen)All four prompts working independently. Maria reviews volunteer email for tone. Partner checkpoint call.11
13Task 6 (integration + pipeline)Full pipeline runs end-to-end. Under 30 minutes. All integration tests pass.6
14Tasks 7, 8 (partner test + handoff)Maria runs pipeline herself. All must-fix issues resolved. Handoff package delivered. Repo organized.11

Total estimated hours: 44 across 4 team members over 5 weeks = ~2.2 hours per person per week. Realistic for a course project.

Risk Register

RiskLikelihoodImpactMitigation
Manifest PDFs are scanned images, not selectable textMediumHigh (breaks Task 2 input)Test in Task 2.1. If scanned: fall back to manual text copy-paste. Add OCR as stretch goal. Document limitation in handoff.
Maria is slow to respond to data requestsHighMedium (delays Task 1)Send request Friday Oct 31. Follow up Monday. If no response by Wednesday: create synthetic data and proceed. Real data can replace synthetic later.
Prompt length limits hit on large manifests (400+ items)MediumMedium (parser fails on real-size input)INT-TEST D catches this. Mitigation: split manifest into chunks, process each chunk, merge results. Add chunking logic to pipeline.
Allocation rules are more complex than documentedMediumMedium (Task 3 output is wrong)Partner checkpoint in Week 12 catches this early. Build rules as configurable list, not hardcoded, so Maria can adjust.
Maria's tone is hard to replicateMediumLow (email needs heavy editing)Task 4.9 catches this. If AI cannot match tone: generate content only, let Maria write the personal parts. Good enough is better than perfect.
Team member unavailable for a weekLowHigh (delays a phase)Each task has a single owner but all prompts are documented. Any team member can pick up any task. Pipeline doc (Task 6.9) ensures continuity.
Integration breaks when chaining promptsHighMedium (pipeline does not flow)Data contracts defined in Task 6.1 before building connector. Each stage saves output to file. Failures are isolated, not cascading.

SE 395-2: AI Tools for Social Impact | Rollins College | Fall 2026

Live Workspace

Team Workspace

Work through each step. Save your progress. Share with teammates.

Join Your Team

Enter your name and select your team to start working.