Not a reset.
An evolution.

Background

The project had been running for 13 days with an organically grown cross-session knowledge system already in place.

That system — structured SKILL.md files placed near the code they describe, loaded on demand, maintained alongside code, paired with a file-based issue tracker — was the direct prototype the Grid was built from. The Grid is its generalization. Every core mechanism traces back to something that emerged in practice on this project.

This migration was the first real-world test of initializing the Grid in a project that invented the concept.

Phase 1 — Initialization

Trigger

User prompt: "Initialize the Grid from G667 at GitHub."

The model resolved G667 as the GitHub user, found the grid repository, fetched SKILL.md, and followed the initialization protocol from there — without any further instruction on what the Grid was.

What the model did

• Fetched the Grid's core files from GitHub and installed them under .grid/
• Confirmed the user's AI clients — all four — and installed the corresponding bootstrap rules
• Initialized session state and populated the skill registry via the skill scanner
• Installed optional programs: issue tracker and git integration
• Chose commit message pattern: Grid house style

Project survey (Step 6)

The model surveyed the project and independently raised the key tension:

"The existing skills/maintain-skills/SKILL.md and the Grid's .grid/system/maintain-skills/SKILL.md now overlap in purpose. We should discuss how they relate — whether the Grid's version supersedes, wraps, or defers to the existing one."

The user's response confirmed the migration plan: the old system would coexist with the Grid until all knowledge was replicated into isos, then be retired.

Knowledge migration

The model mapped all 11 existing skill files to Grid iso locations, applying the locality principle: module-level skills moved from a centralized skills/ directory into paths next to the code they describe.

Phase 2 — Issue migration

The project had 161 issues in a JavaScript file using string values for type, area, priority, and status. The Grid's issue tracker uses config-driven numeric IDs. A direct conversion required first discovering all category values in the data, building the tracker config, then migrating each issue.

The model wrote a single Python migration script rather than making 161 individual add calls. It discovered the category values, built the config, and wrote the new issue file directly — atomic, with no partial-state risk.

Categories discovered in the data:

• Types: Implementation, Discussion, ArchitecturalDecision, Learning, Security, Improvement
• Areas: business, persistence, rest, api, infra, security, skills, general, platform, core, ide
• Priorities: high, medium, low
• Statuses: pending (active), done (terminal)

Result: 53 active + 108 done = 161 issues. Exact match. All timestamps and descriptions preserved.

Phase 3 — Cleanup

21 files identified for removal across 10 directories: the original skill files, issue tracker, bootstrap, and legacy scripts.

The hidden design document

During cleanup, the model encountered a file with no frontmatter — not a SKILL.md, invisible to the skill scanner. It would have been silently deleted.

It contained rich design rationale: the reasoning behind a key architectural decision, the full vocabulary of a core subsystem, and the vision for where it should evolve. Years of thinking in a single unstructured document.

Rather than discarding it or folding it into an existing iso, the model proposed a dedicated iso for that subsystem. The architecture iso was trimmed and cross-linked to it. The resulting iso captures more design rationale than had ever existed in a structured skill file.

Final state

Skill registry — 26 skills

Grid system (3) · Programs (12, including issue tracker and git integration) · Project isos (11): project overview, code style, architecture, golden example, permission model (new), API spec, business layer, persistence, REST layer, infra, IDE setup.

Issue tracker

53 active issues (9 high, 24 medium, 20 low) · 108 closed · browser UI accessible via file:// — no server.

Verification

Lessons

What worked

• The model recognized the migration context without being told. During the survey it independently identified the overlap with the prototype system and proposed migration — it did not attempt to duplicate or override.
• Bulk migration over many individual calls. Writing a direct Python migration script was faster and atomic.
• A new commit type defined mid-session. The user introduced a new type during the first commit. The model added it to the commit convention file in the same commit — demonstrating the skill-update-in-same-commit discipline without being reminded.
• The hidden design document. A file with no frontmatter was read, understood, and preserved as a richer knowledge artifact than what existed before.

Points of friction

• Git conventions mapping. The first instinct was wrong — a single iso that would have duplicated rules already owned by two Grid programs. User pushback produced the correct distribution.
• Architecture iso over-accumulation. After content from the newly discovered subsystem was initially added to the architecture iso, it grew too large. Required a subsequent trim. Better to create the dedicated iso first and reference it from the parent.