One folder

Your work lives on GitHub, and you move it there from the terminal with two tools: git, which keeps the history, and gh, GitHub's own command-line tool, which signs you in and creates the repository. Use this one way all month.

Once, on Day 1

1. Make a GitHub account.

   At github.com, before Day 1 if you can. Use a username you'd be happy to see on an exhibition label.

2. Install git and gh.

   On a Mac with Homebrew, one line. On Windows, use winget. Check both answer with a version number.

   brew install git gh # Mac winget install --id GitHub.cli # Windows (git: winget install --id Git.Git) git --version gh --version
3. Tell git who you are.

   Once per computer. Use the email of your GitHub account.

   git config --global user.name "Your Name" git config --global user.email "you@example.com"
4. Sign in with gh.

   Choose GitHub.com, then HTTPS, then Login with a web browser. Say yes when it asks to authenticate git. This means you never type a password in the terminal.

   gh auth login gh auth status
5. Create your repository from the studio starter.

   This makes a public copy of the starter under your account and downloads it in one go. The starter is kala0606/computationally-yours-starter.

   cd ~/Documents gh repo create your-project --public --template kala0606/computationally-yours-starter --clone cd your-project
6. Check it worked.

   This opens your repository in the browser.

   gh repo view --web

Every day

Unsure what's happening? git status tells you what has changed and whether you're up to date, and is always safe to run. You can also ask Codex to commit and push for you; read the commands it proposes before approving them.

If something goes wrong

Create your repository from the starter on Day 1 (above). By Day 18 it should look like this. Files appear as the month goes on.

Names matter: Codex and the final checklist both look for these files. If you need something else, add it, but don't rename these.

The README is the front door. A visitor scanning the QR code lands here, so it should make sense to someone who has never met you.

# [Identity name]

*[One sentence: who the identity is and the condition it answers to.]*

Made by [your name] in Computationally Yours: Out of One's Place,
Srishti Manipal Institute, Interim 2026.

## The work

[Two or three sentences on what the system makes and the artefact in the exhibition.]

## Manifesto

See [manifesto.md](manifesto.md).

## How the system works

[Three to five plain sentences. The full account is in [process.md](process.md).]

## Parameters

| Parameter | What it controls | Range | The identity's reason |
| --- | --- | --- | --- |
|  |  |  |  |

## Run it

[The exact commands to install and run the system, and to render a seed.]

## Files

- identity.md, manifesto.md, references.md: the identity
- system.md, process.md: the system
- log.md, authorship.md: the record of the month
- outputs/: what the system made

Codex reads AGENTS.md before it works in your folder. Use it to tell Codex who it's working for, what it must never do, and how your project is built.

# Working on this project

## Who this is for

This is a student project in a generative art studio. The student writes as an
authored identity, [identity name], who [one line: position and condition].
Read identity.md and manifesto.md before suggesting anything creative.

## Authorship rules

- Propose; don't decide. Explain options and wait for the student to choose.
- Never write or rewrite manifesto.md, final-statement.md, log.md or the
  "I rejected, and why" lines in authorship.md. You may question them.
- Ask for a plan to be agreed before writing code. Then work one step at a time.
- Explain every change in plain language, as if to an artist new to code.
- Don't use AI image generation in the system.
- If you're unsure a library, dataset or reference exists, say so.

## How the code is built

- Language and setup: [e.g. JavaScript with p5.js / Python with ...]
- Every parameter lives in config/params.json, with a default and a range.
- All randomness comes from one seeded generator. Same seed and params, same output.
- Outputs are saved to outputs/digital/ as NNN_seed-SEED_[key params].svg (or .png).
- Keep the code small enough for the student to read and explain.

## Don't touch

- data/ (raw data is read, never modified)
- outputs/ (never delete outputs)
- docs/photos/

## Run

[the command to run the system]
[the command to render a batch of seeds]

Fill in the brackets on Day 1 with what you know, and update it as the identity and the system settle. A short, true AGENTS.md is better than a long, generic one.

Git is your undo button and your record. Four habits cover the month.

1. Commit before you ask Codex for a change.

   Then you can always return to a version that worked.

   git add -A git commit -m "before: line weight from deficit"
2. Commit after every step that works.

   Small commits are easier to read and to undo.

3. Say what changed, not that something changed.

   "line weight follows deficit" tells a story; "update" doesn't. Log entries use log: day 07.

4. Push at the end of every day.

   Your laptop is not a backup. Pushing also lets the facilitator see the work.

   git push

Start with this and add to it.

# system files
.DS_Store
Thumbs.db

# dependencies and caches
node_modules/
__pycache__/
.venv/

# secrets: never commit these
.env
*.key

# large files: store on the studio drive instead
*.mov
*.mp4
*.zip
raw/

If you ever commit a password or key by mistake, tell the facilitator straight away. Deleting the file doesn't remove it from the history.

From Day 17 the repository is linked from the exhibition, so anyone can read it.

• Read it as a stranger would. Open the README on your phone. Does it make sense without you there?
• Check for anything private. Personal data, other people's photos without permission, keys or passwords.
• Credit your sources. Data in data/SOURCES.md, references in references.md, code you adapted in the README.

How the QR code is made and tested is in QR codes and documentation workflow.