Migrate scripts/ to git-repokit-common subtree
Context
The scripts/ directory in this repo was copied from the comfydbg template at project creation (late March 2026). The source of truth for these shared utilities lives at C:\code\git-repokit-common\, but we never hooked up a subtree relationship -- each script is a plain file, frozen at whatever comfydbg had committed at fork time.
Current state
Our scripts/ contains:
build_demo.py
demo_render.py
extract_tool_result.py
gh_issue_full.py
gh_sub_issues.py
hooks/
install-hooks.sh
paths.sh
safe_move.sh
search_sesslog.py
sync-versions.py
update-version.sh
vhs/
git-repokit-common/ has the same files plus additional infrastructure we don't have:
VERSION
README.md
CONTRIBUTING.md
LICENSE
demo/
docs/
private/
tests/
update-common.sh
The problem
Any bug fixes or improvements made to git-repokit-common since late March 2026 are not in our copy. We have no mechanism to pull updates. If gh_issue_full.py gains a new feature in the upstream common repo, we'd have to manually copy the change over.
This affects every project spawned from comfydbg, not just csb.
Options
Option A: Subtree add
cd C:/code/claude-projects/Claude-Session-Backup
# Remove the copied files first (to avoid merge conflicts)
git rm -r scripts/
git commit -m "chore: remove copied scripts before subtree add"
# Add as subtree
git subtree add --prefix=scripts https://github.com/djdarcy/git-repokit-common.git main --squash
Pros: Clean, standard approach. git subtree pull for updates. Fits the RepoKit convention.
Cons: Requires the upstream repo to be at a public URL (or accessible via ssh). Need to verify what's at https://github.com/djdarcy/git-repokit-common -- may not be pushed.
Option B: Subtree with a subdirectory
Keep scripts/ as project-specific, add scripts/common/ as the subtree. Lets us have both shared and project-specific scripts coexist.
git subtree add --prefix=scripts/common https://github.com/djdarcy/git-repokit-common.git main --squash
Pros: Non-destructive, preserves any project-specific additions we've made to scripts/.
Cons: Double-nested, slightly more verbose paths.
Option C: Defer
Leave the copied scripts as-is for now. Document as known tech debt. Address in a cleanup pass across all DazzleML projects later.
Pros: Zero risk for alpha.
Cons: The drift gets worse over time. Our copy becomes increasingly stale.
Recommendation
Option C (defer) for now, but file this issue to track. When we do the cleanup, do it across all DazzleML projects in one coordinated pass (csb, session-logger, claude-session-metadata, comfydbg, etc.). That's the right unit of work, not a csb-specific fix.
Acceptance criteria
Related
Migrate scripts/ to git-repokit-common subtree
Context
The
scripts/directory in this repo was copied from the comfydbg template at project creation (late March 2026). The source of truth for these shared utilities lives atC:\code\git-repokit-common\, but we never hooked up a subtree relationship -- each script is a plain file, frozen at whatever comfydbg had committed at fork time.Current state
Our
scripts/contains:git-repokit-common/has the same files plus additional infrastructure we don't have:The problem
Any bug fixes or improvements made to
git-repokit-commonsince late March 2026 are not in our copy. We have no mechanism to pull updates. Ifgh_issue_full.pygains a new feature in the upstream common repo, we'd have to manually copy the change over.This affects every project spawned from comfydbg, not just csb.
Options
Option A: Subtree add
Pros: Clean, standard approach.
git subtree pullfor updates. Fits the RepoKit convention.Cons: Requires the upstream repo to be at a public URL (or accessible via ssh). Need to verify what's at
https://github.com/djdarcy/git-repokit-common-- may not be pushed.Option B: Subtree with a subdirectory
Keep
scripts/as project-specific, addscripts/common/as the subtree. Lets us have both shared and project-specific scripts coexist.Pros: Non-destructive, preserves any project-specific additions we've made to
scripts/.Cons: Double-nested, slightly more verbose paths.
Option C: Defer
Leave the copied scripts as-is for now. Document as known tech debt. Address in a cleanup pass across all DazzleML projects later.
Pros: Zero risk for alpha.
Cons: The drift gets worse over time. Our copy becomes increasingly stale.
Recommendation
Option C (defer) for now, but file this issue to track. When we do the cleanup, do it across all DazzleML projects in one coordinated pass (csb, session-logger, claude-session-metadata, comfydbg, etc.). That's the right unit of work, not a csb-specific fix.
Acceptance criteria
git-repokit-commonhas a public remote (or set one up)scripts/(if any) into git-repokit-common upstreamRelated
notes/ideas/2026-04-10__21-58-00__both_initial-release-criteria-and-repokit-common-question.md