laurence
4a18048542
Merged into git.discworld.casa/laurence/astrophotography on 2026-07-21, where it lives on as the itelescope/ directory alongside the processing pipeline, with both histories preserved. The notice goes in CLAUDE.md as well as README.md deliberately: under the Default Workflow a session reads CLAUDE.md first, and the drain campaign is live with runs most nights, so a concurrent session needs to see the redirect before it starts work rather than after it has committed. Not archiving yet. The campaign runs until 10-12 Aug and nothing should break mid-flight; archive once it closes.
3.2 KiB
Important
This repository has moved. Since 2026-07-21 it lives on as the
itelescope/directory of astrophotography, merged with the processing pipeline. Both histories were preserved.Do new work there, not here. This copy is kept read-only-in-spirit until the drain campaign closes (10-12 Aug 2026), because sessions are running most nights and nothing should break mid-campaign. Anything committed here after the merge will be stranded.
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
-
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.
-
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. -
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.
-
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.
-
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
- Read
state/PROJECT.md,state/TODO.mdandstate/DECISIONS.md(cheap, small). - Check
git log --oneline -15andgit statusto see where things stand. - Do the work under the rules above.
- Before ending, update the
state/files so the next session needs no chat history.
Detailed docs
- Project setup - starting a new project on this workflow
- Workflow - branch, commit, PR and merge process
- Cost and tokens - keeping usage within limits
- Documentation policy - comments, and docs in a separate session
- User expectations - how the user wants Claude to behave