Agentic Engineering

Your coding agent starts every session from zero, and you never see what it got wrong.
This finds out. It asks your agent five questions about your repo, cold, writes a small docs/ layer from your real code, then asks the same five again and prints the score.

The kit is one layer of the method I teach in Prompt to Production. One full module is free.

⭐ If you find this useful, please star the repo so more developers can find it.

Your agent can read your code. It can't read the decisions behind it. Where does a new file go here? Why this database and not the obvious one? None of that is in the repo, so the agent guesses with whatever was most common in its training data.

So you write those decisions down where the agent will read them. By hand that's an afternoon per repo. This does it from your real code instead.

Not a Spec Kit replacement. Spec Kit writes a spec, then builds the code from it. This reads the code you already have and writes the memory your agent is missing. Use both.

Run it

Paste this to the agent already working in your repo:

Clone https://github.com/NirDiamant/Agentic_Engineering into a temp folder, read its RUN.md, and follow it on this repository.

What it promises you:

• It writes docs/, one instruction file at your repo root (plus a one-line pointer if your tools need the other name), a scorecard beside it, and the kit's two commands into .claude/commands/. Nothing else changes.
• It deletes nothing of yours and overwrites nothing of yours. Your files are read as input. The most it does to one is append a dated entry to a log that is already append-only.
• It stops once, for your approval, before it writes the layer. The only thing on disk before that is your scorecard.
• About fifteen minutes.

The check

Before it reads your code it answers five questions about your repo, cold. After the docs exist, it answers the same five again reading only what this run wrote, and prints the score, plus a count of the claims in your own docs that your code contradicts:

AGENT MEMORY CHECK: seo-autopilot
Before the docs layer:  3 of 5 questions right
After:                  5 of 5
It was guessing about:  which tools are installed vs only planned; the conventions the linter actually enforces; that packages/db is wired to nothing
Contradictions found in your existing docs: 5
Written:                CLAUDE.md + 4 docs, 4 unconfirmed
Still advisory: nothing enforces these rules. That takes hooks, tests, CI.

A real run on a real repo, not a mock-up. It went 3 to 5, and the interesting half is the 3. That repo has a good README and a
600-line spec, so the agent had plenty to read. It read all of it and still named two
tools that are installed nowhere in the tree, because they sit in the spec as a plan.
It reported the plan as the stack, with the label SURE on it.

The contradictions line is the five claims in that repo's own README and spec that its
code disproves: two tools named in the spec that no package installs, a scheduler the
spec never chose doing the work, an upload the docs call unbuilt that shipped. Zero is
a normal answer on a repo whose docs are current.

What goes into your repo

Each file answers one question your code can't. Here is TECH_STACK.md, filled in:

- **Database:** PostgreSQL
- **Why Postgres:** the team already knows it, and we don't need anything fancier.

The second line is the one that matters. Your code already shows that you use Postgres. Why you chose it lives in someone's head, and an agent that never heard the reason will swap it for whatever it saw more often in training.

Keeping it alive

When the agent gets something wrong: "update CLAUDE.md so you don't repeat that, and tell me which old rule can come out."

When you stop for the day: "update docs/context/CONTINUE_PROMPT.md with where we are and what's next."

No code yet?

/start-project builds the same layer for a stack you've already chosen, plus SETUP.md, DEPLOYMENT.md, CI_CD.md and TESTING.md. /spark is for when it's still an idea: experimental, and it needs two skills that don't ship here, /harness-plan and /harness-unleash. Both are skills, so they need one extra step to install. The reasoning under all of it is in docs/why_this_works.md.

What this doesn't do

Your agent reads these files and tries to follow them. Nothing forces it. A rule that has to hold every single time belongs in a hook, a test, or a CI gate, and none of that ships here. Those layers are where the full method lives.

The final check is one model checking another. It catches empty placeholders and docs that contradict the code. It can't tell you the docs are true.

And it checks itself best in Claude Code. The after score is meant to be answered by a fresh reader, which means a sub-agent. Claude Code has them. Codex, Cursor and Copilot do not, so there the same session that wrote the files also grades them, and your card says so on its own line. Treat what you get in those tools as a first draft and read it before you trust it. A first draft of this carries real errors, and a confident wrong file is worse than no file.

🎓 From a docs layer to production

📫 Stay Updated

Contributing. Sharpen /apply or tighten a template. Issues and PRs are welcome. Apache 2.0, see LICENSE, and copy the output into any project, commercial ones included. These are starting points and not guarantees. They don't replace tests, review, or judgment.

More open-source guides: RAG · Agents · Prompting · Agent memory

_{If this saved you a session of re-explaining your project, a star helps other people find it.}