ワンクリックでManusで任意のスキルを実行

file-issue

スター0

フォーク0

更新日2026年5月19日 03:32

File a bug report or feature request for the odd-pipeline itself, with auto-gathered context from the current project and session. Use when the user says "/file-issue", "file a bug", "report an issue", "this is a pipeline problem", or encounters a pipeline defect during daily use.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

TonyWu20

TonyWu20/odd-pipeline

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

File Issue

Gathers context from the current project and session to file a structured issue on the TonyWu20/odd-pipeline repository. Lowers friction for reporting pipeline defects encountered during daily use.

Trigger

/file-issue

No arguments. The skill prompts the user for issue details interactively.

Step 0: Resolve Agent Mapping

The pipeline uses pluggable agents. Determine which agent to use for context gathering:

Check CLI args: If the user's invocation includes --agent-griller=<agent-name>, use that agent. CLI args override everything.
Check AGENT_CONFIG.md: Read AGENT_CONFIG.md from the project root. If it exists, parse **griller:** <agent-name>. Apply if not already set by CLI args.
Apply default: If still unset, griller defaults to general-purpose.
Build resolved mapping: Record which agent will be used for griller.

Throughout this skill, whenever a subagent is launched, use the resolved agent name.

Process

Step 1: Gather Context (Subagent)

Launch the griller subagent (resolved in Step 0) to collect relevant context:

Agent: {griller} (subagent, discardable context)

Task: Gather context for a pipeline issue report.

