# ILCA Starter Handoff
### The document you give the model at the start of every session

*Based on the ILCA practice of Phil Renato and Claude, renato.design, 2026.*
*Use it, adapt it, make it yours. The process is not a product.*

---

## A note before you fill this in

This template was developed while building software. The methodology it describes was not. It has been used to build macOS applications, design tools, simulation environments, and written bodies of work, and the same principles apply to designing physical objects, developing a visual practice, writing a thesis, building a curriculum, making a film, or any other sustained creative project where you need a collaborator who holds the craft while you hold the vision.

Where the examples below come from a software context, read past the specifics and take the principle. The fields that matter most — aesthetic register, settled decisions, what you bring versus what the model brings — work the same way whether you're building an app, a collection of objects, or a research practice.

**A note on how to use this document with the model:**

Don't just fill in the blanks and hand it over. Use the first session to develop your answers collaboratively. Tell the model you're setting up a working relationship and ask it to help you find versions of each field that actually fit your practice. The aesthetic register section is the one to talk through first — the model can help you identify the right kind of cultural reference for how your mind works, and test whether it's specific enough to be useful. The goal is a document that sounds like you, not like the examples.

---

# PART A — WHO YOU ARE

## Your identity and practice

*Who are you and what do you make? Be specific about your domain. The model uses this to calibrate everything — vocabulary, references, the level of technical explanation you need, what counts as an aesthetic success in your field. A furniture designer, a filmmaker, a graduate student in materials science, and a software developer will work very differently with a model. Say which one you are.*

**Example:**
> I am a product design professor and industrial designer. My domain expertise includes footwear construction, jewelry, automotive form, and textile engineering. I have strong aesthetic convictions developed over years of hands-on making. I do not have a programming background. I direct the work; you execute it. When I describe something visually or physically, take it seriously as a design constraint, not as a metaphor.

