ragarciaruben 1.20.20 → 1.20.21

package/.github/copilot-context/agents/executor.agent.md

@@ -1,84 +0,0 @@
----
-name: Executor
-description: Implements planned phases — writes code, runs tests, and makes atomic commits following established conventions. Use me to execute a ready plan.
-tools:
-  - editFiles
-  - runInTerminal
-  - search
-  - geppetto/*
-  - geppetto-api/*
-  - jira/*
-model: Claude Opus 4.6
-handoffs:
-  - label: Verify This Work
-    agent: Verifier
-    prompt: "Implementation is complete. Please verify the completed phase against the requirements in .planning/REQUIREMENTS.md and the phase success criteria in .planning/ROADMAP.md."
-  - label: Pause & Save State
-    agent: Pause
-    prompt: "Please save the current session state to .planning/continue-here.md so we can resume in a new session."
----
-
-# Executor Agent
-
-I am an implementation specialist. I execute plans precisely, follow established conventions, commit atomically, and verify with tests at every step.
-
-## My Approach
-
-1. **Load context first:** Before writing a single line of code, I read:
-   - The plan files in `.planning/phases/[current-phase]/`
-   - `.planning/codebase/CONVENTIONS.md` — coding standards
-   - `.planning/codebase/STRUCTURE.md` — where to place files
-   - `.planning/codebase/CONCERNS.md` — fragile areas to handle carefully
-
-2. **Pre-flight check:** Run `npm test` to confirm baseline before I start
-
-3. **Implement step by step:** Follow the plan's steps in order — no shortcuts, no improvising architecture
-
-4. **Test continuously:** Run tests after each meaningful change; fix failures immediately
-
-5. **Commit per plan:** After each plan is complete, commit with a descriptive message
-
-6. **Update ROADMAP.md:** Mark completed plans with `[x]`
-
-7. **Hand off to Verifier when done**
-
-## My Rules
-
-- **Never skip tests** — if a plan says "write tests", tests are written before moving to the next step
-- **Never improvise architecture** — if the plan is unclear, ask before implementing
-- **Follow conventions exactly** — refer to `.planning/codebase/CONVENTIONS.md` on every new file
-- **Atomic commits** — one commit per completed plan, not per file
-- **If I hit a blocker** — document it in `.planning/STATE.md`, save state, and surface it to you
-
-## Jira Integration
-
-When executing work tied to Jira tickets, I:
-
-- **Read ticket details** with `mcp_jira_jira_get_issue` for acceptance criteria and context
-- **Comment progress** with `mcp_jira_jira_add_comment` after completing significant steps
-- **Transition tickets** with `mcp_jira_jira_transition_issue` (e.g., To Do → In Progress → In Review)
-- Reference Jira ticket IDs in commit messages: `feat(PROJ-123): implement user auth flow`
-
-## Trigger Phrases
-
-"Execute phase [N]", "Implement the plan", "Build [feature] from the plan", "Continue implementing"
-
-## Corporate Context (Geppetto MCP)
-
-When implementing with corporate frameworks, APIs, or services, use the Geppetto MCP tools to look up Inditex-specific patterns:
-
-- **`mcp_geppetto_generic_search`** — Search all Inditex technical documentation (best general-purpose fallback)
-- **`mcp_geppetto_api_search`** — Search Inditex API best practices, guidelines, and REST API specifications
-
-Use these tools when:
-- Implementing against AMIGA framework patterns (Java, Node, Python, Go, Web)
-- Calling or building corporate REST APIs
-- Setting up CI/CD pipelines, Dockerfiles, or infrastructure config
-- Implementing authorization flows (Heimdal) or other internal service integrations
-
-## Reference Documents
-
-- [.planning/codebase/CONVENTIONS.md](../../../.planning/codebase/CONVENTIONS.md) — coding standards
-- [.planning/codebase/STRUCTURE.md](../../../.planning/codebase/STRUCTURE.md) — file placement
-- [.planning/codebase/CONCERNS.md](../../../.planning/codebase/CONCERNS.md) — fragile areas
-- [.planning/codebase/TESTING.md](../../../.planning/codebase/TESTING.md) — test patterns

package/.github/copilot-context/agents/planner.agent.md

@@ -1,96 +0,0 @@
----
-name: Planner
-description: Plans implementation phases — reads requirements and codebase context to produce executable step-by-step plans. Use me before starting new work.
-tools:
-  - editFiles
-  - search
-  - geppetto/*
-  - geppetto-api/*
-  - jira/*
-model: Claude Opus 4.6
-handoffs:
-  - label: Start Executing
-    agent: Executor
-    prompt: "The plan is ready. Please execute the phase plan just created, following the steps in .planning/phases/ and the conventions in .planning/codebase/CONVENTIONS.md."
----
-
-# Planner Agent
-
-I am a planning specialist. My job is to analyze requirements (from Jira, roadmaps, or user input), study the codebase, and produce concrete, executable plans. **I write plan documents but never implementation code.**
-
-## My Capabilities
-
-- **Write plan files** to `.planning/phases/` and update `.planning/ROADMAP.md`, `.planning/STATE.md`
-- **Read Jira tickets** to pull requirements, sprint items, and acceptance criteria
-- **Search the codebase** to understand existing patterns and architecture
-- **Search corporate docs** (Geppetto) for framework and API context
-- I hand off to the Executor agent when a plan is ready
-
-## How I Work
-
-When you ask me to plan a phase, I will:
-
-1. **Gather requirements from the source of truth:**
-   - If a Jira project/sprint is configured: pull tickets with `mcp_jira_jira_search` or `mcp_jira_jira_get_sprint_issues`
-   - If `.planning/REQUIREMENTS.md` exists: load requirement IDs and descriptions
-   - If neither: ask the user for requirements
-
-2. **Read project context:** Load `.planning/ROADMAP.md`, `.planning/PROJECT.md`, and relevant codebase docs from `.planning/codebase/`
-
-3. **Explore the code:** Search for existing patterns, find files that will need modification, understand the current architecture
-
-4. **Ask clarifying questions** (if needed): Ambiguous requirements, tradeoffs, or scope boundaries
-
-5. **Write the plan:** Create detailed step-by-step plan files in `.planning/phases/[NN]-[phase-name]/` with exact file paths, function signatures, and success criteria
-
-6. **Update tracking docs:** Update `.planning/ROADMAP.md` with the plan, link to Jira ticket IDs where applicable
-
-7. **Hand off:** Offer to hand off to the Executor agent to implement
-
-## Trigger Phrases
-
-"Plan phase [N]", "Plan the next phase", "Plan from Jira [PROJ-123]", "Create a plan for [feature]"
-
-## What a Good Plan Includes
-
-- **Jira ticket references** (if applicable) — link each plan step to its source ticket
-- Exact file paths for files to create and modify
-- Function/method signatures and their contracts
-- Data structures and API schemas
-- Test cases to write (not just "add tests")
-- Success criteria that are verifiable
-
-## Jira Integration
-
-When tasks come from Jira, I use these tools:
-
-- **`mcp_jira_jira_search`** — Find tickets by JQL (e.g., `project = PROJ AND sprint in openSprints()`)
-- **`mcp_jira_jira_get_issue`** — Get full ticket details, acceptance criteria, and description
-- **`mcp_jira_jira_get_sprint_issues`** — Get all issues in the current sprint
-- **`mcp_jira_jira_get_project_issues`** — Get all issues in a project
-- **`mcp_jira_jira_get_agile_boards`** — Find boards by project or name
-- **`mcp_jira_jira_get_sprints_from_board`** — Find active/future sprints
-
-I map Jira tickets to plan phases: each ticket (or group of related tickets) becomes a phase with clear steps.
-
-## Corporate Context (Geppetto MCP)
-
-When planning involves corporate frameworks, APIs, or services, use the Geppetto MCP tools to search Inditex documentation:
-
-- **`mcp_geppetto_generic_search`** — Search all Inditex technical documentation (best general-purpose fallback)
-- **`mcp_geppetto_api_search`** — Search Inditex API best practices, guidelines, and REST API specifications
-
-Use these tools when:
-- The project uses AMIGA frameworks (Java, Node, Python, Go, Web)
-- You need to understand corporate API contracts or conventions
-- Planning integration with internal Inditex services
-- Researching corporate CI/CD, authorization (Heimdal), or infrastructure patterns
-
-## Reference Documents
-
-Always load relevant docs before planning:
-- [.planning/PROJECT.md](../../../.planning/PROJECT.md) — requirements and constraints
-- [.planning/REQUIREMENTS.md](../../../.planning/REQUIREMENTS.md) — requirement IDs
-- [.planning/ROADMAP.md](../../../.planning/ROADMAP.md) — phase structure
-- [.planning/codebase/ARCHITECTURE.md](../../../.planning/codebase/ARCHITECTURE.md) — layer design
-- [.planning/codebase/STRUCTURE.md](../../../.planning/codebase/STRUCTURE.md) — where files go

package/.github/copilot-context/hooks/hooks.json

@@ -1,11 +0,0 @@
-{
-  "_comment": "Copilot Hooks — Preview feature (VS Code 1.109.3+). See: https://code.visualstudio.com/docs/copilot/chat/chat-hooks",
-  "_note": "SessionStart hook: Reads .planning/STATE.md and .planning/continue-here.md at session start and injects them as additional context. Every new chat session immediately knows where you left off.",
-  "hooks": [
-    {
-      "event": "SessionStart",
-      "command": "node .github/copilot-context/hooks/inject-context.js",
-      "description": "Inject project state and session continuity context at session start"
-    }
-  ]
-}

package/.github/copilot-context/hooks/inject-context.js

@@ -1,107 +0,0 @@
-#!/usr/bin/env node
-/**
- * Copilot SessionStart Hook — Context Injector
- *
- * Reads .planning/STATE.md and .planning/continue-here.md, then outputs
- * additionalContext JSON for Copilot to inject at session start.
- *
- * This ensures every new chat session automatically knows where you left off.
- *
- * Protocol: Read JSON from stdin, write JSON to stdout.
- * See: https://code.visualstudio.com/docs/copilot/chat/chat-hooks
- *
- * Usage: Configured in .github/copilot-context/hooks/hooks.json as a SessionStart event hook.
- */
-
-const fs = require('fs');
-const path = require('path');
-
-// Read hook input from stdin (Copilot passes session info here)
-let stdin = '';
-process.stdin.on('data', (chunk) => { stdin += chunk; });
-
-process.stdin.on('end', () => {
-  const workspaceRoot = resolveWorkspaceRoot();
-  const contextParts = [];
-
-  // Load STATE.md
-  const statePath = path.join(workspaceRoot, '.planning', 'STATE.md');
-  if (fs.existsSync(statePath)) {
-    const content = fs.readFileSync(statePath, 'utf8');
-    // Extract just the essential sections (avoid dumping the whole file)
-    const essential = extractEssentialState(content);
-    if (essential) {
-      contextParts.push(`## Project State\n\n${essential}`);
-    }
-  }
-
-  // Load continue-here.md if it exists (session resumption)
-  const continuePath = path.join(workspaceRoot, '.planning', 'continue-here.md');
-  if (fs.existsSync(continuePath)) {
-    const content = fs.readFileSync(continuePath, 'utf8');
-    contextParts.push(`## Resume Context\n\n${content}`);
-  }
-
-  if (contextParts.length === 0) {
-    // No context to inject — exit cleanly without output
-    process.exit(0);
-  }
-
-  // Output additionalContext for Copilot to inject
-  const output = {
-    additionalContext: contextParts.join('\n\n---\n\n')
-  };
-
-  process.stdout.write(JSON.stringify(output));
-});
-
-/**
- * Extract essential sections from STATE.md to avoid injecting the whole file.
- * Gets: core value, current position, last activity, next action.
- */
-function extractEssentialState(content) {
-  const lines = content.split('\n');
-  const essential = [];
-  let inRelevantSection = false;
-  let sectionDepth = 0;
-
-  for (const line of lines) {
-    // Always include core value and current position lines
-    if (
-      line.includes('Core value:') ||
-      line.includes('Current focus:') ||
-      line.includes('Phase:') ||
-      line.includes('Status:') ||
-      line.includes('Last activity:') ||
-      line.includes('Next action:') ||
-      line.includes('Progress:')
-    ) {
-      essential.push(line);
-    }
-  }
-
-  return essential.join('\n').trim();
-}
-
-/**
- * Resolve workspace root — walk up from script location until we find .planning/
- */
-function resolveWorkspaceRoot() {
-  // Try to get from stdin (Copilot may pass workspace info)
-  try {
-    const input = JSON.parse(stdin || '{}');
-    if (input.workspaceFolder) return input.workspaceFolder;
-  } catch {}
-
-  // Walk up from script directory
-  let dir = __dirname;
-  for (let i = 0; i < 5; i++) {
-    if (fs.existsSync(path.join(dir, '.planning'))) return dir;
-    const parent = path.dirname(dir);
-    if (parent === dir) break;
-    dir = parent;
-  }
-
-  // Fallback to cwd
-  return process.cwd();
-}

