[Feature]: Add /speckit.guide for dry-run implementation planning

### Problem Statement

While /speckit.clarify helps reduce ambiguity in the feature specification before planning, there is currently no equivalent step for validating implementation scope after task generation and before execution.

This leaves a gap where /speckit.implement may exceed the intended scope by acting on future tasks or making architectural assumptions that were not explicitly reviewed beforehand.

This creates risks such as:

Scope creep across planned phases
Unintended architecture changes
Hallucinated dependencies or missing interfaces
Higher review and rollback costs

### Proposed Solution

Introduce a new optional command: `/speckit.guide`.

This command would run after `/speckit.tasks` and before `/speckit.implement`, generating a `guide.md` file that acts as a dry-run implementation plan.

The generated guide would describe:

* Which files are expected to be modified
* Which interfaces or services may be affected
* Required dependencies or prerequisites
* Execution order of tasks
* Scope boundaries for the current phase
* Potential risks or stop conditions

This would provide developers with a reviewable implementation artifact before execution, reducing the chance of scope drift and improving architecture control.

Proposed workflow:

```text
/speckit.specify
→ /speckit.clarify
→ /speckit.plan
→ /speckit.tasks
→ /speckit.guide
→ Human review
→ /speckit.implement
```

This would not replace `/speckit.clarify`, but complement it by extending the same validation principle into the implementation phase.

### Alternatives Considered

Yes, I considered the following alternatives:

1. **Using `/speckit.clarify`**

* This helps resolve ambiguity in the feature specification before planning.
* However, it does not address implementation scope validation after task generation.

2. **Improving `/speckit.implement` directly**

* Scope validation logic could be embedded into `/speckit.implement`.
* However, this would mix planning/review concerns with execution, reducing workflow transparency.

3. **Manual `guide.md` creation**

* This is the current workaround I use.
* It provides better control, but it is manual, inconsistent, and not integrated into the Spec Kit workflow.

I believe a dedicated `/speckit.guide` command is the cleanest solution because it introduces a reusable, explicit review layer between task generation and implementation.

### Component

Agent integrations (command files, workflows)

### AI Agent (if applicable)

None

### Use Cases

_No response_

### Acceptance Criteria

_No response_

### Additional Context

_No response_

Commencez par examiner les fichiers de commandes et les workflows existants pour /speckit.tasks et /speckit.implement afin de comprendre comment s’intégrerait une nouvelle étape /speckit.guide. L’issue propose de générer guide.md avec le périmètre, les dépendances, l’ordre d’exécution, les limites, les risques et les conditions d’arrêt, mais ne fournit aucun fichier nommé, test ni critère d’acceptation ; ceux-ci doivent être définis avant que l’implémentation soit terminée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.