@polymorphism-tech/morph-spec 8.0.0 → 8.1.1

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "8.0.0",
+  "version": "8.1.1",
   "displayName": "MORPH-SPEC Framework",
   "description": "Spec-driven development with 38 agents and 8-phase workflow for .NET/Blazor/Next.js/Azure",
   "publisher": "polymorphism-tech",

package/docs/CHEATSHEET.md

@@ -237,4 +237,4 @@ These files are never edited directly. Use CLI commands or `morph-spec update` i
 
 ---
 
-*morph-spec v8.0.0 by Polymorphism Tech*
+*morph-spec v8.1.1 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -256,4 +256,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v8.0.0 by Polymorphism Tech*
+*morph-spec v8.1.1 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -25,7 +25,7 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - Apresentar gates com o template fixo definido em MORPH.md / morph-plan.
 - Registrar decisões não triviais em `decisions.md`.
 - Aplicar `morph-eval` após cada tarefa; silêncio em score ≥ 9 é o sinal correto. Score < 9 dispara o loop de correção autônomo (re-implementa, sem pausa), não escala ao humano entre tarefas. No Gate 3, o score composto da feature vem do **avaliador independente** despachado pela `morph-review` (persona `evaluator`, contexto fresco) — nunca de auto-avaliação de quem implementou.
-- Incluir as 3 cláusulas de protocolo em todo dispatch de sub-agent (**ato final = relatório via `SendMessage` para `main` como a ÚLTIMA tool call, encerrando imediatamente depois — zero texto extra, zero "aguardando confirmação"** — última mensagem em texto não chega ao orquestrador; não tocar tasks.json/feature.json/board; sem build/test da suíte compartilhada em batch paralelo) — templates com exemplo literal em `morph-implement` §4 e `morph-apply` §3b. O hook `subagent-report-guard` bloqueia uma vez o encerramento de subagent despachado sem SendMessage. **Ao consumir o relatório, libere a sessão do sub-agent com `TaskStop`** — não deixe o idle-detector do harness ser o único a encerrá-la.
+- Incluir as 3 cláusulas do contrato do relatório final em todo dispatch de sub-agent (**ato final = o relatório é a ÚLTIMA MENSAGEM DE TEXTO do sub-agent, com os 4 itens obrigatórios (o quê / arquivos / problemas / auto-score 0-10) — ela é o valor de retorno e chega inteira ao orquestrador; não chamar `SendMessage`, que gera um evento a mais e custa um turno inútil**; não tocar tasks.json/feature.json/board; sem build/test da suíte compartilhada em batch paralelo) — templates em `morph-implement` §4 e `morph-apply` §3b.
 
 ## Slash commands
 

package/framework/MORPH.md

@@ -250,7 +250,7 @@ Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do d
 
 **Mecanismo de dispatch:** os agents de domínio são subagents **registrados** (`.claude/agents/morph-{id}.md`, gerados de `agents.json` — a fonte única — na instalação). Despache com `subagent_type: "morph-{id}"` (ex.: `morph-dotnet-senior`): a persona é o **system prompt** do subagent, com tools, model e MCPs definidos por domínio no próprio `agents.json` (ex.: `context7` para docs vivas nos implementadores; Stitch/Gemini/Playwright no `morph-ui-designer`; o `morph-evaluator` é read-only). **Fallback** quando o tipo não está registrado (stack não instalado neste projeto): `general-purpose` com o campo `persona` de `agents.json` colado no prompt, **registrado nas `notes` da task**. O `**Persona:**` do recap registra sempre o mecanismo real usado — nunca uma auto-declaração.
 
-**Persona de estágio — scout:** além das personas de domínio, existe o `morph-scout` (read-only: Read/Glob/Grep/Bash somente-leitura). Despache-o quando precisar de um mapa do território sem contaminar a thread principal — obrigatoriamente no início de um hotfix (localizar root cause + blast radius) e opcionalmente antes do plan de uma feature grande (buscar código, docs e specs anteriores relevantes). Ele devolve um mapa curto via SendMessage e encerra; não escreve código.
+**Persona de estágio — scout:** além das personas de domínio, existe o `morph-scout` (read-only: Read/Glob/Grep/Bash somente-leitura). Despache-o quando precisar de um mapa do território sem contaminar a thread principal — obrigatoriamente no início de um hotfix (localizar root cause + blast radius) e opcionalmente antes do plan de uma feature grande (buscar código, docs e specs anteriores relevantes). Ele devolve um mapa curto como relatório final e encerra; não escreve código.
 
 **O que passar ao sub-agent:**
 - Especificação da tarefa (do tasks.json)