package/.github/copilot-context/instructions/architecture.instructions.md

@@ -1,33 +0,0 @@
----
-name: System Architecture
-description: System architecture, layer organization, data flow, and component boundaries for backend, API, and refactoring work
----
-
-# System Architecture
-
-> Full architecture reference: [.planning/codebase/ARCHITECTURE.md](../../../.planning/codebase/ARCHITECTURE.md)
->
-> Read this document when: designing new features, deciding where logic belongs, refactoring, or resolving layer violations.
-
-## Core Principle
-
-Code belongs in the correct layer. Moving logic between layers is a refactoring task, not a shortcut.
-
-## Layer Summary
-
-Read `.planning/codebase/ARCHITECTURE.md` for the full diagram and data flow examples. Key rules:
-
-- **Routes/Controllers:** parse input, validate, delegate to service — no business logic here
-- **Services:** all business logic lives here — no direct DB calls, no HTTP knowledge
-- **Repositories:** all database access here — raw queries or ORM calls only, no business logic
-- **Middleware:** cross-cutting concerns (auth, logging, error handling) — applied at application level
-- **Models:** data shapes and ORM definitions — no behavior
-
-## Decision Guide
-
-| Question | Answer in |
-|----------|-----------|
-| Where does this request flow? | `.planning/codebase/ARCHITECTURE.md` → Data Flow |
-| What layer handles this logic? | `.planning/codebase/ARCHITECTURE.md` → Layers |
-| What are the entry points? | `.planning/codebase/ARCHITECTURE.md` → Entry Points |
-| How are errors propagated? | `.planning/codebase/ARCHITECTURE.md` → Cross-Cutting Concerns |

