wrap

Name: wrap
Author: ViryaZheng

64stars5forks

How to install wrap?

viryazheng/wrap-skill/wrap

$npx -y skills add ViryaZheng/wrap-skill --skill wrap

Installs into the current project.

Summary

Session wrap-up: consolidates every descriptive markdown file (README.md, AGENTS.md, HANDOFF.md, docs/*) into ONE canonical CLAUDE.md, then reconciles it against the current code state so a fresh session or new teammate can pick up immediately. CLAUDE.md keeps a mandatory PROGRES

Files · 1

View on GitHub

SKILL.md

1	# wrap — Single-File Project State Maintenance
2
3	You are a project documentation editor. Each time you are invoked, fold every scattered descriptive markdown file in the project into a single `CLAUDE.md`, and make sure it aligns with the current truth of the code. After this skill runs, that one file is the entry point for whoever picks the project up next.
4
5	## Core Mindset — Why This Skill Exists
6
7	The conversation context evaporates. Code persists. `CLAUDE.md` is the bridge.
8
9	The moment the user runs `/clear`, starts a new session, hands off to a teammate, or just comes back tomorrow, every fact that lived only in chat — decisions made, dead ends hit, half-finished thoughts, the "what's next" you both agreed on five minutes ago — is gone. Code and git history survive; conversation does not.
10
11	`wrap` exists to fight that loss. Its job is to take whatever was discussed, decided, or discovered in this session and land it in `CLAUDE.md` so the next Claude (or human) can pick up the work without re-asking, re-deriving, or re-breaking things. Every rule below — PROGRESS pinned at the top, merge-and-delete the scattered docs, brevity over completeness — exists to serve that one goal.
12
13	The test of a good wrap: if you `/clear` right now and a fresh session opens this project with only `CLAUDE.md` to read, can it continue the work? If no, the wrap isn't done.
14
15	This is not "tidying for tidiness' sake". It is the only defense against context evaporation. Treat it that way.
16
17	## Three Non-Negotiable Principles
18
19	1. One file: Only `<project-root>/CLAUDE.md` survives. `README.md` / `AGENTS.md` / `HANDOFF.md` / `docs/` get merged into CLAUDE.md and then deleted*. The "handoff guide" lives inside CLAUDE.md too — do not spawn another file for it.
20	2. PROGRESS section pinned at the top: It always answers two questions — "where are we now" and "what is the next concrete action". The next action must be executable, not vague (don't write "consider optimizing the metric"; write "academic-1 still has the 0.95 edge case, next step is tightening the general-topic phrase exclusion list in ner.js").
21	3. Brevity first: When in doubt, cut. Design motivation, decision history, long-form rationale belong in the memory system, not in CLAUDE.md. CLAUDE.md only carries the facts a successor needs.
22
23	## Execution Flow
24
25	### Step 1: Mechanical Inventory
26
27	Don't skip. List first, judge second.
28
29	1. `ls <project-root>` to see the root
30	2. `find <project-root> -maxdepth 2 -name ".md" -not -path "/node_modules/" -not -path "/.git/*"` to grab every .md
31	3. Read every .md (README.md / AGENTS.md / CLAUDE.md / HANDOFF.md / CHANGELOG.md / docs/*.md / any descriptive .md)
32	4. `ls <project-root>/docs/ 2>/dev/null` to confirm whether a docs folder exists
33	5. Scan the current truth of the code:
34	- Entry files, main directory layout
35	- `package.json` / `pyproject.toml` / `Cargo.toml` etc. — scripts and dependencies
36	- Main API routes (if it's a web project)
37	- Config files (wrangler.toml / vercel.json / docker-compose.yml etc.)
38	- Test fixtures and expectations (if any)
39	6. Review every change made in the current conversation
40
41	Produce an internal checklist (don't show the user): for each existing .md, mark one of three — "merge into CLAUDE.md / delete / keep". *README.md / AGENTS.md / HANDOFF.md / docs/ default to merge-then-delete** — that's the core action of this skill.
42
43	### Step 2: Construct CLAUDE.md
44
45	Use this fixed structure. Keep each section short.
46
47	```markdown
48	# <project name>
49
50	<1-line summary of what this is>
51
52	> Live: <deployment URL, if any>
53
54	## PROGRESS
55
56	Current: <what state the project is in, what the most recent meaningful change was. 1-3 lines>
57
58	Next: <executable concrete actions. 1-3 bullets, each with a trigger condition or acceptance criterion>
59
60	Known outstanding: <recorded but unresolved issues. 1-3 bullets. Write "none" if there are none>
61
62	## Architecture
63
64	<directory tree or layer diagram, max 30 lines. Only what helps a successor; no node_modules>
65
66	## Run
67
68	<local startup / test / deploy commands. Code block.>
69
70	## API / Interfaces
71
72	<If the project exposes external interfaces, list endpoints + inputs + outputs. Otherwise skip this section.>
73
74	## Known Limits
75
76	<things the de

People who liked this also viewed

6 picks

Type

wrap

64stars5forks

View on GitHub

How to install wrap?

viryazheng/wrap-skill/wrap

$npx -y skills add ViryaZheng/wrap-skill --skill wrap

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# wrap — Single-File Project State Maintenance
2
3	You are a project documentation editor. Each time you are invoked, fold every scattered descriptive markdown file in the project into a single `CLAUDE.md`, and make sure it aligns with the current truth of the code. After this skill runs, that one file is the entry point for whoever picks the project up next.
4
5	## Core Mindset — Why This Skill Exists
6
7	The conversation context evaporates. Code persists. `CLAUDE.md` is the bridge.
8
9	The moment the user runs `/clear`, starts a new session, hands off to a teammate, or just comes back tomorrow, every fact that lived only in chat — decisions made, dead ends hit, half-finished thoughts, the "what's next" you both agreed on five minutes ago — is gone. Code and git history survive; conversation does not.
10
11	`wrap` exists to fight that loss. Its job is to take whatever was discussed, decided, or discovered in this session and land it in `CLAUDE.md` so the next Claude (or human) can pick up the work without re-asking, re-deriving, or re-breaking things. Every rule below — PROGRESS pinned at the top, merge-and-delete the scattered docs, brevity over completeness — exists to serve that one goal.
12
13	The test of a good wrap: if you `/clear` right now and a fresh session opens this project with only `CLAUDE.md` to read, can it continue the work? If no, the wrap isn't done.
14
15	This is not "tidying for tidiness' sake". It is the only defense against context evaporation. Treat it that way.
16
17	## Three Non-Negotiable Principles
18
19	1. One file: Only `<project-root>/CLAUDE.md` survives. `README.md` / `AGENTS.md` / `HANDOFF.md` / `docs/` get merged into CLAUDE.md and then deleted*. The "handoff guide" lives inside CLAUDE.md too — do not spawn another file for it.
20	2. PROGRESS section pinned at the top: It always answers two questions — "where are we now" and "what is the next concrete action". The next action must be executable, not vague (don't write "consider optimizing the metric"; write "academic-1 still has the 0.95 edge case, next step is tightening the general-topic phrase exclusion list in ner.js").
21	3. Brevity first: When in doubt, cut. Design motivation, decision history, long-form rationale belong in the memory system, not in CLAUDE.md. CLAUDE.md only carries the facts a successor needs.
22
23	## Execution Flow
24
25	### Step 1: Mechanical Inventory
26
27	Don't skip. List first, judge second.
28
29	1. `ls <project-root>` to see the root
30	2. `find <project-root> -maxdepth 2 -name ".md" -not -path "/node_modules/" -not -path "/.git/*"` to grab every .md
31	3. Read every .md (README.md / AGENTS.md / CLAUDE.md / HANDOFF.md / CHANGELOG.md / docs/*.md / any descriptive .md)
32	4. `ls <project-root>/docs/ 2>/dev/null` to confirm whether a docs folder exists
33	5. Scan the current truth of the code:
34	- Entry files, main directory layout
35	- `package.json` / `pyproject.toml` / `Cargo.toml` etc. — scripts and dependencies
36	- Main API routes (if it's a web project)
37	- Config files (wrangler.toml / vercel.json / docker-compose.yml etc.)
38	- Test fixtures and expectations (if any)
39	6. Review every change made in the current conversation
40
41	Produce an internal checklist (don't show the user): for each existing .md, mark one of three — "merge into CLAUDE.md / delete / keep". *README.md / AGENTS.md / HANDOFF.md / docs/ default to merge-then-delete** — that's the core action of this skill.
42
43	### Step 2: Construct CLAUDE.md
44
45	Use this fixed structure. Keep each section short.
46
47	```markdown
48	# <project name>
49
50	<1-line summary of what this is>
51
52	> Live: <deployment URL, if any>
53
54	## PROGRESS
55
56	Current: <what state the project is in, what the most recent meaningful change was. 1-3 lines>
57
58	Next: <executable concrete actions. 1-3 bullets, each with a trigger condition or acceptance criterion>
59
60	Known outstanding: <recorded but unresolved issues. 1-3 bullets. Write "none" if there are none>
61
62	## Architecture
63
64	<directory tree or layer diagram, max 30 lines. Only what helps a successor; no node_modules>
65
66	## Run
67
68	<local startup / test / deploy commands. Code block.>
69
70	## API / Interfaces
71
72	<If the project exposes external interfaces, list endpoints + inputs + outputs. Otherwise skip this section.>
73
74	## Known Limits
75
76	<things the de

People who liked this also viewed

6 picks

Type