Skip to content
Skills Library
Documents & office · Writing

code-sync

/code-sync

Reconcile the project's documents with what the code now shows, after a merge or at the end of a build: spec statuses (building → done only with a named gate, or → stale with the reason), assumed specs owed ratification, the project README map and its Last verified date. Surgical edits only. Use when the user says "/memory-kit:code-sync", "sync the docs", "sync specs with code", "синхронизируй доки с кодом", "что устарело в спеках", or right after merging an executor branch.

Licence
MIT
Last repository change
13.11.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
1
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 13.11.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Reconcile the project's documents with what the code now shows, after a merge or at the end of a build: spec statuses (building → done only with a named gate, or → stale with the reason), assumed specs owed ratification, the project README map and its Last verified date. Surgical edits only. Use when the user says "/memory-kit:code-sync", "sync the docs", "sync specs with code", "синхронизируй доки с кодом", "что устарело в спеках", or right after merging an executor branch.

Triggers from the description

sync the docssync specs with codeсинхронизируй доки с кодомчто устарело в спеках
Original author description

Reconcile the project's documents with what the code now shows, after a merge or at the end of a build: spec statuses (building → done only with a named gate, or → stale with the reason), assumed specs owed ratification, the project README map and its Last verified date. Surgical edits only. Use when the user says "/memory-kit:code-sync", "sync the docs", "sync specs with code", "синхронизируй доки с кодом", "что устарело в спеках", or right after merging an executor branch.

How it works

  1. Step 0 — locate the projects
  2. Step 1 — inventory the specs
  3. Step 2 — every building spec against the code
  4. Step 3 — assumed specs owed ratification
  5. Step 4 — BACKLOG.md, only what you can prove
  6. Step 5 — the README map and Last verified
  7. Step 6 — report
  8. Dry run
  9. What NOT to do
Original SKILL.md headings · 136 lines, 1,359 words
SKILL.md preview
---
name: code-sync
description: >
  Reconcile the project's documents with what the code now shows, after a merge or at the end of
  a build: spec statuses (building → done only with a named gate, or → stale with the reason),
  assumed specs owed ratification, the project README map and its Last verified date. Surgical
  edits only. Use when the user says "/memory-kit:code-sync", "sync the docs", "sync specs with
  code", "синхронизируй доки с кодом", "что устарело в спеках", or right after merging an
  executor branch.
allowed-tools: Read, Grep, Glob, Edit(projects/**)
---

# /code-sync — documents reconciled against the repository

`close-session` reconciles the SESSION with memory. This reconciles a PROJECT's documents with
the CODE: every claim a spec still makes is checked against what is in the tree right now.

Two rails hold the whole skill up. **Evidence, never a claim** — a spec becomes `done` only from
a gate YOU ran in this session or a `Verified` cell someone already filled. **Surgical edits
only** — the only things you write are a status value, a `Verified` cell, one `Stale since:`
line, a map row, `Last verified:`, and a BACKLOG Done line. Everything else keeps its bytes.

## Step 0 — locate the projects

- `Glob projects/*/README.md`. If the repo keeps its documents elsewhere, read the root
  `CLAUDE.md` / `README.md` for the docs home and use the map it names. Nothing found → say so
  and stop. This skill never scaffolds.
- From each project README read two things: the map table ("Where this project's documents
  live") — the SSOT for where plans, QA records and the backlog actually are — and the
  `**Workflow tier:**` line, which sets how much evidence a `done` needs:

| Tier | Evidence a `done` needs |
|---|---|
| `prototype` | the gate output, run by you |
| `alpha` | + an integrator acceptance walk named in the `Verified` cell |
| `beta` | + a `qa/qa-run-*.md` record and tests naming each `AC-n` |
| `ga` | + a review pass and a `document` entry for the change |

- The user named one project → sweep only that one. Otherwise sweep all of them.

## Step 1 — inventory the specs

Read the header of every `plans/*.md` (`**Created:** YYYY-MM-DD · **Status:** …`; one grep over
the folder is enough). A plain `Status: …` line counts too, and a spec with no `Created:` takes its
date from a `YYYY-MM-DD-<slug>.md` file name — the SessionStart spec flags read them the same way.
A spec with no status line at all is counted as `no status` in the table, never guessed. Statuses are `draft · decided · building · done · assumed ·
stale`. Build the working table: spec · status · created · age in days.

`building` goes to step 2, `assumed` to step 3. `draft`, `decided`, `done` and `stale` are counted
and left untouched. A `superseded` spec (an older kit's status) is counted and named under Heads up
as one to delete — `reference/doc-governance.md` R3.

## Step 2 — every `building` spec against the code

Read its Acceptance table and its `## Gates` block in full. For each `AC-n` row hunt evidence in
this order and stop at the first that holds:

1. the row's `Verified` cell is already filled (date + pointer) → taken as is;
2. a QA run record naming the id — `grep -l "AC-3" projects/<name>/qa/qa-run-*.md` — and it
   records a pass;
3. a test that names the id (grep the test tree for the id), in a suite the gate below runs;
4. **the gate**: run the commands from the spec's `## Gates` block yourself, from the repo root,
   and read the output. A gate you did not run is not evidence.

Report per AC: evidence found (what · where) or missing. Then exactly one of:

- **All ACs have evidence** → set the status line to `done` and fill each `Verified` cell you
  earned with `YYYY-MM-DD · <the command you ran, or the record>`. Cells already filled stay as
  they are.
- **The code contradicts the spec** → check the spec's Slices "Files it owns" and the interfaces
  it names: `Glob`/`Grep` each one. A named file gone, a symbol renamed, a signature the spec
  depends on changed → set the status to `stale` and append, directly under the status line, one
  line: `**Stale since:** YYYY-MM-DD — <reason, file:line>`. A `stale` spec is never also `done`.
- **Anything else** → leave `building` exactly as it is and name what is missing: which `AC-n`,
  and what evidence would settle it. Half-evidence is not a flip.

## Step 3 — `assumed` specs owed ratification

An `assumed` spec is an executor's recorded override, not a decision. List every one of them:

| Assumed spec | Parent spec | Owed decision | Authorized by | Age |
|---|---|---|---|---|

Take Owed decision from the file's `## Owed decision` section, one line, and the authorizer from
its header. Print the table under the heading **Owed ratification** and recommend which to take
first (the oldest, or the one whose Code area the current work touches).

**Never flip or edit an `assumed` spec yourself.** The kit has no architect skill: the main
session deliberates, then either writes the real spec and deletes the assumed one (its live
references repointed in the same change), or confirms the assumption and flips it to `decided`. Your output is that agenda, nothing more.

## Step 4 — BACKLOG.md, only what you can prove

A task moves to `## Done` only when BOTH hold: its `**Spec:**` points at a spec you flipped to
`done` in step 2, AND every box in its Acceptance list is already ticked. Then move it as one
line, newest first, in the file's own format:

```
- [YYYY-MM-DD] T-NNN — <its one line> · verified by `<the gate you ran>`
```

Everything else in that file — priorities, ordering, wording, `TODO` / `IN PROGRESS` / `BLOCKED`
statuses — is untouched. Never tick an acceptance box yourself: an unticked box is the
integrator's open question, not your paperwork.

## Step 5 — the README map and `Last verified`

For every document class that now has files on disk but no row in the map table, add the row
(Class · Path · Written by), using the classes the project template already names: Tasks ·
Plans / specs · Research + evidence · Decisions ledger · Review-finding classes · QA protocol +
runs · Client materials. An empty folder is not a row. A row that points at the wrong place is
the integrator's call — report the mismatch, don't repoint it. Then set `**Last verified:**` to
today. Nothing else in the README changes.

## Step 6 — report

Four lines, the kit's shape:

- **Headline:** `N specs reconciled: a done · b stale · c still building · d assumed owed`.
- **Next:** the ONE command or decision that moves this forward — the gate that would close the
  nearest `building` spec, or the assumed spec to ratify first.
- **Heads up:** only if a spec went `stale` or one is left to delete — one line each, spec + reason.
- **Pointer:** the files you edited, as paths.

## Dry run

With the argument `--dry-run` — or when the user says "just show me" / "покажи, не трогай" — do
the whole walk and run the gates (reading is not writing), but print the plan of edits as a
table (file · line · from → to) instead of applying it. Nothing is written, not even
`Last verified:`. Close with the same four-line report plus the command to run it for real.

## What NOT to do

- **Never rewrite prose or a whole section.** The six writable things are listed at the top; if
  a fix needs anything else, report it instead of doing it.
- **Never mark `done` from a claim** — not an executor's report, not a subagent's summary, not
  "the tests should pass". Run the gate yourself (`reference/orchestrator-fact-check.md`).
- **Never flip or edit an `assumed` spec.** You list it; the integrator decides.
- **Never touch** `.claude/memory/MEMORY.md`, `context/handoffs/`, `knowledge/` or
  `.claude/rules/` — promotion lives in `/memory-kit:close-session`, on the user's yes.
- **Never create a file.** This skill creates none: no spec, no run record, no report file.
- **Never delete a document yourself.** A spec no work needs is deleted by the main session, with
  its live references fixed in the same change — the past lives in git (`reference/doc-governance.md`,
  R3). You name it under Heads up; `stale` is a status you set, not a removal.
- **Don't touch** a `draft`, `decided`, `done` or `superseded` spec at all — they are not yours
  to reconcile.

Versions

RepositoryScoreLicence
This page · awrshift/agent-memory-kit100MIT
awrshift/claude-memory-kit100MIT

Database snapshot: 13.11.2026 · package version 20c487f99c83 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100sync-docs-site
    Bring the user documentation in docs-site/ up to date with Folio's released features, from CHANGELOG.md, the README and the code. Use when the user asks to update, sync or check the docs site, after a release, or when a feature change should be reflected in the user docs.
  • 90align-docs
    Cross-check a project's documents against each other and against the code so they agree, don't duplicate content, and make no claim the project can't back up. Use when the user asks whether docs, plans, specs, reports, references and code are "aligned", "consistent", "in sync",…
  • 100sync-context
    After a change lands, brings the shared context in line with the code (roadmap statuses, AGENTS.md commands, known issues, env vars, architecture lists) with surgical edits that add lines and never rewrite curated prose. Flags specs the change made stale. Use when a slice is…
  • 85write-the-docs
    Write or edit project documentation. Use when writing a README, design doc, or module doc.
  • 100skill-doc-sync
    Post-ship doc sync across project markdown. Use when: sync docs, update docs, document changes, release notes.
  • 90sync-docs
    Bring harness-eval's CLAUDE.md files, architecture docs, and manifests back in line with the current code. Use when the user asks to sync or audit docs, or after structural changes.

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.