DEV Community: Meesam Abbas

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

Meesam Abbas — Wed, 07 Oct 2026 09:04:22 +0000

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:

Information	Owner record
Task scope, work and actual checks	Active task
Durable choice and supersession	Decision record
Findings and source limitations	Research record
Paused idea and resume condition	Holds record
Where work stands now	Short context summary

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.

I kept re-explaining my project to Codex, so I built Cricino

Meesam Abbas — Tue, 06 Oct 2026 19:08:23 +0000

I'm building my first application, and I have really bad memory. probably not the best combination lol.

I use Codex for a lot of the work. We'd make a decision, fix something, leave another idea for later, and then the next session I'd be trying to remember how all of it connected.

The code was there. The reasoning was scattered.

I made Cricino because I wanted a better starting point than explaining the same things again.

A one-minute overview

Watch the narrated Cricino video

The animation uses synthetic narration and original music. It's an illustrative overview, not a recorded installation or proof of performance. The rest of this post explains the idea in text.

The checklist wasn't enough

A checklist helped me remember what to check. It didn't tell the next session which decision was current, what we had put on hold, or what had actually been verified.

I was still the person connecting all the pieces.

So the idea became simple: give the project a short entry point that leads to its goal, decisions, current work and parked ideas. Leave a useful handoff when the session ends.

The assistant has something concrete to read. I have something concrete to review.

Start with your own rules

Cricino includes a guide, templates and an optional installer. The setup is meant to ask about your project before adapting the records.

Things like:

What are you trying to build?
What is outside the scope?
Which actions need your approval?
Which checks matter for this project?
Where should decisions and unfinished work live?

My application's checks are specific to my application. Copying them into somebody else's project would make little sense. Cricino provides a structure for defining those checks.

You can start with the public repository and its INSTALL.md. Give the setup document to your coding assistant, have it read the procedure, and review the proposed changes before applying them. Existing project instructions should be preserved.

A small example

Imagine you're building a bookmarks app. You decide that the first export format will be CSV, and PDF export can wait.

A useful record would say:

Current decision: CSV export for the first version.

Parked work: PDF export. Don't start it as part of this task.

Next task: implement CSV export using the current decision.

Verification: pending until the checks are actually run.

That's an illustrative example, not output from an executed installation.

At the end of the work, the handoff should say what changed, what was checked, what failed, and what the next step is. If checks haven't run, it should say that.

Try starting another session and see whether the assistant can find the decision and parked work from the records. If you have to quietly explain both again, the setup needs improvement.

I also created too much documentation

At first, the same update could end up in several places. That gave me more things to maintain and more chances for them to disagree.

The improvement was to keep the details in one place and link to them from the other records.

The entry point can stay short. The task can point to the decision. The handoff can point to the work and evidence. Every file doesn't need to retell the entire story.

What this doesn't solve

Cricino isn't a background memory service. The assistant still needs to read the records and maintain them.

If a decision is stale, a link is broken, or a session forgets to update the handoff, the system can still mislead the next session. A written rule also doesn't enforce a permission by itself. Use actual checks and access controls where you need enforcement.

It doesn't guarantee correct code, compliance, or a bug-free release. I haven't measured a universal speed improvement or token saving, either.

What I'm trying to make easier is the handoff: what we're doing, why, what we're leaving alone, and what happens next.

Try it somewhere small

The guide and templates are MIT licensed. Start with a small project and see whether the next session can pick up the right context.

I'd especially like feedback on the setup questions and the amount of documentation. Where does it help, and where does it become another chore? :)