| name | using-bearpaws |
| description | Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions |
If you were dispatched as a subagent to execute a specific task, skip this skill.
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill. IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
Skill discovery and invocation. Bearpaws skills override default system behavior where they conflict, but **user instructions always take precedence**: user > skill > default system prompt.
Use at the start of every conversation, before any response.
Use before clarifying questions — skill check comes first.
Use before exploring the codebase — skills tell you HOW to explore.
**In Claude Code:** Use the `Skill` tool. When you invoke a skill, its content loads — follow it directly. Never `Read` skill files.
**In Devin for Terminal / Windsurf Cascade:** Use the `skill` tool (slash command `/skill-name`). Skills live in `.devin/skills/` or `.windsurf/skills/`.
**In Gemini CLI:** Skills activate via `activate_skill`. Gemini loads metadata at session start, full content on demand.
Even a 1% chance a skill might apply means invoke the skill to check.
If an invoked skill turns out to be wrong for the situation, you don't need to use it.
Red Flags
These thoughts mean STOP — you're rationalizing:
| Thought | Reality |
|---|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "Let me gather information first" | Skills tell you HOW to gather information. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This doesn't count as a task" | Action = task. Check for skills. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
Lazy-load contract
Inside a loaded skill, <see file="..."> and <include ref="..."> are advisory pointers, not directives. Read the target only if the current task explicitly needs it. Never auto-Read them at skill load time.
Skill priority
When multiple skills apply, the order is:
bp:onboarding-to-a-project — first, whenever there's an existing project context. Identify the key files and stack from manifests, READMEs, and a sample of similar files. Skip only for purely abstract design discussion with no codebase ("how would I architect a system that does X?" with no project named).bp:brainstorming — next, for any creative/design work. Brainstorming designs against the conventions you discovered in onboarding, not against your training-data prior.- Other process skills (writing-plans, TDD, debugging, code review, verification) — stack-agnostic, apply during implementation.
Onboarding tells you the project's specific conventions; brainstorming reconciles them with the work to be done before code is written. Onboarding → brainstorming → implementation is the standard flow.
Brevity Policy
When no process skill governs the current output, prefer concise, low-commentary responses.
Default behavior:
- Answer directly.
- Do not restate the prompt.
- Skip preamble and post-hoc summaries unless asked.
- Prefer actionable output over commentary.
- For routine progress updates, use one line; expand only when something unexpected happens.
- Ask at most one clarification question when blocked.
Skill precedence:
- Active process skills define their own verbosity expectations.
- If a skill requires detailed plans, verification, debugging analysis, or acceptance criteria, follow the skill.
- Do not shorten outputs in ways that reduce correctness, safety, or usefulness.
Never compress:
- safety-critical warnings
- migration risks
- acceptance criteria
- code review findings needed to prevent defects
- test failures and error output
- verification results
Skill types
Rigid (TDD, debugging) — follow exactly. Flexible (patterns) — adapt to context. The skill itself tells you which.
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.
