@laitszkin/apollo-toolkit 2.11.2 → 2.11.3

package/commit-and-push/SKILL.md

@@ -15,9 +15,9 @@ description: "Guide the agent to submit local changes with commit and push only
 ## Standards
 
 - Evidence: Inspect git state and classify the change set before deciding which quality gates apply.
-- Execution: Run the required quality-gate skills when applicable, convert completed spec sets into categorized project docs during submission, normalize non-standard project docs when needed, preserve staging intent, then commit and push without release steps.
-- Quality: Re-run relevant validation for runtime changes and keep project docs plus agent constraints synchronized before committing; treat `archive-specs` outputs as the canonical project-doc structure when normalization is required.
-- Output: Produce a concise Conventional Commit and push it to the current branch only.
+- Execution: Run the required quality-gate skills when applicable, convert completed spec sets into categorized project docs during submission, normalize non-standard project docs when needed, preserve staging intent, honor any explicit user-specified target branch, then commit and push without release steps.
+- Quality: Re-run relevant validation for runtime changes, keep project docs plus agent constraints synchronized before committing, and preserve unrelated local work safely when branch switching or post-push local sync is required; treat `archive-specs` outputs as the canonical project-doc structure when normalization is required.
+- Output: Produce a concise Conventional Commit, push it to the intended branch, and report any temporary stash/restore or local branch sync that was required.
 
 ## Overview
 
@@ -43,29 +43,36 @@ Load only when needed:
    - `repo-specs-ready-for-conversion`: the relevant `spec.md`, `tasks.md`, and `checklist.md` have been updated to reflect the actual outcome of the work, and any unchecked task/decision checkbox that is clearly not selected, replaced, deferred, or `N/A` (for example, E2E intentionally not created) does not by itself mean the spec set is unfinished.
    - `project-doc-structure-mismatch`: existing `README.md` and project docs do not match the categorized structure required by `archive-specs`.
    - Treat a spec set as still active when it documents remaining implementation gaps, follow-up integration work, undecided design work, or deferred tasks that still belong to the same in-flight change.
-3. Run code-affecting dependency skills (when applicable)
+3. Resolve branch target before mutating history
+   - Treat an explicit user-specified destination such as `main`, `origin/main`, or another named branch as authoritative over the current branch.
+   - If the current branch does not match the requested destination, inspect `git status --short` for unrelated local changes before switching branches.
+   - Preserve unrelated uncommitted work safely before branch operations, for example with `git stash push`, and restore it after the target branch has been updated.
+   - If the fix was committed on the wrong branch, move it to the requested branch with safe history-preserving operations such as `cherry-pick`, `merge --ff-only`, or a clean replay; do not force-push unless the user explicitly asks for it.
+   - If the user asks to sync the local target branch after pushing, fast-forward or pull that branch locally and then restore any preserved worktree changes.
+4. Run code-affecting dependency skills (when applicable)
    - Run `review-change-set`, `discover-edge-cases`, and `harden-app-security` for the same code-affecting scope when their coverage is needed.
    - Consolidate and resolve all confirmed findings before continuing.
    - Re-run relevant tests when runtime logic changes.
-4. Standardize project docs when specs or doc normalization is needed
+5. Standardize project docs when specs or doc normalization is needed
    - During submission, execute `archive-specs` when `repo-specs-ready-for-conversion` is true or when `project-doc-structure-mismatch` is true.
    - Let `archive-specs` convert the relevant specs into categorized project docs such as `docs/README.md`, `docs/getting-started.md`, `docs/configuration.md`, `docs/architecture.md`, `docs/features.md`, and `docs/developer-guide.md`.
    - Let the skill normalize any existing project docs to the same structure and archive superseded source spec files.
    - Do not treat unchecked task or decision checkboxes alone as blocking unfinished work; read the surrounding notes and requirement status semantically.
    - If the docs still show unresolved implementation scope that is neither completed, intentionally deferred, nor explicitly `N/A`, do not convert them yet; report that the spec files remain active and should not be deleted.
    - If the current change intentionally ships a partial phase while the same plan set still tracks remaining work, keep that plan set live and skip archival for that scope.
