The Base 16 — Full Content

Confirm that Gmail API access is available. Check for valid OAuth2 credentials with gmail.users.messages scope. Verify by listing the 1 most recent message. If auth fails, stop and report the missing credential or expired token. Do not attempt to re-authenticate — just report what is missing so the user can fix it.

Diagnose the current state of the user's Gmail inbox. Report: total message count, unread count, age of the oldest unread message, top 5 senders by volume in the last 30 days, threads where the user was the last recipient but hasn't replied in 7+ days (stale threads), messages with attachments that were never opened or downloaded, and whether labels or filters are actively being used or if everything is dumped into the primary inbox. Produce a health score from 0-100 based on how manageable the inbox is, with specific actionable recommendations for improvement. This is not a message listing — it is a behavioral diagnosis of email habits.

Search Gmail using advanced query syntax. Translate the user's natural language search intent into the correct Gmail query operators: from:, to:, subject:, has:attachment, after:, before:, newer_than:, older_than:, label:, is:unread, is:starred, filename:, and boolean operators (OR, -, {}). Handle common mistakes — it is from: not sender:, it is has:attachment not has:attachments. If the query returns zero results, analyze why and suggest 2-3 refined queries that broaden the search intelligently. Return matching messages with sender, subject, date, snippet, and thread ID for downstream use.

Take an email thread found via search and produce a synthesis, not a chronological recap. Identify: all participants and their roles in the conversation, the core topic or request that started the thread, key decisions that were made (with who made them), open questions or unresolved items, the most recent ask or action item, and any commitments with deadlines. If the thread is longer than 10 messages, identify the 2-3 turning points where the conversation changed direction. Flag anything that looks like a stale commitment — something someone said they'd do but there's no follow-up confirming it was done.

Analyze the user's actual sent emails to learn their writing voice before attempting to draft anything on their behalf. Sample 15-20 recent sent messages across different recipients and contexts (formal vs casual, internal vs external, requests vs replies vs updates). Extract and document: average message length, formality spectrum (how they write to their boss vs a friend), greeting and signoff patterns, punctuation habits (exclamation marks, ellipses, emoji), sentence structure tendencies (short and punchy vs long and flowing), vocabulary preferences and repeated phrases, how they handle requests (direct or softened), how they open cold emails vs replies. Produce a structured writing profile that captures their voice. This gates all drafting — you cannot write as someone until you know how they write.

Draft an email that sounds like the user wrote it, using their writing profile from the analysis step. Match their typical tone, sentence length, greeting style, signoff, and vocabulary for the type of email being written (check: is this a request, update, reply, or cold outreach — they may write each differently). Collect recipient, subject, and the intent of what the user wants to say. Write the draft, then self-check: does this sound like the samples in the profile, or does it sound like a generic AI email? If it sounds robotic, rewrite. Save as a Gmail draft — never send directly. Confirm the draft exists in their drafts folder and report the draft ID so they can review and send themselves.

Verify filesystem access by creating and deleting a temporary file (.seed-check-tmp) in the current directory. If permission denied, stop and report the specific error. Do not escalate privileges or attempt workarounds — just confirm whether the agent can read and write files in the working directory.

Scan the current directory to understand what kind of project this is. Detect: primary language and framework by looking for signature files (package.json → Node/JS, Cargo.toml → Rust, pyproject.toml → Python, go.mod → Go, etc.), git status and remote URL if available, README presence and quality, directory structure pattern (src/, lib/, tests/, etc.), build system, test framework, and approximate project size (file count, LOC estimate). Recognize monorepo patterns (multiple package.json files, workspace configs). Distinguish between application, library, and configuration repositories. Flag anything unusual: missing .gitignore, vendored dependencies, mixed languages without clear boundaries, or no entry point. Produce a project fingerprint that downstream seeds can reference without re-scanning.

Ask the user to specify which document or file to work with. Confirm the file exists and is readable. Report the file type (by extension and by inspecting content), size in human-readable format, and the first 10-20 lines as a preview. If the file cannot be found, list available files in the current directory grouped by type. If the file is binary, report that and describe what kind of binary it appears to be (image, PDF, compiled, archive, etc.).

