Repository navigation
[Feature]: Prompt Style Guide #2804
Description
Problem Statement
I'm frustrated when I audit the core markdown prompt files and notice minor formatting, architectural, and structural consistency drift between sequential sections.
For example, in templates/commands/specify.md (Lines 61-77), Step 1 ("Generate a concise short name") uses clean dashes (-) to list out its sub-rules, but Step 2 ("Branch creation") drops bullet points entirely to use double-spaced paragraphs.
Additionally, within templates/commands/specify.md (Lines 130-132) under the Step 6 execution flow, section v. Generate Functional Requirements asks for "testable" requirements but does not explicitly mandate that they be "atomic."
Industry best practice for AI-driven software engineering shows that compound requirements can cause downstream logic fragmentation. While I haven't run into a broken output file myself, leaving these prompt discrepancies unaddressed introduces a strong hypothetical risk. An LLM might experience few-shot mimicry (structural anchoring), causing it to mirror the messy layouts or miss nested logic blocks entirely.
Proposed Solution
I would like us to introduce a minimal Prompt Style Guide to establish baseline rules for any prompts added to this project (including core templates, community presets, and agent flows).
This guide will enforce:
- Standardizing sub-step and constraint hierarchies using unified dashes (
-). - Mandating explicit atomicity constraints for any prompt block generating requirements or tasks.
- Prioritizing the active, imperative voice.
I plan to create this style guide by extracting the most common layout styles already present across the existing prompts. Any edge cases or styling ties during this baseline evaluation will be handled on a case-by-case basis.
Alternatives Considered
I have considered several local and architectural workarounds, though none permanently solves the upstream problem for the community:
- Using a local
.specify/memory/constitution.mdfile to force these constraints at runtime. - Maintaining local template overrides inside individual project repositories.
- Directly modifying the local
skill.mdfiles (which means effectively altering the underlying source code of Spec Kit). - Modifying agent-specific config files like
agents.md. - Manually re-typing or editing the requirements into atomic, standard lines every single time the skill runs (highly inefficient).
Component
Spec templates (BDD, Testing Strategy, etc.)
AI Agent (if applicable)
None
Use Cases
- When community developers build new presets or commands, they have a clear guideline to prevent prompt quality from drifting.
- During template maintenance, reviewers can instantly check incoming PRs against a set formatting baseline.
- When AI agents run the workflows, consistent prompts help them follow the rules better and generate clean, atomic files.
Acceptance Criteria
- A baseline Prompt Style Guide markdown file is added to the documentation.
- Existing prompt templates are lightly refactored to align with the new layout standard.
Additional Context
I noticed these template consistency errors while auditing my local project setup.
AI Disclosure: I used an AI assistant to help me write, refine, and format this entire issue template.
Activity
Yash-Chindam commentedon Aug 18, 2026
Hi maintainers — I’d like to work on this as a focused contribution. My proposed scope is:
I’ll wait for maintainer approval and assignment before implementing, as requested by the contribution guidelines. I used ChatGPT to review the repository guidance and draft this proposal.
Would this focused scope be acceptable?
github-actions commentedon Aug 19, 2026
Feature assessment — prompt-style-guide · Stage 1/5: Intake
Idea Intake: Prompt Style Guide
Idea (as captured)
Restated
The proposal is to add a new Prompt Style Guide document defining baseline formatting conventions (bullet hierarchy, imperative voice, atomicity for requirement blocks) for Spec Kit's prompt/command templates, along with minimal consistency edits to existing templates to match those conventions.
Origin & Context
@Yash-Chindamexpressed interest in contributing a focused implementation (2026-08-18); also AI-assistedFirst-Glance Unknowns
github-actions commentedon Aug 19, 2026
Feature assessment — prompt-style-guide · Stage 2/5: Research
Idea Research: Prompt Style Guide
Users & Demand
@Yash-Chindam) expressed interest in a focused implementation (add style guide + minimal edits), also noting AI assistance. This is a single data point, not a demand signal. — [source: GitHub issue [Feature]: Prompt Style Guide #2804 comment] (confidence: high, cited)Prior Art
docs/,templates/,CONTRIBUTING.md,README.md). — [source: codebase inspection] (confidence: high, cited).specify/extensions/assess/commands/*.md) use a consistent style internally (dash-based sub-bullets, imperative voice throughout, no mixed prose/bullet patterns). This was introduced after the core templates and appears more disciplined. — [source: codebase inspection] (confidence: high, cited)templates/commands/*.md) do exhibit the mixing pattern described in the issue: numbered steps use dashes for sub-items (e.g., Step 1 ofspecify.md) but some numbered steps (e.g., Step 2 "Branch creation" inspecify.md) use prose paragraphs without bullets. This pattern appears inchecklist.md,clarify.md,converge.md,plan.md, andspecify.md. — [source: codebase inspection, grep analysis] (confidence: high, cited)specify.mdStep 6-v says "Each requirement must be testable" but does not say "atomic." Whether "atomic" is implied by "testable" or genuinely missing is a judgment call. — [source: templates/commands/specify.md] (confidence: high, cited)Market & Context
Data & Constraints
Evidence Against the Idea
Gaps & Open Questions
Sources
templates/commands/*.md,CONTRIBUTING.md,.specify/extensions/assess/commands/*.md(local file reads)github-actions commentedon Aug 19, 2026
Feature assessment — prompt-style-guide · Stage 3/5: Problem
Problem Definition: Prompt Style Guide
Problem Statement
Core Spec Kit command templates have minor, inconsistent formatting (mixed bullet-versus-prose sub-steps) with no documented baseline convention to guide contributors, making it unclear which pattern is "correct" when writing new templates or reviewing PRs. The practical impact is low — no agent output failures have been reported — but the absence of any formatting reference creates a low-grade consistency problem that could accumulate over time.
Affected Users & Stakeholders
Goals
templates/commands/specify.md(bullet/prose mixing in numbered steps).Non-Goals
specify.mdwithout separate maintainer validation.Success Metrics
specify.md(baseline: 2 identified locations with mixed formatting).Cost of Inaction
Without a style guide, formatting inconsistencies will accumulate as more contributors add templates and presets. The drift is cosmetic today but makes the template corpus harder to maintain and review over time. However, the near-term cost of inaction is low — no agent output problems have been traced to formatting inconsistency.
Open Questions
specify.mdin scope here, or a separate proposal?]github-actions commentedon Aug 19, 2026
Feature assessment — prompt-style-guide · Stage 4/5: Concept
Concept: Prompt Style Guide
Options
Option A — Full Style Guide with Template Refactor
docs/covering all formatting rules (bullet hierarchy, voice, atomicity, frontmatter conventions), then refactor all 10+ core command templates to conform. Community presets and extension commands also in scope.Option B — Minimal Advisory Style Guide + Targeted Fixes
docs/guides/prompt-style-guide.mdor similar) documenting the observed dominant conventions (dash-based sub-bullets, imperative voice, numbered steps for major phases), then make only the specific formatting fixes cited in the issue — normalizing the two locations inspecify.mdthat mix prose with bullets. No broad refactor. Advisory only.specify.mdedits require manual testing of the specify command.specify.mdneeds separate validation.Option C — No Style Guide; PR-level Convention Only
CONTRIBUTING.mdthat template formatting is reviewed ad hoc; contributors should mirror the nearest existing template. Fix the specificspecify.mdinconsistencies via a small PR with no separate guide document.Recommendation
Option B — a minimal advisory style guide plus the two targeted fixes in
specify.md. This delivers the core value (a formatting reference for contributors and reviewers) at low risk and low maintenance cost.Prerequisite: Maintainer confirmation that a style guide is wanted. CONTRIBUTING.md requires prior agreement for template-touching changes. A PR should be preceded by a short maintainer discussion in this issue.
The "atomicity" wording change to
specify.mdshould be handled separately — not bundled here — because it could alter agent output behavior and requires dedicated testing.Out of Scope (for the recommended option)
specify.mdcited in the issue.specify.mdwithout separate maintainer sign-off.Assumptions to Validate
specify.mdcan be normalized without changing agent behavior (formatting-only change, no semantic impact).docs/guides/location is an appropriate home for the guide (matches existingdocs/guides/structure).github-actions commentedon Aug 19, 2026
Feature assessment — prompt-style-guide · Stage 5/5: Decision — verdict needs-clarification
Decision: Prompt Style Guide
Scorecard
Verdict & Rationale
needs-clarification. The problem is real and the concept is sound, but the evidence strength is rated weak — the central risk claim (LLM mimicry from inconsistent formatting) is speculative, community demand is minimal, and no maintainer has confirmed interest. Per the pipeline rules, a
gorequires evidence strength ofadequateor better; weak evidence mandatesneeds-clarification.Additionally, there is a blocking process question: CONTRIBUTING.md explicitly requires maintainer agreement before large or template-touching changes. No maintainer has commented on issue #2804 in the two months since it was filed (2026-06-02 → 2026-08-19). Before any implementation proceeds, maintainers should confirm they want a Prompt Style Guide and agree on its scope.
The concept (Option B) is viable and well-shaped. If maintainers confirm interest, this could move to
goquickly.If needs-clarification
specify.mdfixes only) acceptable, or should it be broader or narrower?]specify.mdbe in scope here or tracked separately?]