private-content
Skill0 starsChanged 29 days agoApache-2.0View on GitHub
Content guidelines for private repository artifacts -- what's allowed when writing issues, PRs, design docs, and code comments in private repos.
In this repository23 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
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 team members who understand the project context
- Distinctive: line 21
Document "why" decisions were made, not just "what"
- Distinctive: line 24
Document abandoned approaches for historical context
- Distinctive: line 30
Document internal stakeholder discussions and decisions
- Distinctive: line 46
Commit messages can include internal context
≈ “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 private-content 2>&1 || true
Private Repository Content Guidelines
You are creating content for a private repository. Private repos aren't visible externally, so content can freely include competitive analysis, internal strategy, and links to private resources.
General Principles
- Write for team members who understand the project context
- Internal shorthand and references are acceptable
- Focus on decision rationale and trade-offs
- Document "why" decisions were made, not just "what"
- Link to private repos and internal resources
- Include pre-announcement feature discussions
- Document abandoned approaches for historical context
By Artifact Type
Design Documents
- Include competitor analysis with names and direct comparisons
- Document internal stakeholder discussions and decisions
- Include exploratory thinking and ideas that may not pan out
- Reference internal business rationale for decisions
- Reference designs/issues in any repo
Issues
- Mention competitors by name in analysis
- Include internal business rationale
- Reference exploratory ideas that may not pan out
- Assume reader knows internal context
- Reference issues in any repo (private or public)
Pull Requests
- PR body can include internal rationale and context
- Reference competitor analysis or internal discussions
- Mention exploratory approaches considered
- Commit messages can include internal context
- Reference issues/PRs in any repo
Code Comments
- Code comments can assume team knowledge
- Reference internal decisions or rationale
- TODOs can mention internal tracking systems
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.