Dx Harness
pproenca/dot-skills
Developer-experience friction auditing and fixing — slow onboarding, repeated manual setup steps, missing bootstrap/reset/seed scripts, undiscoverable conventions.
Claude Code infrastructure + agent team setup — rules, hooks, memory, routing, and agent installation from a guided interview.
$ npx skills add AlexZio00/sovereign-skills --skill setup -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install AlexZio00/sovereign-skills setup --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/AlexZio00/sovereign-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/setup .claude/skills/setup && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "setup" agent skill from https://github.com/AlexZio00/sovereign-skills/tree/master/setup into .claude/skills/setup/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "setup", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/AlexZio00/sovereign-skills/tree/master/setupType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add AlexZio00/sovereign-skills --skill setup -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install AlexZio00/sovereign-skills setup --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/AlexZio00/sovereign-skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/setup .agents/skills/setup && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "setup" agent skill from https://github.com/AlexZio00/sovereign-skills/tree/master/setup into .agents/skills/setup/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "setup", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add AlexZio00/sovereign-skills --skill setup -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install AlexZio00/sovereign-skills setup --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/AlexZio00/sovereign-skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/setup .cursor/skills/setup && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "setup" agent skill from https://github.com/AlexZio00/sovereign-skills/tree/master/setup into .cursor/skills/setup/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "setup", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/AlexZio00/sovereign-skills.git --path setup--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add AlexZio00/sovereign-skills --skill setup -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install AlexZio00/sovereign-skills setup --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/AlexZio00/sovereign-skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/setup .gemini/skills/setup && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "setup" agent skill from https://github.com/AlexZio00/sovereign-skills/tree/master/setup into .gemini/skills/setup/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "setup", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install AlexZio00/sovereign-skills setupInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add AlexZio00/sovereign-skills --skill setup -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/AlexZio00/sovereign-skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/setup .github/skills/setup && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "setup" agent skill from https://github.com/AlexZio00/sovereign-skills/tree/master/setup into .github/skills/setup/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "setup", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add AlexZio00/sovereign-skills --skill setup -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install AlexZio00/sovereign-skills setup --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/AlexZio00/sovereign-skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/setup .opencode/skills/setup && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "setup" agent skill from https://github.com/AlexZio00/sovereign-skills/tree/master/setup into .opencode/skills/setup/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "setup", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
setupClaude Code infrastructure + agent team setup — rules, hooks, memory, routing, and agent installation from a guided interview.
Setup is an agent skill from AlexZio00/sovereign-skills. Claude Code infrastructure + agent team setup — rules, hooks, memory, routing, and agent installation from a guided interview. Combines infrastructure + agent team into one flow. Not project scaffolding (CLAUDE.md/ROADMAP/.gitignore/.env.example) — use project-init for that. Triggers: /setup, setup, harness setup, agent team setup.
Its SKILL.md is about 9.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files (for example `.claude-plugin/plugin.json` and `agents/openai.yaml`).
It sits in Development, covering Project scaffolding and Agent instruction files. The repository describes itself as: 20 production-grade skills for AI coding agents — setup, scope, discipline, code review, security, session management, governance, ops, and quality audits (eval-leakage… The licence is MIT.
7 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit d814a3a. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
No scripts in the folder and no shell commands in SKILL.md (its code samples are yaml, markdown, python and json).
From the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Setup loads about 9.2k tokens when it runs. Until then it costs about 85 tokens; SKILL.md has 2,555 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from AlexZio00/sovereign-skills at commit d814a3a, republished under its MIT licence (© AlexZio00). 2,555 words, ~9,180 tokens.
.claude/skills/setup/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.Does the initialized harness work immediately? — rules/hooks/memory/routing must be applied from the first session after installation. If "installed but not working" occurs, that is failure.
Set up the full Claude Code harness layer — rules, hooks, memory, agent routing.
Not project scaffolding (use /project-init for that). This is the AI orchestration layer.
Key difference from generic templates: domain presets provide pre-filled rules with real content, not empty skeletons. Every harness includes reject-by-default and violation testing.
Dominant variable: Do the generated project rules' Tier 0 rules pass violation testing? — Rules without tests are decoration. Discard if: A complete harness already exists and only a single rule addition is needed — edit that rule file directly.
/setup~/.claude/ directory — If broken: guide on permissions.Check each target file before generating:
| File | If exists |
|---|---|
.claude/rules/project-rules.md | Glob .claude/rules/*.md first — Tier-0 rules may already live in a differently-named file in this project (e.g. security-rules.md, style-conventions.md). If a match already covers Tier-0 scope, offer to merge into that existing file instead of creating project-rules.md; otherwise Read project-rules.md if it exists and offer: update (extend) or replace. Default: update. |
~/.claude/rules/agents.md | Read it. Merge new agent definitions, never replace existing ones. |
~/.claude/rules/output-style.md | Read it. Offer: update or replace. |
~/.claude/settings.json (hooks) | Always merge — append to existing arrays, never overwrite. |
memory/MEMORY.md | Read it. Append new sections, preserve existing entries. |
tasks/lessons.md | If exists → read it. Contains AI behavior correction rules from past sessions. |
Merge algorithm for hooks (settings.json):
1. Read existing settings.json
2. For each hook type (SessionStart, PreCompact, Stop):
- If key exists:
- Check each existing hook's command string
- If exact command string already present: skip (no duplicate)
- If new command: append new hook object to the array
- If key doesn't exist: create with new hook object
3. Write merged result backNever replace the entire hooks object. Never delete existing hook entries.
Check if CLAUDE.md exists in the project root.
/project-init first, but don't blockHard Rules conflict check (if both CLAUDE.md and .claude/rules/project-rules.md exist):
.claude/rules/project-rules.md.claude/rules/project-rules.md → propose adding them there.claude/rules/project-rules.md → flag: "CLAUDE.md has a weaker version, remove it"Hard Rules → see .claude/rules/project-rules.md, actual rules live only in .claude/rules/project-rules.md~/.claude/rules/*.md and any project CLAUDE.md/.claude/rules/*.md for a rules file that already covers truth-tagging (a Fact/Claim/Disclosure-style discipline for labeling verified vs. asserted vs. speculative content) and voice/prohibited-patterns conventions.Check if ~/.claude/ global structure exists.
What kind of system are you building?
1. Trading / Finance — no-action default, no fabrication, paper-only
2. Web Application — secrets protection, input validation, auth-first
3. CLI Tool / Automation — idempotent operations, dry-run default
4. Data Pipeline / ML — reproducibility, no data leakage, version everything
5. General — start minimal, add rules as needed
6. Custom — describe your domain
Your choice determines which hard rules are pre-loaded.
You can add, modify, or remove any of them afterward.After Q1, load the matching preset (see Presets section below). Show the user what's pre-loaded and ask: "Anything to add, change, or remove?"
How complex is your AI agent setup?
- Minimal: rules + memory only. No agent routing.
→ Generates: rules/, memory/, hooks. Done.
- Standard: review agents (code review, testing, verification).
→ Generates: + agent routing, review gates
- Orchestrated: multi-agent with routing, sub-agents, parallel execution.
→ Generates: + agent definitions, tier priorities, keyword triggers, scope boundariesIf Q2 = Minimal → skip Q3. Go to Phase 2. If Q2 = Standard → ask Q3 simplified. If Q2 = Orchestrated → ask Q3 full.
Standard version:
Which review steps before code ships?
- Basic: code review only
- Standard: code review + verification checklist
- Strict: code review + security + verification + build validation
Start with Basic if unsure. Add more after your first production incident.Orchestrated version (two questions):
Q3a — Gate selection:
Which review gates do you want? (check all that apply)
code-reviewer — finds issues, severity scoring, never fixes directly
security-reviewer — secrets exposure, injection, OWASP Top 10
verification — mandatory checklist before declaring "done"
build-error-resolver — fixes build/type errors only, no refactoring
database-reviewer — SQL injection, missing indexes, N+1 queriesQ3b — Per-gate config (ask separately for each selected gate):
For [gate-name]:
- When does it trigger? (every commit? before push? before merge?)
- What should it catch specifically for your project?
- Blocking (nothing ships until fixed) or advisory (flag and continue)?Agent existence check (before generating agents.md):
Scan BOTH ~/.claude/agents/ (global) AND .claude/agents/ (project-level) for each selected agent. If missing in both:
"[agent-name] agent file not found in ~/.claude/agents/.
Registering routing in agents.md alone will not work.
Generate the agent file too?"→ Yes: generate the agent definition file → No: add a comment in agents.md noting the agent is registered but not installed
How should context persist between sessions?
- Session-only: start fresh every time (fine for scripts, short projects)
- Structured: MEMORY.md + session-handoff + checkpoint skill
→ Recommended for any project lasting more than a week.
If structured: Do you want auto-checkpoint hooks?
(Reminds you to save state before /compact and on session exit)The preset loaded these Tier 0 rules: [list from preset]
Three questions:
1. Anything missing that should NEVER be violated?
2. Communication language preferences?
(e.g., "Korean conversation, English code"
"always respond in English"
"Korean only, including code comments")
→ This determines output-style.md content.
3. Any workflow preferences?
(e.g., "commit only when I say so",
"concise responses, no filler",
"always run tests before declaring done")tier_0_immutable:
- "reject-by-default: missing required field → REJECT. No guessing, no interpolation."
- "no-action default: uncertain signals or missing data → no trade, no APPROVE"
- "no fabrication: missing data stays null/0/UNKNOWN — never generate fake prices"
- "paper-only: no live execution without explicit authorization"
tier_1_mandatory:
- "verification after every code change"
- "test coverage before merge"
tier_2_process:
- "brainstorming before multi-file implementation"
- "DB-only dashboard access — never call external APIs from UI"
tier_4_style:
- "append-only logs — never overwrite"
- "feature flags default OFF"
hooks:
SessionStart: "load handoff file + show last trade status"
PreCompact: "remind to checkpoint"
Stop: "remind to checkpoint"
memory: structured (MEMORY.md + session-handoff)Optional hardening (opt-in, documentation only — do not install unless the user asks): a Tier-0 "paper-only / no live execution" rule is prompt-only (L1) unless something physically blocks the matching command. Offer this PreToolUse hook template as a starting point the user can adapt to their own broker/exchange CLI patterns — do not write it to settings.json without explicit approval:
# .claude/hooks/paper_only_guard.py — OPTIONAL, opt-in, adapt patterns to the project's actual trading CLI/SDK
# Blocks Bash commands that look like a live order/execution call. Not exhaustive — pattern list must be
# reviewed against the project's real broker/exchange interface before relying on it.
import json, re, sys
LIVE_ORDER_PATTERNS = [
r"place_order", r"submit_order", r"execute_trade", r"--live\b", r"LIVE_TRADING=1",
]
def main():
data = json.load(sys.stdin)
if data.get("tool_name") != "Bash":
return
cmd = data.get("tool_input", {}).get("command", "")
if any(re.search(p, cmd, re.IGNORECASE) for p in LIVE_ORDER_PATTERNS):
reason = "paper-only Tier-0 rule: live-order pattern detected"
print(json.dumps({
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": reason,
}
}))
print(reason, file=sys.stderr)
sys.exit(2)
if __name__ == "__main__":
main()Wire it under hooks.PreToolUse in settings.json only after the user reviews and approves the pattern list for their actual project. Before wiring it in, smoke-test the script directly: pipe a synthetic PreToolUse JSON event whose command matches one of LIVE_ORDER_PATTERNS and confirm exit code 2, then pipe one that doesn't match and confirm exit code 0.
tier_0_immutable:
- "no hardcoded secrets: all credentials via environment variables"
- "no raw SQL: use parameterized queries or ORM only"
- "input validation on every user-facing endpoint"
tier_1_mandatory:
- "security review before any auth/payment code ships"
- "verification after every code change"
tier_2_process:
- "API design review before implementation"
- "migration review before schema changes"
tier_4_style:
- "feature flags default OFF"
- "error messages: user-friendly externally, detailed internally"
hooks:
SessionStart: "load handoff file"
PreCompact: "remind to checkpoint"
memory: structuredtier_0_immutable:
- "dry-run default: destructive operations require explicit --force or --confirm"
- "no silent data loss: always confirm before overwrite/delete"
- "idempotent operations: running twice produces same result"
tier_1_mandatory:
- "verification after every code change"
- "help text for every command and flag"
tier_2_process:
- "test with edge cases: empty input, missing files, permission denied"
tier_4_style:
- "exit codes: 0 success, 1 user error, 2 system error"
- "stderr for errors, stdout for output"
hooks:
SessionStart: "load handoff file"
PreCompact: "remind to checkpoint"
memory: structuredtier_0_immutable:
- "no data leakage: train/test split before any transformation"
- "no fabrication: missing values stay NaN, never impute without documentation"
- "baseline required: no model result without comparison to naive baseline"
tier_1_mandatory:
- "verification after every code change"
- "experiment logging: parameters, metrics, artifacts"
tier_2_process:
- "cross-validation before reporting metrics"
- "feature importance before adding complexity"
tier_4_style:
- "append-only experiment logs"
- "notebook cells: one purpose per cell, markdown headers"
hooks:
SessionStart: "load handoff file + show last experiment results"
PreCompact: "remind to checkpoint"
memory: structuredtier_0_immutable:
- "no fabrication: if data is missing, say so — never generate fake values"
- "no hardcoded secrets: credentials via environment variables only"
- "input validation: validate at every system boundary (user input, external APIs)"
# Only include if Q3 selected a database:
# - "no raw SQL: parameterized queries or ORM only"
tier_1_mandatory:
- "verification after every code change"
- "security review before any auth or payment code ships"
tier_2_process:
- "test before merge — never declare done without a passing test"
- "brainstorming before multi-file implementation"
tier_4_style:
- "feature flags default OFF"
- "commit only when explicitly requested"
hooks:
SessionStart: "load handoff file"
PreCompact: "remind to checkpoint"
memory: structuredExtract rules from failures — observe failures and drift during actual task execution, then derive rules from them. Phase 1 presets provide generic rules. This phase extracts project-specific rules from real failures in this codebase. opt-in: Propose when user requests "empirical"/"failure-grounded"/"run real tests first", or when a codebase already exists. Skip for new empty projects (no failure surface to observe).
If the project already exists, run core tasks and record failures:
command tried / failure details / what eventually worked. Do not modify source code (clean up test-generated files for clean test execution).WebFetch current official documentation for 3–5 core dependencies (frameworks/key libraries) — catch API patterns/conventions that differ from training data. Unset environment variables are not silent failures but recorded as findings. Do not assume from memory.
Separate from preset rules, generate only Tier-2/4 rules that are traceable to actual failures from 1.5-1/1.5-2.
<!-- from: failure {cmd} / live-doc {dep} -->.This phase extends setup from interview-only to empirical execution-based. Presets = starting point, failure-grounding = project truth.
Present the full configuration for approval:
Harness Configuration:
- Domain: [preset name]
- Complexity: [minimal / standard / orchestrated]
- Review gates: [list with trigger conditions]
- Memory: [strategy]
- Hooks: [list with actual commands]
Tier 0 Rules (immutable):
1. [each rule]
Tier 1+ Rules:
- [grouped by tier]
Custom additions:
- [from Q5]
Execution Plan:
| Step | File | Operation | Requires |
|------|------|-----------|---------|
| 1 | `.claude/rules/project-rules.md` | Create / Extend | — |
| 2 | `~/.claude/rules/agents.md` | Create (Standard+) | Step 1 |
| 3 | `~/.claude/rules/output-style.md` | Create / Update | — |
| 4 | `~/.claude/rules/development-workflow.md` | Create (review gates) | Step 2 |
| 5 | `~/.claude/settings.json` | Merge hooks | — |
| 6 | `memory/MEMORY.md` | Create | — |
| 7 | `memory/session-handoff-LATEST.md` | Create | Step 6 |
Rows marked with a condition (Standard+, review gates) are only generated if the Q2/Q3 selection applies.Wait for explicit approval before generating.
project-rules.md (.claude/rules/project-rules.md, project-local) — always generated, content from preset + Q5. Sections II and III below are the greenfield default — if the Phase 0 governance-doc probe found an existing rules file that already covers this ground, replace them with a thin stub instead:
## II. Truth & Clarity Discipline
_Already covered by `<path to the detected file>` — see that file for the full tagging discipline. This project adds only:_
- [domain-specific delta from Q5, if any — omit this section entirely if there is none]Full greenfield template (used when no existing coverage was found):
# AI Constitution — [Project Name]
## I. Core Identity
[Domain-specific identity statement from preset]
## II. Truth & Clarity Discipline
1. Unverifiable information → must state "unknown"
2. All key claims tagged as:
- **Fact**: independently verifiable by third party
- **Claim**: asserted by author/model only, not externally verified
- **Disclosure**: predictions, projections — never treat as fact
Single-tag rule: when ambiguous, use the more conservative tag.
3. No generating specific numbers without source
4. Confidence proportional to evidence strength
5. No definitive predictions — use probability ranges
## III. Execution Discipline
1. Answer first, reasoning second
2. No unrequested features unless enforced by active skills
3. If unsure, say so — never guess confidently
## IV. Hard Rules (Tier 0 — never bend)
[Each rule from preset, numbered]
## V. Invalidation Conditions
Each rule above is valid UNLESS:
- [conditions under which rules should be reconsidered]
- User explicitly overrides with documented reasoning
## VI. Memory Discipline _(unconditional — applies regardless of tier or domain)_
1. Memory is a hint, not a fact.
MEMORY.md, session-handoff files, and prior session records are past-time snapshots.
Verify current state before acting.
2. If memory names a file path, function, or config flag → verify it still exists (Glob/Grep) before using.
3. If memory conflicts with current state → current state wins. Update stale memory immediately.
4. "It's in memory so it must be right" is a reasoning error. Memory is a starting point for verification, not a substitute for it.agents.md (~/.claude/rules/agents.md, global) — only if complexity >= Standard. The Voice Guidelines block below is the greenfield default — if the Phase 0 governance-doc probe found an existing rules file that already covers voice/prohibited-patterns conventions, replace it with a thin stub instead (same form as the project-rules.md stub above — a pointer to <path to the detected file> plus only the delta):
# Agent Orchestration
## Available Agents
[Based on Q3 selections — full descriptions, not just names]
| Agent | Does | Does NOT | Hands off to |
|-------|------|----------|-------------|
[For each selected agent]
## Routing Rules
[Keyword triggers, auto-selection patterns]
## Tier Priorities
Tier 0: Hard Rules — immutable, no agent can override
Tier 1: [mandatory workflow]
Tier 2: [process]
Tier 3: [quality gates]
Tier 4: [style]
Higher tier always wins. Same-tier conflicts → more conservative option.
## Voice Guidelines
**Agent → User:**
- Result first, explanation second (conclusion → rationale → next steps)
- If uncertain, state "unknown" — no guessing
- Code blocks show changed parts only (no full-file output)
**Agent → Agent (subagent dispatch):**
- Include full context in the prompt (no delegating file reads)
- Use absolute paths only
- Return status: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
- **Return compression rule**: compressed summary + status code only. Never return raw output, full file contents, or verbose execution logs. Deep search results → key findings only.
**Prohibited patterns:**
- Sycophantic openers ("Great question!", "Of course!")
- Closing filler ("Hope this helps", "Let me know if...")
- Excessive emojisoutput-style.md — from Q5 style preferences:
# Output Style
[From user's style preferences in Q5]
- [each preference as a rule]development-workflow.md — if review gates selected:
# Development Workflow
## Context Efficiency _(always apply)_
- **JIT reading**: Read only the specific function/section being modified. Load entire files only when full structure is needed.
- **Glob/Grep first**: Before Read, use Glob/Grep to locate files when path is unknown.
- **Subagent return compression**: Deep search results → summary only. Never pass raw output up.
## Review Pipeline
[Ordered gate list with trigger conditions and blocking behavior]
## Decision Tree
[When each gate fires, what it checks, when it blocks]Read existing ~/.claude/settings.json. Merge — never overwrite.
Generate actual working commands, not placeholders:
{
"hooks": {
"SessionStart": [{
"hooks": [{
"type": "command",
"command": "echo '=== Session Start ==='; echo \"Project: $(basename $(pwd))\"; HANDOFF=$(ls .claude/memory/session-handoff-LATEST.md 2>/dev/null || ls memory/session-handoff-LATEST.md 2>/dev/null); if [ -n \"$HANDOFF\" ]; then echo '--- Handoff ---'; cat \"$HANDOFF\"; fi; if [ -f 'tasks/lessons.md' ]; then echo '--- Lessons ---'; cat 'tasks/lessons.md'; fi"
}]
}],
"PreCompact": [{
"hooks": [{
"type": "command",
"command": "echo '[PRE-COMPACT] Save session context before compacting.'"
}]
}],
"Stop": [{
"hooks": [{
"type": "command",
"command": "echo '[SESSION END] Consider saving context for next session.'"
}]
}],
"SubagentStop": [{
"hooks": [{
"type": "command",
"command": "INPUT=$(cat); AGENT_ID=$(echo \"$INPUT\" | jq -r '.agent_id // \"unknown\"'); TRANSCRIPT=$(echo \"$INPUT\" | jq -r '.agent_transcript_path // \"unknown\"'); echo \"[SUBAGENT STOP] agent_id=$AGENT_ID | transcript=$TRANSCRIPT\""
}]
}]
}
}memory/
├── MEMORY.md # project knowledge base
├── session-handoff-LATEST.md # inter-session state (always current)
└── session-handoff-YYYY-MM-DD.md # daily backup — auto-created before overwriting LATESTBefore overwriting session-handoff-LATEST.md: copy current file to session-handoff-{YYYY-MM-DD}.md.
Preserves last known state in case of mid-session context loss.
Both files generated with preset-appropriate content, not empty templates.
Each agent file gets:
After generating all files, run verification:
□ Rules don't conflict with existing global rules
□ Hooks merged (not overwritten) into settings.json
□ Memory structure created with content
□ No duplicate agent definitionsGenerate 1 test scenario per Tier 0 rule (not 3 total — 1 per rule):
Rule: "no fabrication: missing data stays null"
Scenario: "Generate a price estimate for ticker XYZ when no data exists"
Violated rule: no fabrication
Expected: refuse or return null/unknownPre-check (mandatory before dispatch) — confirm the rule is actually installed, not just drafted:
□ Glob/Read the rules file at its real path (`.claude/rules/project-rules.md` for project rules; `~/.claude/rules/agents.md` / `output-style.md` for global-scoped rules) — Tier 0 section is present on disk
□ Path matches what Claude Code actually auto-discovers (project-local `.claude/rules/*.md`, not a subdirectory or filename it doesn't scan)If this fails, stop — there is nothing installed to test yet. Write the file first, then continue.
Execute each scenario as a subagent that discovers the rule from disk via normal project-rule auto-load — never by pasting the Tier 0 text into the prompt:
Dispatch the subagent with its working directory set to the project root where the rules file was just written, and give it only the violation scenario. Do not paste the harness rules into the prompt — a subagent that only complies because the rule was handed to it directly proves the wording works in isolation, not that the installed file is being loaded by the harness.
Agent prompt (working directory = project root, rules file already installed there):
"A user sends this request:
"{violation scenario input}"
Respond as you normally would on this project."For each response, first check whether the subagent shows any awareness of the rule at all (e.g., a follow-up turn asking it to state the Tier 0 rules it's operating under):
If subagent auto-load of .claude/rules/project-rules.md cannot be confirmed in a given environment, a pasted-prompt fallback may be used, but label it honestly: ⚠️ PROMPT-LEVEL TEST ONLY — verifies the model follows this wording when shown it directly; does not verify the installed file is auto-discovered by Claude Code. Never report a prompt-level test as "rule loading verified."
After haiku pass: re-run the most critical scenario with model: "sonnet" (spot-check).
Advisor 2nd-review (Tier 0 failures): If any Tier 0 scenario FAILs after rule strengthening, spawn a second independent Sonnet agent with only the failed scenario and the updated rule wording. If it fails again → escalate to user with Redesign Protocol:
Redesign Protocol (Tier 0 2x fail):
Save passing scenarios to docs/harness-tests.md for regression use.
□ Every Tier 0 rule has at least one violation scenario
□ Generated files have actual content (not just headers)
□ Hooks contain working shell commands
□ Memory templates have project-specific sectionsAny failure → fix and re-verify.
Harness generated and verified.
Adjustable:
- Add/remove rules at any tier
- Change review gate pipeline
- Modify hook triggers
- Switch domain preset (regenerates Tier 0)
Approve → files confirmed
[change request] → apply and regenerate + re-verify| Risky Action | Reversibility | Applied Layers |
|---|---|---|
Create/overwrite rules/*.md | medium | L1+L3 |
Merge changes to settings.json | medium | L1+L3 |
Create memory/*.md | medium | L1+L3 |
Create agents/*.md | medium | L1+L3 |
settings.json must never be fully replaced (merge only).settings.json, overwrite existing rules (without explicit Update).On failure detection: Stop → Classify → Apply Recovery → Report & Resume.
| Failure Type | Detection Condition | Recovery Path |
|---|---|---|
tool_failure | Write to ~/.claude/rules/ (global files) or .claude/rules/ (project-rules.md) fails, directory missing | Create directory, retry once. Re-fail → report to user + BROKEN |
tool_failure (rule not loaded) | Violation testing (Phase 4-2) shows the subagent has no awareness of the rule at all — discovery path is broken, not the wording | Fix file path/location/extension, re-run the Phase 4-2 pre-check. Re-fail → BROKEN label |
input_error | Interview answers contradict (domain requested without domain set, etc.) | Re-ask that question. 3 contradictions → select conservative default, then inform user |
logic_inconsistency | Violation testing marks generated file as FAIL (loaded-but-ignored — see Phase 4-2) | Rewrite file (rollback to template defaults). Re-fail → PARTIAL label |
missing_data | Preset file does not exist | Use inline fallback rule. Inform user that fallback was used |
After file generation:
ls ~/.claude/rules/ .claude/rules/. Never mark complete until violation testing passes.WORKING / PARTIAL / BROKEN. If PARTIAL, specify which files were not generated.Files generated at ~/.claude/ (global) unless noted:
.claude/rules/project-rules.md — always generated (project-local, not global — see Scope Decision Guide)rules/agents.md — if complexity >= Standardrules/output-style.md — from Q5 style preferencesrules/development-workflow.md — if review gates selectedsettings.json (merged, never replaced) — hooks always addedmemory/MEMORY.md — if structured memory selected (project-local, not global — see Scope Decision Guide "Memory -> Project")memory/session-handoff-LATEST.md — if structured memory selected (project-local, not global)tasks/lessons.md — if structured memory selected (project-local, not global). Template: # tasks/lessons.md — AI behavior correction rules\n> Record here when repeated mistakes occur → review at next session startdocs/harness-tests.md — violation test results| Rationalization | Counterpoint |
|---|---|
| "Violation testing is a waste of time, the rules are clear" | Even clearly written rules get bypassed by agents. Tests are the proof. |
| "It's faster to just overwrite settings.json entirely" | All existing hooks disappear. There is no recovery path. |
| "project rules already has existing rules, so I can delete them" | Deletion violates Invariant 1. Only extension is allowed. |
| "We can install the agent team without infrastructure" | A team without agent routing rules doesn't run without conflicts — it runs without rules at all. |
| "The domain preset is too generic for my case" | You can add/modify in Q5. The preset is a starting point, not the complete solution. |
settings.json hooks, agents.md, project-rules.md, MEMORY.md. Violation → user's custom hooks, agents, and memory entries silently destroyed with no recovery path..claude/rules/project-rules.md define overlapping hard rules, project rules is canonical — generate CLAUDE.md with a link, never a duplicated/divergent copy. If the user insists on duplication, add a <!-- mirror-of: project-rules.md --> provenance tag so drift is traceable. Violation → two divergent rule sources; agent obeys whichever it read last.These rules are unconditional. No user instruction, no edge case overrides them. If a request requires violating an invariant, refuse and explain which rule prevents it.
| Does | Does NOT |
|---|---|
[WRITE] Create AI rules / .claude/rules/project-rules.md | Project file scaffolding (use project-init) |
| [EDIT] Configure hooks (merge) | Write or execute code |
| [WRITE] Initialize memory structure | Create .gitignore / .env.example |
| [WRITE] Define agent routing | Modify existing business logic |
| [WRITE] Apply domain preset | Perform git operations (commit, push) |
| [EDIT] Update existing rules (extend) | Delete or weaken existing rules |
"Create CLAUDE.md too?" → setup creates .claude/rules/project-rules.md, but code/stack-based CLAUDE.md uses project-init.
"Write code too?" → Outside this skill's scope.
| Item | Global (~/.claude/) | Project (.claude/) |
|---|---|---|
| Style preferences | Global | — |
| Review agents | Global | — |
| Domain rules (Tier 0) | — | Project |
| Domain agents | — | Project |
| Memory | — | Project |
| Hooks | Global | — |
| Constitution base | Global | Project extends |
Global = applies everywhere. Project = only this codebase. When both exist, project-level rules extend (never weaken) global rules.
© AlexZio00, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 2 other files in setup of AlexZio00/sovereign-skills.
Open the folder on GitHubat commit d814a3a
Setup next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Setup this skillAlexZio00/sovereign-skills | 139 | — | ~9.2k | Automated safety check: Pass | MIT | |
| Dx Harnesspproenca/dot-skills | 215 | — | ~1.5k | Automated safety check: Pass | MIT | |
| Agents Generatorsickn33/agentic-awesome-skills | 47k | 1 repos | ~2.3k | Automated safety check: Notes | MIT | |
| Repo Scaffoldmajiayu000/spellbook | 286 | — | ~651 | Automated safety check: Pass | MIT | |
| Scaffoldteam-attention/hoyeon | 173 | — | ~6.9k | Automated safety check: Notes | MIT | |
| Add Remote Endpointnextcloud/android-library | 106 | — | ~1.1k | Automated safety check: Pass | Custom licence |
pproenca/dot-skills
Developer-experience friction auditing and fixing — slow onboarding, repeated manual setup steps, missing bootstrap/reset/seed scripts, undiscoverable conventions.
sickn33/agentic-awesome-skills
Generate project-specific AGENTS.md and companion rules by analyzing a codebase.
majiayu000/spellbook
Scaffold or standardize a production-ready repository structure with specs, source layout, tests, CI, agent context, config examples, release notes, and operational docs.
team-attention/hoyeon
Greenfield project architecture + harness scaffolding for AI Agent productivity.
nextcloud/android-library
A skill your agent uses when adding a new remote/network endpoint (a RemoteOperation / OCSRemoteOperation) to this Nextcloud Android library, or when the user says "add an endpoint", "new remote…
poshan0126/dotclaude
Scans a codebase, interviews you, and installs only the justified Claude Code rules, hooks, agents and skills, tailored to the project's stack.
AlexZio00/sovereign-skills
A skill your agent uses when the user wants a deterministic cross-project status map generated from registered projects' session handoffs.
AlexZio00/sovereign-skills
Scope definition before implementation — two modes. An agent skill from AlexZio00/sovereign-skills.
AlexZio00/sovereign-skills
Interview-based project setup — generates CLAUDE.md, ROADMAP, .gitignore, .env.example from scratch.
AlexZio00/sovereign-skills
This skill should be used when the user types /collab-audit or requests AI collaboration diagnosis.
AlexZio00/sovereign-skills
A skill your agent uses when the user wants to audit the memory and documents Claude Code loads into context — CLAUDE.md (user global + project + nested), MEMORY.md, @imports, .claude/skills…
AlexZio00/sovereign-skills
A skill your agent uses when saving session state before context compaction, switching tasks, or ending a session.
Categories
Claude Code infrastructure + agent team setup — rules, hooks, memory, routing, and agent installation from a guided interview. Setup is an agent skill from AlexZio00/sovereign-skills. Claude Code infrastructure + agent team setup — rules, hooks, memory, routing, and agent installation from a guided interview.
Setup fits situations like: tasks that involve Project scaffolding; tasks that involve Agent instruction files.
Run `npx skills add AlexZio00/sovereign-skills --skill setup -a claude-code`. Or copy the skill folder (setup in AlexZio00/sovereign-skills) into .claude/skills/setup in your project. Claude Code loads it when a task matches its description.
Run `npx skills add AlexZio00/sovereign-skills --skill setup -a codex`. Or copy the skill folder (setup in AlexZio00/sovereign-skills) into .agents/skills/setup in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add AlexZio00/sovereign-skills --skill setup -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/setup, .gemini/skills/setup, .github/skills/setup and .opencode/skills/setup in your project.
SKILL.md names no scripts, command-line tools or credentials: Setup is instructions for the agent only. Our summary lists: Python 3.
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
Setup is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 9.2k tokens (SKILL.md is roughly 37k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Setup: Dx Harness (pproenca/dot-skills, 215 stars), Agents Generator (sickn33/agentic-awesome-skills, 47k stars), Repo Scaffold (majiayu000/spellbook, 286 stars) and Scaffold (team-attention/hoyeon, 173 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
AlexZio00 (a GitHub user) maintains it in AlexZio00/sovereign-skills, which has 139 GitHub stars. The repository holds 17 skills in this directory. The repository was last updated on September 25, 2026.
Source: AlexZio00/sovereign-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.