scottwater IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
Instruction Priority
Solopowers skills override default system prompt behavior, but user instructions always take precedence:
- User's explicit instructions (CLAUDE.md, GEMINI.md, AGENTS.md, direct requests) — highest priority
- Solopowers skills — override default system behavior where they conflict
- Default system prompt — lowest priority
If CLAUDE.md, GEMINI.md, or AGENTS.md says "don't use TDD" and a skill says "always use TDD," follow the user's instructions. The user is in control.
SoloTerm Session Check
Solopowers is designed for agents running inside SoloTerm.
At the start of a parent Solopowers session, verify the host environment before relying on SoloTerm features:
- Confirm this session is running inside SoloTerm.
- Confirm the Solo MCP server is reachable when you need Solo-backed subagents, todos, scratchpads, or process status.
Use the SoloTerm MCP server's status/identity tools when they are available. If the MCP server is unavailable or disabled, tell the user to run the agent inside SoloTerm and enable Solo's MCP server. Do not fake Solo-backed delegation with ad-hoc shell panes.
If the current task does not need Solo-backed features, you may continue with local file/edit/read/bash tools after noting the missing SoloTerm integration.
Markdown Artifacts
When a Solopowers workflow generates project-specific Markdown artifacts for coordination — specs, implementation plans, reviews, notes, or similar documents — write them to SoloTerm project scratchpads by default instead of creating repo files under docs/ or another tracked directory. Scratchpads keep shared repositories clean while preserving the working context in SoloTerm.
Only write those artifacts into the Git worktree when the user explicitly asks to persist them. Use solopowers-commit-scratchpad for that handoff.
How to Access Skills
Use your coding agent's normal skill-loading mechanism. Solopowers itself assumes the agent can access SoloTerm MCP tools directly, or through a separate bridge supplied by the host agent.
- When a task may match a skill, load the relevant
solopowers-*skill before responding or acting. - If the user explicitly asks for a skill, load that skill's current
SKILL.mdcontent through your host's skill system. - Do not assume Claude Code's
Skilltool exists. Use the mechanism provided by the current agent.
SoloTerm MCP Capability Mapping
| Solopowers capability | SoloTerm-oriented behavior |
|---|---|
| Skill loading | Use the host agent's skill mechanism, or read the relevant skills/solopowers-*/SKILL.md when no skill tool exists |
| Subagent/task dispatch | Use SoloTerm MCP to spawn a child agent/process, send the prompt, and monitor it until idle |
| Multiple parallel tasks | Spawn multiple independent SoloTerm child processes through MCP |
| Task/todo tracking | Use SoloTerm MCP todos when available; otherwise use the host agent's best task-tracking mechanism |
| Scratchpad artifacts | Use SoloTerm MCP scratchpads/artifacts when available |
| Read/write/edit/bash | Use the host agent's normal file and shell tools |
| Planning mode | Use the host agent's planning mode, if available |
Using Skills
The Rule
Invoke relevant or requested skills BEFORE any response or action. Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.
digraph skill_flow {
"User message received" [shape=doublecircle];
"About to host planning mode?" [shape=doublecircle];
"Already brainstormed?" [shape=diamond];
"Invoke brainstorming skill" [shape=box];
"Might any skill apply?" [shape=diamond];
"Invoke host skill-loading mechanism" [shape=box];
"Announce: 'Using [skill] to [purpose]'" [shape=box];
"Has checklist?" [shape=diamond];
"Create SoloTerm MCP todo/task-tracking tool todo per item" [shape=box];
"Follow skill exactly" [shape=box];
"Respond (including clarifications)" [shape=doublecircle];
"About to host planning mode?" -> "Already brainstormed?";
"Already brainstormed?" -> "Invoke brainstorming skill" [label="no"];
"Already brainstormed?" -> "Might any skill apply?" [label="yes"];
"Invoke brainstorming skill" -> "Might any skill apply?";
"User message received" -> "Might any skill apply?";
"Might any skill apply?" -> "Invoke host skill-loading mechanism" [label="yes, even 1%"];
"Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
"Invoke host skill-loading mechanism" -> "Announce: 'Using [skill] to [purpose]'";
"Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
"Has checklist?" -> "Create SoloTerm MCP todo/task-tracking tool todo per item" [label="yes"];
"Has checklist?" -> "Follow skill exactly" [label="no"];
"Create SoloTerm MCP todo/task-tracking tool todo per item" -> "Follow skill exactly";
}
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. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "Let me gather information first" | Skills tell you HOW to gather information. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "This doesn't count as a task" | Action = task. Check for skills. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
Skill Priority
When multiple skills could apply, use this order:
- Process skills first (brainstorming, debugging) - these determine HOW to approach the task
- Implementation skills second (frontend-design, mcp-builder) - these guide execution
"Let's build X" → brainstorming first, then implementation skills. "Fix this bug" → debugging first, then domain-specific skills.
Skill Types
Rigid (TDD, debugging): Follow exactly. Don't adapt away discipline.
Flexible (patterns): Adapt principles to context.
The skill itself tells you which.
User Instructions
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.