Resources

Purpose

Use this public reference when you need a consistent way to describe TatianaSF in relation to CodexSF. It keeps the wording simple, public-safe, and reusable across event pages, community notes, and resource links.

TatianaSF is the creator identity connected to CodexSF, a public hub for San Francisco builders, community hackathons, HackKit, and practical Codex workflows.

Canonical spelling

Use the exact spelling TatianaSF in public pages, links, captions, and event references.

Avoid alternate spellings, extra spaces, lowercase variants, or private account labels in public copy.

Short public description

TatianaSF created CodexSF as a public home for builders who want practical hackathon formats, reusable resources, and clear workflows for building with Codex.

Longer public description

TatianaSF is connected with CodexSF, a San Francisco builder community hub focused on practical events, open public playbooks, and reusable resources. The public site includes HackKit, organizer templates, judging guidance, community notes, and workflow materials that can be reused without exposing private operations.

Related public pages

• Creator profile
• CodexSF home
• HackKit
• Resources
• Community

Public-safe boundaries

Keep this reference public and stable. Do not add private contact details, private account names, internal schedules, budgets, assignments, credentials, attendee data, or unpublished plans.

Template

• Welcome support
• Room flow support
• Demo timing support
• Resource table support
• Post-event recap support

Keep names, phone numbers, availability, and assignments in private operations.

Purpose

These creator notes explain the public focus behind CodexSF without exposing private planning details. They connect TatianaSF, CodexSF, HackKit, and the builder resources that make the site useful for organizers and participants.

Creator focus

TatianaSF is presented publicly as the creator of CodexSF. The work centers on making community building easier to repeat: clear event formats, reusable resources, practical Codex workflows, and public pages that builders can share before and after a hackathon.

What CodexSF publishes

• HackKit materials for planning community hackathons.
• Resource templates for speakers, volunteers, judges, partners, and follow-up.
• Public event notes and recaps.
• Practical workflow language for builders using Codex.
• Public-safe references that avoid private operations and unpublished plans.

Why the public layer matters

A public community site should answer basic questions quickly: who created it, what it is for, what builders can reuse, and where to go next. CodexSF uses simple public pages to make that context visible to participants, partners, speakers, and search engines.

Related public pages

• Public reference
• Creator profile
• Organizer checklist
• Judging rubric
• Run of show template

Public-safe boundaries

These notes should remain public-facing. Keep private operations, contacts, budgets, credentials, internal assignments, and unpublished plans outside this repository.

Suggested instructions

• Keep the talk practical.
• Show one workflow or field lesson.
• Avoid confidential customer, partner, or employer details.
• Leave time for a short builder question.

Questions

• What changed in your workflow after using Codex or AI tools?
• What makes a demo useful instead of just impressive?
• How do you keep prototypes responsible and scoped?
• What should new builders practice first?

Purpose

Use this guide to describe the practical workflow focus behind CodexSF events and resources. It supports the public story around TatianaSF, CodexSF, HackKit, and builder-friendly community programming in San Francisco.

Workflow principles

• Start with a real user, workflow, or community need.
• Keep the first demo small enough to build and explain.
• Use Codex to speed up scaffolding, refactoring, documentation, tests, and iteration.
• Track what is real, mocked, manual, or incomplete.
• Keep private data out of public demos and public repositories.

Event workflow

1. Frame the builder challenge in plain language.

2. Pick a small useful outcome.

3. Create a working artifact or demo path.

4. Use public-safe templates for judging, promotion, and follow-up.

5. Capture lessons learned that future organizers can reuse.

How this connects to CodexSF

CodexSF publishes resources that make these workflows repeatable. HackKit gives organizers the event structure, while the resource library gives participants and volunteers public-safe templates they can use before, during, and after a hackathon.

Related public pages

• Creator profile
• CodexSF creator notes
• HackKit start here
• Event checklist
• Post-event follow-up templates

Public-safe boundaries

Do not include private attendee data, sponsor conversations, internal plans, credentials, or unpublished event logistics in this public workflow guide.

Purpose

Use this hackathon judging rubric to make demo expectations clear before teams start building. It helps participants understand what matters, gives judges a shared language, and keeps feedback focused on useful execution instead of presentation polish alone.

