From open-source
Open-source issue creation: bug reports, feature requests, and structured contribution communication. Invoke whenever task involves any interaction with issues in external repositories — filing bugs, proposing features, reporting problems, or preparing issue content for open-source projects.
npx claudepluginhub xobotyi/cc-foundry --plugin open-sourceThis skill uses the workspace's default tool permissions.
**Every issue you file costs maintainer time. Earn that time with evidence, not prose.**
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Every issue you file costs maintainer time. Earn that time with evidence, not prose.
Open-source maintainers are volunteers. A single low-quality issue engages 3-4 people for up to 3 hours each. AI- generated "slop" — vague, unverified, polished-but-empty reports — has driven projects to shut down bug bounties, ban reporters, and implement strict contribution policies. You are an AI agent. You are the exact actor these policies target. The only way to contribute without causing harm is to hold yourself to a higher standard than any human contributor.
${CLAUDE_SKILL_DIR}/references/bug-report-structure.md Title formulas, body template, MRE
construction, regression info, supporting evidence guidelines${CLAUDE_SKILL_DIR}/references/feature-request-structure.md Problem-first framing,
proposed solution, alternatives, research on what drives developer engagement${CLAUDE_SKILL_DIR}/references/anti-slop.md How maintainers detect AI slop, stylistic and
structural markers, project policies against AI contributions, verification checklistBefore writing a single word of an issue, complete every step. No exceptions.
CONTRIBUTING.md (check root, docs/, and .github/ directories).github/ISSUE_TEMPLATE/ — if templates exist, you must use themCODE_OF_CONDUCT.md if presentSearch the project's issue tracker for both open and closed issues. Use multiple search terms — the same problem is often described differently by different people.
# GitHub CLI duplicate search
gh issue list -R owner/repo --search "keyword" --state all --limit 30
If you find a related issue:
Collect concrete evidence before writing:
Follow the project's issue template if one exists. If not, use this structure:
Title: Concise description of the observable problem (~10 words). Describe what breaks, not what you think the cause is.
--output json flag produces invalid JSON when input contains unicode"Body:
For detailed structural guidance, read the bug report reference.
Title: Describe the desired capability, not a vague wish.
Body:
For detailed structural guidance and research on what drives developer engagement, read the feature request reference.
Before submitting, every item must pass. This is not optional.
Factual accuracy:
Completeness:
Anti-slop:
Do not create the issue until the user explicitly approves it. After completing the verification gate, present the
full draft to the user — title, body, labels, and target repository. Wait for explicit approval before executing the
gh issue create command or any equivalent action. The user may request changes, and you iterate until approved.
This gate exists because issues are public, permanent, and affect real maintainers. An agent creating issues without human review is the exact behavior that erodes maintainer trust.
When creating issues via gh:
# Create with template (preferred — respects project conventions)
gh issue create -R owner/repo --template "bug_report.md"
# Create with explicit fields
gh issue create -R owner/repo \
--title "concise problem description" \
--body "structured body content" \
--label "bug"
# Create from a file (for longer issues)
gh issue create -R owner/repo \
--title "concise problem description" \
--body-file issue-body.md
Use --template when the project has issue templates. This ensures you provide the information the maintainers expect
in the structure they expect. Some projects use YAML-based issue forms (.github/ISSUE_TEMPLATE/*.yml) which enforce
structured fields — when these exist, fill every required field.
List available templates:
# List issue templates via GitHub API
gh api repos/OWNER/REPO/contents/.github/ISSUE_TEMPLATE --jq '.[].name' 2>/dev/null
# Or browse the repository directory directly
gh browse -R OWNER/REPO -- .github/ISSUE_TEMPLATE
Scenario: You discovered that a CLI tool's --format json flag outputs invalid JSON when a field contains a newline
character.
Preparation:
echo -e "line1\nline2" | tool --format json → output contains unescaped newline in JSON string.Title: --format json produces invalid JSON when field values contain newlines
Body:
**Version:** v2.4.1 on macOS 14.5 (Apple Silicon)
**Description**
The `--format json` flag produces output with unescaped newline characters inside
JSON string values, resulting in invalid JSON that breaks downstream parsers.
**Steps to reproduce**
1. Install tool v2.4.1
2. Create input: `echo -e "line1\nline2" > test.txt`
3. Run: `tool process test.txt --format json`
4. Pipe output to a JSON validator: `tool process test.txt --format json | jq .`
**Expected result**
Valid JSON with newlines escaped as `\n` inside string values.
**Actual result**
jq exits with error: `parse error (Invalid string) at line 3, column 0`.
Raw output contains a literal newline inside the JSON string value.
**Minimal reproducible example**
[attached as gist: link]