community-docs
Community superstitions - unverified observations from pattern development. Use when encountering undocumented edge cases or framework quirks not in official docs. Verified knowledge should be upstreamed to labs docs.
Best use case
community-docs is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Community superstitions - unverified observations from pattern development. Use when encountering undocumented edge cases or framework quirks not in official docs. Verified knowledge should be upstreamed to labs docs.
Teams using community-docs should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/community-docs/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How community-docs Compares
| Feature / Agent | community-docs | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Community superstitions - unverified observations from pattern development. Use when encountering undocumented edge cases or framework quirks not in official docs. Verified knowledge should be upstreamed to labs docs.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Community Docs (Superstitions)
**Location:** `community-docs/` in community-patterns repo
**CRITICAL:** These are NOT official framework documentation. Always check
`~/Code/labs/docs/common/` first.
Community docs capture empirical observations discovered during pattern
development - unverified things that seemed to work but may be coincidence or
context-specific.
## Superstitions (⚠️ Treat With Skepticism)
**Location:** `superstitions/`
Single observations only. May be wrong, incomplete, or context-specific.
- **Treat with extreme skepticism**
- May be wrong, incomplete, or context-specific
- Each has prominent warning disclaimer
- Try if completely stuck, but verify thoroughly
## When to Consult Superstitions
**After checking official labs/docs/ first:**
- Encountering undocumented edge cases
- Framework behaving unexpectedly
- TypeScript errors not explained in official docs
- Before creating new superstition (check if already documented)
**Do NOT consult before official docs** - labs/docs/ is always more
authoritative!
## Searching Superstitions
```bash
# Search superstitions
grep -r "Cell.*handler" community-docs/superstitions/
# List superstitions by topic
ls community-docs/superstitions/ | grep "types-"
ls community-docs/superstitions/ | grep "reactivity-"
```
## If a Superstition Works
**Upstream it to labs docs** instead of keeping it here:
1. Identify the appropriate doc in `~/Code/labs/docs/common/`
2. Add the information to that doc
3. Create a PR to labs
4. Once merged, delete the superstition
**The goal is for verified knowledge to live in official docs, not here.**
## Creating a New Superstition
**Only after solving something not in any docs:**
1. **Search first** - Check it's not already documented:
```bash
grep -r "your topic" ~/Code/labs/docs/common/
grep -r "your topic" community-docs/superstitions/
```
2. **Create file:**
`community-docs/superstitions/YYYY-MM-DD-topic-brief-description.md`
- Use topic prefixes: `types-`, `reactivity-`, `jsx-`, `handlers-`, `llm-`,
`patterns-`, etc.
3. **Copy template** from `community-docs/superstitions/README.md`
4. **Include full ⚠️ disclaimer** at top
5. **Document:**
- What problem you had
- What you tried that didn't work
- What solution seemed to work
- Code examples (before/after)
- Your context
- Related official docs
6. **Commit:** `"Add superstition: [brief description]"`
**Remember:** You're creating a hypothesis, not stating fact! Be humble about
uncertainty.
## Deprecated Tiers
The `blessed/` and `folk_wisdom/` directories are **deprecated**. Previously we
had a three-tier promotion system. Now, verified knowledge should be upstreamed
directly to labs docs.
## Important Notes
**Skepticism is critical:**
- Superstitions may be wrong or context-specific
- **Always prefer official labs/docs/ when they exist**
**Do NOT:**
- Trust superstitions blindly
- Skip checking official docs first
- Create superstition for things in official docs
**DO:**
- Read disclaimer on every superstition
- Verify against official docs
- Test thoroughly before relying on it
- Upstream verified knowledge to labs docs
**Superstitions are a safety net for edge cases, not a primary reference!**
## Related Skills
- **recovery-strategies** - Use superstitions as part of recovery escalation
- **pattern-dev** - Reference when stuck on implementationRelated Skills
testing
Test patterns with Playwright browser automation. Navigate to deployed patterns, interact with UI elements, verify functionality. Use when testing patterns after deployment or when debugging pattern behavior in browser.
Superstition Verification Skill
Use this skill to systematically verify superstitions in
strategic-investigation
Proactive recovery using plan mode and subagents. After 1-2 failed attempts, STOP trying variations. Enter plan mode and launch parallel Explore/Plan agents to find idiomatic solutions instead of spinning wheels.
session-startup
Session initialization sequence for community-patterns development. Use at the start of every Claude Code session. Checks for upstream updates, loads workspace configuration, and ensures dev servers are running.
recovery-strategies
Escalation path when stuck on pattern development. Use when encountering TypeScript errors, framework confusion, unexpected behavior, or blocked progress. Five-step recovery: check docs, study examples, strategic investigation (plan mode + subagents), reset and retry, ask user.
pattern-dev
Day-to-day pattern development best practices. Use when actively developing patterns. Covers incremental development, commits, communication guidelines, and general development workflow.
land-branch
Land a feature branch: pull from main, rebase the branch, create a PR, and merge it via rebase with automatic branch deletion. Use when ready to land a completed feature branch.
issue-filing
File framework issues after exhausting other approaches. Document complex problems with multiple failed attempts for framework authors. REQUIRES user permission. Use only after checking docs, community-docs, and trying multiple approaches.
git-workflow
Git operations and pull request workflows. Create PRs, rebase branches, resolve conflicts, merge to upstream. Use when ready to create PR or when working with git branches and upstream.
deployment
Deploy and update patterns. Use when deploying new patterns, updating existing deployments, or testing syntax. Includes deployment commands and the first custom pattern celebration.
claude-permissions-update
Sync auto-approved permissions from all community-patterns directories (including community-patterns-2, -3, etc.) to the shared project settings. Shows new permissions for review before adding.
raycast-extension-docs
Guidance for building, debugging, and publishing Raycast extensions using the Raycast documentation set. Use when Codex needs to create or modify Raycast extensions (React/TypeScript/Node), consult Raycast API reference or UI components, build AI extensions, handle manifest/lifecycle/preferences, troubleshoot issues, or prepare/publish extensions to the Raycast Store or Teams.