fix(#194): keep agentic scaffold guidance provider-neutral

 Update generated architect/design guidance to use provider-neutral issue/work item wording and rely on the markdown-authoring skill instead of duplicating copy-safe fence
rules.

Author: stiwicourage

.github/agents/architect.agent.md

@@ -62,6 +62,7 @@ Design or reshape changes that cross public commands, private helper boundaries,
 - If the user chooses full finalization, a GitHub issue draft is ready to paste or create from the final output.
 - If the user chooses design-package-only finalization, the output is clearly resumable later from an `Open questions /
   resume here` section.
+- Finalization output is copy-ready Markdown that applies the project `markdown-authoring` skill.
 
 ## Must not do
 
@@ -71,4 +72,5 @@ Design or reshape changes that cross public commands, private helper boundaries,
 - Must not create or edit repository files when the task is still in design mode.
 - Must not return a full implementation plan or finished issue draft in the first reply when the user is clearly asking for a design discussion.
 - Must not leave the user guessing whether the final output is a handoff document, paste-ready issue text, or both.
+- Must not return finalization Markdown that skips the project `markdown-authoring` guidance.
 - Must not decide on its own that requested work is out of scope and then finalize the design without the user's confirmation.

.github/prompts/design-change.prompt.md

@@ -49,6 +49,8 @@ Do not produce the full final design package in the first response unless the us
 
 ## Finalization output
 
+All finalization output is copy-ready Markdown. Apply the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`) for copy-safe UI output, including any required wrapping, and do not add prose outside the final output.
+
 If the user chooses **design package and GitHub issue draft**, return:
 
 - a short usage note that explains:
@@ -85,12 +87,13 @@ In design-package-only mode:
 - do not include a GitHub issue draft
 - preserve the settled decisions clearly enough that the user can resume later
 - end with the next unresolved design decision or a short resume prompt the user can reuse later
+- still apply the `markdown-authoring` skill to the final response
 
 ## Repository-specific reminders
 
 - Preserve the distinction between public PowerShell cmdlets and `% nova` CLI behavior.
 - Keep contributor docs, command help, website docs, changelog entries, and release notes separated by audience.
-- If the final design summary or GitHub issue draft is returned as Markdown or copy-ready UI output, format it according to the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
+- Final design summaries and GitHub issue drafts are always copy-ready Markdown output; apply the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
 - Draft issue text in English unless the user explicitly asks for another language.
 - If the task still has unresolved choices, end the turn with the next best question or the next design decision the user should make.
 - If unresolved choices remain and you offer finalization anyway, explain what is settled, what is unresolved, and what each finalization option will produce.

CHANGELOG.md

@@ -12,10 +12,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
     - The new prompt appears after the Git question, defaults to `No`, and adds one shared Nova-maintained starter tree when enabled.
     - Example scaffolds now merge the existing example README with the Agentic starter README instead of flattening the example guide into the generic starter file.
     - The starter tree is now generated from a filtered mirror of Nova's own agentic `.github/` files, with a dedicated sync script and drift test so future scaffolds and `dist` stay aligned with the maintained source guidance.
+    - The generated architect/design prompt now requires final design packages and issue/work item drafts to be returned as copy-ready Markdown using the project Markdown authoring guidance.
 
 ### Changed
 
-- The architect/design flow now surfaces settled vs unresolved design items before finalization, offers explicit choices for full finalization vs design-package-only handoff, and clarifies how to use design notes versus the paste-ready GitHub issue draft.
+- The architect/design flow now surfaces settled vs unresolved design items before finalization, offers explicit choices for full finalization vs design-package-only handoff, clarifies how to use design notes versus the paste-ready GitHub issue draft, and requires finalization output to follow the project Markdown authoring guidance.
 
 ### Deprecated
 

RELEASE_NOTE.md

@@ -10,6 +10,7 @@ changes will be included in the next **stable** release!
 
 - `Initialize-NovaModule` and `% nova init` now offer an optional Agentic Copilot starter package in both the minimal and example interactive scaffold flows.
     - The starter package follows a filtered mirror of Nova's maintained agentic guidance so newly scaffolded projects receive a broader Nova-style agentic baseline without Nova-specific CodeScene or docs-site surfaces.
+    - Generated architect/design guidance now requires final design packages and issue/work item drafts to be returned as copy-ready Markdown using the project Markdown authoring guidance.
 
 ### Changed
 

scripts/build/Sync-AgenticCopilotScaffold.psd1

@@ -262,13 +262,49 @@
             Old = '- Run `./run.ps1`'
             New = '- Run full regression tests'
         }
+        @{
+            Old = 'or GitHub release automation.'
+            New = 'or release automation.'
+        }
+        @{
+            Old = 'a GitHub issue-ready change design'
+            New = 'a tracker-ready change design'
+        }
+        @{
+            Old = 'an issue-ready change design'
+            New = 'a tracker-ready change design'
+        }
+        @{
+            Old = 'fully issue-ready'
+            New = 'fully tracker-ready'
+        }
+        @{
+            Old = 'and a GitHub issue draft'
+            New = 'and an issue/work item draft'
+        }
+        @{
+            Old = 'a GitHub issue draft'
+            New = 'an issue/work item draft'
+        }
+        @{
+            Old = 'GitHub issue draft'
+            New = 'issue/work item draft'
+        }
         @{
             Old = 'GitHub issue'
-            New = 'issue'
+            New = 'issue/work item'
+        }
+        @{
+            Old = 'issue-ready change design'
+            New = 'tracker-ready change design'
+        }
+        @{
+            Old = 'issue drafting'
+            New = 'issue/work item drafting'
         }
         @{
-            Old = '- issue'
-            New = '- Issue'
+            Old = 'paste-ready GitHub text'
+            New = 'paste-ready tracker text'
         }
         @{
             Old = '- `pwsh -NoLogo -NoProfile -File ./run.ps1` before completion'

src/resources/agentic-copilot/.github/agents/architect.agent.md

@@ -19,9 +19,9 @@ Design or reshape changes that cross public commands, private helper boundaries,
 - Treat scope cuts, deferrals, and out-of-scope boundaries as proposals that require explicit user confirmation.
 - Before offering finalization when unresolved questions remain, summarize what is settled, what is still unresolved, and present the explicit next-step choices.
 - Support two finalization modes when the discussion is sufficiently scoped:
-    - design package plus issue draft
+    - design package plus issue/work item draft
     - design package only
-- Once the discussion is sufficiently scoped, produce an issue-ready change design with acceptance criteria, out-of-scope boundaries, and a issue draft.
+- Once the discussion is sufficiently scoped, produce a tracker-ready change design with acceptance criteria, out-of-scope boundaries, and an issue/work item draft.
 
 ## Inputs to inspect
 
@@ -50,17 +50,18 @@ Design or reshape changes that cross public commands, private helper boundaries,
 - Avoid introducing new abstractions unless the current structure clearly duplicates or conflicts.
 - Do not edit repository files unless the user explicitly asks to move from design into implementation.
 - Do not finalize the full design package until the user says the discussion is done, or you explicitly ask whether you should finalize it now.
-- Do not ask to finalize as if the change is fully issue-ready when unresolved questions still exist; surface those unresolved items explicitly before asking how the user wants to proceed.
+- Do not ask to finalize as if the change is fully tracker-ready when unresolved questions still exist; surface those unresolved items explicitly before asking how the user wants to proceed.
 - Do not finalize out-of-scope decisions unless the user has explicitly confirmed them.
 
 ## Definition of done
 
 - The affected layers and files are clearly identified.
 - The scoped implementation approach matches existing repo structure.
 - Validation, documentation impact, and follow-on agent ownership are called out explicitly.
-- If the user chooses full finalization, a issue draft is ready to paste or create from the final output.
+- If the user chooses full finalization, an issue/work item draft is ready to paste or create from the final output.
 - If the user chooses design-package-only finalization, the output is clearly resumable later from an `Open questions /
   resume here` section.
+- Finalization output is copy-ready Markdown that applies the project `markdown-authoring` skill.
 
 ## Must not do
 
@@ -70,4 +71,5 @@ Design or reshape changes that cross public commands, private helper boundaries,
 - Must not create or edit repository files when the task is still in design mode.
 - Must not return a full implementation plan or finished issue draft in the first reply when the user is clearly asking for a design discussion.
 - Must not leave the user guessing whether the final output is a handoff document, paste-ready issue text, or both.
+- Must not return finalization Markdown that skips the project `markdown-authoring` guidance.
 - Must not decide on its own that requested work is out of scope and then finalize the design without the user's confirmation.

src/resources/agentic-copilot/.github/copilot-instructions.md

@@ -19,7 +19,7 @@ Read these files before making non-trivial changes:
 Prompt templates under `.github/prompts/*.prompt.md` are not auto-loaded. Reference them explicitly in chat when you want to use one of the repository's reusable task prompts.
 
 For new or not-yet-scoped work, start with `.github/agents/architect.agent.md` and
-`.github/prompts/design-change.prompt.md`. That flow should stay conversational first: analyze the request, ask clarifying questions, present design options when needed, and only draft the final scoped solution or issue after the discussion is complete. When unresolved questions still remain, architect should surface what is settled vs unresolved before asking whether to finalize, and should allow either full finalization or a resumable design-package-only handoff. Proposed scope cuts or out-of-scope boundaries must be confirmed by the user before they are treated as final.
+`.github/prompts/design-change.prompt.md`. That flow should stay conversational first: analyze the request, ask clarifying questions, present design options when needed, and only draft the final scoped solution or issue/work item after the discussion is complete. When unresolved questions still remain, architect should surface what is settled vs unresolved before asking whether to finalize, and should allow either full finalization or a resumable design-package-only handoff. Proposed scope cuts or out-of-scope boundaries must be confirmed by the user before they are treated as final.
 
 ## Repository map
 

src/resources/agentic-copilot/.github/instructions/release-policy.instructions.md

@@ -6,7 +6,7 @@ applyTo: "CHANGELOG.md,RELEASE_NOTE.md,project.json,.github/pull_request_templat
 
 ## Scope
 
-Use this file when changing versioning, changelog handling, package metadata, publish workflows, or GitHub release automation.
+Use this file when changing versioning, changelog handling, package metadata, publish workflows, or release automation.
 
 ## Versioning rules
 

src/resources/agentic-copilot/.github/prompts/design-change.prompt.md

@@ -1,8 +1,8 @@
 # Design a {{ProjectName}} change
 
-Use this prompt with `architect.agent.md` when a change still needs analysis, scoping, and issue drafting before anyone starts editing files.
+Use this prompt with `architect.agent.md` when a change still needs analysis, scoping, and issue/work item drafting before anyone starts editing files.
 
-This is a discussion-first prompt. The default behavior is to hold a short design conversation with the user before producing a final scoped solution, implementation handoff, or issue draft.
+This is a discussion-first prompt. The default behavior is to hold a short design conversation with the user before producing a final scoped solution, implementation handoff, or issue/work item draft.
 
 Scope is not final until the user confirms it. That includes anything you think should be treated as out of scope, deferred, split into follow-up work, or excluded from the first implementation pass.
 
@@ -26,11 +26,11 @@ Scope is not final until the user confirms it. That includes anything you think
     - list what is already settled
     - list what is still unresolved
     - offer three explicit choices:
-        - finalize with design package and issue draft
+        - finalize with design package and issue/work item draft
         - finalize with design package only
         - keep discussing
 8. Keep the conversation interactive until the user explicitly confirms the scope is correct and says the task is clear enough to finalize, or until you explicitly ask whether you should now draft the final output and the user chooses one of those options.
-9. Only after that discussion is complete, produce the final scoped solution and implementation handoff, and include the issue draft only when the user chose the full-finalization option.
+9. Only after that discussion is complete, produce the final scoped solution and implementation handoff, and include the issue/work item draft only when the user chose the full-finalization option.
 10. Do not edit repository files unless the user explicitly switches from design to implementation.
 
 ## Discussion-phase output
@@ -49,11 +49,13 @@ Do not produce the full final design package in the first response unless the us
 
 ## Finalization output
 
-If the user chooses **design package and issue draft**, return:
+All finalization output is copy-ready Markdown. Apply the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`) for copy-safe UI output, including any required wrapping, and do not add prose outside the final output.
+
+If the user chooses **design package and issue/work item draft**, return:
 
 - a short usage note that explains:
-    - the sections before `issue draft` are design/handoff notes
-    - only the `issue draft` section is paste-ready GitHub text
+    - the sections before `issue/work item draft` are design/handoff notes
+    - only the `issue/work item draft` section is paste-ready tracker text
 - Problem
 - Why it matters
 - Scope
@@ -63,10 +65,10 @@ If the user chooses **design package and issue draft**, return:
 - Proposed implementation approach
 - Open questions
 - Recommended follow-on agent
-- Issue draft
+- issue/work item draft
 
 If unresolved questions still remain, keep them under `Open questions` in the design package and add a short `Open
-questions` section inside the issue draft too.
+questions` section inside the issue/work item draft too.
 
 If the user chooses **design package only**, return:
 
@@ -82,17 +84,18 @@ If the user chooses **design package only**, return:
 
 In design-package-only mode:
 
-- do not include a issue draft
+- do not include an issue/work item draft
 - preserve the settled decisions clearly enough that the user can resume later
 - end with the next unresolved design decision or a short resume prompt the user can reuse later
+- still apply the `markdown-authoring` skill to the final response
 
 ## Repository-specific reminders
 
 - Preserve the distinction between public PowerShell cmdlets and `% nova` CLI behavior.
 - Keep contributor docs, command help, project docs, changelog entries, and release notes separated by audience.
-- If the final design summary or issue draft is returned as Markdown or copy-ready UI output, format it according to the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
+- Final design summaries and issue/work item drafts are always copy-ready Markdown output; apply the `markdown-authoring` skill (`.github/skills/markdown-authoring/SKILL.md`).
 - Draft issue text in English unless the user explicitly asks for another language.
 - If the task still has unresolved choices, end the turn with the next best question or the next design decision the user should make.
 - If unresolved choices remain and you offer finalization anyway, explain what is settled, what is unresolved, and what each finalization option will produce.
-- If you return both design notes and a issue draft, explicitly tell the user how to use each part.
+- If you return both design notes and an issue/work item draft, explicitly tell the user how to use each part.
 - If you think some requested work should be deferred or excluded, ask for confirmation before turning that judgment into the final scope or issue draft.