package/.github/copilot-context/instructions/concerns.instructions.md

@@ -1,30 +0,0 @@
----
-name: Technical Concerns
-description: Technical debt, known bugs, fragile code areas, security considerations, and areas to approach with caution
----
-
-# Technical Concerns
-
-> Full concerns reference: [.planning/codebase/CONCERNS.md](../../../.planning/codebase/CONCERNS.md)
->
-> Read this document when: refactoring, touching legacy code, working near known fragile areas, or doing security-sensitive work.
-
-## Core Rule
-
-**Before modifying code in a warning area, check `.planning/codebase/CONCERNS.md`.** Modifying fragile code without understanding why it's fragile frequently introduces regressions.
-
-## Quick Guide
-
-Read `.planning/codebase/CONCERNS.md` for:
-- **Critical issues:** Active bugs or broken functionality — don't make them worse
-- **High-priority debt:** Significant friction or risk areas worth knowing about
-- **Fragile areas table:** Specific files that are risky to modify and HOW to proceed safely
-- **Security notes:** Known vulnerabilities, applied mitigations, what not to bypass
-- **Performance bottlenecks:** Known slow paths and their workarounds
-
-## Rules
-
-- After fixing a known issue, **remove it from CONCERNS.md** or mark it resolved
-- After discovering a new issue, **add it to CONCERNS.md** — don't leave land mines undocumented
-- When a fix is deferred, add a `// TODO(issue-ref):` comment at the affected location
-- **Never introduce new `any` types, disable linting rules, or skip test coverage** without documenting the reason in CONCERNS.md

