[Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks)

[TheovanKraay]

Problem Statement

Spec Kit extensions can deliver knowledge only two ways today: commands (on-demand prompts/skills the agent must choose to invoke) and hooks (fire around /speckit.implement). Both are opt-in by the agent. So in autonomous / hands-off workflows - increasingly the common case - an extension's guidance often never reaches the model: the agent is given a task, writes code directly, and never invokes the commands, so the extension has no effect.

We hit this building the Azure Cosmos DB Spec Kit extension (pre-release, still in active development). In autonomous agent runs where it was installed exactly as intended, the agent invoked its commands in 0 of 30 runs and the before_implement/after_implement hooks fired 0 times - net effect ≈ zero. There is currently no way for an extension to contribute always-on guidance (a few "always apply this while you work" rules in the agent's persistent context) the way the project constitution does.

Proposed Solution

Add an optional provides: instructions: capability to the extension manifest, so an extension can ship a compact always-on rule block that specify extension add installs into the agent-native always-on file for the active integration:

provides:
  commands: [ ... ]     # unchanged
  hooks: [ ... ]        # unchanged
  instructions:         # NEW
    - file: instructions/best-practices.md

Install it as a delimited, per-extension block so it is merge-safe (multiple extensions coexist; user-authored content preserved), idempotent, removable on uninstall, and routed per agent (.github/copilot-instructions.md for Copilot; AGENTS.md / CLAUDE.md / GEMINI.md; .cursor/rules/…) - or appended to .specify/memory/constitution.md if a single canonical target is preferred.

This looks very feasible because Spec Kit already has the building blocks and would reuse all three rather than invent a subsystem: an always-on context concept (the constitution), per-agent routing, and merge-with-markers for extension content (hooks -> speckit.json).

Evidence it matters: delivering the same guidance as an always-on rule block instead of commands improved a best-practice conformance score by +0.16 mean (vs +0.10 as commands), with better determinism and improvement in every measured cell (2 models × 4 languages × 3 complexity levels) - because always-on context can't be bypassed.

Alternatives Considered

• A hook that writes the always-on file at before_implement. Unreliable: agents load instruction files at session start, so writing mid-session isn't picked up; also couples always-on context to the implement step.
• Docs-only ("paste these rules into your copilot-instructions.md"). Manual, easily skipped, not portable across agents, and defeats the point of an extension.
• Status quo (everything as commands/hooks). Proven not to reach autonomous agents (the 0/30 invocation above).

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

All agents

Use Cases

1. A domain extension (e.g. Azure Cosmos DB) wants its few mandatory best-practices followed even when an autonomous agent never runs a command.
2. A security / hardening extension wants "always apply these secure-coding rules" in context for every generation.
3. An IaC / framework / accessibility extension wants its house style enforced across a whole session without the user or agent invoking anything.
4. A team installs several extensions and wants each one's key rules merged, attributed, and cleanly removable, alongside their own project constitution.

Acceptance Criteria

• provides: instructions: is accepted in the extension manifest schema.
• specify extension add installs each instructions file into the correct always-on location for the active integration.
• Content is written as a delimited, attributed block that merges safely with user content and with other extensions.
• Uninstall / update cleanly removes or replaces the extension's block.
• Users can disable extension-provided instructions (globally or per extension).
• Works across supported agents (or a documented no-op where an agent has no always-on file).
• Documentation updated.

Additional Context

• General gap, not Cosmos-specific. Any extension whose value is best-practice guidance (security, IaC, API-design, framework, accessibility, …) hits the same wall - commands only help if the agent opts to run them. Azure Cosmos DB is just where we measured it.
• Design notes (input welcome): keep instructions compact — always-on text costs tokens on every request, so a soft size cap / lint is worth considering; user-authored instructions and the constitution should take precedence over extension blocks; ensure deterministic ordering; support opt-out.
• Forward-looking: the extension that surfaced this is still pre-release; we want to align its delivery model with Spec Kit's direction before shipping broadly - this is not a report of a regression in a shipped extension.
• We have the full delivery-mechanism A/B data (models × languages × complexity) and a reference compact rule block, and are happy to share or prototype the capability.

[github-actions]

Feature assessment — extension-always-on-instructions · Stage 1/5: Intake

Idea Intake: Extension Always-On Instructions

• Slug: extension-always-on-instructions
• Created: 2026-08-19
• Source: GitHub issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200 ([Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200) — labeled feature-assess, raised by @TheovanKraay
• Type: new-capability

Idea (as captured)

Spec Kit extensions can deliver knowledge only two ways today: commands (on-demand prompts/skills the agent must choose to invoke) and hooks (fire around /speckit.implement). Both are opt-in by the agent. So in autonomous / hands-off workflows — increasingly the common case — an extension's guidance often never reaches the model: the agent is given a task, writes code directly, and never invokes the commands, so the extension has no effect.

Add an optional provides: instructions: capability to the extension manifest, so an extension can ship a compact always-on rule block that specify extension add installs into the agent-native always-on file for the active integration (.github/copilot-instructions.md, AGENTS.md, CLAUDE.md, GEMINI.md, .cursor/rules/...) or appended to .specify/memory/constitution.md. Content written as a delimited, attributed, merge-safe block. Removable on uninstall.

Evidence cited by the author: delivering guidance as an always-on rule block vs. commands improved a best-practice conformance score by +0.16 mean (vs +0.10 as commands), measured across 2 models × 4 languages × 3 complexity levels — improvement in every measured cell.

Restated

Extensions today can only inject guidance when an agent actively invokes a command or a hook fires; autonomous agents skip both. The proposal adds a new provides: instructions: manifest field so that specify extension add can install a compact, per-extension rule block into the agent's always-on context file, making the guidance unconditionally present from session start.

Origin & Context

• Raised by: @TheovanKraay (GitHub)
• Trigger: Building the Azure Cosmos DB Spec Kit extension (pre-release). In autonomous agent runs, the extension's commands were invoked in 0 of 30 runs and before_implement/after_implement hooks fired 0 times — net effect ≈ zero. Authors have A/B delivery data and a reference compact rule block ready to share.

First-Glance Unknowns

• [NEEDS CLARIFICATION: What is the intended canonical target — per-agent always-on file (routing matrix) vs. .specify/memory/constitution.md vs. both?]
• [NEEDS CLARIFICATION: What size limit / lint threshold is acceptable for extension-provided instruction blocks?]
• [NEEDS CLARIFICATION: How should ordering and precedence among multiple extensions (and the user's own constitution) be defined?]
• [NEEDS CLARIFICATION: Is per-extension opt-out sufficient, or does a per-project global disable also need to be supported?]
• [NEEDS CLARIFICATION: For agents with no always-on file (or an unsupported integration), is a silent no-op acceptable, or must it be surfaced as a warning?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4200 · 478.7 AIC · ⌖ 35.8 AIC · ⊞ 36.5K · ◷

[github-actions]

Feature assessment — extension-always-on-instructions · Stage 2/5: Research

Idea Research: Extension Always-On Instructions

• Slug: extension-always-on-instructions
• Created: 2026-08-19
• Evidence confidence (overall): medium

Users & Demand

• Extension authors building domain/best-practice extensions: The submitter (@TheovanKraay, Azure Cosmos DB extension author) reports 0/30 autonomous agent runs invoking extension commands, and 0 before_implement/after_implement hook fires — cited as direct, first-hand measurement (confidence: high, cited: issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200).
• Any extension whose value is best-practice guidance (security, IaC, framework, accessibility): The submitter identifies this as a general gap, not Cosmos-specific. The class of affected extensions is plausibly large, but broader community demand data is not provided (confidence: medium, assumption).
• Autonomous/hands-off workflow users: The feature request notes autonomous workflows as "increasingly the common case." Supporting evidence from usage data is not provided in the issue; consistent with industry trends but unverified within Spec Kit telemetry (confidence: low, assumption).

Prior Art

• Spec Kit agent-context extension (internal): Already delivers marker-based merge into agent-native context files (.github/copilot-instructions.md, CLAUDE.md, AGENTS.md, etc.) using <!-- SPECKIT START --> / <!-- SPECKIT END --> delimiters, per-agent routing, and install/uninstall lifecycle. This is the most directly reusable prior art — the feature request would extend this mechanism to cover extension-contributed blocks. Source: extensions/agent-context/, extensions/agent-context/scripts/bash/update-agent-context.sh (confidence: high, cited: codebase).
• Spec Kit constitution (internal): .specify/memory/constitution.md is the project's always-on context file, already surfaced to agents as persistent guidance. An alternative implementation could append extension instructions here rather than routing to per-agent files. Source: codebase (confidence: high, cited: codebase).
• Extension manifest provides: schema (internal): Currently supports commands, templates, scripts, config. No instructions key exists. Codebase search confirms zero results for provides.*instructions. Extending the schema is a well-trodden pattern. Source: src/specify_cli/extensions/__init__.py (confidence: high, cited: codebase).
• VS Code extension contributions: VS Code uses contributes.* in package.json to let extensions inject into workspace-level files at install time — conceptually identical to what provides: instructions: proposes (confidence: high, cited: industry knowledge).
• No prior Spec Kit RFC or spec found for this capability (confidence: high, cited: codebase search).

Market & Context

• Cost of doing nothing: Extension authors who need best-practice enforcement must choose between docs-only instructions, commands that autonomous agents skip, or not shipping the extension's core value. This weakens the extension ecosystem for the agentic-first use case (confidence: medium, cited: issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200).
• Alternatives users rely on today: The submitter considered and rejected: (a) a hook that writes the always-on file at before_implement — unreliable because agents load instruction files at session start, not mid-session; (b) docs-only — manual, not portable. Both documented in issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200 (confidence: high, cited: issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200).
• Token cost concern: Always-on context costs tokens on every request. The submitter acknowledges this and suggests a soft size cap / lint. Genuine adoption-limiting constraint (confidence: high, cited: issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200).

Data & Constraints

• A/B conformance data (submitter-provided, unverified): Always-on rule block vs. commands showed +0.16 mean conformance improvement (vs. +0.10 for commands) across 2 models × 4 languages × 3 complexity levels, with improvement in every cell (confidence: medium, cited: issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200 — reported by feature author, not independently reproduced).
• 0/30 autonomous invocations: Extension commands invoked 0 times in 30 autonomous agent runs — first-hand measurement, not independently verified (confidence: medium, cited: issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200).
• Manifest schema extensibility: The existing _validate_provides function handles commands, templates, scripts, config. A new instructions key requires schema validation, file-reference resolution, and install/uninstall hooks — estimated medium scope (confidence: high, cited: codebase).
• Per-agent routing complexity: The agent-context extension already maintains agent key → context file mapping. Reusing this avoids reinventing routing but requires coordination between extension system and agent-context layer, or a simpler fallback via constitution.md (confidence: high, cited: codebase).
• Merge-safety constraint: Multiple extensions may contribute instruction blocks simultaneously. The existing marker pattern must be extended to per-extension namespaced blocks (e.g., <!-- SPECKIT EXT:cosmos-db START -->). This convention does not yet exist (confidence: high, cited: codebase analysis).

Evidence Against the Idea

• Token overhead is real: Always-on instructions increase prompt size for every request regardless of relevance. May be resisted by users managing token budgets. [cited: issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200 (acknowledged by submitter) + general LLM cost considerations]
• Adds install-time complexity: specify extension add must now perform context-file writes with merge logic, ordering, and conflict handling — increases blast radius of extension installs. [cited: codebase analysis]
• Context file ownership is already complex: AGENTS.md custom instruction explicitly states "The Specify CLI carries no agent-context state whatsoever." A parallel mechanism in core specify extension add risks ownership fragmentation. [cited: AGENTS.md custom instruction]
• A/B data is unverified: The +0.16 conformance improvement comes from the feature author's own measurements. [cited: issue [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200]

Gaps & Open Questions

• [NEEDS CLARIFICATION: Canonical routing target — per-agent always-on files vs. constitution.md vs. both?]
• [NEEDS CLARIFICATION: Size cap value and enforcement mode (error vs. warning)?]
• [NEEDS CLARIFICATION: Ownership boundary — core CLI vs. agent-context extension?]
• [NEEDS CLARIFICATION: Ordering/precedence when multiple extensions contribute instruction blocks?]
• [NEEDS CLARIFICATION: Upgrade/replace semantics for specify extension update?]

Sources

• [Feature]: Let extensions contribute always-on instructions (not just on-demand commands + hooks) #4200 (host: github.com, policy: allowlisted)
• src/specify_cli/extensions/__init__.py — manifest validation code (codebase)
• extensions/agent-context/ — agent-context extension (codebase)
• extensions/agent-context/scripts/bash/update-agent-context.sh — marker-merge implementation (codebase)
• AGENTS.md — design constraint re: CLI context-file ownership (codebase)

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4200 · 478.7 AIC · ⌖ 35.8 AIC · ⊞ 36.5K · ◷

[github-actions]

Feature assessment — extension-always-on-instructions · Stage 3/5: Problem

Problem Definition: Extension Always-On Instructions

• Slug: extension-always-on-instructions
• Created: 2026-08-19
• Inputs used: intake.md | research.md

Problem Statement

Extensions that deliver guidance through commands and hooks are effectively invisible to autonomous agents, which skip both — leaving the extension's core value undelivered in the increasingly dominant agentic workflow mode. There is no mechanism for an extension to contribute guidance that is unconditionally present in the model's context from the start of every session.

Affected Users & Stakeholders

• Users (extension authors): Developers building domain-specific, security, IaC, or best-practice extensions whose guidance needs to be followed even when no command is ever invoked. Currently their extension has near-zero effect in autonomous runs.
• Users (extension consumers): Developers using Spec Kit in autonomous/agentic workflows who install an extension expecting its guidance to be active, but receive no benefit because the agent never invokes the extension's commands.
• Stakeholders (Spec Kit maintainers): The extension ecosystem's value proposition depends on extensions actually working in the primary use case. If extensions are silent in agentic runs, extension adoption is undermined.
• Stakeholders (enterprise/team leads): Teams deploying Spec Kit with security or compliance extensions need those rules reliably enforced, not conditionally invoked.

Goals

• Allow extensions to contribute a compact, always-on instruction block that is present in the agent's context from session start, without requiring the agent to invoke any command.
• Ensure the mechanism is merge-safe: multiple extension blocks coexist without clobbering each other or user-authored content.
• Ensure the mechanism is lifecycle-safe: install, update, and uninstall cleanly manage each extension's block.
• Work across supported agents, or document a clear no-op for unsupported ones.

Non-Goals

• Full replacement of commands and hooks — those remain the delivery mechanism for structured, on-demand workflows.
• Arbitrary file writes by extensions outside the designated instruction block.
• Modifying extension behavior for IDE-invoked (non-autonomous) workflows where commands are already reachable.
• Auto-generating instructions from an extension's commands (extension authors author the instruction block explicitly).

Success Metrics

• Extension-provided instruction blocks are present in the agent context file (or constitution) after specify extension add, verifiable by inspection (baseline: 0% of installed extensions contribute always-on context today).
• specify extension uninstall cleanly removes the extension's block without affecting adjacent content (baseline: uninstall removes command files only today).
• (Qualitative) Extension authors confirm the feature addresses the agentic delivery gap they hit in practice.
• (Optional) Best-practice conformance scores for extensions that migrate key rules to provides: instructions: improve over command-only delivery (baseline: +0.10 mean from commands per submitter's data).

Cost of Inaction

Extensions whose core value is best-practice guidance remain ineffective in autonomous agent runs. The extension ecosystem's credibility for the agentic use case is weakened; extension authors face a dead end that pushes them toward fragile workarounds (docs-only, mid-session file writes). The Azure Cosmos DB extension — and any similar extension — ships with a known gap that cannot be closed without this feature.

Open Questions

• [NEEDS CLARIFICATION: Should instructions be written to per-agent always-on files (via agent-context routing) or to constitution.md, or both?]
• [NEEDS CLARIFICATION: What is the acceptable size cap for an extension instruction block, and how should violations be surfaced?]
• [NEEDS CLARIFICATION: What is the correct ownership boundary — core specify extension add, the agent-context extension, or a new bridge layer?]
• [NEEDS CLARIFICATION: What ordering/precedence rules apply when multiple extensions each contribute instruction blocks?]
• [NEEDS CLARIFICATION: How should specify extension update handle block replacement to avoid stale rules?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4200 · 478.7 AIC · ⌖ 35.8 AIC · ⊞ 36.5K · ◷

[github-actions]

Feature assessment — extension-always-on-instructions · Stage 4/5: Concept

Concept: Extension Always-On Instructions

• Slug: extension-always-on-instructions
• Created: 2026-08-19
• Recommended option: Option A — Manifest provides: instructions: routed through agent-context

Options

Option A — Manifest provides: instructions: with agent-context routing

• Sketch: Add provides: instructions: to the extension manifest schema, listing one or more Markdown files whose content should be installed as always-on context. specify extension add reads the active integration, looks up the agent's canonical always-on file via the agent-context routing map, and writes each extension's instruction block inside a namespaced marker block (e.g., <!-- SPECKIT EXT:cosmos-db START -->...<!-- SPECKIT EXT:cosmos-db END -->). Multiple extensions coexist via separate namespaced blocks. specify extension uninstall removes only the extension's own block. If the active integration has no always-on file, falls back to constitution.md.
• Appetite: medium (weeks) — manifest schema change, _validate_provides extension, install/uninstall context-file write logic, agent routing, size cap lint, tests.
• Trade-offs:
  • Wins: Most powerful delivery; works for all supported agents; fully lifecycle-safe; reuses existing routing infra.
  • Sacrifices: Adds coupling between core extension install and agent-context logic; increases install complexity.
• Rabbit holes: Ownership boundary tension — AGENTS.md custom instruction explicitly states "CLI carries no agent-context state whatsoever"; marker namespace collisions for short extension IDs; ordering guarantees with many extensions installed.

Option B — Constitution.md-only delivery

• Sketch: specify extension add appends the extension's instruction block to .specify/memory/constitution.md using namespaced markers. No per-agent routing; one canonical target regardless of integration. Agents that read the constitution receive the instructions unconditionally (requires agent-context extension to surface it, which it does for all current integrations).
• Appetite: small (days) — constitution is a project-local Markdown file; install/uninstall reduces to marker-aware file edit; no per-agent routing.
• Trade-offs:
  • Wins: Simpler to implement; no per-agent routing; no coupling to agent-context internals; constitution is always present.
  • Sacrifices: Relies on agent-context extension being installed to surface the constitution; one extra indirection vs. writing directly to the agent file.
• Rabbit holes: Does every integration reliably surface constitution.md? Needs verification per integration.

Option C — Do nothing / docs only

• Sketch: Document a recommended pattern for extension authors to manually include instructions in their README for users to copy into their context file. No CLI changes.
• Appetite: small (hours)
• Trade-offs:
  • Wins: Zero implementation risk.
  • Sacrifices: Proven not to solve the problem (manual, skippable, not portable, defeats the point of an extension ecosystem).
• Rabbit holes: None — but no value delivered.

Recommendation

Option A is recommended: it directly addresses the problem at the right abstraction layer, reusing existing per-agent routing infra and marker-merge patterns. The routing map and merge logic already exist in the agent-context extension; the manifest extension pattern is established; the marker approach is proven.

Option B is the preferred fallback: if the ownership boundary question (AGENTS.md: "CLI carries no agent-context state") proves blocking for Option A, Option B delivers the core value with lower scope while still solving the problem for projects with agent-context installed.

The spec phase must resolve ownership first: (a) implement in core CLI with a narrow exception to the no-context-state rule for extension instruction blocks, or (b) implement as a new capability inside the agent-context extension triggered by an extension install event.

Out of Scope (for the recommended option)

• Auto-generation of instruction content from command files.
• Real-time / session-time injection (instructions installed at specify extension add time).
• Agent-side enforcement of instruction compliance.
• Agents with no always-on file and no constitution fallback (documented no-op).

Assumptions to Validate

• The agent-context routing map is accessible at specify extension add time.
• Namespaced markers (<!-- SPECKIT EXT:<id> START/END -->) are robust for all valid extension IDs.
• Constitution.md is reliably surfaced to agents by all current integrations (Option B viability).
• A soft size cap (e.g., 2 KB per extension block) is acceptable to extension authors.

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4200 · 478.7 AIC · ⌖ 35.8 AIC · ⊞ 36.5K · ◷

[github-actions]

Feature assessment — extension-always-on-instructions · Stage 5/5: Decision — verdict go

Decision: Extension Always-On Instructions

• Slug: extension-always-on-instructions
• Decided: 2026-08-19
• Verdict: go
• Artifacts reviewed: intake.md | research.md | problem.md | concept.md

Scorecard

Criterion	Rating	Justification
Problem validity	strong	The gap is real and mechanistically clear: commands and hooks are opt-in; autonomous agents skip both; extension guidance never reaches the model. The 0/30 invocation measurement is first-hand and internally consistent.
Evidence strength	adequate	Submitter provides direct measurement (0/30 invocations, A/B conformance +0.16 vs. +0.10) and a sound mechanistic argument. Data is unverified by a third party but is concrete and consistent with known agent behavior. Honest rating: adequate, not weak.
Value vs. inaction	strong	Inaction leaves domain/best-practice extensions ineffective in the primary agentic use case. The extension ecosystem's value proposition is directly undermined.
Feasibility / appetite	adequate	Building blocks exist: manifest schema extension pattern, agent-context marker-merge, constitution fallback. Option A is medium appetite; Option B is small. No novel infrastructure required. Ownership boundary is a design decision, not a feasibility blocker.
Strategic fit	strong	Aligns directly with Spec Kit's direction: extension ecosystem for agentic delivery; agent-context for always-on guidance; lifecycle-safe install/uninstall for all extension artifacts. The feature fills a gap the architecture creates.
Risk posture	adequate	Main risks (token cost, ownership boundary, marker collisions) are identified and credibly mitigated in the concept: size cap, namespaced markers, two clear implementation paths. No unmitigated surprises.

Verdict & Rationale

Go. The problem is valid, evidence is adequate, a recommended concept option exists with a well-scoped fallback, and the feature fits squarely within Spec Kit's strategic direction. Evidence strength clears the adequate threshold required for a go verdict: the 0/30 invocation data and the A/B conformance numbers are first-hand and mechanistically sound, even if not independently replicated.

The key design question — ownership boundary between core CLI and the agent-context extension — is not a blocking unknown. It is a well-defined decision to be resolved in the spec phase, with two clear paths. Option B (constitution-only, small appetite) is a viable reduced-scope entry if Option A's boundary proves more complex than expected.

If go — Handoff to /speckit.specify

• Problem: Extensions that rely on commands and hooks deliver zero guidance to autonomous agents that skip both; there is no mechanism to contribute always-on context that is present from session start.
• Chosen approach: Option A — provides: instructions: in extension manifest, installed as per-extension namespaced marker blocks in the agent's always-on file (via agent-context routing), with constitution.md as fallback. Option B (constitution-only) is the fallback scope if Option A ownership boundary proves blocking.
• In scope: Manifest schema addition (provides: instructions:); install-time write of instruction block to always-on target; uninstall/update lifecycle management; merge-safe namespaced markers; agent routing fallback to constitution.md; size cap lint; documentation updates.
• Out of scope: Auto-generation from commands; session-time injection; agent-side enforcement; agents with no always-on file and no constitution fallback.
• Success metrics: Instruction block present in agent context file after specify extension add; cleanly removed by specify extension uninstall; no regressions in existing extension install/uninstall tests.
• Carried-forward open questions:
  • [NEEDS CLARIFICATION: Ownership — implement in core CLI or inside agent-context extension? Resolve before spec begins.]
  • [NEEDS CLARIFICATION: Size cap value and enforcement mode (error vs. warning).]
  • [NEEDS CLARIFICATION: Ordering/precedence when multiple extensions contribute blocks.]
  • [NEEDS CLARIFICATION: Upgrade/replace semantics for specify extension update.]
  • [NEEDS CLARIFICATION: No-op behavior for agents with no always-on file and no constitution — error, warning, or silent skip?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4200 · 478.7 AIC · ⌖ 35.8 AIC · ⊞ 36.5K · ◷

[mnriem]

Before adding a new provides: instructions: capability, it's worth checking whether existing primitives already cover this. Two to read up on:

• Workflows — deterministic command/prompt steps and overlays, which run regardless of what the agent chooses: https://github.github.io/spec-kit/reference/workflows.html
• Presets — can override core and extension commands/scripts (wrap/replace): https://github.github.io/spec-kit/reference/presets.html

Please let us know if that's sufficient for your use case, and if not, why not.

_{Posted with AI assistance (GitHub Copilot) on behalf of @mnriem.}

[Yash-Chindam]

I would like to explore a contribution for this issue. I’ll first compare the existing Workflows and Presets primitives with the proposed always-on instruction blocks, then report whether they fully cover the use case or identify the smallest missing capability. If a maintainer confirms the gap and preferred ownership boundary, could this issue be assigned to me for implementation?

Disclosure: I used ChatGPT to review the repository guidance and draft this comment.