tools-registry-context

Name: tools-registry-context
Author: superdesigndev

56stars5forks

How to install tools-registry-context?

superdesigndev/tools-registry/tools-registry-context

$npx -y skills add superdesigndev/tools-registry --skill tools-registry-context

Installs into the current project.

Summary

tools-registry context + doc upkeep. Use to warm up a fresh session (orient on the architecture + recent commits) or when working on tools-registry — changing code, rules, content, data, or process (proxy · auth/secrets · API · CLI · the registry skill) — loads the relevant fragm

Files · 1

View on GitHub

SKILL.md

1	# tools-registry-context — load the right design fragment, keep docs honest
2
3	tools-registry's design docs are fragments under `docs/context/` (one per subsystem), each declaring the
4	source files it covers in frontmatter. [`MAP.md`](MAP.md) (next to this file) is the generated reverse
5	index: source file → the fragment that documents it. This skill has two modes.
6
7	## Mode A — LOAD context (default). Adapt to when you're called:
8
9	Cold start (a fresh session, little/no prior context) → warm up. Read
10	[`docs/context/README.md`](../../../docs/context/README.md) (the index), then the fragments that matter
11	(the `foundation`-style overview fragments plus whichever subsystems the query or repo state points at).
12	Run `git log --oneline -15` and `git status` to catch recent commits + uncommitted work. Then give a
13	short orientation — what tools-registry is, the subsystems in play, what changed recently — and say you're ready.
14
15	Mid-chat (a task/topic is already in play) → stay targeted. Map the artifacts/topic at hand via
16	[`MAP.md`](MAP.md)'s "Source file → fragment(s)" table, read just those fragment(s), and proceed.
17	Don't re-warm the whole tree.
18
19	A focus query (`/tools-registry-context <query>`) always wins — use it to pick the fragment(s) and
20	focus the warm-up on that area, in either case.
21
22	Always: read the data model / behavior / RCAs / symbol anchors before changing anything; load only
23	what's relevant (never dump the whole tree); if an artifact you touch has no fragment, note it as a
24	gap for Mode B.
25
26	## Mode B — SYNC docs (`/tools-registry-context sync`, or before a push)
27
28	Before a push to the main branch, remind the user to run this; proceed only on their yes. Then
29	follow [`MAINTAINING.md`](MAINTAINING.md) — the short version:
30
31	1. Detect drift: `bash .Codex/skills/tools-registry-context/scripts/drift.sh` (defaults to
32	`origin/main..HEAD`). It prints, per changed source, which fragment(s) document it — plus gaps.
33	2. Draft updates: for each affected fragment, read it + the diff; update prose to match changed
34	behavior and verify cited symbols still exist (no line-number chasing — symbols don't drift).
35	New subsystem with no fragment → draft a new fragment from `fragment.md.tmpl`.
36	3. Show, then apply: present proposed changes and get approval before writing.
37	4. Regenerate: `python3 .Codex/skills/tools-registry-context/scripts/build-map.py` (rewrites README + MAP).
38	5. Commit together: doc updates ride with the code in the same commit/push.
39
40	## Invariants
41
42	- Docs are the source of truth; this skill is a lens. Fragments live in `docs/context/`; never
43	duplicate them into the skill. The skill holds only the generated `MAP.md` + scripts + config.
44	- Frontmatter drives everything. A fragment's `sources:` feeds the index, the MAP, and drift. When a
45	fragment starts covering a new file, add it to `sources:` and rerun `build-map.py`.
46	- Cite stable symbols, not line numbers. Anchor every claim to a grep-able symbol; bare line
47	numbers drift on every edit and slow sync. Describe what shipped, not intent.
48	- No automation behind the user's back. Sync is reminder → approve → apply. There is no git hook.
49	- Handoffs and plans are NOT documentation. They live outside `docs/context/` (e.g. `.context/`) and
50	are out of scope — never read, fold in, or scan them as fragment input.

People who liked this also viewed

6 picks

Type

tools-registry-context

56stars5forks

View on GitHub

How to install tools-registry-context?

superdesigndev/tools-registry/tools-registry-context

$npx -y skills add superdesigndev/tools-registry --skill tools-registry-context

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# tools-registry-context — load the right design fragment, keep docs honest
2
3	tools-registry's design docs are fragments under `docs/context/` (one per subsystem), each declaring the
4	source files it covers in frontmatter. [`MAP.md`](MAP.md) (next to this file) is the generated reverse
5	index: source file → the fragment that documents it. This skill has two modes.
6
7	## Mode A — LOAD context (default). Adapt to when you're called:
8
9	Cold start (a fresh session, little/no prior context) → warm up. Read
10	[`docs/context/README.md`](../../../docs/context/README.md) (the index), then the fragments that matter
11	(the `foundation`-style overview fragments plus whichever subsystems the query or repo state points at).
12	Run `git log --oneline -15` and `git status` to catch recent commits + uncommitted work. Then give a
13	short orientation — what tools-registry is, the subsystems in play, what changed recently — and say you're ready.
14
15	Mid-chat (a task/topic is already in play) → stay targeted. Map the artifacts/topic at hand via
16	[`MAP.md`](MAP.md)'s "Source file → fragment(s)" table, read just those fragment(s), and proceed.
17	Don't re-warm the whole tree.
18
19	A focus query (`/tools-registry-context <query>`) always wins — use it to pick the fragment(s) and
20	focus the warm-up on that area, in either case.
21
22	Always: read the data model / behavior / RCAs / symbol anchors before changing anything; load only
23	what's relevant (never dump the whole tree); if an artifact you touch has no fragment, note it as a
24	gap for Mode B.
25
26	## Mode B — SYNC docs (`/tools-registry-context sync`, or before a push)
27
28	Before a push to the main branch, remind the user to run this; proceed only on their yes. Then
29	follow [`MAINTAINING.md`](MAINTAINING.md) — the short version:
30
31	1. Detect drift: `bash .Codex/skills/tools-registry-context/scripts/drift.sh` (defaults to
32	`origin/main..HEAD`). It prints, per changed source, which fragment(s) document it — plus gaps.
33	2. Draft updates: for each affected fragment, read it + the diff; update prose to match changed
34	behavior and verify cited symbols still exist (no line-number chasing — symbols don't drift).
35	New subsystem with no fragment → draft a new fragment from `fragment.md.tmpl`.
36	3. Show, then apply: present proposed changes and get approval before writing.
37	4. Regenerate: `python3 .Codex/skills/tools-registry-context/scripts/build-map.py` (rewrites README + MAP).
38	5. Commit together: doc updates ride with the code in the same commit/push.
39
40	## Invariants
41
42	- Docs are the source of truth; this skill is a lens. Fragments live in `docs/context/`; never
43	duplicate them into the skill. The skill holds only the generated `MAP.md` + scripts + config.
44	- Frontmatter drives everything. A fragment's `sources:` feeds the index, the MAP, and drift. When a
45	fragment starts covering a new file, add it to `sources:` and rerun `build-map.py`.
46	- Cite stable symbols, not line numbers. Anchor every claim to a grep-able symbol; bare line
47	numbers drift on every edit and slow sync. Describe what shipped, not intent.
48	- No automation behind the user's back. Sync is reminder → approve → apply. There is no git hook.
49	- Handoffs and plans are NOT documentation. They live outside `docs/context/` (e.g. `.context/`) and
50	are out of scope — never read, fold in, or scan them as fragment input.

People who liked this also viewed

6 picks

Type