package/.github/copilot-context/instructions/conventions.instructions.md

@@ -1,25 +0,0 @@
----
-name: Coding Conventions
-description: Coding style, naming conventions, error handling, and formatting standards for this codebase
-applyTo: "**/*.{ts,tsx,js,jsx,mts,cts}"
----
-
-# Coding Conventions
-
-> Full conventions reference: [.planning/codebase/CONVENTIONS.md](../../../.planning/codebase/CONVENTIONS.md)
->
-> **This file is auto-loaded when you edit source files. Always follow these patterns.**
-> When in doubt, look at existing files in the codebase and match their style.
-
-## Quick Reference
-
-Read `.planning/codebase/CONVENTIONS.md` for the full guide. Key rules:
-
-- **Naming:** variables/functions = `camelCase`, classes = `PascalCase`, constants = `SCREAMING_SNAKE_CASE`, files = `kebab-case.ts`
-- **Imports:** built-ins → external packages → internal (`@/`) → relative — always in this order
-- **Error handling:** never swallow errors silently; use custom error classes; let `src/middleware/error.ts` handle HTTP errors
-- **Functions:** single responsibility; max ~50 lines; prefer early returns over deep nesting; always annotate return types
-- **Comments:** explain WHY not WHAT; JSDoc on all exported functions; include ticket ref in TODO comments
-- **No `any`:** use `unknown` + type guards instead; strict TypeScript throughout
-
-When writing new code, always check `.planning/codebase/CONVENTIONS.md` to confirm you're matching the exact patterns established in this codebase.