-5. Run pre-commit sync dependencies
+6. Run pre-commit sync dependencies
    - Execute `align-project-documents` after spec conversion and code/doc scans are complete.
    - Execute `maintain-project-constraints` immediately before the commit.
-6. Keep docs synchronized when needed
+7. Keep docs synchronized when needed
    - Apply the output from `archive-specs` when repository specs were converted or existing project docs were normalized into categorized project docs.
    - Apply the output from `align-project-documents` when behavior or usage changed.
    - Apply the output from `maintain-project-constraints` when agent workflow/rules changed.
-7. Commit
+8. Commit
    - Preserve user staging intent where possible.
    - Write a concise Conventional Commit message using `references/commit-messages.md`.
-8. Push
-   - Push commit(s) to the current branch.
+9. Push
+   - Push commit(s) to the intended branch.
+   - Confirm the local branch state matches the user's requested destination when post-push synchronization was requested.
 
 ## Notes
 

package/maintain-skill-catalog/SKILL.md

@@ -16,7 +16,7 @@ description: Audit and maintain a repository of installable skills so the catalo
 
 - Evidence: Read the actual skill folders, validation scripts, repository docs, and local installed skill names before changing dependency classifications or catalog docs.
 - Execution: Audit first, classify findings, make focused catalog updates, then run the repo validators before finishing.
-- Quality: Avoid duplicate skills, avoid rewording behavior without checking the implementation, and distinguish aliases or local unpublished skills from true external dependencies.
+- Quality: Avoid duplicate skills, avoid rewording behavior without checking the implementation, distinguish aliases or local unpublished skills from true external dependencies, and enforce the repository's current metadata constraints such as `SKILL.md` frontmatter validity, description-length limits, and synchronized agent configs.
 - Output: Leave the catalog with synchronized skill metadata, dependency documentation, and validation status.
 
 ## Goal
@@ -35,6 +35,7 @@ Keep a skill repository coherent when many top-level skills evolve together.
 ### 2) Audit dependency declarations and shared conventions
 
 - Use the standardized `## Dependencies` section as the source of truth for skill-to-skill relationships.
+- Read the current validator scripts before changing frontmatter-heavy files so metadata limits come from implementation rather than memory.
 - Classify each dependency as:
   - vendored in this repository
   - local/private skill that should not be documented as external
@@ -49,6 +50,7 @@ Keep a skill repository coherent when many top-level skills evolve together.
 - Update `README.md` skill lists and external dependency sections when the catalog actually changes.
 - Update `AGENTS.md` when the repository gains or loses a user-visible capability or a standing convention changes.
 - When creating a new shared skill, align naming, frontmatter, `agents/openai.yaml`, and any lightweight README with neighboring skills.
+- When a failure comes from validator drift or a metadata constraint that was not caught early, tighten the validator or CI path in the same change instead of only fixing the offending skill text.
 - Do not treat unpublished local skills as external dependencies just because they are not yet installed elsewhere.
 
 ### 4) Validate the catalog after changes

package/open-github-issue/README.md

@@ -1,15 +1,15 @@
 # Open GitHub Issue
 
-Structured GitHub issue and feature-proposal publishing with deterministic authentication fallback and repository-language-aware issue bodies.
+Structured GitHub issue publishing across multiple issue categories with deterministic authentication fallback and repository-language-aware issue bodies.
 
-This skill helps agents publish confirmed findings or accepted feature proposals as GitHub issues without embedding repository resolution, auth handling, and language detection logic into every other workflow.
+This skill helps agents publish confirmed findings, accepted proposals, documentation gaps, security risks, observability gaps, and performance issues as GitHub issues without embedding repository resolution, auth handling, and language detection logic into every other workflow.
 
 ## What this skill provides
 
 - Target repository resolution from `--repo` or current git `origin`.
 - Strict auth fallback order: `gh` login -> `GITHUB_TOKEN`/`GH_TOKEN` -> draft only.
 - Issue body language detection based on the target repository README.