@@ -269,10 +269,10 @@ Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do d
 - Problemas encontrados e como foram resolvidos
 - Auto-score 0-10 com justificativa em uma linha
 
-**Protocolo obrigatório do sub-agent** (cláusulas que todo prompt de dispatch inclui — ver templates em `morph-implement` §4 e `morph-apply` §3b):
-1. **ATO FINAL: enviar o relatório completo via `SendMessage` para `main` como a ÚLTIMA tool call do turno, e encerrar IMEDIATAMENTE depois** — a última mensagem em texto NÃO chega ao orquestrador; só SendMessage chega. Zero texto adicional, zero nova tool call, zero "aguardando confirmação" depois do SendMessage: é o encerramento, não um passo intermediário. Terminar idle sem SendMessage, ou continuar agindo depois dele, é **falha de protocolo**: o hook `subagent-report-guard` bloqueia o encerramento uma vez com a instrução, e a cobrança do orquestrador via SendMessage é apenas o fallback (registrada como falha no recap). Os templates trazem o exemplo literal da chamada.
+**Contrato do relatório final** (cláusulas que todo prompt de dispatch inclui — ver templates em `morph-implement` §4 e `morph-apply` §3b):
+1. **ATO FINAL: o seu relatório é a sua ÚLTIMA MENSAGEM DE TEXTO** — ela é o valor de retorno do sub-agent e chega inteira ao orquestrador. **Não chame `SendMessage`**: ele gera um evento a mais (o teammate-message) além da notificação de término, custando um turno inútil ao orquestrador. Conteúdo obrigatório: (1) o que foi feito em 2-3 frases, (2) arquivos modificados, (3) problemas encontrados e como foram resolvidos, (4) auto-score 0-10 com justificativa em uma linha. Relatório oco ou sem os 4 itens é **falha de protocolo** — registrada no recap.
 2. Não tocar em `tasks.json`, `feature.json`, `state.json` nem no board de sessão (TaskCreate/TaskUpdate) — todo estado é gravado exclusivamente pelo orquestrador.
-3. **Verificação em batch paralelo — condicional ao isolamento:** em batch **sem isolamento** (agentes na mesma working tree), não rode build/test da suíte compartilhada — a verificação (`morph-spec verify`) é do orquestrador, uma vez, pós-batch. Em batch **com `isolation: "worktree"`** (quando o `morph-spec dag` recomenda, por colisão de `outputs` entre fluxos), a regra se inverte: rode build/test **dentro do seu worktree**, commite o trabalho na branch do worktree como penúltimo ato (antes do SendMessage), reporte a branch + status de build, e **nunca** faça merge nem toque na árvore principal — a integração é do orquestrador.
+3. **Verificação em batch paralelo — condicional ao isolamento:** em batch **sem isolamento** (agentes na mesma working tree), não rode build/test da suíte compartilhada — a verificação (`morph-spec verify`) é do orquestrador, uma vez, pós-batch. Em batch **com `isolation: "worktree"`** (quando o `morph-spec dag` recomenda, por colisão de `outputs` entre fluxos), a regra se inverte: rode build/test **dentro do seu worktree**, commite o trabalho na branch do worktree como último ato antes do relatório, reporte a branch + status de build, e **nunca** faça merge nem toque na árvore principal — a integração é do orquestrador.
 
 O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais contexto para começar, a tarefa não estava bem especificada — refine antes de despachar.
 
@@ -281,7 +281,7 @@ O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais
 - Quando o feedback do sub-agent precisaria ser discutido em tempo real — dispatch é assíncrono.
 - Quando a tarefa envolve mudanças de arquitetura que o Orchestrator precisa validar antes de executar.
 