package/.github/copilot-context/instructions/integrations.instructions.md

@@ -1,30 +0,0 @@
----
-name: External Integrations
-description: External API integrations, third-party services, SDK usage patterns, and service configuration
----
-
-# External Integrations
-
-> Full integrations reference: [.planning/codebase/INTEGRATIONS.md](../../../.planning/codebase/INTEGRATIONS.md)
->
-> Read this document when: touching external service code, adding a new integration, debugging third-party API issues, or handling webhooks.
-
-## Core Rule
-
-**Before writing code that touches an external service, read the relevant section in `.planning/codebase/INTEGRATIONS.md`.** It documents which SDK is used, where the client is initialized, how errors are handled, and which environment variables are required.
-
-## Quick Guide
-
-Read `.planning/codebase/INTEGRATIONS.md` for:
-- **Database:** ORM/client used, connection config location, migration commands
-- **Authentication:** Provider, middleware location, how user identity is propagated
-- **Payment / billing:** SDK, webhook handling location, key operations
-- **Email:** Provider, template locations, key send operations  
-- **CI/CD:** Pipeline config, what triggers what
-
-## Rules
-
-- **Client singletons:** never create a new SDK client instance inside a function — use the initialized instance from `src/config/`
-- **Environment variables:** required vars for each service are documented in INTEGRATIONS.md — ensure they're in `.env.example`
-- **Webhook security:** always verify webhook signatures; never trust payload without verification
-- New integrations: add the service to INTEGRATIONS.md with its SDK, config location, and env vars before implementing

package/.github/copilot-context/instructions/stack.instructions.md

@@ -1,30 +0,0 @@
----
-name: Technology Stack
-description: Technology stack, framework choices, key dependencies, runtime environment, and configuration
----
-
-# Technology Stack
-
-> Full stack reference: [.planning/codebase/STACK.md](../../../.planning/codebase/STACK.md)
->
-> Read this document when: adding dependencies, modifying configuration, setting up environments, or debugging infrastructure issues.
-
-## Core Rule
-
-**Do not introduce new dependencies or change the build configuration without first checking `.planning/codebase/STACK.md`.** The stack is intentional — changes to core dependencies have broad impact.
-
-## Quick Guide
-
-Read `.planning/codebase/STACK.md` for:
-- **Runtime:** Language version, Node.js version, package manager
-- **Key frameworks:** Web framework, ORM, auth library — and how they're configured
-- **Dev toolchain:** TypeScript config, ESLint, Prettier, test runner setup
-- **Infrastructure:** Database, cache, object storage, message queue details
-- **Environment variables:** Full list of required env vars and their purpose
-
-## Rules
-
-- Always check if a required capability already exists in the stack before adding a new package
-- New dependencies: add to the appropriate section in STACK.md after installation
-- Breaking upgrades: document the upgrade decision in `.planning/PROJECT.md` Key Decisions
-- **Never read `.env` file contents** — work only with `.env.example` and environment variable names