-- Consistent structured issue bodies for both problem issues and feature proposal issues.
+- Consistent structured issue bodies for `problem`, `feature`, `performance`, `security`, `docs`, and `observability` issues.
 - Machine-readable JSON output so parent skills can report publication status consistently.
 
 ## Repository structure
@@ -33,7 +33,7 @@ cp -R open-github-issue "$CODEX_HOME/skills/open-github-issue"
 Invoke the skill in your prompt:
 
 ```text
-Use $open-github-issue to publish this confirmed finding or accepted feature proposal to GitHub.
+Use $open-github-issue to publish this confirmed finding or accepted proposal to GitHub.
 ```
 
 The bundled script can also be called directly:
@@ -58,6 +58,19 @@ python scripts/open_github_issue.py \
   --repo owner/repo
 ```
 
+```bash
+python scripts/open_github_issue.py \
+  --issue-type security \
+  --title "[Security] Missing authorization check on admin export" \
+  --problem-description "The admin export endpoint can be reached without verifying the caller's admin role." \
+  --severity high \
+  --affected-scope "/admin/export endpoint and exported customer data" \
+  --impact "Unauthorized users may access privileged exports containing sensitive business data." \
+  --evidence "Code path review and reproduced requests show the handler validates session presence but not the admin permission gate." \
+  --suggested-action "Add explicit authorization enforcement, regression tests, and audit logging for denied access attempts." \
+  --repo owner/repo
+```
+
 ## Publication behavior
 
 For each issue:
@@ -66,7 +79,7 @@ For each issue:
 2. Otherwise, if `GITHUB_TOKEN` or `GH_TOKEN` exists, publish via GitHub REST API.
 3. Otherwise, return draft issue content without blocking the caller.
 
-Problem issues always include exactly three sections:
+`problem` issues always include exactly three sections:
 
 - `Problem Description`
 - `Suspected Cause`
@@ -80,7 +93,7 @@ Within `Problem Description`, include:
 
 For Chinese-language repositories, use translated section titles with the same meaning.
 
-Feature proposal issues always include:
+`feature` issues always include:
 
 - `Feature Proposal`
 - `Why This Is Needed`
@@ -88,6 +101,35 @@ Feature proposal issues always include:
 
 For Chinese-language repositories, use translated section titles with the same meaning.
 
+`performance` issues include:
+
+- `Performance Problem`
+- `Impact`
+- `Evidence`
+- `Suggested Action`
+
+`security` issues include:
+
+- `Security Risk`
+- `Severity`
+- `Affected Scope`
+- `Impact`
+- `Evidence`
+- `Suggested Mitigation`
+
+`docs` issues include:
+
+- `Documentation Gap`
+- `Evidence`
+- `Suggested Update`
+
+`observability` issues include:
+
+- `Observability Gap`
+- `Impact`
+- `Evidence`
+- `Suggested Instrumentation`
+
 ## Output
 
 The script prints JSON including:

package/open-github-issue/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: open-github-issue
-description: Publish structured GitHub issues and feature proposals with deterministic auth fallback, target-repo resolution, README-based language detection, and draft-only fallback when authentication is unavailable. Use when users ask to open GitHub issues from confirmed findings, accepted feature proposals, or prepared issue content.
+description: Publish structured GitHub issues across multiple issue categories with deterministic auth fallback, target-repo resolution, README-based language detection, and draft-only fallback when authentication is unavailable. Use when users ask to open GitHub issues from confirmed findings, accepted proposals, documentation gaps, security risks, observability gaps, or prepared issue content.
 ---
 
 # Open GitHub Issue
@@ -14,14 +14,14 @@ description: Publish structured GitHub issues and feature proposals with determi
 
 ## Standards
 
-- Evidence: Require structured issue inputs, detect repository language from the target README instead of guessing, and for `problem` issues capture BDD-style expected vs current behavior with an explicit delta.
+- Evidence: Require structured issue inputs, detect repository language from the target README instead of guessing, and enforce category-specific required fields so each issue type matches the situation being reported.
 - Execution: Resolve the repo, normalize the issue body, publish with strict auth order, then return the publication result.
 - Quality: Preserve upstream evidence, localize only the structural parts, keep publication deterministic and reproducible, and make behavioral mismatches easy for maintainers to verify.
 - Output: Return publication mode, issue URL when created, rendered body, and any publish error in the standardized JSON contract.
 
 ## Overview
 
-Use this skill to publish a structured GitHub issue or feature proposal deterministically.
+Use this skill to publish structured GitHub issues deterministically across several common issue situations.
 
 It is designed to be reusable by other skills that already know the issue title and evidence, but need a consistent way to:
 
@@ -36,7 +36,7 @@ It is designed to be reusable by other skills that already know the issue title
 - Prefer authenticated `gh` CLI first, then GitHub token, then draft-only fallback.
 - Detect repository issue language from the target remote README instead of guessing.
 - Preserve upstream evidence content; only localize section headers and default fallback text.
-- Make the issue type explicit: `problem` for defects/incidents, `feature` for proposals.
+- Make the issue type explicit: `problem`, `feature`, `performance`, `security`, `docs`, or `observability`.
 - For `problem` issues, describe the expected behavior and current behavior with BDD-style `Given / When / Then`, then state the behavioral difference explicitly.
 
 ## Workflow
@@ -59,6 +59,27 @@ It is designed to be reusable by other skills that already know the issue title
      - `proposal` (optional; defaults to title when omitted)
      - `reason`
      - `suggested-architecture`
+   - For `performance` issues, require:
+     - `problem-description`
+     - `impact`
+     - `evidence`
+     - `suggested-action`
+   - For `security` issues, require:
+     - `problem-description`
+     - `severity`
+     - `affected-scope`
+     - `impact`
+     - `evidence`
+     - `suggested-action`
+   - For `docs` issues, require:
+     - `problem-description`
+     - `evidence`
+     - `suggested-action`
+   - For `observability` issues, require:
+     - `problem-description`
+     - `impact`
+     - `evidence`
+     - `suggested-action`
    - If reproduction is missing for a `problem` issue, insert the default non-reproducible note in the target issue language.
 3. Detect issue language
    - Read the target repository README from GitHub.
@@ -98,6 +119,59 @@ python scripts/open_github_issue.py \
   --repo <owner/repo>
 ```
 