-**Após receber o retorno do sub-agent:** leia o auto-score — ele é **triagem, não aprovação**. Se for < 7, re-despache com o feedback específico (ou corrija inline) antes de avaliar. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (a barra única do §0); integre o resultado ao recap.md e siga para a próxima tarefa. **Libere a sessão do sub-agent imediatamente ao consumir o relatório** — `TaskStop(task_id: <id/nome retornado pelo dispatch>)`, tratando falha (agente já finalizado sozinho) como não-fatal — não espere o idle-detector do harness fazer isso sozinho minutos depois.
+**Após receber o retorno do sub-agent:** leia o auto-score — ele é **triagem, não aprovação**. Se for < 7, re-despache com o feedback específico (ou corrija inline) antes de avaliar. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (a barra única do §0); integre o resultado ao recap.md e siga para a próxima tarefa.
 
 > **Anti-padrão a evitar:** implementar múltiplas tasks de domínios diferentes inline, em sequência, na thread principal — "eu já sei o padrão de cada uma". Isso é exatamente o sinal de que o sistema de delegação foi ignorado. Quando uma feature cruza ≥2 domínios, o caminho default é o Orchestrator despachando especialistas, não o Orchestrator virando faz-tudo.
 

package/framework/agents.json

@@ -155,7 +155,7 @@
       "standards": [],
       "tools": "Read, Glob, Grep, Bash",
       "model": "haiku",
-      "persona": "Você é um scout read-only: mapeia o território sem escrever código. Dado um sintoma ou uma feature, localiza os arquivos relevantes, o root cause provável e o blast radius (o que mais é afetado). Usa Read/Glob/Grep e Bash SOMENTE-LEITURA (git log/diff/show, ls, cat) — nunca Write/Edit, nunca comandos que mudam estado. Devolve um mapa curto e acionável (arquivos com paths, hipótese de causa, áreas de impacto) via SendMessage e encerra. Não implementa, não corrige — ilumina o caminho para quem vai."
+      "persona": "Você é um scout read-only: mapeia o território sem escrever código. Dado um sintoma ou uma feature, localiza os arquivos relevantes, o root cause provável e o blast radius (o que mais é afetado). Usa Read/Glob/Grep e Bash SOMENTE-LEITURA (git log/diff/show, ls, cat) — nunca Write/Edit, nunca comandos que mudam estado. Devolve um mapa curto e acionável (arquivos com paths, hipótese de causa, áreas de impacto) como relatório final e encerra. Não implementa, não corrige — ilumina o caminho para quem vai."
     }
   }
 }

package/framework/commands/commit.md