package/.github/copilot-context/instructions/structure.instructions.md

@@ -1,32 +0,0 @@
----
-name: File Structure
-description: File and directory organization, naming conventions, and where to place new code, components, routes, or modules
----
-
-# File Structure
-
-> Full structure reference: [.planning/codebase/STRUCTURE.md](../../../.planning/codebase/STRUCTURE.md)
->
-> Read this document when: creating new files, deciding on location for new code, or setting up new modules.
-
-## Core Rule
-
-**Always check `.planning/codebase/STRUCTURE.md` before creating a new file.** It contains a "Where to Put New Code" table that answers exactly where each type of file belongs and what naming convention to use.
-
-## Quick Guide
-
-| I'm creating... | Check STRUCTURE.md section |
-|----------------|---------------------------|
-| A new API endpoint | "Where to Put New Code" → routes row |
-| A new service | "Where to Put New Code" → services row |
-| A new component | "Where to Put New Code" → components row |
-| A test for existing code | Mirror the source path in the `tests/` directory |
-| A new database model | "Where to Put New Code" → models row |
-| A utility function | "Where to Put New Code" → utilities row |
-
-## Rules
-
-- **Never create files at the root of `src/`** — always find the correct subdirectory
-- **Follow the naming convention exactly** as specified in STRUCTURE.md for each file type
-- **Use barrel exports (`index.ts`)** where the pattern exists — don't skip them for convenience
-- When creating a feature that spans multiple layers (route + service + repository), create all files before wiring them together

package/.github/copilot-context/instructions/testing.instructions.md

@@ -1,25 +0,0 @@
----
-name: Testing Patterns
-description: Test framework, patterns, mocking strategy, and test organization for writing and running tests
-applyTo: "**/*.{test,spec}.{ts,tsx,js,jsx}"
----
-
-# Testing Patterns
-
-> Full testing reference: [.planning/codebase/TESTING.md](../../../.planning/codebase/TESTING.md)
->
-> **This file is auto-loaded when you edit test files. Always follow these patterns.**
-
-## Quick Reference
-
-Read `.planning/codebase/TESTING.md` for the full guide. Key rules:
-
-- **Structure:** `describe('[ClassName/Function]')` → `describe('[methodName()]')` → `it('[readable description of behavior]')`
-- **Pattern:** Arrange-Act-Assert — comment each section if the test is non-trivial
-- **Test data:** always use factory functions from `tests/helpers/factories.ts`, never hardcoded raw objects
-- **Mocking:** mock at the outermost layer (repositories for service tests, network for integration tests); use `vi.mock()` / `jest.mock()`
-- **Isolation:** each test must pass in isolation and in any order; no shared mutable state between tests
-- **What to test:** business logic, API contract (status codes + response shape), error paths, edge cases
-- **What NOT to test:** framework internals, private implementation details, trivial getters/setters
-
-When writing a new test, check `.planning/codebase/TESTING.md` for the exact patterns used in this project, including how the test database is set up for integration tests.

package/.github/copilot-context/skills/map-codebase/SKILL.md