+Performance issue:
+
+```bash
+python scripts/open_github_issue.py \
+  --issue-type performance \
+  --title "[Performance] Slow dashboard query under large tenants" \
+  --problem-description "Dashboard loading time degrades sharply once tenant data exceeds current pagination assumptions." \
+  --impact "Users wait 8-12 seconds before the page becomes interactive; this blocks support workflows." \
+  --evidence "Profiler output, slow-query logs, and production timings all point to repeated full-table scans in the summary query path." \
+  --suggested-action "Add bounded pagination, pre-aggregated summaries, and an index review for the offending query path." \
+  --repo <owner/repo>
+```
+
+Security issue:
+
+```bash
+python scripts/open_github_issue.py \
+  --issue-type security \
+  --title "[Security] Missing authorization check on admin export" \
+  --problem-description "The admin export endpoint can be reached without verifying the caller's admin role." \
+  --severity high \
+  --affected-scope "/admin/export endpoint and exported customer data" \
+  --impact "Unauthorized users may access privileged exports containing sensitive business data." \
+  --evidence "Code path review and reproduced requests show the handler validates session presence but not the admin permission gate." \
+  --suggested-action "Add explicit authorization enforcement, regression tests, and audit logging for denied access attempts." \
+  --repo <owner/repo>
+```
+
+Docs issue:
+
+```bash
+python scripts/open_github_issue.py \
+  --issue-type docs \
+  --title "[Docs] Deployment guide omits required Redis configuration" \
+  --problem-description "The deployment guide does not mention the required Redis URL and worker startup order." \
+  --evidence "README deploy steps differ from the actual compose file and runtime startup checks." \
+  --suggested-action "Update deployment docs with required env vars, startup order, and a minimal validation checklist." \
+  --repo <owner/repo>
+```
+
+Observability issue:
+
+```bash
+python scripts/open_github_issue.py \
+  --issue-type observability \
+  --title "[Observability] Missing request identifiers in payment retry logs" \
+  --problem-description "Retry logs do not include stable request or trace identifiers, so multi-line failures cannot be correlated quickly." \
+  --impact "On-call engineers cannot isolate a single failing payment flow without manual log stitching." \
+  --evidence "Current retry log lines include endpoint and error text only; incident review required manual timestamp matching." \
+  --suggested-action "Add request_id, trace_id, upstream target, and retry attempt fields to retry logs and dashboard facets." \
+  --repo <owner/repo>
+```
+
 ## Output contract
 
 The script prints JSON with these fields:
@@ -115,11 +189,12 @@ The script prints JSON with these fields:
 
 When another skill depends on `open-github-issue`:
 
-- Pass exactly one confirmed problem or one accepted feature proposal per invocation.
+- Pass exactly one confirmed issue or one accepted proposal per invocation.
 - Prepare evidence or proposal details before calling this skill; do not ask this skill to infer root cause or architecture.
 - For `problem` issues, pass a `problem-description` that contains `Expected Behavior (BDD)`, `Current Behavior (BDD)`, and `Behavior Gap`; the difference must be explicit, not implied.
 - Reuse the returned `mode`, `issue_url`, and `publish_error` in the parent skill response.
 - For accepted feature proposals, pass `--issue-type feature` plus `--proposal`, `--reason`, and `--suggested-architecture`.
+- For security, performance, docs, or observability findings, choose the matching `issue-type` instead of overloading `problem`.
 
 ## Resources
 

package/open-github-issue/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Open GitHub Issue"
-  short_description: "Publish structured issues and feature proposals"
-  default_prompt: "Use $open-github-issue to publish a structured GitHub issue or feature proposal from prepared content, resolve the target repo, detect README language for issue sections, and fall back deterministically from gh CLI to GitHub token to draft-only output."
+  short_description: "Publish structured issues across multiple categories"
+  default_prompt: "Use $open-github-issue to publish a structured GitHub issue from prepared content, choose the correct issue category such as problem, feature, performance, security, docs, or observability, resolve the target repo, detect README language for issue sections, and fall back deterministically from gh CLI to GitHub token to draft-only output."

package/open-github-issue/scripts/open_github_issue.py

@@ -19,6 +19,18 @@ DEFAULT_REPRO_ZH = "尚未穩定重現；需補充更多執行期資料。"
 DEFAULT_REPRO_EN = "Not yet reliably reproducible; more runtime evidence is required."
 ISSUE_TYPE_PROBLEM = "problem"
 ISSUE_TYPE_FEATURE = "feature"
+ISSUE_TYPE_PERFORMANCE = "performance"
+ISSUE_TYPE_SECURITY = "security"
+ISSUE_TYPE_DOCS = "docs"
+ISSUE_TYPE_OBSERVABILITY = "observability"
+ISSUE_TYPES = [
+    ISSUE_TYPE_PROBLEM,
+    ISSUE_TYPE_FEATURE,
+    ISSUE_TYPE_PERFORMANCE,
+    ISSUE_TYPE_SECURITY,
+    ISSUE_TYPE_DOCS,
+    ISSUE_TYPE_OBSERVABILITY,
+]
 PROBLEM_BDD_MARKER_GROUPS = (
     (
         r"Expected Behavior\s*\(BDD\)",
@@ -43,7 +55,7 @@ def parse_args() -> argparse.Namespace:
     parser.add_argument("--title", required=True, help="Issue title")
     parser.add_argument(
         "--issue-type",
-        choices=[ISSUE_TYPE_PROBLEM, ISSUE_TYPE_FEATURE],
+        choices=ISSUE_TYPES,
         default=ISSUE_TYPE_PROBLEM,
         help="Structured issue type to publish.",
     )
@@ -71,6 +83,27 @@ def parse_args() -> argparse.Namespace:
         "--suggested-architecture",
         help="Issue section content: suggested architecture for the feature",
     )
+    parser.add_argument(
+        "--impact",
+        help="Issue section content: concrete user, system, or business impact",
+    )
+    parser.add_argument(
+        "--evidence",
+        help="Issue section content: concrete evidence, metrics, logs, or repository facts",
+    )
+    parser.add_argument(
+        "--suggested-action",
+        help="Issue section content: suggested remediation, mitigation, or next action",
+    )
+    parser.add_argument(
+        "--severity",
+        choices=["critical", "high", "medium", "low"],
+        help="Issue section content: severity level for security-oriented issues",
+    )
+    parser.add_argument(
+        "--affected-scope",
+        help="Issue section content: affected endpoint, module, user cohort, or system surface",
+    )
     parser.add_argument(
         "--repo",
         help="Target repository in owner/repo format. Defaults to origin remote.",
@@ -91,6 +124,35 @@ def validate_issue_content_args(args: argparse.Namespace) -> None:
             raise SystemExit("Feature issues require --suggested-architecture.")
         return
 
+    if args.issue_type == ISSUE_TYPE_PERFORMANCE:
+        require_non_empty(args.problem_description, "Performance issues require --problem-description.")
+        require_non_empty(args.impact, "Performance issues require --impact.")
+        require_non_empty(args.evidence, "Performance issues require --evidence.")
+        require_non_empty(args.suggested_action, "Performance issues require --suggested-action.")
+        return
+
+    if args.issue_type == ISSUE_TYPE_SECURITY:
+        require_non_empty(args.problem_description, "Security issues require --problem-description.")
+        require_non_empty(args.affected_scope, "Security issues require --affected-scope.")
+        require_non_empty(args.impact, "Security issues require --impact.")
+        require_non_empty(args.evidence, "Security issues require --evidence.")
+        require_non_empty(args.suggested_action, "Security issues require --suggested-action.")
+        require_non_empty(args.severity, "Security issues require --severity.")
+        return
+
+    if args.issue_type == ISSUE_TYPE_DOCS:
+        require_non_empty(args.problem_description, "Docs issues require --problem-description.")
+        require_non_empty(args.evidence, "Docs issues require --evidence.")
+        require_non_empty(args.suggested_action, "Docs issues require --suggested-action.")
+        return
+
+    if args.issue_type == ISSUE_TYPE_OBSERVABILITY:
+        require_non_empty(args.problem_description, "Observability issues require --problem-description.")
+        require_non_empty(args.impact, "Observability issues require --impact.")
+        require_non_empty(args.evidence, "Observability issues require --evidence.")
+        require_non_empty(args.suggested_action, "Observability issues require --suggested-action.")
+        return
+
     if not (args.problem_description or "").strip():
         raise SystemExit("Problem issues require --problem-description.")
     if not (args.suspected_cause or "").strip():
@@ -102,6 +164,11 @@ def validate_issue_content_args(args: argparse.Namespace) -> None:
         )
 
 
+def require_non_empty(value: str | None, message: str) -> None:
+    if not (value or "").strip():
+        raise SystemExit(message)
+
+
 def has_required_problem_bdd_sections(problem_description: str) -> bool:
     normalized = problem_description.strip()
     return any(
@@ -236,6 +303,11 @@ def build_issue_body(
     proposal: str | None,
     reason: str | None,
     suggested_architecture: str | None,
+    impact: str | None = None,
+    evidence: str | None = None,
+    suggested_action: str | None = None,
+    severity: str | None = None,
+    affected_scope: str | None = None,
 ) -> str:
     if issue_type == ISSUE_TYPE_FEATURE:
         proposal_text = (proposal or title).strip()
@@ -261,6 +333,102 @@ def build_issue_body(
             f"{architecture_text}\n"
         )
 
+    if issue_type == ISSUE_TYPE_PERFORMANCE:
+        if language == "zh":
+            return (
+                "### 效能問題\n"
+                f"{(problem_description or '').strip()}\n\n"
+                "### 影響\n"
+                f"{(impact or '').strip()}\n\n"
+                "### 證據\n"
+                f"{(evidence or '').strip()}\n\n"
+                "### 建議行動\n"
+                f"{(suggested_action or '').strip()}\n"
+            )
+        return (
+            "### Performance Problem\n"
+            f"{(problem_description or '').strip()}\n\n"
+            "### Impact\n"
+            f"{(impact or '').strip()}\n\n"
+            "### Evidence\n"
+            f"{(evidence or '').strip()}\n\n"
+            "### Suggested Action\n"
+            f"{(suggested_action or '').strip()}\n"
+        )
+
+    if issue_type == ISSUE_TYPE_SECURITY:
+        if language == "zh":
+            return (
+                "### 安全風險\n"
+                f"{(problem_description or '').strip()}\n\n"
+                "### 嚴重程度\n"
+                f"{(severity or '').strip()}\n\n"
+                "### 受影響範圍\n"
+                f"{(affected_scope or '').strip()}\n\n"
+                "### 影響\n"
+                f"{(impact or '').strip()}\n\n"
+                "### 證據\n"
+                f"{(evidence or '').strip()}\n\n"
+                "### 建議緩解\n"
+                f"{(suggested_action or '').strip()}\n"
+            )
+        return (
+            "### Security Risk\n"
+            f"{(problem_description or '').strip()}\n\n"
+            "### Severity\n"
+            f"{(severity or '').strip()}\n\n"
+            "### Affected Scope\n"
+            f"{(affected_scope or '').strip()}\n\n"
+            "### Impact\n"
+            f"{(impact or '').strip()}\n\n"
+            "### Evidence\n"
+            f"{(evidence or '').strip()}\n\n"
+            "### Suggested Mitigation\n"
+            f"{(suggested_action or '').strip()}\n"
+        )
+
+    if issue_type == ISSUE_TYPE_DOCS:
+        if language == "zh":
+            return (
+                "### 文件缺口\n"
+                f"{(problem_description or '').strip()}\n\n"
+                "### 證據\n"
+                f"{(evidence or '').strip()}\n\n"
+                "### 建議更新\n"
+                f"{(suggested_action or '').strip()}\n"
+            )
+        return (
+            "### Documentation Gap\n"
+            f"{(problem_description or '').strip()}\n\n"
+            "### Evidence\n"
+            f"{(evidence or '').strip()}\n\n"
+            "### Suggested Update\n"
+            f"{(suggested_action or '').strip()}\n"
+        )
+
+    if issue_type == ISSUE_TYPE_OBSERVABILITY:
+        if language == "zh":
+            return (
+                "### 可觀測性缺口\n"
+                f"{(problem_description or '').strip()}\n\n"
+                "### 影響\n"
+                f"{(impact or '').strip()}\n\n"
+                "### 證據\n"
+                f"{(evidence or '').strip()}\n\n"
+                "### 建議儀表化\n"
+                f"{(suggested_action or '').strip()}\n"
+            )
+        return (
+            "### Observability Gap\n"
+            f"{(problem_description or '').strip()}\n\n"
+            "### Impact\n"
+            f"{(impact or '').strip()}\n\n"
+            "### Evidence\n"
+            f"{(evidence or '').strip()}\n\n"
+            "### Suggested Instrumentation\n"
+            f"{(suggested_action or '').strip()}\n"
+        )
+
     if language == "zh":
         repro_text = (reproduction or DEFAULT_REPRO_ZH).strip()
         return (
@@ -349,6 +517,11 @@ def main() -> int:
         proposal=args.proposal,
         reason=args.reason,
         suggested_architecture=args.suggested_architecture,
+        impact=args.impact,
+        evidence=args.evidence,
+        suggested_action=args.suggested_action,
+        severity=args.severity,
+        affected_scope=args.affected_scope,
     )
 
     mode = "draft-only"