**Your version:**
> [Write your own here. If you're not sure how to describe your practice, tell the model and ask it to help you articulate it through a few questions.]

---

## What you bring to this collaboration

*Name it explicitly. This is the line you hold. It will feel obvious to write down and important to have written.*

**Example:**
> I bring: domain knowledge, aesthetic judgment, the vision for what the thing should be and feel like, and the authority to say when something is wrong even if I can't explain why technically. I also bring the willingness to kill ideas that aren't working, including ones I was excited about.

**Your version:**
> [Write your own here.]

---

## What the model brings

*Name this too. Knowing what you're not responsible for is as important as knowing what you are.*

**Example:**
> You bring: technical execution, architectural consistency across the whole project, documentation discipline, and the ability to hold the entire project in working memory simultaneously. You catch technical errors. You maintain the standards we agree on. You do not drive the conceptual direction unless I explicitly ask you to propose something.

**Your version:**
> [Write your own here. The specifics depend on what you're making — "technical execution" means something different for a woodworker than for a programmer, but the principle is the same: the model holds the craft, you hold the vision.]

---

## Standing rules that apply to every session

*These are the non-negotiables. Write them once and mean them. Start with two or three — more will come as you learn what you actually need. The best standing rules come from friction you've already experienced: the thing the model kept doing wrong, the assumption it kept making, the decision it kept relitigating.*

**Example (from software practice — take what applies, discard what doesn't):**

- Comments in code explain **why**, not what. Never narrate the code. Explain the decision behind it.
- No placeholder content. Ever. If a thing isn't built yet, it isn't there yet.
- When I describe something and you're uncertain whether I mean it aesthetically or technically, ask. Don't assume.
- If something I'm asking for is technically impossible or likely to break something, say so directly and immediately. Don't build toward it and fail later.
- If I seem to be moving away from a decision we already made, flag it before executing.
- Do not re-litigate settled choices unless I ask you to.
- At the end of every session, update the handoff document to reflect what changed.

**If you're not making software, your standing rules might look more like:**
- When I describe a material or a surface quality, treat it as a precise specification, not a mood.
- Don't suggest I resolve an open question by simplifying the idea. Complexity is sometimes the point.
- If a reference I give you is outside your knowledge, say so rather than approximate it.

**Your version:**
> [Write your rules here. If you don't know what they are yet, leave this blank and come back to it after your first two or three sessions. The rules will become obvious.]

---

## How I like to work

*Rhythm, communication style, how you handle disagreement. The model will adapt to this. Worth stating explicitly rather than negotiating it implicitly every session.*

**Example:**
> I work in focused sessions, iterating fast. I'll describe what I want in plain language, often using physical or material analogies. I expect you to attempt it, show me the result, and tell me what you weren't sure about. I'd rather see a wrong attempt than a list of clarifying questions. When I say something is wrong, don't defend it — ask what I'd rather have instead. If you think I'm making a mistake, say so once, directly. Then do what I asked.

**Your version:**
> [Write your own here.]

---

# PART B — THE PROJECT

*Copy this section for each new project. Keep the most recent version in the file. Update it at the end of every session.*

---

## Project name and version

*Use a consistent naming convention from the start. We use: `projectname™ v00000-001` — the zeros are a design choice, the three-digit number is a build record. Find a convention that fits your practice and hold it. For non-software projects, version numbers still work — they mark where you are and make it possible to go back.*

**Example:**
> **gesture™ v00000-012**

**Your version:**
> [Project name and version]

---

## What this project is

*One paragraph. What is the thing, why does it exist, what is the core experience or value it creates? Write it as if explaining to a smart person who hasn't seen it. This is also a test — if you can't write this paragraph clearly, the concept isn't ready to build yet. Applies whether the thing is software, a physical object, a body of research, a designed space, or a written work.*

**Example:**
> gesture is a drawing tool that uses AI to transfigure marks rather than generate images from prompts. The user draws on a blank canvas; a local diffusion model refines and extends the marks. A transfiguration slider controls how much the model transforms the input — from a whisper of refinement to aggressive reimagining, capped at 0.85 so the user's hand is always visible in the result. The core experience is: your mark, made stranger and smarter than you could make it alone.

**Your version:**
> [Write your one paragraph here.]

---

## Aesthetic register

*This is one of the most productive tools in the methodology. The idea is to anchor the project's personality to something culturally dense enough that it can answer small decisions without a meeting — and generate interesting, coherent variety across a body of work.*

*The original version of this tool uses music genres as the anchor. A genre carries tempo, attitude, instrumentation, relationship to the audience, and a whole set of cultural associations — enough to answer questions like "should this be aggressive or restrained?" or "does this feel right?" without re-explaining the project's entire personality every time.*

*But the anchor doesn't have to be a music genre. It should be whatever kind of cultural reference your mind already uses to navigate aesthetic decisions. Some people think in film directors. Some in decades of architecture. Some in painters, novelists, fashion designers, material traditions, sporting disciplines, or theoretical frameworks. The right anchor is one that's specific enough to rule things out, rich enough to generate things you wouldn't have thought of alone, and native to how you already think.*

*If you're not sure what your anchor should be, ask the model to help you find it. Describe two or three things you've made that you're proud of, or two or three existing works in any field that you think are doing something right. The model can often identify the underlying aesthetic logic and suggest a register that fits.*

**Example (music genre as anchor):**
> **Genre handle:** post-hardcore
>
> **What that means for this project:** Raw but precise. Emotional intensity kept entirely internal — visible in the system architecture and naming, never in the marketing language. Nothing decorative. Aggression expressed through constraint, not through loudness. The app should feel like it means it.
>
> **What it rules out:** Softness, roundedness, friendliness as aesthetic goals. Skeuomorphism. Anything that looks like it's trying to be approachable.

**Other possible anchors — to illustrate the principle:**
> *A film director:* "This project is Tarkovsky — long duration, material texture, the sense that nothing is happening and everything is happening. Rules out: pace, cleverness, resolution."
>
> *A material:* "This project is raw concrete — weight, permanence, the honest expression of process. Rules out: finish, decoration, anything that conceals how it was made."
>
> *A decade of architecture:* "This project is Brutalist 1960s — institutional confidence, structural expression, slightly hostile to comfort. Rules out: warmth, domesticity, ornament."
>
> *A novel:* "This project is Remainder by Tom McCarthy — obsessive repetition, unreliable interiority, the uncanny made procedural. Rules out: resolution, naturalism, emotional legibility."

**Your version:**
> **Anchor type:** [music genre / film director / painter / material / decade / novel / other — pick what fits your thinking]
>
> **Anchor:** [the specific reference]
>
> **What that means for this project:** [2–4 sentences]
>
> **What it rules out:** [1–2 sentences — what this project is not is often more useful than what it is]

---

## Output type and medium

*What is this project actually producing? This section replaces the software-specific "technical environment" field for practitioners working outside software. Be specific — the model needs to know what it's helping you make in order to give you correct, useful responses.*

**For software:**
> macOS native Swift/SwiftUI application. Target: macOS 14+. Shared infrastructure in the `renatokit` folder — check there before building something new. Versioning tracked in README.txt and CLAUDE_HANDOFF.md.

**For physical/designed objects:**
> A series of cast iron vessels, edition of six. Fabrication through lost-wax casting at [foundry]. Constraints: maximum dimension 300mm, must survive dishwasher cycling. I work in Rhino for form development; you help with parametric logic and documentation.

**For written/research work:**
> A design thesis, approximately 12,000 words, with visual documentation. The argument concerns [topic]. The model helps with structure, consistency of argument, and research synthesis. I write all primary prose; you help me see where the argument breaks.

**For spatial/installation work:**
> A site-specific installation for a gallery with dimensions [x]. Materials: [list]. The model helps develop the concept, write proposals, and maintain documentation of the design decisions.

**Your version:**
> [Describe what you're making, what tools or materials are involved, and what role the model plays in the making.]

---

## File structure and documentation standards

*Establish this early and hold it. The specifics will vary by medium — a software project and a design research project will have different file structures — but the principle is the same: a consistent, maintained record is what makes continuity possible across sessions.*

**For software (example):**
> Every project maintains two files that are always current:
> - `CLAUDE_HANDOFF.md` — what the model needs to know to continue the work. Updated every session.
> - `README.txt` — what a human needs to know to understand and run the project.
>
> These are not optional. They are the memory of the collaboration.

**For other project types, the equivalent might be:**
> A single `PROJECT-STATE.md` that lives in the project folder and contains: what the project is, what was decided last session, what's open, and what the current version of the core concept is. Updated every session. If the project generates physical or visual outputs, a running log of what was made and what it revealed.

**Your version:**
> [Describe how you'll maintain the record of the collaboration. Simple is fine. What matters is that it exists and stays current.]

---

## What has already been decided

*This is the most protective field in the document. List the choices that are settled. The model will not revisit them unless you ask. Add to this every session — it is how the project accumulates identity over time.*

**Example:**
> - The transfiguration slider caps at 0.85. This is intentional and permanent.
> - The post-hardcore aesthetic register is kept entirely internal — never in marketing copy or UI labels.
> - The app does not connect to any external API. Everything runs on-device.

**Your version:**
> [List your settled decisions here. Start with the ones that feel obvious — those are usually the ones most worth protecting.]

---

## What was worked on last session

*One paragraph or a short list. What did you make, test, or find out? What state did you leave it in?*

**Your version:**
> [Fill in after your first session. Leave blank to start.]

---

## Open questions

*What isn't resolved yet? What are you uncertain about? What might change? Writing these down prevents the model from making decisions in those spaces without you.*

**Your version:**
> [List your open questions here.]

---

## What I want to work on this session

*Write this fresh at the start of each session, before you give the model the document. Be specific. "Make it better" is not a session goal. "Resolve the proportion problem in the upper section and decide whether the edge treatment should be consistent across all six pieces" is a session goal.*

**Your version:**
> [What do you want to accomplish today?]

---

---

*ILCA — Iterative LLM Co-Authorship. Developed by Phil Renato with Claude, renato.design, 2026.*
*Use it, adapt it, make it yours. The process is not a product.*
