diff --git a/.claude/commands/speckit.analyze.md b/.claude/commands/speckit.analyze.md index 0c71cf32..1f8c12c4 100644 --- a/.claude/commands/speckit.analyze.md +++ b/.claude/commands/speckit.analyze.md @@ -8,7 +8,7 @@ description: Perform a non-destructive cross-artifact consistency and quality an $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). +The user's input above, when present, shapes everything that follows. ## Goal @@ -173,7 +173,6 @@ Ask the user: "Would you like me to suggest concrete remediation edits for the t ### Analysis Guidelines -- **NEVER modify files** (this is read-only analysis) - **NEVER hallucinate missing sections** (if absent, report them accurately) - **Prioritize constitution violations** (these are always CRITICAL) - **Use examples over exhaustive rules** (cite specific instances, not generic patterns) diff --git a/.claude/commands/speckit.checklist.md b/.claude/commands/speckit.checklist.md index b7624e22..a3e6723a 100644 --- a/.claude/commands/speckit.checklist.md +++ b/.claude/commands/speckit.checklist.md @@ -29,7 +29,7 @@ description: Generate a custom checklist for the current feature based on user r $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). +The user's input above, when present, shapes everything that follows. ## Execution Steps @@ -188,14 +188,6 @@ You **MUST** consider the user input before proceeding (if not empty). - Merge near-duplicates checking the same requirement aspect - If >5 low-impact edge cases, create one item: "Are edge cases X, Y, Z addressed in requirements? [Coverage]" - **🚫 ABSOLUTELY PROHIBITED** - These make it an implementation test, not a requirements test: - - ❌ Any item starting with "Verify", "Test", "Confirm", "Check" + implementation behavior - - ❌ References to code execution, user actions, system behavior - - ❌ "Displays correctly", "works properly", "functions as expected" - - ❌ "Click", "navigate", "render", "load", "execute" - - ❌ Test cases, test plans, QA procedures - - ❌ Implementation details (frameworks, APIs, algorithms) - **βœ… REQUIRED PATTERNS** - These test requirements quality: - βœ… "Are [requirement type] defined/specified/documented for [scenario]?" - βœ… "Is [vague term] quantified/clarified with specific criteria?" @@ -262,34 +254,3 @@ Sample items: - "Is the threat model documented and requirements aligned to it? [Traceability]" - "Are security requirements consistent with compliance obligations? [Consistency]" - "Are security failure/breach response requirements defined? [Gap, Exception Flow]" - -## Anti-Examples: What NOT To Do - -**❌ WRONG - These test implementation, not requirements:** - -```markdown -- [ ] CHK001 - Verify landing page displays 3 episode cards [Spec Β§FR-001] -- [ ] CHK002 - Test hover states work correctly on desktop [Spec Β§FR-003] -- [ ] CHK003 - Confirm logo click navigates to home page [Spec Β§FR-010] -- [ ] CHK004 - Check that related episodes section shows 3-5 items [Spec Β§FR-005] -``` - -**βœ… CORRECT - These test requirements quality:** - -```markdown -- [ ] CHK001 - Are the number and layout of featured episodes explicitly specified? [Completeness, Spec Β§FR-001] -- [ ] CHK002 - Are hover state requirements consistently defined for all interactive elements? [Consistency, Spec Β§FR-003] -- [ ] CHK003 - Are navigation requirements clear for all clickable brand elements? [Clarity, Spec Β§FR-010] -- [ ] CHK004 - Is the selection criteria for related episodes documented? [Gap, Spec Β§FR-005] -- [ ] CHK005 - Are loading state requirements defined for asynchronous episode data? [Gap] -- [ ] CHK006 - Can "visual hierarchy" requirements be objectively measured? [Measurability, Spec Β§FR-001] -``` - -**Key Differences:** - -- Wrong: Tests if the system works correctly -- Correct: Tests if the requirements are written correctly -- Wrong: Verification of behavior -- Correct: Validation of requirement quality -- Wrong: "Does it do X?" -- Correct: "Is X clearly specified?" diff --git a/.claude/commands/speckit.clarify.md b/.claude/commands/speckit.clarify.md index 3f4376a4..8cf6c71c 100644 --- a/.claude/commands/speckit.clarify.md +++ b/.claude/commands/speckit.clarify.md @@ -12,7 +12,7 @@ handoffs: $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). +The user's input above, when present, shapes everything that follows. ## Outline diff --git a/.claude/commands/speckit.constitution.md b/.claude/commands/speckit.constitution.md index 63d4f662..b56e83e7 100644 --- a/.claude/commands/speckit.constitution.md +++ b/.claude/commands/speckit.constitution.md @@ -12,7 +12,7 @@ handoffs: $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). +The user's input above, when present, shapes everything that follows. ## Outline diff --git a/.claude/commands/speckit.implement.md b/.claude/commands/speckit.implement.md index 5847f611..78a62945 100644 --- a/.claude/commands/speckit.implement.md +++ b/.claude/commands/speckit.implement.md @@ -8,41 +8,7 @@ description: Execute the implementation plan by processing and executing all tas $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). - -## Pre-Execution Checks - -**Check for extension hooks (before implementation)**: -- Check if `.specify/extensions.yml` exists in the project root. -- If it exists, read it and look for entries under the `hooks.before_implement` key -- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally -- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default. -- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions: - - If the hook has no `condition` field, or it is null/empty, treat the hook as executable - - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation -- For each executable hook, output the following based on its `optional` flag: - - **Optional hook** (`optional: true`): - ``` - ## Extension Hooks - - **Optional Pre-Hook**: {extension} - Command: `/{command}` - Description: {description} - - Prompt: {prompt} - To execute: `/{command}` - ``` - - **Mandatory hook** (`optional: false`): - ``` - ## Extension Hooks - - **Automatic Pre-Hook**: {extension} - Executing: `/{command}` - EXECUTE_COMMAND: {command} - - Wait for the result of the hook command before proceeding to the Outline. - ``` -- If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently +The user's input above, when present, shapes everything that follows. ## Outline @@ -87,49 +53,10 @@ You **MUST** consider the user input before proceeding (if not empty). - **IF EXISTS**: Read research.md for technical decisions and constraints - **IF EXISTS**: Read quickstart.md for integration scenarios -4. **Project Setup Verification**: - - **REQUIRED**: Create/verify ignore files based on actual project setup: - - **Detection & Creation Logic**: - - Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so): - - ```sh - git rev-parse --git-dir 2>/dev/null - ``` - - - Check if Dockerfile* exists or Docker in plan.md β†’ create/verify .dockerignore - - Check if .eslintrc* exists β†’ create/verify .eslintignore - - Check if eslint.config.* exists β†’ ensure the config's `ignores` entries cover required patterns - - Check if .prettierrc* exists β†’ create/verify .prettierignore - - Check if .npmrc or package.json exists β†’ create/verify .npmignore (if publishing) - - Check if terraform files (*.tf) exist β†’ create/verify .terraformignore - - Check if .helmignore needed (helm charts present) β†’ create/verify .helmignore - - **If ignore file already exists**: Verify it contains essential patterns, append missing critical patterns only - **If ignore file missing**: Create with full pattern set for detected technology - - **Common Patterns by Technology** (from plan.md tech stack): - - **Node.js/JavaScript/TypeScript**: `node_modules/`, `dist/`, `build/`, `*.log`, `.env*` - - **Python**: `__pycache__/`, `*.pyc`, `.venv/`, `venv/`, `dist/`, `*.egg-info/` - - **Java**: `target/`, `*.class`, `*.jar`, `.gradle/`, `build/` - - **C#/.NET**: `bin/`, `obj/`, `*.user`, `*.suo`, `packages/` - - **Go**: `*.exe`, `*.test`, `vendor/`, `*.out` - - **Ruby**: `.bundle/`, `log/`, `tmp/`, `*.gem`, `vendor/bundle/` - - **PHP**: `vendor/`, `*.log`, `*.cache`, `*.env` - - **Rust**: `target/`, `debug/`, `release/`, `*.rs.bk`, `*.rlib`, `*.prof*`, `.idea/`, `*.log`, `.env*` - - **Kotlin**: `build/`, `out/`, `.gradle/`, `.idea/`, `*.class`, `*.jar`, `*.iml`, `*.log`, `.env*` - - **C++**: `build/`, `bin/`, `obj/`, `out/`, `*.o`, `*.so`, `*.a`, `*.exe`, `*.dll`, `.idea/`, `*.log`, `.env*` - - **C**: `build/`, `bin/`, `obj/`, `out/`, `*.o`, `*.a`, `*.so`, `*.exe`, `*.dll`, `autom4te.cache/`, `config.status`, `config.log`, `.idea/`, `*.log`, `.env*` - - **Swift**: `.build/`, `DerivedData/`, `*.swiftpm/`, `Packages/` - - **R**: `.Rproj.user/`, `.Rhistory`, `.RData`, `.Ruserdata`, `*.Rproj`, `packrat/`, `renv/` - - **Universal**: `.DS_Store`, `Thumbs.db`, `*.tmp`, `*.swp`, `.vscode/`, `.idea/` - - **Tool-Specific Patterns**: - - **Docker**: `node_modules/`, `.git/`, `Dockerfile*`, `.dockerignore`, `*.log*`, `.env*`, `coverage/` - - **ESLint**: `node_modules/`, `dist/`, `build/`, `coverage/`, `*.min.js` - - **Prettier**: `node_modules/`, `dist/`, `build/`, `coverage/`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml` - - **Terraform**: `.terraform/`, `*.tfstate*`, `*.tfvars`, `.terraform.lock.hcl` - - **Kubernetes/k8s**: `*.secret.yaml`, `secrets/`, `.kube/`, `kubeconfig*`, `*.key`, `*.crt` +4. **Ignore files**: Check that the repository's ignore files (`.gitignore`, and any + tool-specific ones the plan's tooling uses) cover its build outputs, caches and + secrets; add only the patterns that are missing. Do not create ignore files for + tools the project does not use. 5. Parse tasks.md structure and extract: - **Task phases**: Setup, Tests, Core, Integration, Polish @@ -137,21 +64,12 @@ You **MUST** consider the user input before proceeding (if not empty). - **Task details**: ID, description, file paths, parallel markers [P] - **Execution flow**: Order and dependency requirements -6. Execute implementation following the task plan: - - **Phase-by-phase execution**: Complete each phase before moving to the next - - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together - - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks - - **File-based coordination**: Tasks affecting the same files must run sequentially - - **Validation checkpoints**: Verify each phase completion before proceeding - -7. Implementation execution rules: - - **Setup first**: Initialize project structure, dependencies, configuration - - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios - - **Core development**: Implement models, services, CLI commands, endpoints - - **Integration work**: Database connections, middleware, logging, external services - - **Polish and validation**: Unit tests, performance optimization, documentation - -8. Progress tracking and error handling: +6. Execute the tasks in tasks.md order. Tasks marked [P] may run together; tasks + that touch the same file run one after another. Where the task list includes + test tasks, write those tests before the code they cover. Verify each phase's + checkpoint before starting the next. + +7. Progress tracking and error handling: - Report progress after each completed task - Halt execution if any non-parallel task fails - For parallel tasks [P], continue with successful tasks, report failed ones @@ -159,7 +77,7 @@ You **MUST** consider the user input before proceeding (if not empty). - Suggest next steps if implementation cannot proceed - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file. -9. Completion validation: +8. Completion validation: - Verify all required tasks are completed - Check that implemented features match the original specification - Validate that tests pass and coverage meets requirements @@ -167,32 +85,3 @@ You **MUST** consider the user input before proceeding (if not empty). - Report final status with summary of completed work Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/speckit.tasks` first to regenerate the task list. - -10. **Check for extension hooks**: After completion validation, check if `.specify/extensions.yml` exists in the project root. - - If it exists, read it and look for entries under the `hooks.after_implement` key - - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally - - Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default. - - For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions: - - If the hook has no `condition` field, or it is null/empty, treat the hook as executable - - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation - - For each executable hook, output the following based on its `optional` flag: - - **Optional hook** (`optional: true`): - ``` - ## Extension Hooks - - **Optional Hook**: {extension} - Command: `/{command}` - Description: {description} - - Prompt: {prompt} - To execute: `/{command}` - ``` - - **Mandatory hook** (`optional: false`): - ``` - ## Extension Hooks - - **Automatic Hook**: {extension} - Executing: `/{command}` - EXECUTE_COMMAND: {command} - ``` - - If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently diff --git a/.claude/commands/speckit.plan.md b/.claude/commands/speckit.plan.md index e3c0764b..9a6f142e 100644 --- a/.claude/commands/speckit.plan.md +++ b/.claude/commands/speckit.plan.md @@ -16,41 +16,7 @@ handoffs: $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). - -## Pre-Execution Checks - -**Check for extension hooks (before planning)**: -- Check if `.specify/extensions.yml` exists in the project root. -- If it exists, read it and look for entries under the `hooks.before_plan` key -- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally -- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default. -- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions: - - If the hook has no `condition` field, or it is null/empty, treat the hook as executable - - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation -- For each executable hook, output the following based on its `optional` flag: - - **Optional hook** (`optional: true`): - ``` - ## Extension Hooks - - **Optional Pre-Hook**: {extension} - Command: `/{command}` - Description: {description} - - Prompt: {prompt} - To execute: `/{command}` - ``` - - **Mandatory hook** (`optional: false`): - ``` - ## Extension Hooks - - **Automatic Pre-Hook**: {extension} - Executing: `/{command}` - EXECUTE_COMMAND: {command} - - Wait for the result of the hook command before proceeding to the Outline. - ``` -- If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently +The user's input above, when present, shapes everything that follows. ## Outline @@ -69,35 +35,6 @@ You **MUST** consider the user input before proceeding (if not empty). 4. **Stop and report**: Command ends after Phase 2 planning. Report branch, IMPL_PLAN path, and generated artifacts. -5. **Check for extension hooks**: After reporting, check if `.specify/extensions.yml` exists in the project root. - - If it exists, read it and look for entries under the `hooks.after_plan` key - - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally - - Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default. - - For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions: - - If the hook has no `condition` field, or it is null/empty, treat the hook as executable - - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation - - For each executable hook, output the following based on its `optional` flag: - - **Optional hook** (`optional: true`): - ``` - ## Extension Hooks - - **Optional Hook**: {extension} - Command: `/{command}` - Description: {description} - - Prompt: {prompt} - To execute: `/{command}` - ``` - - **Mandatory hook** (`optional: false`): - ``` - ## Extension Hooks - - **Automatic Hook**: {extension} - Executing: `/{command}` - EXECUTE_COMMAND: {command} - ``` - - If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently - ## Phases ### Phase 0: Outline & Research @@ -107,14 +44,10 @@ You **MUST** consider the user input before proceeding (if not empty). - For each dependency β†’ best practices task - For each integration β†’ patterns task -2. **Generate and dispatch research agents**: - - ```text - For each unknown in Technical Context: - Task: "Research {unknown} for {feature context}" - For each technology choice: - Task: "Find best practices for {tech} in {domain}" - ``` +2. **Resolve each unknown**: research it yourself, or hand it to a sub-agent when + the question is independent of the others and large enough to be worth its own + context. The stack is fixed (see Technical Context), so a technology the plan + merely restates needs no research task. 3. **Consolidate findings** in `research.md` using format: - Decision: [what was chosen] diff --git a/.claude/commands/speckit.specify.md b/.claude/commands/speckit.specify.md index fbb630ba..04b8763e 100644 --- a/.claude/commands/speckit.specify.md +++ b/.claude/commands/speckit.specify.md @@ -16,41 +16,7 @@ handoffs: $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). - -## Pre-Execution Checks - -**Check for extension hooks (before specification)**: -- Check if `.specify/extensions.yml` exists in the project root. -- If it exists, read it and look for entries under the `hooks.before_specify` key -- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally -- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default. -- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions: - - If the hook has no `condition` field, or it is null/empty, treat the hook as executable - - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation -- For each executable hook, output the following based on its `optional` flag: - - **Optional hook** (`optional: true`): - ``` - ## Extension Hooks - - **Optional Pre-Hook**: {extension} - Command: `/{command}` - Description: {description} - - Prompt: {prompt} - To execute: `/{command}` - ``` - - **Mandatory hook** (`optional: false`): - ``` - ## Extension Hooks - - **Automatic Pre-Hook**: {extension} - Executing: `/{command}` - EXECUTE_COMMAND: {command} - - Wait for the result of the hook command before proceeding to the Outline. - ``` -- If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently +The user's input above, when present, shapes everything that follows. ## Outline @@ -198,50 +164,16 @@ Given that feature description, do this: **Your choice**: _[Wait for user response]_ ``` - 4. **CRITICAL - Table Formatting**: Ensure markdown tables are properly formatted: - - Use consistent spacing with pipes aligned - - Each cell should have spaces around content: `| Content |` not `|Content|` - - Header separator must have at least 3 dashes: `|--------|` - - Test that the table renders correctly in markdown preview - 5. Number questions sequentially (Q1, Q2, Q3 - max 3 total) - 6. Present all questions together before waiting for responses - 7. Wait for user to respond with their choices for all questions (e.g., "Q1: A, Q2: Custom - [details], Q3: B") - 8. Update the spec by replacing each [NEEDS CLARIFICATION] marker with the user's selected or provided answer - 9. Re-run validation after all clarifications are resolved + 4. Number questions sequentially (Q1, Q2, Q3 - max 3 total) + 5. Present all questions together before waiting for responses + 6. Wait for user to respond with their choices for all questions (e.g., "Q1: A, Q2: Custom - [details], Q3: B") + 7. Update the spec by replacing each [NEEDS CLARIFICATION] marker with the user's selected or provided answer + 8. Re-run validation after all clarifications are resolved d. **Update Checklist**: After each validation iteration, update the checklist file with current pass/fail status 7. Report completion with branch name, spec file path, checklist results, and readiness for the next phase (`/speckit.clarify` or `/speckit.plan`). -8. **Check for extension hooks**: After reporting completion, check if `.specify/extensions.yml` exists in the project root. - - If it exists, read it and look for entries under the `hooks.after_specify` key - - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally - - Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default. - - For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions: - - If the hook has no `condition` field, or it is null/empty, treat the hook as executable - - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation - - For each executable hook, output the following based on its `optional` flag: - - **Optional hook** (`optional: true`): - ``` - ## Extension Hooks - - **Optional Hook**: {extension} - Command: `/{command}` - Description: {description} - - Prompt: {prompt} - To execute: `/{command}` - ``` - - **Mandatory hook** (`optional: false`): - ``` - ## Extension Hooks - - **Automatic Hook**: {extension} - Executing: `/{command}` - EXECUTE_COMMAND: {command} - ``` - - If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently - **NOTE:** The script creates and checks out the new branch and initializes the spec file before writing. ## Quick Guidelines diff --git a/.claude/commands/speckit.tasks.md b/.claude/commands/speckit.tasks.md index d021892d..3fa175c2 100644 --- a/.claude/commands/speckit.tasks.md +++ b/.claude/commands/speckit.tasks.md @@ -17,41 +17,7 @@ handoffs: $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). - -## Pre-Execution Checks - -**Check for extension hooks (before tasks generation)**: -- Check if `.specify/extensions.yml` exists in the project root. -- If it exists, read it and look for entries under the `hooks.before_tasks` key -- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally -- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default. -- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions: - - If the hook has no `condition` field, or it is null/empty, treat the hook as executable - - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation -- For each executable hook, output the following based on its `optional` flag: - - **Optional hook** (`optional: true`): - ``` - ## Extension Hooks - - **Optional Pre-Hook**: {extension} - Command: `/{command}` - Description: {description} - - Prompt: {prompt} - To execute: `/{command}` - ``` - - **Mandatory hook** (`optional: false`): - ``` - ## Extension Hooks - - **Automatic Pre-Hook**: {extension} - Executing: `/{command}` - EXECUTE_COMMAND: {command} - - Wait for the result of the hook command before proceeding to the Outline. - ``` -- If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently +The user's input above, when present, shapes everything that follows. ## Outline @@ -94,42 +60,13 @@ You **MUST** consider the user input before proceeding (if not empty). - Suggested MVP scope (typically just User Story 1) - Format validation: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths) -6. **Check for extension hooks**: After tasks.md is generated, check if `.specify/extensions.yml` exists in the project root. - - If it exists, read it and look for entries under the `hooks.after_tasks` key - - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally - - Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default. - - For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions: - - If the hook has no `condition` field, or it is null/empty, treat the hook as executable - - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation - - For each executable hook, output the following based on its `optional` flag: - - **Optional hook** (`optional: true`): - ``` - ## Extension Hooks - - **Optional Hook**: {extension} - Command: `/{command}` - Description: {description} - - Prompt: {prompt} - To execute: `/{command}` - ``` - - **Mandatory hook** (`optional: false`): - ``` - ## Extension Hooks - - **Automatic Hook**: {extension} - Executing: `/{command}` - EXECUTE_COMMAND: {command} - ``` - - If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently - Context for task generation: $ARGUMENTS The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context. ## Task Generation Rules -**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing. +Tasks are organized by user story, so each story can be implemented and tested on its own. **Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach. diff --git a/.claude/commands/speckit.taskstoissues.md b/.claude/commands/speckit.taskstoissues.md index 07991911..dc0ad717 100644 --- a/.claude/commands/speckit.taskstoissues.md +++ b/.claude/commands/speckit.taskstoissues.md @@ -9,7 +9,7 @@ tools: ['github/github-mcp-server/issue_write'] $ARGUMENTS ``` -You **MUST** consider the user input before proceeding (if not empty). +The user's input above, when present, shapes everything that follows. ## Outline diff --git a/.specify/memory/constitution.md b/.specify/memory/constitution.md index d201562c..a3814887 100644 --- a/.specify/memory/constitution.md +++ b/.specify/memory/constitution.md @@ -1,14 +1,24 @@ # GramFrame Constitution @@ -45,7 +55,8 @@ coordinate, event, or rendering regressions. ### III. Modular Mode Architecture -Each interaction mode (Analysis, Harmonics, Doppler) MUST extend `BaseMode`. +Each interaction mode β€” Pan, Analysis, Harmonics, Sidebands and Doppler, with +`src/modes/modeRoster.js` as the one list β€” MUST extend `BaseMode`. New modes MUST be registered via `ModeFactory`. Modes MUST NOT directly depend on each other. @@ -65,7 +76,8 @@ GramFrame instances MUST be configured via HTML tables with class `gram-config`. The component auto-discovers and replaces these tables on `DOMContentLoaded`. - Configuration MUST be parsed from 2-column table rows (`parameter | value`) -- The first row MUST contain the spectrogram `` element +- The first row MUST hold the source: the spectrogram ``, or the `