itelescope/CLAUDE.md
Laurence 3fad877dee Bootstrap: Default Workflow scaffold
Repo created for a reference/review of the iTelescope.net remote telescope
network. This commit copies the Default Workflow in (CLAUDE.md and docs/ from
the Default-Workflow repo), adds a .gitignore (secrets and scratch), and fills
in state/PROJECT.md with the objective: review every telescope on the network
and provide a choosing guide, using only public sources (support article and
the maintained Google Sheet; the go.itelescope.net launchpad is login-only).
2026-07-17 14:20:36 +01:00

2.6 KiB

Default Workflow

This file is the entry point for any Claude Code session working under the Default Workflow. Keep it small and read the detailed docs on demand so a session does not load everything at once (see Cost and tokens).

What this is

A standard operating procedure for building software with Claude Code. It defines how a project is set up, how features are branched, committed, reviewed and merged, how documentation is produced, and what the user expects. Copy this workflow into a new project (see Project setup) and follow it.

The five rules

  1. Minimise cost. Staying within usage limits matters more than speed. Prefer cheap actions over expensive ones. Read only what you need. Subagents and parallel processing are allowed when they are the effective path (see User expectations). See Cost and tokens.

  2. State lives in the repo, not the chat. Do not rely on chat history, context, or cache to remember decisions, todos, notes, architecture, or objectives. Write them to the committed markdown files under state/ so a fresh session can pick up with no prior context. See Documentation policy.

  3. Every feature is a branch. Create a branch, commit with full notes in each message, open a PR describing the feature, the tools used and what was achieved, then merge into the trunk. See Workflow.

  4. Code and its documentation are written in separate sessions. The building session comments the code well enough that a later, cold session can write the docs from git history and comments alone. See Documentation policy.

  5. Comment for a stranger. Assume the next session has no memory of why you did anything. The commit history and code comments are the only record.

Start of every session

  1. Read state/PROJECT.md, state/TODO.md and state/DECISIONS.md (cheap, small).
  2. Check git log --oneline -15 and git status to see where things stand.
  3. Do the work under the rules above.
  4. Before ending, update the state/ files so the next session needs no chat history.

Detailed docs