ワンクリックで
activity-publish-github
Publish user stories as GitHub Issues following github-ops conventions. Use after generate-stories.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Publish user stories as GitHub Issues following github-ops conventions. Use after generate-stories.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | activity-publish-github |
| description | Publish user stories as GitHub Issues following github-ops conventions. Use after generate-stories. |
Publish user stories as GitHub Issues so GitHub becomes the source of truth for execution tracking. Use this skill after stories are approved. Invoked by the product-engineer agent in Feature Mode.
RFC 2119 Notice: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.
Take a list of user stories and publish them as GitHub Issues using GitHub MCP or gh CLI, so GitHub becomes the source of truth for execution tracking.
This activity assumes the following document exists:
user-stories-[prd-name].md — The comprehensive list of user stories (produced by the generate-stories activity)github-ops conventions.github-ops whenever possible.Execution method rules:
gh CLI MAY be used.github-mcp or gh-cli) MUST be recorded in the publication report.If github-ops delegation is unavailable in the current runtime, you MUST apply github-ops issue, label, milestone, and comment conventions directly and explicitly note that fallback in your status output.
Attribution rules:
Assisted-by: <assistant name and version> in the corresponding PR body or closing comment.owner/repo)"Each GitHub Issue MUST be created using:
[PRD-<prd-number or name>] Story [ID]: [Title]lint, format:check, typecheck, test, audit, optionally validate)For JS/TS projects, command examples in issues MUST prefer pnpm and canonical scripts (pnpm run <script>).
All issue formatting and metadata MUST conform to github-ops conventions.
You MUST create a publication report:
# GitHub Publication Report: [PRD Name]
## Target Repository
- Repo: owner/repo
- Date: YYYY-MM-DD
## Created Issues
| Story ID | Story Title | Issue URL | Labels | Milestone | Assignee |
| -------- | ----------- | ---------------------------------------- | ------------- | --------- | -------- |
| S-001 | [Title] | https://github.com/owner/repo/issues/123 | backend, auth | v1 | @user |
| ... | ... | ... | ... | ... | ... |
## Notes
- Any skipped stories and why
- Any template or permission limitations
- Any manual follow-up needed
- Execution method used: `github-mcp` or `gh-cli`
- Assisted-by value used for PR creation/issue closure (if applicable)
.md)/workstream/github-publication-[prd-name].mdgithub-ops whenever possible.Read and write architectural decisions to the shared memo-cli knowledge base. Use when recording or restoring cross-session context.
Break a technical specification into user stories with coverage validation. Use after generate-spec.
Establish product-context.md and technical-guidelines.md foundation docs. Use in product-engineer Init Mode.
Clarify scope: produce a lightweight issue refinement or a full PRD. Use in product-engineer Feature or Issue Mode.
Execute a task list step-by-step with strict sequencing, branch/PR discipline, GitHub Issue sync, and user approval gates. Single source of truth for implementation. Use when implementing from a tasks-*.md file.
Convert selected user stories or a refined GitHub Issue into an execution-ready tasks-*.md list and sync the GitHub Issue checklist. Use after stories/refinement, before implementation.