[Feature]: Use documentation first approach #5057

Activity

1. sergeyglazyrindev

   added

   enhancement

   needs-triage

   on Oct 21, 2026
2. mnriem commented on Oct 21, 2026

   

   mnriem

   on Oct 21, 2026

   Collaborator

   More actions

   Thanks for describing the documentation-first use case. Keeping BA-owned requirements in Confluence while deriving a working specification from them makes sense.

   We recommend delivering this through a community extension and a companion preset, rather than adding /specify-usespec and /specify-refreshspec to core.

   There is already a Confluence extension in the community catalog with documented page-retrieval support. It would be worth discussing reuse or an enhancement with its author. Its documented update operation writes to Confluence, however, so it does not establish that refreshing a local specification from changed BA documentation is already supported. Community catalog inclusion is not a code review or endorsement; users must vet third-party components before use.

   A rough division of responsibilities:

   • Confluence extension: retrieve source pages, record their identities and revisions, and provide an explicit refresh operation for an existing feature.
   • Documentation-first preset: augment /speckit.specify so it retrieves the referenced documentation through the extension, uses it as requirements input, and records source provenance in the generated specification. A wrap composition strategy can retain {CORE_TEMPLATE} instead of copying the core prompt.

   /speckit.specify <Confluence page URL>
       |
       +-- Preset: retrieve source through Confluence extension
       |       +-- page content, URL/page ID, revision
       |
       +-- Existing specify process
               +-- spec.md with source references
               +-- saved source baseline for later comparison
   
   Extension refresh command <existing feature>
       |
       +-- Retrieve latest source revision
       +-- Compare baseline + latest source + current spec
       +-- Present requirement changes and conflicts
       +-- Apply agreed updates; advance source baseline
   

   For refresh, compare the previously imported source, the latest Confluence revision, and the current local specification. Propose changes without silently discarding local clarifications; surface conflicts for a decision. Confluence remains authoritative for BA requirements, while the local spec is the derived delivery artifact. This need not write back to Confluence. Refresh should target the existing feature directly, not rerun feature creation or silently regenerate its plan and tasks.

   Docmost support could follow through its own provider-specific extension, using the same documentation-first convention. No new core command is needed for that approach.

   Closing this as out of scope for core, not as an indication that the existing extension already satisfies the acceptance criteria. Further development can proceed in a community extension and companion preset.

   ---

   AI disclosure: Posted on behalf of @mnriem using GitHub Copilot, powered by GPT-6.1 Sol (model ID: gpt-6.1-sol), in user-directed agent mode. AI assistance covered assessment of published documentation and drafting this response; no third-party extension code audit was performed.
3. mnriem

   closed this as not plannedon Oct 21, 2026