Collect the following:
Current pipeline state:
ls skills/*/SKILL.md 2>/dev/null
Pipeline version:
git log --oneline -5
Current project context (from the working directory where the issue was encountered):
pwd
git remote -v 2>/dev/null
git log --oneline -3 2>/dev/null
Output the gathered context as structured data for the issue template.

Step 2: Build Issue Template

Format the issue using the GitHub issue template:

---
title: "[pipeline]: <short description>"
---

## Description

{User's description of the problem or feature request}

## Context

- **Pipeline version**: {commit hash from git log}
- **Project**: {current project URL or path}
- **Session**: {what skills were being used when the issue occurred}

## Reproduction Steps

{User-provided or auto-detected steps}

## Expected vs Actual

- **Expected**: {what should happen}
- **Actual**: {what actually happened}

## Environment

- **Pipeline branch**: {current branch}
- **OS**: {auto-detected}
- **Claude Code version**: {if available}

## Relevant Artifacts

{Paths to relevant plan files, directions.json, execution reports, etc.}

Step 3: User Review

Present the formatted issue to the user for review and editing:

"Here's the draft issue for TonyWu20/odd-pipeline:

{ISSUE_BODY}

Please review and edit the description above, then confirm to file the issue. Type 'confirm' to file, or provide changes."

Step 4: File the Issue

Once the user confirms, file the issue:

gh issue create --repo TonyWu20/odd-pipeline --title "<title>" --body "<body>"

Report the resulting issue URL to the user.

Boundaries

Will:

Auto-gather context from the current project and pipeline state
Format a structured issue using the project's template
Let the user review and edit before filing
File via gh CLI

Will not:

File issues without user review
Modify any project files
Include sensitive information (API keys, tokens) in the issue

このリポジトリの他の Skills

同じリポジトリ

define-outcomes

TonyWu20/odd-pipeline

Interactive skill that helps users define desired outcomes for the next phase through Socratic grilling. Produces a PHASE_PLAN.md with concrete goals, scope boundaries, and success criteria. Uses grill-me + first-principle thinking to question priorities and foundations before committing to a plan. This is the recommended step before `/drive-outcomes`, especially when goals are still vague. Use when the user says "/define-outcomes", "define the outcomes", "clarify what we want", "what should the next phase achieve", "plan the next phase", or wants to decide what the next phase should accomplish before implementing.

2026-05-190

drive-outcomes

TonyWu20/odd-pipeline

Merged Stage 1+2 — define success criteria, explore against real fixtures, validate, implement, and produce a forensic record. One continuous session with a checkpoint in the middle. Use when the user says "/drive-outcomes <plan-path>", "drive the outcomes for this phase", after /define-outcomes completes, or when a phase plan is already ready for ODD-driven implementation.

2026-05-190

init-project

TonyWu20/odd-pipeline

Stage 0 — grill the user to settle the repo constitution: architecture, coding patterns, domain language, dependency choices, and tooling configuration. Produces CONTEXT.md (domain glossary + tooling config) and ADRs (architectural decisions). MUST be run before `/drive-outcomes` on any project. Use when the user says "/init-project", "set up the project constitution", "initialize the repo for the pipeline", or on a fresh project checkout before any planning begins.

2026-05-190

make-judgement

TonyWu20/odd-pipeline

Review implemented changes against TASKS.md, produce review.md and fix-tasks.md for any defects found. Accepts a TASKS.md path and progressively loads group sections for validation. Use when the user says "/make-judgement <tasks-path>", "review the implementation", "judge the changes", or after /drive-outcomes completes for complex multi-group changes.

2026-05-190

debug-outcomes

TonyWu20/odd-pipeline

Debug an existing fixture-anchored system that passes its acceptance test but produces wrong output. Classifies prior investigation notes, establishes external anchor criteria, applies upstream-audit rule, implements fix with discriminator-value tests, and captures resolution. Use when the user says "/debug-outcomes", "debug this failure", "the test passes but the output is wrong", or describes a symptom in a system that already has fixture files and a passing (but loose) acceptance test.

2026-05-150

diagnose-tests

TonyWu20/odd-pipeline

Scans a project's existing test suite for placebo test patterns (vacuous assertions, circular round-trip, unbounded thresholds, synthetic-only data). Produces a migration report to help projects adopt the Outcome-Driven Development (ODD) pipeline. Use when migrating from the old TDD pipeline, auditing test quality, or when the user says "/diagnose-tests", "audit my tests", "find placebo tests", or "how healthy are my tests?".

2026-05-150

name	file-issue
description	File a bug report or feature request for the odd-pipeline itself, with auto-gathered context from the current project and session. Use when the user says "/file-issue", "file a bug", "report an issue", "this is a pipeline problem", or encounters a pipeline defect during daily use.

File Issue

Gathers context from the current project and session to file a structured issue on the TonyWu20/odd-pipeline repository. Lowers friction for reporting pipeline defects encountered during daily use.

Trigger

/file-issue

No arguments. The skill prompts the user for issue details interactively.

Step 0: Resolve Agent Mapping

The pipeline uses pluggable agents. Determine which agent to use for context gathering:

Check CLI args: If the user's invocation includes --agent-griller=<agent-name>, use that agent. CLI args override everything.
Check AGENT_CONFIG.md: Read AGENT_CONFIG.md from the project root. If it exists, parse **griller:** <agent-name>. Apply if not already set by CLI args.
Apply default: If still unset, griller defaults to general-purpose.
Build resolved mapping: Record which agent will be used for griller.

Throughout this skill, whenever a subagent is launched, use the resolved agent name.

Process

Step 1: Gather Context (Subagent)

Launch the griller subagent (resolved in Step 0) to collect relevant context:

Agent: {griller} (subagent, discardable context)

Task: Gather context for a pipeline issue report.

Collect the following:
Current pipeline state:
ls skills/*/SKILL.md 2>/dev/null
Pipeline version:
git log --oneline -5
Current project context (from the working directory where the issue was encountered):
pwd
git remote -v 2>/dev/null
git log --oneline -3 2>/dev/null
Output the gathered context as structured data for the issue template.

Step 2: Build Issue Template

Format the issue using the GitHub issue template:

---
title: "[pipeline]: <short description>"
---

## Description

{User's description of the problem or feature request}

## Context

- **Pipeline version**: {commit hash from git log}
- **Project**: {current project URL or path}
- **Session**: {what skills were being used when the issue occurred}

## Reproduction Steps

{User-provided or auto-detected steps}

## Expected vs Actual

- **Expected**: {what should happen}
- **Actual**: {what actually happened}

## Environment

- **Pipeline branch**: {current branch}
- **OS**: {auto-detected}
- **Claude Code version**: {if available}

## Relevant Artifacts

{Paths to relevant plan files, directions.json, execution reports, etc.}

Step 3: User Review

Present the formatted issue to the user for review and editing:

"Here's the draft issue for TonyWu20/odd-pipeline:

{ISSUE_BODY}

Please review and edit the description above, then confirm to file the issue. Type 'confirm' to file, or provide changes."

Step 4: File the Issue

Once the user confirms, file the issue:

gh issue create --repo TonyWu20/odd-pipeline --title "<title>" --body "<body>"

Report the resulting issue URL to the user.

Boundaries

Will:

Auto-gather context from the current project and pipeline state
Format a structured issue using the project's template
Let the user review and edit before filing
File via gh CLI

Will not:

File issues without user review
Modify any project files
Include sensitive information (API keys, tokens) in the issue