@@ -1,166 +1,166 @@
----
-allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*)
-argument-hint: [message] | --no-verify | --amend
-description: Create well-formatted commits with conventional commit format and emoji
----
-
-# Smart Git Commit
-
-Create well-formatted commit: $ARGUMENTS
-
-## Current Repository State
-
-- Git status: !git status --porcelain
-- Current branch: !git branch --show-current
-- Staged changes: !git diff --cached --stat
-- Unstaged changes: !git diff --stat
-- Recent commits: !git log --oneline -5
-
-## What This Command Does
-
-1. Unless specified with --no-verify, automatically runs pre-commit checks:
-   - pnpm lint to ensure code quality
-   - pnpm build to verify the build succeeds
-   - pnpm generate:docs to update documentation
-2. Checks which files are staged with git status
-3. If 0 files are staged, automatically adds all modified and new files with git add
-4. Performs a git diff to understand what changes are being committed
-5. Analyzes the diff to determine if multiple distinct logical changes are present
-6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
-7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
-
-## Best Practices for Commits
-
-- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
-- **Atomic commits**: Each commit should contain related changes that serve a single purpose
-- **Split large changes**: If changes touch multiple concerns, split them into separate commits
-- **Conventional commit format**: Use the format <type>: <description> where type is one of:
-  - feat: A new feature
-  - fix: A bug fix
-  - docs: Documentation changes
-  - style: Code style changes (formatting, etc)
-  - refactor: Code changes that neither fix bugs nor add features
-  - perf: Performance improvements
-  - test: Adding or fixing tests
-  - chore: Changes to the build process, tools, etc.
-- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
-- **Concise first line**: Keep the first line under 72 characters
-- **Emoji**: Each commit type is paired with an appropriate emoji:
-  - ✨ feat: New feature
-  - 🐛 fix: Bug fix
-  - 📝 docs: Documentation
-  - 💄 style: Formatting/style
-  - ♻️ refactor: Code refactoring
-  - ⚡️ perf: Performance improvements
-  - ✅ test: Tests
-  - 🔧 chore: Tooling, configuration
-  - 🚀 ci: CI/CD improvements
-  - 🗑️ revert: Reverting changes
-  - 🧪 test: Add a failing test
-  - 🚨 fix: Fix compiler/linter warnings
-  - 🔒️ fix: Fix security issues
-  - 👥 chore: Add or update contributors
-  - 🚚 refactor: Move or rename resources
-  - 🏗️ refactor: Make architectural changes
-  - 🔀 chore: Merge branches
-  - 📦️ chore: Add or update compiled files or packages
-  - ➕ chore: Add a dependency
-  - ➖ chore: Remove a dependency
-  - 🌱 chore: Add or update seed files
-  - 🧑‍💻 chore: Improve developer experience
-  - 🧵 feat: Add or update code related to multithreading or concurrency
-  - 🔍️ feat: Improve SEO
-  - 🏷️ feat: Add or update types
-  - 💬 feat: Add or update text and literals
-  - 🌐 feat: Internationalization and localization
-  - 👔 feat: Add or update business logic
-  - 📱 feat: Work on responsive design
-  - 🚸 feat: Improve user experience / usability
-  - 🩹 fix: Simple fix for a non-critical issue
-  - 🥅 fix: Catch errors
-  - 👽️ fix: Update code due to external API changes
-  - 🔥 fix: Remove code or files
-  - 🎨 style: Improve structure/format of the code
-  - 🚑️ fix: Critical hotfix
-  - 🎉 chore: Begin a project
-  - 🔖 chore: Release/Version tags
-  - 🚧 wip: Work in progress
-  - 💚 fix: Fix CI build
-  - 📌 chore: Pin dependencies to specific versions
-  - 👷 ci: Add or update CI build system
-  - 📈 feat: Add or update analytics or tracking code
-  - ✏️ fix: Fix typos
-  - ⏪️ revert: Revert changes
-  - 📄 chore: Add or update license
-  - 💥 feat: Introduce breaking changes
-  - 🍱 assets: Add or update assets
-  - ♿️ feat: Improve accessibility
-  - 💡 docs: Add or update comments in source code
-  - 🗃️ db: Perform database related changes
-  - 🔊 feat: Add or update logs
-  - 🔇 fix: Remove logs
-  - 🤡 test: Mock things
-  - 🥚 feat: Add or update an easter egg
-  - 🙈 chore: Add or update .gitignore file
-  - 📸 test: Add or update snapshots
-  - ⚗️ experiment: Perform experiments
-  - 🚩 feat: Add, update, or remove feature flags
-  - 💫 ui: Add or update animations and transitions
-  - ⚰️ refactor: Remove dead code
-  - 🦺 feat: Add or update code related to validation
-  - ✈️ feat: Improve offline support
-
-## Guidelines for Splitting Commits
-
-When analyzing the diff, consider splitting commits based on these criteria:
-
-1. **Different concerns**: Changes to unrelated parts of the codebase
-2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
-3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
-4. **Logical grouping**: Changes that would be easier to understand or review separately
-5. **Size**: Very large changes that would be clearer if broken down
-
-## Examples
-
-Good commit messages:
-- ✨ feat: add user authentication system
-- 🐛 fix: resolve memory leak in rendering process
-- 📝 docs: update API documentation with new endpoints
-- ♻️ refactor: simplify error handling logic in parser
-- 🚨 fix: resolve linter warnings in component files
-- 🧑‍💻 chore: improve developer tooling setup process
-- 👔 feat: implement business logic for transaction validation
-- 🩹 fix: address minor styling inconsistency in header
-- 🚑️ fix: patch critical security vulnerability in auth flow
-- 🎨 style: reorganize component structure for better readability
-- 🔥 fix: remove deprecated legacy code
-- 🦺 feat: add input validation for user registration form
-- 💚 fix: resolve failing CI pipeline tests
-- 📈 feat: implement analytics tracking for user engagement
-- 🔒️ fix: strengthen authentication password requirements
-- ♿️ feat: improve form accessibility for screen readers
-
-Example of splitting commits:
-- First commit: ✨ feat: add new solc version type definitions
-- Second commit: 📝 docs: update documentation for new solc versions
-- Third commit: 🔧 chore: update package.json dependencies
-- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
-- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
-- Sixth commit: 🚨 fix: resolve linting issues in new code
-- Seventh commit: ✅ test: add unit tests for new solc version features
-- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
-
-## Command Options
-
-- --no-verify: Skip running the pre-commit checks (lint, build, generate:docs)
-
-## Important Notes
-
-- By default, pre-commit checks (pnpm lint, pnpm build, pnpm generate:docs) will run to ensure code quality
-- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
-- If specific files are already staged, the command will only commit those files
-- If no files are staged, it will automatically stage all modified and new files
-- The commit message will be constructed based on the changes detected
-- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
-- If suggesting multiple commits, it will help you stage and commit the changes separately
-- Always reviews the commit diff to ensure the message matches the changes
+---
+allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*)
+argument-hint: [message] | --no-verify | --amend
+description: Create well-formatted commits with conventional commit format and emoji
+---
+
+# Smart Git Commit
+
+Create well-formatted commit: $ARGUMENTS
+
+## Current Repository State
+
+- Git status: !git status --porcelain
+- Current branch: !git branch --show-current
+- Staged changes: !git diff --cached --stat
+- Unstaged changes: !git diff --stat
+- Recent commits: !git log --oneline -5
+
+## What This Command Does
+
+1. Unless specified with --no-verify, automatically runs pre-commit checks:
+   - pnpm lint to ensure code quality
+   - pnpm build to verify the build succeeds
+   - pnpm generate:docs to update documentation
+2. Checks which files are staged with git status
+3. If 0 files are staged, automatically adds all modified and new files with git add
+4. Performs a git diff to understand what changes are being committed
+5. Analyzes the diff to determine if multiple distinct logical changes are present
+6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
+7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
+
+## Best Practices for Commits
+
+- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
+- **Atomic commits**: Each commit should contain related changes that serve a single purpose
+- **Split large changes**: If changes touch multiple concerns, split them into separate commits
+- **Conventional commit format**: Use the format <type>: <description> where type is one of:
+  - feat: A new feature
+  - fix: A bug fix
+  - docs: Documentation changes
+  - style: Code style changes (formatting, etc)
+  - refactor: Code changes that neither fix bugs nor add features
+  - perf: Performance improvements
+  - test: Adding or fixing tests
+  - chore: Changes to the build process, tools, etc.
+- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
+- **Concise first line**: Keep the first line under 72 characters
+- **Emoji**: Each commit type is paired with an appropriate emoji:
+  - ✨ feat: New feature
+  - 🐛 fix: Bug fix
+  - 📝 docs: Documentation
+  - 💄 style: Formatting/style
+  - ♻️ refactor: Code refactoring
+  - ⚡️ perf: Performance improvements
+  - ✅ test: Tests
+  - 🔧 chore: Tooling, configuration
+  - 🚀 ci: CI/CD improvements
+  - 🗑️ revert: Reverting changes
+  - 🧪 test: Add a failing test
+  - 🚨 fix: Fix compiler/linter warnings
+  - 🔒️ fix: Fix security issues
+  - 👥 chore: Add or update contributors
+  - 🚚 refactor: Move or rename resources
+  - 🏗️ refactor: Make architectural changes
+  - 🔀 chore: Merge branches
+  - 📦️ chore: Add or update compiled files or packages
+  - ➕ chore: Add a dependency
+  - ➖ chore: Remove a dependency
+  - 🌱 chore: Add or update seed files
+  - 🧑‍💻 chore: Improve developer experience
+  - 🧵 feat: Add or update code related to multithreading or concurrency
+  - 🔍️ feat: Improve SEO
+  - 🏷️ feat: Add or update types
+  - 💬 feat: Add or update text and literals
+  - 🌐 feat: Internationalization and localization
+  - 👔 feat: Add or update business logic
+  - 📱 feat: Work on responsive design
+  - 🚸 feat: Improve user experience / usability
+  - 🩹 fix: Simple fix for a non-critical issue
+  - 🥅 fix: Catch errors
+  - 👽️ fix: Update code due to external API changes
+  - 🔥 fix: Remove code or files
+  - 🎨 style: Improve structure/format of the code
+  - 🚑️ fix: Critical hotfix
+  - 🎉 chore: Begin a project
+  - 🔖 chore: Release/Version tags
+  - 🚧 wip: Work in progress
+  - 💚 fix: Fix CI build
+  - 📌 chore: Pin dependencies to specific versions
+  - 👷 ci: Add or update CI build system
+  - 📈 feat: Add or update analytics or tracking code
+  - ✏️ fix: Fix typos
+  - ⏪️ revert: Revert changes
+  - 📄 chore: Add or update license
+  - 💥 feat: Introduce breaking changes
+  - 🍱 assets: Add or update assets
+  - ♿️ feat: Improve accessibility
+  - 💡 docs: Add or update comments in source code
+  - 🗃️ db: Perform database related changes
+  - 🔊 feat: Add or update logs
+  - 🔇 fix: Remove logs
+  - 🤡 test: Mock things
+  - 🥚 feat: Add or update an easter egg
+  - 🙈 chore: Add or update .gitignore file
+  - 📸 test: Add or update snapshots
+  - ⚗️ experiment: Perform experiments
+  - 🚩 feat: Add, update, or remove feature flags
+  - 💫 ui: Add or update animations and transitions
+  - ⚰️ refactor: Remove dead code
+  - 🦺 feat: Add or update code related to validation
+  - ✈️ feat: Improve offline support
+
+## Guidelines for Splitting Commits
+
+When analyzing the diff, consider splitting commits based on these criteria:
+
+1. **Different concerns**: Changes to unrelated parts of the codebase
+2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
+3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
+4. **Logical grouping**: Changes that would be easier to understand or review separately
+5. **Size**: Very large changes that would be clearer if broken down
+
+## Examples
+
+Good commit messages:
+- ✨ feat: add user authentication system
+- 🐛 fix: resolve memory leak in rendering process
+- 📝 docs: update API documentation with new endpoints
+- ♻️ refactor: simplify error handling logic in parser
+- 🚨 fix: resolve linter warnings in component files
+- 🧑‍💻 chore: improve developer tooling setup process
+- 👔 feat: implement business logic for transaction validation
+- 🩹 fix: address minor styling inconsistency in header
+- 🚑️ fix: patch critical security vulnerability in auth flow
+- 🎨 style: reorganize component structure for better readability
+- 🔥 fix: remove deprecated legacy code
+- 🦺 feat: add input validation for user registration form
+- 💚 fix: resolve failing CI pipeline tests
+- 📈 feat: implement analytics tracking for user engagement
+- 🔒️ fix: strengthen authentication password requirements
+- ♿️ feat: improve form accessibility for screen readers
+
+Example of splitting commits:
+- First commit: ✨ feat: add new solc version type definitions
+- Second commit: 📝 docs: update documentation for new solc versions
+- Third commit: 🔧 chore: update package.json dependencies
+- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
+- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
+- Sixth commit: 🚨 fix: resolve linting issues in new code
+- Seventh commit: ✅ test: add unit tests for new solc version features
+- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
+
+## Command Options
+
+- --no-verify: Skip running the pre-commit checks (lint, build, generate:docs)
+
+## Important Notes
+
+- By default, pre-commit checks (pnpm lint, pnpm build, pnpm generate:docs) will run to ensure code quality
+- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
+- If specific files are already staged, the command will only commit those files
+- If no files are staged, it will automatically stage all modified and new files
+- The commit message will be constructed based on the changes detected
+- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
+- If suggesting multiple commits, it will help you stage and commit the changes separately
+- Always reviews the commit diff to ensure the message matches the changes