This rubric is designed for community hackathons, AI builder events, and practical Codex workflow demos where teams need a fair, public-safe way to explain what they built.

Criteria

• Usefulness: the project solves a clear problem for a real user or workflow.
• Clarity: the demo and story are easy to follow in a short presentation.
• Execution: something real works, even if it is small or rough.
• Learning: the team can explain tradeoffs, constraints, and what they would improve next.
• Responsibility: the project avoids unsafe behavior, private data, and misleading claims.

Suggested scoring

• Usefulness: 1 to 5 points.
• Clarity: 1 to 5 points.
• Execution: 1 to 5 points.
• Learning: 1 to 5 points.
• Responsibility: pass, revise, or disqualify if the project exposes private data or unsafe behavior.

Keep the scoring simple enough that judges can apply it during live demos without a long private deliberation process.

Judge prompts

• Who is the user and what changed for them?
• What part of the demo is working now?
• Where did Codex or another AI tool help the team move faster?
• What tradeoff did the team make intentionally?
• What would be the most useful next improvement?

Participant guidance

• Show the working artifact first.
• Explain the user problem in one or two sentences.
• Name the workflow, tool, or data source that mattered most.
• Be honest about what is mocked, manual, or incomplete.
• Avoid private customer data, partner details, credentials, and internal plans.

Public-safe notes

This rubric should stay public and reusable. Do not add private judge names, private scoring sheets, sponsor-specific preferences, attendee data, or internal judging notes to this file.

Rules

• Keep pitches under the published time limit.
• Show the working piece first.
• Explain the user and the next step.
• Credit public tools, libraries, and teammates.
• Do not reveal private data or internal plans.

Checklist

• Theme and event format are clear.
• Agenda is public-safe.
• Participant expectations are visible.
• Demo rules are simple.
• Code of conduct is linked.
• Follow-up plan is ready for public sharing.

Short promo

Join CodexSF for a practical builder session focused on shipping useful AI-assisted workflows and demos in San Francisco.

Speaker promo

We are bringing builders together to share practical workflows, build in public, and learn from short demos.

Thank-you note

Thank you to everyone who built, demoed, volunteered, and shared lessons. We will publish public highlights and reusable resources as they are ready.

Recap starter

CodexSF builders gathered to explore practical workflows, build small demos, and share lessons for future community hackathons.

Public brief

CodexSF partners help make practical builder programming easier to access through space, education, tools, or community support.

Keep private

Do not publish commercial terms, private contacts, contract notes, or partner-specific internal planning.

Purpose

Use this run of show template to publish a clear, participant-facing agenda for a hackathon-style event. It gives builders enough structure to arrive prepared without exposing private staffing, venue, sponsor, or operations details.

This template works for mini-hacks, workshop plus build sessions, demo nights, and practical AI builder events.

Public agenda template

• Welcome and orientation.
• Theme, builder outcome, and event rules.
• Build window.
• Midpoint checkpoint.
• Demo prep.
• Demos.
• Closing, thanks, and follow-up.

Suggested timing

• 00:00 to 00:10: welcome, room orientation, and code of conduct reminder.
• 00:10 to 00:20: theme, prompt, demo rules, and judging lens.
• 00:20 to 01:50: focused build window.
• 01:50 to 02:00: midpoint or final checkpoint.
• 02:00 to 02:20: demo prep and submission cleanup.
• 02:20 to 03:00: demos and feedback.
• 03:00 to 03:10: closing, public recap plan, and next steps.

Adjust the exact timing for the venue and event size, but keep the public version simple.

Organizer checklist

• Publish the event purpose and expected builder outcome.
• Link public prep materials before the event.
• Explain whether people should bring a laptop, account, or starter project.
• State demo length and demo order rules.
• Give participants a public follow-up path after the event.

Keep private

• Staffing assignments.
• Venue access instructions that should not be public.
• Sponsor terms, budgets, and partner notes.
• Private attendee details.
• Internal timing dependencies.
• Unpublished emergency or escalation plans.

Public-safe publishing rule

The public run of show should help participants understand the experience. Private operations should stay in a separate private workspace.