Sélection de profil de qualité

VérifiéSûr

Sélectionne un profil de qualité (lean, standard, thorough, exhaustive, custom, inherit) et persiste la configuration globalement ou par projet.

Spar Skills Guide Bot
ProductiviteIntermédiaire
07/08/2026
Claude Code
#token-optimization#quality-profiles#configuration#agent-orchestration#cost-control

Recommandé pour

Synthèse automatique

Cette skill permet de choisir un profil d'arbitrage entre rigueur de qualité et consommation de tokens (lean, standard, thorough, exhaustive, custom, inherit) et de l'enregistrer globalement ou pour un projet donné.

Points forts

  • Table de correspondance unique et explicite pour chaque profil (modèle d'agent, modèle de relecture, double relecture, passe de refactoring)
  • Persistance à deux niveaux : global via ~/.nwave/global-config.json ou projet via .nwave/des-config.json
  • Mode interactif si aucun profil n'est fourni, et profil 'standard' marqué comme recommandé
  • Rappelle que le socle de livraison (test d'acceptation, changement minimal, refactoring, revue) reste identique quel que soit le profil

Limites

  • N'a d'effet que sur les commandes wave du framework nWave, pas sur le comportement général de Claude
  • Le profil lean désactive la relecture (review_enabled=false, reviewer_model=skip), ce qui réduit le contrôle qualité
  • Aucune granularité par tâche : le profil s'applique à l'ensemble des commandes wave du périmètre choisi
Quand l'utiliser

À utiliser lorsque vous voulez ajuster le compromis coût en tokens / rigueur de revue pour toutes les commandes wave d'un projet ou de votre environnement global.

Quand l'éviter

À éviter si vous travaillez hors du framework nWave ou si vous cherchez un réglage de qualité limité à une seule tâche plutôt qu'à tout un périmètre.

Analyse de sécurité

Sûr
Score qualité74/100

The skill is a documentation/instruction file that guides the agent to select a quality profile and persist it as JSON config in ~/.nwave or .nwave. There are no declared tools, no bash/docker/network invocation, no curl|sh, no secret/token exfiltration, and no destructive or obfuscated actions. The only mildly notable behavior is writing to a global home-directory config, which is legitimate for a config-persistence command.

Points d'attention
  • •Writes persistent config to the user's home directory (~/.nwave/global-config.json) and project (.nwave/des-config.json) — this is the stated purpose but is a persistent global-state change worth noting
Comment cette analyse est faite

Exemples

Set the project to the lean profile
/nw-rigor lean — apply it to this project only so wave commands consume fewer tokens
Interactive profile selection
/nw-rigor
Switch globally to thorough
/nw-rigor thorough and persist it in my global config so every project uses it

name: nw-rigor description: "Selects a quality-vs-token-consumption profile (lean, standard, thorough, exhaustive, custom, inherit) and persists it globally (~/.nwave/global-config.json) or per-project (.nwave/des-config.json). Use when tuning how much rigor wave commands apply." user-invocable: false argument-hint: '[profile] - Optional: lean, standard, thorough, exhaustive, custom, inherit. Omit for interactive selection.'

NW-RIGOR: Quality Profile Selection

Wave: CROSS_WAVE | Agent: Main Instance (self) | Command: /nw-rigor [profile]

Overview

Interactive command to select a quality-vs-token-consumption profile. Persists choice to either ~/.nwave/global-config.json (global scope) or .nwave/des-config.json (project scope) under the rigor key. All wave commands read this config to adjust agent models, review policy, examination depth, and refactoring effort.

You (the main Claude instance) run this directly. No subagent delegation.

Every delivery uses the same fixed floor: consume an upstream executable acceptance test, implement the smallest design-conformant change that makes it pass, refactor proportionately, and independently review or EXAMINE observable behaviour. Profiles do not select workflow phases or retain phase history.

Profile Mappings (Single Source of Truth)

| Setting | lean | standard [recommended] | thorough | exhaustive | inherit | |--------------------|---------------------------------------|------------------------------------------------------------------------------|------------------------------------------------------------------------------|------------------------------------------------------------------------------|------------------------------------------------------------------------------| | agent_model | haiku | sonnet | opus | opus | inherit | | reviewer_model | skip | haiku | sonnet | opus | haiku | | review_enabled | false | true | true | true | true | | double_review | false | false | true | true | false | | refactor_pass | false | true | true | true | true | | examine_swarm_n | 1 | 1 | 3 | 5 | 1 |

v2 evolution notes (evidence-by-execution migration, 2026-07-03) — the rigor axes shifted with the flow:

  • examine_swarm_n (NEW): how many independent User-Examiners ("Vera") walk each slice's expectation charter at the DELIVER EXAMINE step. 1 = one exam; ≥3 = swarm, and divergence between the session logs is itself a signal (a charter that different examiners read differently is under-specified). The examiner runs on haiku (its work is walk/observe/describe, not code reasoning — model pinned in the nw-user-examiner agent, not a rigor knob).
  • reviewer_model is now the FEATURE-END deep-review model (P2.2). The per-slice code-reading C_REVIEWER_AUDIT is REPLACED by the EXAMINE step (execution-observation) — see nw-deliver. reviewer_model is retained (backward-compat + the feature-end review), not deleted.
  • agent_model is UNCAPPED — thorough/exhaustive legitimately offer opus for the user's high-stakes choice (vision principle 4). (The no-opus/fable rule governs Lyra's own migration dispatches + defaults, not the product ceiling.)
  • The mutation-testing knob is no longer a rigor axis, and mutation testing is DEPRECATED (FR-1, velocity-v2) — NOT a per-feature knob and NOT a nightly job. New profiles disable it; its 2 consumers skip when it is off. The mutation-test task is explicit opt-in only; green ATs + EXAMINE are the truth.

Execution-observing floor (ALWAYS on — NOT rigor-gated)

Ale 2026-07-03 (ratified). The gates that observe execution — verify-red-green (the AT genuinely went RED→GREEN, non-vacuous), verify-spec-coverage (every requirement has a covering AT), and the examine-verdict gate (a User-Examiner walked the charter on the real surface) — are a FIXED FLOOR present in EVERY profile, lean included. No profile can gate them off.

Rigor modulates only the elevatable dimensions ABOVE the floor: agent_model, examine_swarm_n, reviewer_model (feature-end), refactor_pass, review depth. It NEVER lowers the floor. This refines vision principle 4 (proportional quality) — proportional above the floor, never below it: the execution-observation is the one thing that is not bartered for speed (it is exactly the hole that shipped testing-theater in the external eval). See [[feedback_execution_observing_gates_are_fixed_floor_not_rigor_gated_2026_07_03]].

Behavior Flow

Mode Detection

  • No argument -> Mode 1 (Interactive Selection)
  • Argument is a preset name (lean, standard, thorough, exhaustive, inherit) -> Mode 2 (Quick Switch)
  • Argument is custom -> Mode 3 (Custom Builder)

Mode 1: Interactive Selection (no argument)

Step 1: Welcome

Read .nwave/des-config.json. If missing or .nwave/ directory absent -> error: "No nWave config directory found. Run nwave install first."

If JSON is invalid -> backup as .nwave/des-config.json.bak, reset config to {}, note: "Config was corrupted. Backed up and reset."

Display current profile (from config.rigor.profile) or "none set" if absent.

Brief explanation: "Rigor profiles control how much quality infrastructure nWave applies per wave: agent models, review and examination depth, refactoring effort. Higher rigor = stronger optional assurance and higher token cost; the executable-AT floor remains fixed."

Step 1.5: Scope Selection

Display the current project rigor (from .nwave/des-config.json) and current global rigor (from ~/.nwave/global-config.json, if it exists).

Ask via AskUserQuestion:

Where do you want to save this configuration?

Options:

  1. Globally (~/.nwave/global-config.json) — applies to all projects without their own rigor
  2. This project only (.nwave/des-config.json) — overrides global for this project

Store the user's choice as {scope} and the corresponding file path as {target_file}:

  • If global: {target_file} = ~/.nwave/global-config.json
  • If project: {target_file} = .nwave/des-config.json

Step 2: Comparison Table

Display this table:

+-----------+--------+----------+----------+------------+---------+
|           | lean   | standard | thorough | exhaustive | inherit |
+-----------+--------+----------+----------+------------+---------+
| Agent     | haiku  | sonnet   | opus     | opus       | *yours* |
| Reviewer  | --     | haiku    | sonnet   | opus       | haiku   |
| Review    | no     | yes      | double   | double     | yes     |
| Refactor  | no     | yes      | yes      | yes        | yes     |
+-----------+--------+----------+----------+------------+---------+
| Est. cost | lowest | moderate | higher   | highest    | varies  |
| Est. time | fast   | moderate | slower   | slowest    | varies  |
+-----------+--------+----------+----------+------------+---------+

Mark "standard" as [recommended]. Below the table, note: "Or choose custom to configure each setting individually. Type inherit to use your current session model."

Step 3: User Selection

Ask user to select via AskUserQuestion (4 options + Other for inherit/custom):

  1. standard [recommended]
  2. lean
  3. thorough
  4. exhaustive

Note in the question text: "Type 'custom' to build your own profile, or 'inherit' to use your session model."

If user selects or types "custom" -> jump to Mode 3 (Custom Builder). If user types "inherit" -> proceed with inherit profile to Step 4.

Step 4: Detail View

Show the detail view for the selected profile. Render in a code block for visual clarity.

lean:

WHAT YOU GET:
  - Haiku agent (fastest, cheapest)
  - The fixed executable-AT delivery floor

WHAT YOU LOSE:
  - No code review
  - No dedicated refactoring pass

WHEN TO USE:
  Config changes, documentation, simple bug fixes, spikes/prototypes

ESTIMATED IMPACT:
  Lowest token cost | Fastest per step

standard [recommended]:

WHAT YOU GET:
  - Sonnet agent (balanced quality/speed)
  - Haiku reviewer (cost-effective review)
  - Dedicated proportional refactoring pass

WHAT'S NOT INCLUDED:
  - No double review (single pass only)
  - Not opus-level reasoning

WHEN TO USE:
  Most development work — features, integrations, refactoring

ESTIMATED IMPACT:
  Moderate token cost | Moderate time per step

thorough:

WHAT YOU GET:
  - Opus agent (strongest reasoning)
  - Sonnet reviewer (deeper review analysis)
  - Double review (two independent review passes)
  - Dedicated proportional refactoring pass

WHAT IT COSTS:
  Higher token cost | Slower per step

WHEN TO USE:
  Critical features, security-sensitive code, public APIs, complex algorithms

exhaustive:

WHAT YOU GET:
  - Opus agent and opus reviewer (strongest at every stage)
  - Double review (two independent review passes)
  - Dedicated proportional refactoring pass

WHAT IT COSTS:
  Highest token cost | Slowest per step

WHEN TO USE:
  Critical production systems, compliance-sensitive code, long-lived core modules

inherit:

WHAT YOU GET:
  - Your session model for agents (nWave inherits, does not override)
  - Haiku reviewer
  - Single review pass
  - Dedicated proportional refactoring pass

WHAT THIS MEANS:
  nWave respects your model choice and controls the process around it.
  If your session runs opus, agents get opus. If sonnet, agents get sonnet.

WHEN TO USE:
  When you have strong opinions about which model to use,
  or your organization controls model selection externally.

Step 5: Confirm

Ask user to confirm via AskUserQuestion:

  1. Yes, apply this profile
  2. No, go back to selection (return to Step 2)
  3. Cancel (exit without saving)

Step 6: Save to Config

  1. If {scope} is global AND the directory ~/.nwave/ does not exist, create it with parents=True
  2. Read {target_file} (handle missing file or corrupt JSON: start with {})
  3. Parse JSON
  4. Set config["rigor"] to the full profile object:
    {
      "profile": "{selected}",
      "agent_model": "...",
      "reviewer_model": "...",
      "review_enabled": true/false,
      "double_review": true/false,
      "refactor_pass": true/false
    }
    
  5. Write back to {target_file}, preserving all other top-level keys (audit_logging_enabled, skill_tracking, etc.)

Step 7: Summary

Display all resolved settings:

Rigor profile saved: {name}

  Resolved settings:
  +-----------------------+---------------------------------------------------+
  | agent_model           | {value}                                           |
  | reviewer_model        | {value}                                           |
  | review_enabled        | {value}                                           |
  | double_review         | {value}                                           |
  | refactor_pass         | {value}                                           |
  +-----------------------+---------------------------------------------------+

  Config: {target_file} ({scope})
  All wave commands will use these settings.

Mode 2: Quick Switch (with argument)

Step 1: Validate Argument

If argument is not one of: lean, standard, thorough, exhaustive, custom, inherit -> error: "Unknown profile '{name}'. Available: lean, standard, thorough, exhaustive, custom, inherit"

If argument is custom -> redirect to Mode 3 (Custom Builder).

Read .nwave/des-config.json. If missing -> same error as Mode 1 Step 1.

Step 1.5: Scope Selection

Same as Mode 1 Step 1.5. Ask scope question, store {scope} and {target_file}.

Step 2: Show Diff

Display what changes from current profile to target profile:

Switching from {current} -> {target}:

  agent_model:      sonnet -> haiku
  reviewer_model:   haiku -> skip
  review_enabled:   true -> false
  refactor_pass:    true -> false

If downgrading (moving to a less rigorous profile), highlight what user will lose:

You will LOSE:
  - Code review (reviewer_model: skip)
  - Dedicated refactoring pass

If no current profile is set, show the target profile settings without diff.

Step 3: Confirm

Ask user to confirm via AskUserQuestion:

  1. Yes, switch to {target}
  2. No, keep current profile

Step 4: Save + Summary

Same as Mode 1 Steps 6 and 7. Uses {target_file} from Step 1.5.

Mode 3: Custom Builder (/nw-rigor custom or selected from interactive)

Build a profile setting by setting. Each question uses AskUserQuestion with sensible defaults (standard values pre-selected). After all questions, show summary and confirm.

Step 1: Config Check

Same as Mode 1 Step 1 (read config, handle missing/corrupt).

Step 1.5: Scope Selection

Same as Mode 1 Step 1.5. Ask scope question, store {scope} and {target_file}.

Step 2: Agent Model

Ask via AskUserQuestion:

Which model should agents use? (crafter, architect, acceptance-designer)

Options:

  1. sonnet (Recommended) — balanced quality and speed
  2. haiku — fastest, lowest cost
  3. opus — strongest reasoning, highest cost
  4. inherit — use your current session model

Step 3: Reviewer Model

Ask via AskUserQuestion:

Which model for peer reviewers?

Options:

  1. haiku (Recommended) — cost-effective review
  2. sonnet — deeper analysis
  3. opus — most thorough review
  4. skip — no peer review

Step 4: Double Review

Ask via AskUserQuestion:

Run peer review twice (two independent passes)?

Options:

  1. No (Recommended) — single review pass
  2. Yes — two independent review passes (higher cost)

Only show this question if reviewer_model is not "skip". If "skip", set double_review = false automatically.

Step 5: Refactoring Pass

Ask via AskUserQuestion:

Include a dedicated refactoring pass after implementation?

Options:

  1. Yes (Recommended) — a dedicated proportional refactoring pass after the AT is green
  2. No — use only the fixed delivery floor's inline cleanup

Step 6: Summary + Confirm

Display the assembled profile:

Custom profile:

  +-----------------------+---------------------------------------------------+
  | agent_model           | {value}                                           |
  | reviewer_model        | {value}                                           |
  | double_review         | {value}                                           |
  | refactor_pass         | {value}                                           |
  +-----------------------+---------------------------------------------------+

Ask to confirm via AskUserQuestion:

  1. Yes, apply this custom profile
  2. Start over (return to Step 2)
  3. Cancel (exit without saving)

Step 7: Save + Summary

Same as Mode 1 Steps 6 and 7. Uses {target_file} from Step 1.5. Save with "profile": "custom".

Error Handling

| Error | Response | |-------|----------| | Missing .nwave/ directory | "No nWave config directory found. Run nwave install first." | | Invalid JSON in des-config.json | Backup as .bak, reset to {}, proceed with notice | | Unknown profile name | "Unknown profile '{name}'. Available: lean, standard, thorough, exhaustive, custom, inherit" | | inherit with undetectable session model | Fallback to sonnet with notice: "Could not detect session model. Defaulting agent_model to sonnet." |

Success Criteria

  • [ ] Current profile displayed (or "none set")
  • [ ] Scope question asked (global vs project) in all 3 modes
  • [ ] Comparison table shown with all 5 profiles
  • [ ] User selected and confirmed a profile
  • [ ] Config written to {target_file} (read-modify-write, other keys preserved)
  • [ ] ~/.nwave/ directory auto-created with parents=True on first global save
  • [ ] Summary of all resolved settings displayed (including scope and target file path)

Examples

Example 1: Interactive first-time selection

/nw-rigor

No current profile set. Shows comparison table, user picks "standard", sees detail view, confirms. Config written with full rigor block.

Example 2: Quick switch to lean

/nw-rigor lean

Current profile is "standard". Shows diff: loses review and the dedicated refactoring pass. Agent drops from sonnet to haiku. User confirms. Config updated.

Example 3: Quick switch up

/nw-rigor thorough

Current profile is "standard". Shows diff: sonnet->opus agent, haiku->sonnet reviewer, double review enabled. No losses to highlight (pure upgrade). User confirms. Config updated.

Example 4: Custom profile builder

/nw-rigor custom

Walks through 4 questions: agent model (opus), reviewer (haiku), double review (no), refactoring (yes). Saves as custom profile with opus agent, haiku reviewer, single review, and dedicated refactoring — a combination no preset offers.

Example 5: Invalid profile name

/nw-rigor turbo

Error: "Unknown profile 'turbo'. Available: lean, standard, thorough, exhaustive, inherit"

Example 6: No nWave installed

/nw-rigor

No .nwave/ directory found. Shows: "No nWave config directory found. Run nwave install first." Stops.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/quality-profile-selection-msih95yk/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/quality-profile-selection-msih95yk' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/quality-profile-selection-msih95yk/download' --output '.skill-downloads/quality-profile-selection-msih95yk/SKILL.md.part' && mv '.skill-downloads/quality-profile-selection-msih95yk/SKILL.md.part' '.skill-downloads/quality-profile-selection-msih95yk/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/quality-profile-selection-msih95yk/SKILL.md' && test -s '.skill-downloads/quality-profile-selection-msih95yk/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/nw-rigor' && cp -R '.skill-downloads/quality-profile-selection-msih95yk' '.claude/skills/nw-rigor'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/quality-profile-selection-msih95yk'

openskills read 'quality-profile-selection-msih95yk'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/quality-profile-selection-msih95yk/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires