@laitszkin/apollo-toolkit 2.0.0

package/novel-to-short-video/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: novel-to-short-video
+description: Convert novel text into a loopable short-form video by extracting the single most compelling story segment, generating images and voiceover, and assembling a Remotion render. Use when users ask to turn novels or chapters into a 50-60 second narrative short, teaser reel, or looping story clip that feels self-contained yet leaves strong lingering curiosity.
+---
+
+# Novel to Short Video
+
+## Dependencies
+
+- Required: `openai-text-to-image-storyboard`, `docs-to-voice`, and `remotion-best-practices` in that order.
+- Conditional: none.
+- Optional: none.
+- Fallback: If any required video-production dependency is unavailable, stop and report the missing dependency instead of substituting another pipeline.
+
+## Standards
+
+- Evidence: Choose exactly one self-contained highlight segment from the novel using explicit tension and standalone-story criteria.
+- Execution: Create the plan file, obtain explicit approval, maintain `roles.json`, then generate images, narration, and the final render in sequence.
+- Quality: Keep duration at 50-60 seconds, narration pacing at 3-4 CJK chars per second, and preserve loop closure plus role consistency.
+- Output: Return the approved plan path, role and prompt files, pacing proof, retained Remotion workspace, and final rendered video path.
+
+## Required Inputs
+
+Collect the minimum required inputs before execution:
+
+- `project_dir` (absolute path)
+- `content_name` (output folder/video name)
+- novel content (raw text or file path)
+- output orientation/resolution (default: vertical 1080x1920)
+- narration language/voice preferences when provided
+
+If critical inputs are missing, ask concise follow-up questions.
+
+## Workflow
+
+### 1) Extract one highlight segment
+
+- Parse the novel and list candidate high-tension segments.
+- Score each segment by conflict intensity, stakes, emotional swing, turning-point value, visual concreteness, standalone readability, and cliffhanger potential.
+- Select exactly **1** segment with the strongest overall dramatic impact.
+- Reject segments that cannot be understood without heavy external context from other chapters.
+- Prefer segments that can deliver a complete mini-arc while still leaving one meaningful unresolved question.
+- Keep a structured segment sheet:
+  - `title`
+  - `source_excerpt`
+  - `core_conflict`
+  - `tension_arc` (setup -> escalation -> climax -> aftershock)
+  - `standalone_story_basis`
+  - `lingering_question`
+  - `visual_beats`
+  - `narration_key_line`
+
+### 2) Generate a pre-production plan markdown (required)
+
+- Before image/voice/video generation, create:
+  - `<project_dir>/docs/plans/`
+  - `<project_dir>/docs/plans/<YYYY-MM-DD>-<chapter_slug>.md`
+- `chapter_slug` should come from the chapter name/number and be filesystem-safe.
+- Build the plan content from template file:
+  - `references/plan-template.md`
+- The plan markdown must include:
+  - selected highlight segment details,
+  - narration script and beat-level timing for the full video,
+  - narration pacing target (3-4 chars/second) and expected character count budget,
+  - standalone-story check and lingering-question design,
+  - image assets that will be generated for the segment,
+  - beat-level special-effect cues with intensity guardrails for audience focus.
+- All template guidance/placeholders must be wrapped in square brackets (for example `[fill_this]`).
+- After filling content, remove every placeholder/guidance marker from the final plan file.
+- Enforce 1:1 mapping: one selected highlight segment must map to one full 50-60 second video.
+
+### 3) Request user approval before execution (required)
+
+- Present the generated plan markdown to the user (path + concise summary).
+- Ask for explicit approval.
+- Do not start image/voice/render execution until user explicitly agrees.
+- If user asks for edits, update the plan and request approval again.
+
+### 4) Build a loopable 50-60s script
+
+- Produce one short video with total duration in **50-60 seconds**.
+- Keep narration pacing in **3-4 CJK characters per second** (ignore spaces/punctuation in counting).
+- For a 50-60 second output, keep narration around **150-240 CJK characters**.
+- Build pacing within the same segment using beat progression (hook -> escalation -> climax -> loop closure).
+- Make the segment self-contained as a mini-story:
+  - viewers can understand setup, conflict, turning point, and immediate outcome without prior chapter context,
+  - the narration provides enough context in-line rather than relying on outside exposition.
+- Write narration so:
+  - first sentence is the hook,
+  - final sentence closes the loop by reusing or tightly paraphrasing the first sentence,
+  - ending still leaves one unresolved high-stakes question so viewers feel lingering curiosity.
+- Ensure the final visual beat can cut/fade back to the opening frame naturally.
+- Use the plan markdown as the source of truth and keep beat order aligned with it.
+
+If producing multiple short videos in one request, enforce the same 50-60 second duration for each output.
+
+### 5) Create `roles.json` for recurring character prompts (required)
+
+- Before creating/updating `roles.json`, read:
+  - `references/roles-json.md`
+- Create directory if missing:
+  - `<project_dir>/roles/`
+- Create `roles.json` under:
+  - `<project_dir>/roles/roles.json`
+- If `roles.json` does not exist, create it first before any `prompts.json` planning or generation.
+- If `roles.json` already exists, read existing role prompts first and reuse matching roles.
+- If a required role is missing, append a new role prompt entry for that role (do not overwrite existing entries).
+- Save recurring character prompt skeletons using the schema in `references/roles-json.md`.
+- Treat this file as the shared role registry for both short-video and long-video workflows in the same project.
+- If the selected segment has no recurring roles, still create `roles.json` with `{"characters": []}`.
+- Keep role IDs stable and reuse them in every scene prompt.
+
+### 6) Generate storyboard images (`openai-text-to-image-storyboard`)
+
+- Create `prompts.json` under:
+  - `<project_dir>/pictures/<content_name>/prompts.json`
+- Use the structured JSON prompt format from `openai-text-to-image-storyboard`.
+- Copy top-level `characters` from the final `roles.json` (reused + newly appended roles), then build beat-aligned `scenes` in narrative order.
+- Ensure prompts match the image list defined in the plan markdown.
+- Generate images with:
+
+```bash
+python /Users/tszkinlai/.codex/skills/openai-text-to-image-storyboard/scripts/generate_storyboard_images.py \
+  --project-dir "<project_dir>" \
+  --env-file /Users/tszkinlai/.codex/skills/openai-text-to-image-storyboard/.env \
+  --content-name "<content_name>" \
+  --prompts-file "<project_dir>/pictures/<content_name>/prompts.json"
+```
+
+### 7) Generate narration and subtitles (`docs-to-voice`)
+
+- Use the loop script text as narration input.
+- Generate audio + timeline + SRT:
+
+```bash
+python /Users/tszkinlai/.codex/skills/docs-to-voice/scripts/docs_to_voice.py \
+  --project-dir "<project_dir>" \
+  --project-name "<content_name>" \
+  --text "<loop_narration_script>"
+```
+
+- Enforce pacing validation after each generation:
+  - Read `audio_duration_seconds` from generated `.timeline.json`.
+  - Compute `chars_per_second = cjk_char_count(loop_narration_script) / audio_duration_seconds`.
+  - Target range is **3.0-4.0 chars/second**.
+- If out of range, regenerate with adjustment (max 3 attempts):
+  - `say` mode: tune `--rate` (increase when `<3.0`, decrease when `>4.0`).
+  - `api` mode: keep voice/model fixed and adjust script length to pull pacing back into range.
+- Do not proceed to Remotion render until narration pacing is within target range.
+
+### 8) Compose and render (`remotion-best-practices`)
+
+- Build or reuse Remotion workspace:
+  - `<project_dir>/video/<content_name>/remotion/`
+- Load Remotion rules as needed (at minimum):
+  - `rules/compositions.md`
+  - `rules/audio.md`
+  - `rules/subtitles.md`
+  - `rules/transitions.md`
+  - `rules/animations.md`
+  - `rules/text-animations.md`
+  - `rules/light-leaks.md`
+- Implement beat sequencing with subtitle sync from SRT.
+- Keep one contiguous narrative segment so the plan's segment-to-video mapping remains valid.
+- Apply attention-retention effects according to the approved beat plan:
+  - hook beat uses quick visual emphasis (for example punch-in, kinetic subtitle, or parallax),
+  - escalation/climax beats use one dominant impact effect each (for example shake, flash, light leak, or speed ramp),
+  - loop-closure beat reduces effect intensity and transitions cleanly back to the opening frame.
+- Keep effect density controlled:
+  - do not stack multiple high-intensity effects at the same time,
+  - avoid aggressive flashing that harms subtitle readability.
+- Add loop closure in the tail section:
+  - final 1-2 seconds visually connect back to opening shot,
+  - final spoken line closes back to opening hook.
+- Render MP4 output to:
+  - `<project_dir>/video/<content_name>/renders/`
+
+### 9) Keep Remotion project and enforce `.gitignore`
+
+Preserve Remotion project sources for user revisions. Do not delete project files after rendering.
+
+Ensure `<project_dir>/video/<content_name>/remotion/.gitignore` includes at least:
+
+```gitignore
+node_modules/
+out/
+dist/
+.cache/
+*.log
+.DS_Store
+```
+
+## Output Contract
+
+Return:
+
+- selected highlight-segment summary (with why it was selected)
+- proof note that the segment is self-contained and why the ending still leaves viewers wanting more
+- plan markdown path (`<project_dir>/docs/plans/<YYYY-MM-DD>-<chapter_slug>.md`)
+- explicit user approval confirmation (before asset generation)
+- roles prompt file path (`<project_dir>/roles/roles.json`)
+- prompts file path (`<project_dir>/pictures/<content_name>/prompts.json`)
+- beat-level special-effects summary used in the final render
+- generated image directory path
+- narration audio path
+- subtitle SRT path
+- narration pacing proof (`char_count`, `audio_duration_seconds`, `chars_per_second`)
+- final rendered video path
+- Remotion project path (retained for adjustments)
+
+## Quality Gate Checklist
+
+Before finishing, verify all conditions:
+
+- exactly 1 highest-impact highlight segment selected
+- selected segment is understandable as a standalone mini-story
+- plan markdown exists in `docs/plans/` with date + chapter naming
+- plan content starts from `references/plan-template.md`
+- plan markdown includes the selected segment, beat/script details, standalone-story check, lingering-question design, and segment image generation list
+- plan markdown includes a beat-level special-effects map plus intensity guardrails
+- all bracketed placeholders/guidance are removed from the final filled plan
+- user explicitly approved the plan before image/voice/render steps
+- `roles.json` exists and follows `references/roles-json.md`
+- existing role prompts are reused when available; new role prompts are added only when missing
+- `prompts.json` uses structured mode and reuses role IDs from `roles.json`
+- one selected segment maps to one full output video
+- duration is within 50-60 seconds per output video
+- narration pacing is within 3-4 CJK chars/second
+- opening and ending lines form a narrative loop
+- special effects strengthen hook/escalation/climax focus without breaking subtitle readability
+- ending leaves one unresolved but compelling question
+- images and voice assets are generated successfully
+- Remotion project is preserved and `.gitignore` is configured

package/novel-to-short-video/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Novel to Short Video"
+  short_description: "Turn the best novel segment into a looping 50-60s short video"
+  default_prompt: "Use $novel-to-short-video to extract the single most compelling segment from my novel, ensure it forms a self-contained mini-story while ending with lingering curiosity, create a plan markdown from references/plan-template.md under docs/plans with date+chapter naming, include beat-level audience-focus effects and a 3-4 chars/second narration pacing target in the plan, wait for my approval, then ensure <project_dir>/roles/roles.json exists first (create it if missing using references/roles-json.md), reuse existing role prompts, and only append missing roles before generating prompts/images, then generate storyboard images and voiceover, validate narration speed in 3-4 chars/second before render, and render a 50-60 second looping short video with controlled special effects while keeping the Remotion project editable."

package/novel-to-short-video/references/plan-template.md

@@ -0,0 +1,71 @@
+# [chapter_title] Short Video Plan
+[Instruction: Fill every bracketed placeholder in this template. After filling, remove all bracketed guidance/placeholders (including brackets) before submitting the final plan.]
+
+- Date: [YYYY-MM-DD]
+- Chapter: [chapter_name_or_number]
+- Content Name: [content_name]
+- Source: [novel_file_or_raw_input]
+- Orientation: [1080x1920]
+- Approval Status: [Pending User Approval]
+
+## Highlight Segment: [segment_title]
+- Source Excerpt: [segment_excerpt]
+- Selection Reason: [why_this_is_the_most_compelling_segment]
+- Core Conflict: [segment_core_conflict]
+- Tension Arc: [setup -> escalation -> climax -> aftershock]
+- Standalone Story Basis: [how_viewers_can_understand_this_segment_without_prior_context]
+- Lingering Question: [the_single_unresolved_question_left_at_the_end]
+
+### Narration Script (50-60s)
+[full_narration_script_for_single_segment]
+
+### Beat Plan
+1. [beat_1_title]
+   - duration: [beat_1_seconds]
+   - purpose: [hook_or_setup]
+   - focus effect: [hook_effect_and_trigger]
+2. [beat_2_title]
+   - duration: [beat_2_seconds]
+   - purpose: [conflict_escalation]
+   - focus effect: [escalation_effect_and_trigger]
+3. [beat_3_title]
+   - duration: [beat_3_seconds]
+   - purpose: [climax]
+   - focus effect: [climax_effect_and_trigger]
+4. [beat_4_title]
+   - duration: [beat_4_seconds]
+   - purpose: [loop_closure]
+   - focus effect: [loop_closure_effect_and_trigger]
+
+### Images to Generate
+- [segment_img01.png]: [image_prompt_or_intent_1]
+- [segment_img02.png]: [image_prompt_or_intent_2]
+- [segment_img03.png]: [image_prompt_or_intent_3]
+- [segment_img04.png]: [image_prompt_or_intent_4]
+
+### Video Segment
+- duration: [50-60 seconds]
+- purpose: [how_this_single_segment_supports_the_full_video]
+
+### Audience Focus Effects
+- Hook emphasis: [quick_attention_grabber_for_first_2_seconds]
+- Escalation emphasis: [mid_video_attention_lift_effect]
+- Climax emphasis: [peak_impact_effect]
+- Loop-return treatment: [how_effects_taper_before_returning_to_opening_frame]
+- Intensity guardrails: [limits_to_prevent_effect_overload_or_subtitle_obstruction]
+
+## Story Satisfaction Check
+- Mini-story completeness: [setup_conflict_turning_point_immediate_outcome_are_all_clear]
+- Why this still feels unresolved: [how_the_ending_creates_lingering_curiosity]
+- Why viewers want one more replay: [loop_return_plus_new_question_design]
+
+## Loop Closure
+- Opening hook line: [first_sentence_hook]
+- Closing loop line: [final_sentence_that_returns_to_hook]
+
+## Timing Check
+- Total duration target: [50-60 seconds]
+- Narration pacing target: [3-4 chars/second]
+- Narration char-count budget: [150-240 CJK chars]
+- Pacing validation formula: [cjk_char_count / audio_duration_seconds]
+- Beat transition notes: [beat_transition_plan]

package/novel-to-short-video/references/roles-json.md

@@ -0,0 +1,41 @@
+# `roles.json` Definition
+
+Use this schema when creating or updating:
+
+- `<project_dir>/roles/roles.json`
+
+## JSON Shape
+
+```json
+{
+  "characters": [
+    {
+      "id": "lin_xia",
+      "name": "Lin Xia",
+      "appearance": "short black hair, amber eyes, slim build",
+      "outfit": "dark trench coat, silver pendant, leather boots",
+      "description": "standing calmly, observant expression"
+    }
+  ]
+}
+```
+
+## Rules
+
+- Top-level key must be `characters` (array).
+- If the file does not exist, create `roles.json` first with this schema before prompt generation.
+- Each character entry must include:
+  - `id`
+  - `name`
+  - `appearance`
+  - `outfit`
+  - `description`
+- Keep `id` stable across all scenes and future updates.
+- Reuse existing character entries first; append only missing roles.
+- If there are no recurring roles, still create:
+
+```json
+{"characters": []}
+```
+
+Use this shared file so short-video and long-video skills can reuse the same role definitions within one project.

package/open-github-issue/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Tsz Kin Lai
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/open-github-issue/README.md

@@ -0,0 +1,97 @@
+# Open GitHub Issue
+
+Structured GitHub issue and feature-proposal publishing 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.
+
+## 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.
+- Machine-readable JSON output so parent skills can report publication status consistently.
+
+## Repository structure
+
+- `SKILL.md`: Main skill definition and workflow.
+- `agents/openai.yaml`: Agent interface metadata and default prompt.
+- `scripts/open_github_issue.py`: Deterministic issue publisher.
+
+## Installation
+
+1. Clone this repository.
+2. Copy this folder to your Codex skills directory:
+
+```bash
+mkdir -p "$CODEX_HOME/skills"
+cp -R open-github-issue "$CODEX_HOME/skills/open-github-issue"
+```
+
+## Usage
+
+Invoke the skill in your prompt:
+
+```text
+Use $open-github-issue to publish this confirmed finding or accepted feature proposal to GitHub.
+```
+
+The bundled script can also be called directly:
+
+```bash
+python scripts/open_github_issue.py \
+  --issue-type problem \
+  --title "[Log] Payment timeout spike" \
+  --problem-description "Repeated timeout warnings escalated into request failures during the incident window." \
+  --suspected-cause "payment-api/handler.py:84 retries immediately against a slow upstream with no jitter; confidence high." \
+  --reproduction "Not yet reliably reproducible; more runtime evidence is required." \
+  --repo owner/repo
+```
+
+```bash
+python scripts/open_github_issue.py \
+  --issue-type feature \
+  --title "[Feature] Add incident timeline export" \
+  --proposal "Allow users to export incident timelines as Markdown and CSV from the incident detail page." \
+  --reason "Support handoff to on-call engineers and postmortem writing without copy-paste." \
+  --suggested-architecture "Add an export action in the incident UI, reuse timeline query service, and centralize renderers in a shared export module." \
+  --repo owner/repo
+```
+
+## Publication behavior
+
+For each issue:
+
+1. If `gh auth status` succeeds, publish with GitHub CLI.
+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 Description`
+- `Suspected Cause`
+- `Reproduction Conditions (if available)`
+
+For Chinese-language repositories, use translated section titles with the same meaning.
+
+Feature proposal issues always include:
+
+- `Feature Proposal`
+- `Why This Is Needed`
+- `Suggested Architecture`
+
+For Chinese-language repositories, use translated section titles with the same meaning.
+
+## Output
+
+The script prints JSON including:
+
+- publication mode,
+- issue type,
+- created issue URL when available,
+- rendered issue body,
+- and publish error details when fallback occurs.
+
+## License
+
+MIT. See `LICENSE`.

package/open-github-issue/SKILL.md

@@ -0,0 +1,119 @@
+---
+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.
+---
+
+# Open GitHub Issue
+
+## Dependencies
+
+- Required: none.
+- Conditional: none.
+- Optional: none.
+- Fallback: If authenticated publishing is unavailable, fall back to draft-only output without blocking the caller.
+
+## Standards
+
+- Evidence: Require structured issue inputs and detect repository language from the target README instead of guessing.
+- 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, and keep publication deterministic and reproducible.
+- 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.
+
+It is designed to be reusable by other skills that already know the issue title and evidence, but need a consistent way to:
+
+- resolve the target repository,
+- localize the issue body,
+- publish with the preferred auth path,
+- and fall back to draft-only output without blocking the main workflow.
+
+## Core principles
+
+- Keep publishing deterministic and reproducible.
+- 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.
+
+## Workflow
+
+1. Resolve target repository
+   - Use `--repo owner/name` when provided.
+   - Otherwise resolve from current git `origin`.
+2. Normalize issue content
+   - Require one title and an explicit `issue-type`.
+   - For `problem` issues, require these structured sections:
+     - `problem-description`
+     - `suspected-cause`
+     - `reproduction` (optional)
+   - For `feature` issues, require these structured sections:
+     - `proposal` (optional; defaults to title when omitted)
+     - `reason`
+     - `suggested-architecture`
+   - 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.
+   - If the README is Chinese, publish Chinese section titles; otherwise publish English section titles.
+4. Publish with strict auth order
+   - If `gh auth status` succeeds, use `gh issue create`.
+   - Otherwise, if `GITHUB_TOKEN` or `GH_TOKEN` exists, use GitHub REST API.
+   - Otherwise, return draft-only output and do not block the caller.
+5. Return publication result
+   - Always return publication mode, issue URL when created, rendered issue body, and any publish error.
+
+## Deterministic command
+
+Use the bundled script.
+
+Problem issue:
+
+```bash
+python scripts/open_github_issue.py \
+  --issue-type problem \
+  --title "[Log] <short symptom>" \
+  --problem-description "<symptom + impact + key evidence>" \
+  --suspected-cause "<path:line + causal chain + confidence>" \
+  --reproduction "<steps/conditions or leave empty>" \
+  --repo <owner/repo>
+```
+
+Feature proposal issue:
+
+```bash
+python scripts/open_github_issue.py \
+  --issue-type feature \
+  --title "[Feature] <short proposal>" \
+  --proposal "<what should be added or changed>" \
+  --reason "<why this matters now, user value, constraints>" \
+  --suggested-architecture "<modules, boundaries, implementation direction>" \
+  --repo <owner/repo>
+```
+
+## Output contract
+
+The script prints JSON with these fields:
+
+- `repo`
+- `issue_type`
+- `language`
+- `mode` (`gh-cli` / `github-token` / `draft-only` / `dry-run`)
+- `issue_url`
+- `issue_title`
+- `issue_body`
+- `publish_error`
+
+## Dependency usage guidance
+
+When another skill depends on `open-github-issue`:
+
+- Pass exactly one confirmed problem or one accepted feature proposal per invocation.
+- Prepare evidence or proposal details before calling this skill; do not ask this skill to infer root cause or architecture.
+- 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`.
+
+## Resources
+
+- `scripts/open_github_issue.py`: Deterministic issue publishing helper with auth fallback and README language detection.

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

@@ -0,0 +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."