Menu
Session start guide: explains how to use superharness skills and conventions. Injected by SessionStart hook.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Superharness brainstorming skill. You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Main entry point: end-to-end workflow for building features. Use /superharness:go 'requirement' to start. Orchestrates brainstorm โ plan โ TDD implementation โ review โ QA.
Infrastructure skill: start a local visualization server that renders Mermaid diagrams in the browser. Write .mmd files with pure Mermaid code, the browser updates in real-time via WebSocket (no page reload). Used by brainstorm, writing-plans, and other skills.
Surface unresolved decisions in a development request and ask the user before implementing. Use when starting a non-trivial dev task whose requirements leave open questions that would change the implementation (scope, data shape, UX behavior, compatibility), or when the user asks to confirm first ("ๅ ็กฎ่ฎคไธไธ", "ๆไธๆธ ๆฅ็ๅ ้ฎ").
Discover an existing project's conventions from real evidence and write them as the project spec: AGENTS.md + CLAUDE.md as the thin always-loaded entry, with detail under .superharness/spec/. Use when a project lacks AGENTS.md/CLAUDE.md, when asked to generate conventions ("็ๆ่ง่", "discover conventions"), or when the spec is stale.
| name | using-superharness-lite |
| description | Session start guide: explains how to use superharness skills and conventions. Injected by SessionStart hook. |
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
These skills override default system prompt behavior, but user instructions always take precedence:
These skills auto-trigger by their description โ invoke them via the Skill tool when the situation matches.
| Skill | When to Use |
|---|---|
sh-clarify | Starting a non-trivial dev task whose requirements leave open questions (scope, data shape, UX, compatibility) that would change the implementation โ resolve them BEFORE coding. |
sh-discover | The project lacks AGENTS.md/CLAUDE.md, or the spec is stale โ scan the codebase from real evidence and write the project spec. |
sh-learn | Persist durable learnings (user corrections, pitfalls and fixes, decisions not visible in code) into the project knowledge wiki. |
sh-test | After ALL development on a task is complete โ one terminal pass: Spec Review โ Code Review โ test suite. Not per change. |
Invoke relevant or requested skills BEFORE any response or action. Even a 1% chance a skill might apply means you should invoke it to check. If an invoked skill turns out wrong for the situation, you don't need to use it.
When multiple skills could apply, use this order:
sh-clarify resolves undecided requirements before any code is written.sh-discover establishes the spec when the project has none or it has drifted.sh-test is the terminal gate after all development is done.sh-learn captures anything durable worth remembering."Let's build X" โ clarify undecided requirements first, then implement. "Fix this bug" โ investigate root cause first, then fix, then the terminal test pass.
Whether a change needs tests is your judgment, scaled to its complexity and risk. Trivial edits can skip it. When a change does warrant coverage, add real tests to the project's existing test framework โ committed and long-lived, so they keep guarding the behavior โ not throwaway scripts you run once and delete. sh-test is the terminal review-and-test pass once all development on the task is done.
Rigid (sh-test): Follow exactly. Don't adapt away discipline.
Flexible (sh-clarify, sh-discover): Adapt principles to context.
The skill itself tells you which.
These thoughts mean STOP โ you're rationalizing:
| Thought | Reality |
|---|---|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I'll clarify after I start coding" | Clarification comes BEFORE implementation, not after. |
| "Tests can wait" | Finishing a task means a clean terminal review-and-test pass. |
| "Nothing worth learning here" | Maybe โ but let sh-learn decide; don't skip the check. |
| "I already know this skill" | Skills evolve. Read the current version. |
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip the workflow.
Project-specific conventions live as a spec, with AGENTS.md + CLAUDE.md as the thin always-loaded entry and detail under .superharness/spec/ (read on demand). The sh-discover skill generates and refreshes them from real evidence in the codebase.
Read the relevant spec files before starting work on any task.
Learnings accumulate in .superharness/learnings/, organized as a topic wiki. INDEX.md is the catalog and the only file loaded into future sessions. Read a linked learning file before relying on it; persist new ones with the sh-learn skill.