Analyze the selected document's internal structure to produce a map that downstream seeds can use to operate on specific sections without re-reading the whole file. For text/markdown: heading hierarchy with nesting depth, section count, word count per section, estimated reading level, named entities (people, companies, dates, URLs). For CSV/JSON data files: column names, types, row count, sample values, null/missing counts. For code files: language, top-level function and class inventory, import/dependency list, exported API surface, lines of code. For PDFs: page count, whether it is text-extractable or scanned image, table of contents if present. Output the structural map in a consistent format regardless of input type.

Establish a specific person as the focus of the current working context. Ask the user who they want to work with — get the person's full name and their email address. If the user has already mentioned someone by name or email in the conversation, confirm that is who they mean rather than asking again. Once confirmed, clearly state the person's name and email and hold them as the active context for all subsequent operations. If the user gives a name but no email, ask for it — email is required for most downstream actions (emailing them, looking them up, scheduling with them).

Build a lightweight profile of the selected person using publicly available web sources. Search for their name combined with their email domain, company, or any other context available. Find and report: current role and company, LinkedIn headline or summary if publicly visible, recent public activity (blog posts, conference talks, open source contributions, social media posts), and any notable context (recently changed jobs, published research, founded something, appeared in news). Be explicit about confidence — distinguish between confirmed facts and inferences. If you cannot find information on a specific dimension, say so clearly rather than guessing. Produce both a 1-paragraph natural language briefing suitable for reading before a meeting, and a structured data card with labeled fields.

Verify access to an image generation or editing model that can accept an existing image as input and return a modified version. Test with a concrete operation: take any small test image and apply a simple transformation (e.g., change the background color, apply a minor style adjustment). Confirm the full roundtrip works — image in, prompt describing the edit, modified image out. Report: which model or API is available (DALL-E, Stable Diffusion, Midjourney, Flux, etc.), what resolution it supports for input and output, whether it supports inpainting (editing specific regions while preserving the rest), any content policy restrictions that would affect portrait editing, and rate limits or cost per operation. If multiple models are available, recommend the best one for portrait editing specifically.

Obtain a high-quality portrait photo of the user suitable for professional editing. Ask the user to provide their best headshot or portrait — accept a file path, URL, or pasted image. Once received, validate: resolution must be at least 512x512 pixels, the image must contain exactly one clearly visible face (not a group shot), the face must not be significantly obscured, blurry, or awkwardly cropped (forehead cut off, chin missing), and the image should be reasonably well-lit (not extremely dark or blown out). If the image fails any check, explain specifically what is wrong and why it matters for the intended edit, then ask for a better photo. Do not proceed with a subpar image — the quality of every downstream edit depends on starting with good source material. Hold the validated portrait as the active image for subsequent operations.

Transform the user's validated portrait into a professional headshot that looks like it was taken by a studio photographer. Specific edits: replace the background with a clean neutral gradient (light gray to white, or a subtle professional blue — ask the user's preference or default to neutral gray), adjust lighting to be even and flattering with soft shadows, correct skin tone to look natural under professional lighting without making it look airbrushed, and reframe if needed so the composition is head-and-shoulders with the face occupying roughly 60% of the vertical frame. Critical constraints: preserve the person's actual appearance — do not smooth skin to the point of removing texture and character, do not alter facial structure or proportions, do not change hair color or style, do not whiten teeth or enlarge eyes. If the original has harsh side-lighting shadows, soften them but don't eliminate all shadow — some dimensionality looks more professional than flat lighting. Output the final edited image plus a side-by-side before/after comparison so the user can verify their likeness was preserved.

Apply a specified artistic style to the user's portrait while keeping the person clearly recognizable. Supported styles: oil painting, watercolor, pencil sketch, digital illustration, pop art (Warhol-style), anime/manga, pixel art, or a custom style from a reference image the user provides. The critical constraint is identity preservation — the styled output must still be obviously the same person. Before delivering the final result, compare facial landmarks (eye position, nose shape, jawline, face proportions) between the original and styled version. If the face has distorted beyond recognition (common with heavy style transfer), reduce the style intensity by 25% and regenerate. Repeat until the person is identifiable. Output the styled image with metadata: style name applied, intensity level used (0-100%), and whether any identity-preservation corrections were needed.