@@ -1,49 +0,0 @@
----
-name: map-codebase
-description: Analyzes a codebase and generates 7 structured context documents in .planning/codebase/ — covering architecture, file structure, conventions, testing, tech stack, integrations, and technical concerns
----
-
-# Codebase Mapper Skill
-
-This skill analyzes your codebase and generates 7 structured context documents that Copilot uses on every future request to provide project-aware assistance.
-
-## What This Skill Produces
-
-| Document | Contents |
-|----------|---------|
-| `ARCHITECTURE.md` | Layers, data flow, key abstractions, entry points |
-| `STRUCTURE.md` | Directory tree, "where to put new code" table, naming conventions |
-| `STACK.md` | Runtime, frameworks, dependencies, infrastructure, env vars |
-| `CONVENTIONS.md` | Coding style, naming, error handling, TypeScript rules |
-| `TESTING.md` | Test framework, patterns, mocking strategy, run commands |
-| `INTEGRATIONS.md` | External services, SDKs, connection patterns, webhook handling |
-| `CONCERNS.md` | Tech debt, known bugs, fragile areas, security notes |
-
-## When To Use This Skill
-
-- When first setting up context for an existing codebase
-- After a major architectural change
-- When onboarding a new project or team member
-- When context documents feel stale (> 1 month since major changes)
-
-## Incremental Refresh
-
-To refresh only specific documents, specify the focus area:
-- "Refresh just the conventions" → re-run quality focus
-- "Update the tech stack docs" → re-run tech focus
-- "Check for new concerns" → re-run concerns focus
-
-## Related
-
-Run corresponding prompt file: `/map-codebase`
-
-## Resources
-
-- [Analysis prompt template](.github/copilot-context/prompts/map-codebase.prompt.md)
-- [Architecture template](.planning/codebase/ARCHITECTURE.md)
-- [Structure template](.planning/codebase/STRUCTURE.md)
-- [Stack template](.planning/codebase/STACK.md)
-- [Conventions template](.planning/codebase/CONVENTIONS.md)
-- [Testing template](.planning/codebase/TESTING.md)
-- [Integrations template](.planning/codebase/INTEGRATIONS.md)
-- [Concerns template](.planning/codebase/CONCERNS.md)

package/.github/copilot-context/skills/project-history/SKILL.md

@@ -1,46 +0,0 @@
----
-name: project-history
-description: Accesses historical project context — phase summaries, decisions, retrospectives, and archived milestones. Use when you need to understand past decisions or trace why something was built a certain way.
----
-
-# Project History Skill
-
-This skill provides access to historical project context — understanding past decisions, reviewing what was built in previous phases, and tracing the rationale behind architectural choices.
-
-## What's Available
-
-| Resource | Location | Contents |
-|----------|----------|---------|
-| Phase summaries | `.planning/phases/[NN]-[name]/*.SUMMARY.md` | What was implemented, files changed, decisions made |
-| Verification reports | `.planning/phases/[NN]-[name]/VERIFICATION.md` | Test results, requirement coverage per phase |
-| Key decisions | `.planning/PROJECT.md` → Key Decisions table | All major decisions with rationale |
-| Milestone archives | `.planning/milestones/` (if exists) | Completed milestone documentation |
-| Session logs | `.planning/phases/[NN]-[name]/.continue-here.md` | Saved session states |
-
-## When To Use This Skill
-
-- "Why was [X] implemented this way?"
-- "What changed in Phase [N]?"
-- "When was [feature] added?"
-- "Did we consider [alternative approach]?"
-- "What decisions locked in this constraint?"
-
-## Usage Examples
-
-**Trace a decision:**
-"Show me all architectural decisions made in Phase 1-3"
-→ I'll read the SUMMARY.md files and PROJECT.md Key Decisions table
-
-**Understand past work:**
-"What did we implement in Phase 2?"
-→ I'll read `.planning/phases/02-name/*.SUMMARY.md`
-
-**Check test history:**
-"What was the test coverage when we finished Phase 1?"
-→ I'll read `.planning/phases/01-name/VERIFICATION.md`
-
-## Resources
-
-- [Project decisions](.planning/PROJECT.md)
-- [Current state](.planning/STATE.md)
-- [Full roadmap](.planning/ROADMAP.md)

package/.vscode/settings.json

@@ -1,9 +0,0 @@
-{
-  // GSD Copilot Context — files live in VS Code's default scan locations,
-  // no custom configuration required.
-  //
-  // .github/prompts/       → slash commands (/map-codebase, /plan-phase, etc.)
-  // .github/instructions/  → conditional context injected by Copilot
-  // .github/agents/        → multi-step agents (planner, executor, verifier)
-  // .github/copilot-instructions.md  → always-on project digest
-}