cline-spec-kit-workflows — Prompts
Prompt 1: specify.md (Feature Specification)
Technique: Scripted procedural prompt with numbered execution flow, inline template injection, and quality gate loop.
---
description: Create or update the feature specification from a natural language feature description.
---
## User Input
```text
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty).
Outline
...Given that feature description, do this:
Run the script .specify/scripts/bash/create-new-feature.sh --json "$ARGUMENTS"
from repo root and parse its JSON output for BRANCH_NAME and SPEC_FILE.
IMPORTANT You must only ever run this script once.
Follow this execution flow:
- Parse user description from Input
If empty: ERROR "No feature description provided"
- Extract key concepts from description
Identify: actors, actions, data, constraints
- For unclear aspects:
- Make informed guesses based on context and industry standards
- Only mark with [NEEDS CLARIFICATION: specific question] if:
- The choice significantly impacts feature scope or user experience
- Multiple reasonable interpretations exist with different implications
- No reasonable default exists
- LIMIT: Maximum 3 [NEEDS CLARIFICATION] markers total
- Prioritize clarifications by impact: scope > security/privacy > user experience
**Technique**: Procedural scripted execution with error handling (ERROR keyword), strict limits on clarification requests (max 3), and inline checklist template injection. The `$ARGUMENTS` placeholder is Cline's standard argument substitution mechanism.
---
## Prompt 2: constitution.md (Project Constitution)
**Technique**: Template management + cascading propagation + semantic versioning enforcement.
```markdown
You are updating the project constitution at `.specify/memory/constitution.md`.
This file is a TEMPLATE containing placeholder tokens in square brackets
(e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive
concrete values, (b) fill the template precisely, and (c) propagate any amendments
across dependent artifacts.
`CONSTITUTION_VERSION` must increment according to semantic versioning rules:
* MAJOR: Backward incompatible governance/principle removals or redefinitions.
* MINOR: New principle/section added or materially expanded guidance.
* PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
6. Validation before final output:
- No remaining unexplained bracket tokens.
- Version line matches report.
- Dates ISO format YYYY-MM-DD.
- Principles are declarative, testable, and free of vague language ("should" →
replace with MUST/SHOULD rationale where appropriate).
Technique: Template-filling with explicit validation rules, semantic versioning discipline, and cascading consistency propagation (constitution changes must be reflected in plan-template.md, spec-template.md, tasks-template.md, and all command files).
Prompt 3: implement.md (Implementation Gate)
Technique: Prerequisite-checking + checklist-gated execution flow with automatic ignore file management.
2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
- For each checklist, count:
* Completed items: Lines matching `- [X]` or `- [x]`
* Incomplete items: Lines matching `- [ ]`
- **If any checklist is incomplete**:
* Display the table with incomplete item counts
* **STOP** and ask: "Some checklists are incomplete. Do you want to proceed
with implementation anyway? (yes/no)"
* Wait for user response before continuing
Technique: Programmatic checklist-count logic (regex-based counting of markdown checkbox states) driving a hard stop gate before implementation. This is a novel pattern — the AI is told to count - [X] vs - [ ] patterns as a numeric gate condition.