public-content
Skill0 starsChanged 29 days agoApache-2.0View on GitHub
Content guidelines and restrictions for public repository artifacts -- what to avoid when writing issues, PRs, design docs, and code comments in public repos.
In this repository23 other files it gives its agents.
The file
Show its rules and text
We split this skill into the rules it gives an agent
19 rules. About 0 are common, 19 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈19
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Write for external contributors who lack organizational context
- Distinctive: line 27
Avoid competitor names, especially in negative contexts
- Distinctive: line 29
Only reference issues, PRs, and designs in public repos
- Distinctive: line 30
Only link to public resources (no private repo links)
- Distinctive: line 31
Keep language professional and welcoming
- Distinctive: line 32
No internal tooling references: Never mention organization-internal workflows, proprietary tooling, or development processes that external …
- Distinctive: line 38
Avoid competitor names in negative contexts
- Distinctive: line 41
Write for readers without organizational context
- Distinctive: line 42
Only reference issues/designs in public repos
- Distinctive: line 48
Write for external contributors who lack context
- Distinctive: line 50
Only reference issues in public repos
- Distinctive: line 51
Never reference organization-internal workflows or proprietary tooling
- Distinctive: line 55
No internal references or competitor mentions
- Distinctive: line 56
Write for external reviewers who lack organizational context
- Distinctive: line 57
Commit messages should be self-contained and clear
- Distinctive: line 58
Keep tone professional and welcoming to contributors
- Distinctive: line 59
Only reference issues/PRs in public repos
- Distinctive: line 64
No references to internal systems or discussions
- Distinctive: line 65
Keep comments professional and helpful
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
!${CLAUDE_PLUGIN_ROOT}/scripts/skill-preflight.sh public-content 2>&1 || true
Public Repository Content Guidelines
You are creating content for a public repository. Public repos are visible to anyone, so content must not leak competitive intelligence, internal strategy, or references to resources external readers can't access.
General Principles
- Write for external contributors who lack organizational context
- Clear explanations without assuming internal knowledge
- Professional but approachable tone
- Explain "why" for non-obvious decisions
- Be helpful to first-time contributors
Restrictions
- Focus on user value and technical merit
- Avoid competitor names, especially in negative contexts
- Omit internal business strategy and rationale
- Only reference issues, PRs, and designs in public repos
- Only link to public resources (no private repo links)
- Keep language professional and welcoming
- No internal tooling references: Never mention organization-internal workflows, proprietary tooling, or development processes that external contributors don't have access to
By Artifact Type
Design Documents
- Focus on technical merit and user value
- Avoid competitor names in negative contexts
- Omit internal business strategy references
- Polish language for external consumption
- Write for readers without organizational context
- Only reference issues/designs in public repos
Issues
- Focus on user value and technical merit
- Avoid competitor names in negative contexts
- Omit internal business strategy
- Write for external contributors who lack context
- Keep language professional and welcoming
- Only reference issues in public repos
- Never reference organization-internal workflows or proprietary tooling
Pull Requests
- PR body should focus on what changed and why it benefits users
- No internal references or competitor mentions
- Write for external reviewers who lack organizational context
- Commit messages should be self-contained and clear
- Keep tone professional and welcoming to contributors
- Only reference issues/PRs in public repos
Code Comments
- Code comments should be clear for OSS contributors
- Explain "why" not just "what" for non-obvious code
- No references to internal systems or discussions
- Keep comments professional and helpful
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.