メニュー
Migrates existing projects to GSD structure without rewriting history. Activates when user mentions "migrate to GSD", "adopt GSD", "convert project", "brownfield GSD", or wants to add GSD to existing work.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/Tibsfox/gsd-skill-creator --skill gsd-migrateコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Use the moment a request is underspecified and you are about to act on an ASSUMED goal. Enumerate the candidate goals the request could mean, project the action or artifact each one implies, and check whether they diverge: if two or more plausible goals lead to materially different actions or artifacts, ask exactly ONE targeted clarifying question; otherwise proceed on the most-likely goal and state the assumption in one line. Clarification is an evidence-producing action, not a delay — but one question, never an interrogation. Distinct from gsd-spec-phase (GSD-phase-bound, emits a heavy SPEC.md) and intent-router (fetch strategy, not goal disambiguation). Backed by agent goal-state inference (arxiv 2606.16813v1). Triggers on acting under an assumed goal when the request admits more than one materially different reading.
Use at write time to vector/embedding memory — Grove content-addressed insertion, chroma/pgvector upserts, memory-consolidation promoting session traces to MEMORY.md, or embedding externally-ingested content. Scores each candidate record against a fixed panel of sentinel queries and quarantines any record that would become the nearest neighbor of too many unrelated queries — a hub — whether from adversarial poisoning or accidental over-generality. This is the memory-record-side sibling of skill-injection-guardian (file-side) and the write-side complement of memory-use-warrant (read-side). Quarantine, never silently drop; a human reviews. Backed by the admission-time hubness gate (arxiv 2606.19692v1). Triggers on inserting into vector memory, consolidating memory, and embedding stranger content.
Run this appropriateness check the moment you are about to integrate a retrieved long-term memory — a Grove content-addressed hit, a chroma/pgvector neighbour, a memory-consolidation digest, or a MEMORY.md line — into a response, especially anything touching private origins, Fox Companies IP, credentials, or Center Camp / consent-governed content. It answers a question intent-router never asks: not WHAT to fetch or HOW, but WHETHER a correctly-retrieved item should reach output. Relevance is not appropriateness — a perfect similarity match can still be a boundary violation. Default is FAIL-CLOSED: if in-context authorization is uncertain, the memory may inform behaviour but must not be surfaced. Backed by RBI-Eval (arxiv 2606.06055v1). Triggers on surfacing recalled sensitive memory into a response.
SOC 職業分類に基づく
| name | gsd-migrate |
| description | Migrates existing projects to GSD structure without rewriting history. Activates when user mentions "migrate to GSD", "adopt GSD", "convert project", "brownfield GSD", or wants to add GSD to existing work. |
| type | skill |
| category | gsd |
| status | stable |
| origin | tibsfox |
| modified | false |
| first_seen | "2026-02-07T00:00:00.000Z" |
| first_path | examples/gsd-migrate/SKILL.md |
| superseded_by | null |
Bridges the gap between existing projects and GSD adoption by inferring GSD artifacts from current project state, preserving git history and existing work.
Activate when the user:
Analyzes existing project to extract:
Generates GSD artifacts that map current state:
Preserves history:
# Analyze project indicators
if [ -f "package.json" ]; then
PROJECT_TYPE="javascript"
# Read: name, description, dependencies
elif [ -f "requirements.txt" ] || [ -f "pyproject.toml" ]; then
PROJECT_TYPE="python"
elif [ -f "go.mod" ]; then
PROJECT_TYPE="go"
elif [ -f "Cargo.toml" ]; then
PROJECT_TYPE="rust"
fi
# Check for frameworks
if grep -q package.json 2>/dev/null;
FRAMEWORK=
grep -q package.json 2>/dev/null;
FRAMEWORK=
Sources to analyze:
| Source | What to Extract |
|---|---|
| README.md | Project purpose, features, usage |
| package.json / Cargo.toml | Name, description, keywords |
| CONTRIBUTING.md | Project goals, roadmap |
| docs/ | Architecture, design decisions |
| Git commits | Feature patterns, evolution |
Example extraction:
From README.md:
"TaskFlow - A lightweight task management API for teams"
→ Core Value: Team task coordination
From package.json:
"keywords": ["tasks", "api", "collaboration"]
→ Domain: Collaborative task management
From git log:
Early commits: Setup, models, basic CRUD
Recent commits: Real-time updates, permissions
→ Project maturity: Mid-stage, core features built
Analyze git history:
# Get all commits
git log --oneline --all > commits.txt
# Identify feature commits
grep -E "feat|add|implement" commits.txt
# Group by feature area
# "feat: add user auth" → Authentication feature
# "feat: implement tasks CRUD" → Task management feature
Analyze codebase:
# Find main features from file structure
ls src/
# → auth/, tasks/, notifications/, teams/
# For each directory, infer feature
# auth/ → Authentication feature
# tasks/ → Task management feature
Sources for remaining work:
# TODOs in code
grep -r "TODO" src/ --include="*.js" --include="*.ts"
# GitHub/GitLab issues
gh issue list --state open
# Comments marked with future work
grep -r "FIXME\|HACK\|XXX" src/
# Incomplete features (from README)
# README says "Features: Auth, Tasks, Search"
# But src/ only has auth/ and tasks/
# → Search is remaining work
Template:
# [Project Name]
## What This Is
[Extracted from README/package.json]
## Current State
**Built:** [Summary of completed features]
**Codebase:** [LOC] across [N] files
**Last activity:** [Most recent commit date]
**Migrated to GSD:** [Today's date]
## Core Value
[One-sentence value prop from README]
## Requirements
### Validated
[Features that already exist in codebase]
- ✓ REQ-01: User authentication
- Source: src/auth/, committed [date]
- ✓ REQ-02: Task CRUD operations
- Source: src/tasks/, committed [date]
### Active
[Work in progress or remaining from backlog]
- → REQ-03: Real-time notifications
- Source: TODOs in src/, GitHub issue #42
- → REQ-04: Team collaboration
- Source: README planned features
### Out of Scope
[Explicitly not doing, from CONTRIBUTING or discussions]
## Constraints
[Inferred from dependencies, architecture]
- **Tech stack:** [From package.json/requirements.txt]
- **Deployment:** [From Dockerfile, deployment files]
- **Compatibility:** [From .nvmrc, engines field]
## Key Decisions
| Decision | Rationale | Outcome |
|----------|-----------|---------|
| [Tech choice from dependencies] | [Inferred] | ✓ Good - [status] |
Map completed work to phases:
# Roadmap
## Milestones
### v1.0 - MVP (Complete)
Completed: [Date of feature completion]
#### Phase 1: Project Setup
**Status:** ✓ Complete
**Completed:** [First commit date]
**Goal:** Initialize project structure
**Deliverables:**
- ✓ Node.js project with Express
- ✓ Database configuration (PostgreSQL)
- ✓ Basic server skeleton
**Success Criteria:**
- Server starts successfully
- Database connection works
---
#### Phase 2: Authentication
**Status:** ✓ Complete
**Completed:** [Auth commit date]
**Goal:** User registration and login
**Deliverables:**
- ✓ User model with password hashing
- ✓ Registration endpoint
- ✓ Login with JWT
- ✓ Auth middleware
**Success Criteria:**
- Users can register and login
- Protected routes require valid JWT
---
### v2.0 - Collaboration Features (In Progress)
#### Phase 3: Task Management
**Status:** ✓ Complete
**Completed:** [Task commit date]
**Goal:** CRUD operations for tasks
**Deliverables:**
- ✓ Task model
- ✓ Create, read, update, delete endpoints
- ✓ Task assignment to users
---
#### Phase 4: Real-Time Notifications
**Status:** → In Progress
**Started:** [Date or "Not started"]
**Goal:** Live updates for task changes
**Deliverables:**
- WebSocket server setup
- Task change events
- Client subscription model
**Success Criteria:**
- Users see task updates in real-time
- No polling required
---
#### Phase 5: Team Collaboration
**Status:** Planned
**Goal:** Multi-user teams with permissions
**Deliverables:**
- Team model
- Invite system
- Role-based permissions
- Team task visibility
**Success Criteria:**
- Users can create teams
- Tasks scoped to teams
- Only team members can view team tasks
Map current position:
# Project State
## Project Reference
See: .planning/PROJECT.md (created [date] during migration)
**Core value:** [From PROJECT.md]
**Current focus:** [Inferred from recent commits or in-progress work]
## Current Position
Phase: 4 of 5 (based on ROADMAP.md analysis)
Plan: In progress (Phase 4 started, not complete)
Status: Migrated to GSD [date]
Last activity: [Most recent commit date]
Progress: [████████░░] 80% (4 of 5 phases)
## Completed Work (Pre-GSD)
| Phase | Name | Completion Date |
|-------|------|-----------------|
| 1 | Project Setup | [First commit date] |
| 2 | Authentication | [Auth complete date] |
| 3 | Task Management | [Tasks complete date] |
## Current Work
Phase 4: Real-Time Notifications
Status: In progress (WebSocket setup done, events TODO)
Files: src/websocket/, src/events/ (partial)
## Accumulated Context
### Decisions
Pre-GSD decisions inferred from codebase:
| Decision | Source | Date |
|----------|--------|------|
| PostgreSQL over MongoDB | package.json dependencies | [Date] |
| JWT over sessions | src/auth/jwt.js | [Date] |
| Express framework | package.json | [Initial commit] |
### Pending Todos
- [ ] Complete WebSocket event system (Phase 4)
- [ ] Add team permissions (Phase 5)
- [ ] Write integration tests (TODO comments in code)
### Blockers/Concerns
None (fresh migration)
## Session Continuity
Last session: [Migration date]
Stopped at: Migration complete, GSD structure created
Resume file: None
Sensible defaults:
{
"mode": "interactive",
"model_profile": "balanced",
"depth": "standard",
"research": false,
"commit_docs": true
}
Rationale:
interactive: Safer for existing projects (require confirmation)balanced: Good quality without excessive costdepth: standard: Not too quick, not too thoroughresearch: false: Existing project likely has established patternscommit_docs: true: Track docs with codePresent the migration plan to the user:
# Migration Plan for [Project Name]
## Analysis Summary
**Detected:**
- Language/Framework: Node.js + Express
- Database: PostgreSQL
- Features: Authentication, Task CRUD, partial Notifications
- Commits: 142 commits over 6 months
- Last activity: 3 days ago
## Proposed GSD Structure
### PROJECT.md
- Core Value: Team task coordination
- Validated Requirements: REQ-01 (Auth), REQ-02 (Tasks), REQ-03 (Notifications - partial)
- Active Requirements: REQ-04 (Teams), REQ-05 (Permissions)
### ROADMAP.md
- ✓ Phase 1: Setup (complete)
- ✓ Phase 2: Authentication (complete)
- ✓ Phase 3: Task Management (complete)
- → Phase 4: Notifications (in progress)
- Planned: Phase 5: Team Collaboration
### STATE.md
- Current Position: Phase 4 of 5 (80% progress)
- 142 commits preserved in history
- Ready to continue with GSD workflows
## What Gets Created
Files to write:
- .planning/PROJECT.md
- .planning/REQUIREMENTS.md
- .planning/ROADMAP.md
- .planning/STATE.md
- .planning/config.json
Git:
- 1 commit: "chore: migrate project to GSD structure"
- Existing history untouched
## Next Steps After Migration
1. Review generated artifacts and edit as needed
2. Continue current work:
- /gsd:plan-phase 4 (if not already planned)
- /gsd:execute-phase 4 (finish notifications)
3. Plan remaining work:
- /gsd:plan-phase 5 (team collaboration)
---
Ready to migrate? (yes/review-files/cancel)
If user confirms:
# Create .planning/ directory
mkdir -p .planning/phases
# Write generated artifacts
write_file ".planning/PROJECT.md" "$PROJECT_MD_CONTENT"
write_file ".planning/REQUIREMENTS.md" "$REQUIREMENTS_MD_CONTENT"
write_file ".planning/ROADMAP.md" "$ROADMAP_MD_CONTENT"
write_file ".planning/STATE.md" "$STATE_MD_CONTENT"
write_file ".planning/config.json" "$CONFIG_JSON_CONTENT"
# Create phase directories for completed phases
for phase in 01-setup 02-auth 03-tasks; do
mkdir -p ".planning/phases/$phase"
done
# Create .gitkeep for empty directories
touch .planning/phases/04-notifications/.gitkeep
# Commit the migration
git add .planning/
git commit -m "chore: migrate project to GSD structure
Migrated existing project to GSD workflow system.
Completed work mapped to Phases 1-3.
Current work (Phase 4: Notifications) in progress.
Remaining work (Phase 5: Teams) planned in ROADMAP.
All existing commits preserved.
GSD structure added for future development.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"
When: Complete brownfield project, want full GSD adoption
Approach:
Outcome: Full GSD structure, ready for complete workflow adoption
When: Large project, want to ease into GSD
Approach:
Outcome:
ROADMAP.md:
## Legacy Work (Pre-GSD)
Phases 1-10: Completed before GSD adoption
See: git log --before="2024-01-01"
## v2.0 (GSD-Managed)
Phase 11: New feature (planned with GSD)
Phase 12: Refactor (planned with GSD)
When: Want to try GSD on one feature before full adoption
Approach:
Outcome: Risk-free trial of GSD workflows
Example: E-commerce site with auth, products, cart, checkout
Migration:
Phase 1: Setup
Phase 2: Authentication
Phase 3: Product Catalog
Phase 4: Shopping Cart
Phase 5: Checkout Process
All phases marked complete in ROADMAP.
STATE.md shows: Phase 5 of 5 complete.
Ready for: /gsd:new-milestone to start v2.0
Example: Started notifications but not finished
Migration:
Phase 4: Notifications
Status: In Progress
Completed:
- WebSocket server setup
- Connection handling
Remaining:
- Event emission on task changes
- Client subscription system
ROADMAP: Mark as "In Progress"
STATE.md: Current Position = Phase 4
Next: /gsd:plan-phase 4 to plan remaining work
Example: Monolith with mixed concerns, unclear boundaries
Migration:
Ask user to help define phases:
"I see your project has authentication, data processing,
and reporting features mixed together. How would you
like to structure these into phases?"
User helps define:
Phase 1: Core setup
Phase 2: Data ingestion
Phase 3: Processing pipeline
Phase 4: Report generation
Phase 5: API endpoints
Then map files to phases based on user input.
Migration:
# Extract TODOs from code
grep -r "TODO" src/ > todos.txt
# Group by feature area
# TODO in src/auth/ → Authentication todos
# TODO in src/tasks/ → Task management todos
# Create phase for "Tech Debt & Improvements"
Phase 6: Tech Debt & Improvements
Goal: Address TODOs and improve code quality
Deliverables:
- Fix auth edge cases (3 TODOs)
- Optimize task queries (2 TODOs)
- Add error handling (5 TODOs)
After migration completes:
## Immediate Steps
- [ ] Review generated PROJECT.md - adjust vision/requirements
- [ ] Review ROADMAP.md - verify phase mapping is accurate
- [ ] Review STATE.md - confirm current position
- [ ] Test GSD workflows:
- [ ] Run /gsd:progress (should show current state)
- [ ] Try /gsd:plan-phase for next incomplete phase
- [ ] Try /gsd:quick for a small task
## First Week
- [ ] Complete current phase using GSD execution
- [ ] Run /gsd:verify-work to validate
- [ ] Use /gsd:add-todo for capturing ideas
- [ ] Commit docs and summaries as work progresses
## Long Term
- [ ] Team members run /gsd:progress to sync
- [ ] Use PROJECT.md Key Decisions table for ADRs
- [ ] Plan milestones with /gsd:new-milestone
- [ ] Archive completed milestones with /gsd:complete-milestone
Solution:
Ask user to guide:
"I see features in src/auth/, src/tasks/, and src/notifications/.
Which of these are complete and production-ready?
User: "Auth and tasks are done, notifications is half-done"
→ Mark Phase 2 (Auth) and 3 (Tasks) complete
→ Mark Phase 4 (Notifications) in progress
Solution:
Don't try to parse messy history perfectly.
Instead:
- Look at current file structure (what exists now)
- Ask user what's complete
- Mark everything as "Legacy" if needed
- Focus GSD on future work
Solution:
GSD is flexible - adapt phase mapping:
Phase 1: Infrastructure (Terraform files)
Phase 2: Backend API (src/api/)
Phase 3: Background Jobs (src/workers/)
Phase 4: Frontend (client/)
Map phases to YOUR project's structure, not a template.
Before:
todo-app/
├── src/
│ ├── auth.js
│ ├── todos.js
│ ├── db.js
│ └── server.js
├── tests/
├── README.md
└── package.json
Git: 47 commits over 2 months
Last: "fix: todo deletion bug"
After Migration:
todo-app/
├── .planning/
│ ├── PROJECT.md
│ ├── REQUIREMENTS.md
│ ├── ROADMAP.md
│ ├── STATE.md
│ ├── config.json
│ └── phases/
│ ├── 01-setup/
│ ├── 02-auth/
│ └── 03-todos/
├── src/ [unchanged]
├── tests/ [unchanged]
└── [other files unchanged]
ROADMAP shows:
✓ Phase 1: Setup
✓ Phase 2: Authentication
✓ Phase 3: Todo CRUD
STATE shows:
Current: All phases complete
Next: /gsd:new-milestone for v2.0
Before:
api-server/
├── src/
│ ├── users/ (complete)
│ ├── posts/ (complete)
│ ├── comments/ (partial - create/read only)
│ └── search/ (empty - planned)
Git: 89 commits over 4 months
After Migration:
ROADMAP:
✓ Phase 1: Setup
✓ Phase 2: User Management
✓ Phase 3: Posts
→ Phase 4: Comments (in progress)
Planned: Phase 5: Search
STATE:
Current Position: Phase 4 of 5
Next: /gsd:plan-phase 4 (complete comments CRUD)
This skill complements GSD by:
It does not replace GSD: