Stop explaining your project again: a two-session Cricino walkthrough

coming back to a project shouldn't mean reconstructing yesterday from memory.

i built Cricino because i kept doing exactly that. here's a small example of what it can look like in practice, including the parts that still need your judgment.

The bookmark app below is a fictional example. These instructions were checked against the published package; this article does not report an executed installation or tests.

1. Start with a small project

Imagine a bookmark app. Your next milestone is CSV export. PDF export can wait.

Open an existing Git repository in your coding tool and give it this prompt:

Install Cricino in this repository using https://github.com/ABBAS1947/cricino/blob/main/INSTALL.md. Read the contract and existing project instructions first. Ask me about missing goals, scope, approval rules and the project's gate. Preserve existing instructions and changes. This authorizes workflow setup only. Do not change application code, run application tests, execute gates, commit or publish anything.

The instructions ask your assistant to configure the workflow, rather than leave you with a pile of empty templates. They also permit ordinary file tools if Python isn't available. The optional installer requires Python 3.10+ and defaults to a read-only preview; you should inspect its source and proposed paths before using its apply option.

2. Answer the questions that matter

For this example, the answers could be:

• Goal: a personal bookmark app; finish CSV export next.
• Scope: export work only. Leave authentication and storage unchanged.
• Knowledge: keep project records in repository Markdown. Link existing decisions instead of copying them.
• Authority: planning and workflow documentation are permitted. Ask before application edits, tests, gate execution, commits or publishing.
• Quality: accessible controls, predictable output and no changes outside scope.
• Gate: retain the project's existing requirements. A new gate stays a draft until its requirements and adoption are approved.

Those are example answers, not universal defaults. A school application and a personal bookmark app need different requirements. Cricino supplies a gate structure, not a ready-made compliance verdict.

3. Check what was installed

The published installer uses this layout:

AGENTS.md                  existing instructions plus a bounded pointer
docs/cricino/
  README.md                operating contract
  context.md               goal, milestone and active-task link
  decisions.md             decisions index
  holds.md                 paused-work index
  research.md              research index
  activity.md              brief session entries
  tasks/CR-SETUP.md         setup checkpoint
  LICENSE
.cricino/
  installation.json        setup receipt
  .gitignore
  AGENTS.before            backup, when prior instructions existed

Don't publish the instruction backup automatically. Check preserved instructions, actual changed paths, working links and remaining unknowns. Ask the assistant to distinguish installed, adapted and enforced. Having these files does not establish that your tool loads them or that CI enforces them.

4. Leave a useful first-session checkpoint

Use the task template for a stable task such as CR-2026-001. In this example, the owner has approved planning only:

Objective: export saved bookmarks as CSV.
Scope: export only; authentication and storage excluded.
Authorization: planning only, from the owner's session instruction.
Acceptance: title and URL columns; predictable escaping;
an accessible export control; no unrelated changes.

Implementation: not started.
Verification: not run.
Gate: execution not approved.
Documentation: plan and decision recorded; context links to this task.
Release: not authorized.
Exact revision/diff covered: record the actual inspected revision here.
Next permitted action: request approval for scoped implementation.

This is illustrative text. In a real task, record the actual approval and revision. A blank revision is missing evidence, not a passing check.

Put PDF export in the holds record with its reason and resume condition. Keep the detailed CSV plan in the task; the current-state summary just links to it.

5. Restart without guessing

Next session, even if you've switched tools, try:

Read the project's instruction entry point, Cricino context, active task and relevant decisions and holds. Inspect Git status and compare the current revision and relevant diff with the task's recorded checkpoint. Summarize the objective, authorized next action and any stale context. Do not resume held work or treat earlier planning as approval to implement.

The intended result is a short answer: CSV is active, PDF is parked, implementation still needs approval. If code has changed, the assistant should reconcile the affected task before relying on its old checkpoint. The public scaffold does not automatically monitor Git or enforce freshness; this comparison is a requested workflow step.

Suppose you now decide exports should use a fixed filename instead of a date. Record a dated decision that supersedes the earlier filename choice, and update the active task. Keep the old decision's history. No need to paste the entire discussion into every document.

6. Keep the paperwork small

Each fact needs one home:

End a session with a brief activity entry and documentation dispositions: updated, reviewed unchanged, not applicable with a reason, or pending with the missing action. Don't rewrite unchanged documents just to make them look fresh.

What this does and doesn't solve

Cricino gives your assistant a place to retrieve goals, decisions and unfinished work. It can reduce what you need to carry in your head. It still depends on accurate records and a tool that actually reads them.

It doesn't guarantee obedience, replace code review, prove accessibility or security, enforce permissions, or turn a checklist into certification. Tests and independent access controls remain separate. Don't hide failed checks behind a tidy handoff.

Try it on one task first. At your next session, check whether the assistant retrieves the right scope and next action. If it doesn't, that failure is useful feedback too.

I'd be interested in where it becomes useful for you, and where the documentation starts feeling like extra work.