بنقرة واحدة
declare-target-ruleset
Declare Ruleset Input-Output from a Suggestion File
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Declare Ruleset Input-Output from a Suggestion File
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Emit Catala
Create Sample Tests
Draft or Update Test Cases
Expand Test Coverage
Extract Test Cases from Policy Documents
Generate a Demo App (Catala-Python Backend)
| name | declare-target-ruleset |
| description | Declare Ruleset Input-Output from a Suggestion File |
Bootstrap the guidance/ folder for a domain from a ruleset file produced by /suggest-target-ruleset. The deterministic write logic lives in xlator declare-target-ruleset; this skill owns the menu prompts and overwrite confirmation.
/declare-target-ruleset <domain> [<ruleset_name>]
Read ../../core/output-fencing.md now.
Domain argument provided?
$DOMAINS_DIR/*/ as a numbered menu and prompt:
:::user_input
Available domains:
<domain>. Then continue.Domain folder exists?
suggested_targets/ directory exists and has at least one .yaml file?
Ruleset file resolved:
<ruleset_name> was provided: check $DOMAINS_DIR/<domain>/specs/suggested_targets/<ruleset_name>.yaml exists.
<ruleset_name> was NOT provided: list .yaml files in $DOMAINS_DIR/<domain>/specs/suggested_targets/ as a numbered menu and prompt:
:::user_input
Available ruleset files:
<ruleset_name>. Then continue.guidance/metadata.yaml already exists?
$DOMAINS_DIR/<domain>/specs/guidance/metadata.yaml present → Prompt:
:::user_input
guidance/metadata.yaml already exists at $DOMAINS_DIR//specs/guidance/metadata.yaml. Overwrite? [y/n]
:::
n → Stop without writing.y → continue.Ensure the guidance/ folder exists and seed CLAUDE.md:
xlator ensure-guidance <domain>
This is idempotent — safe to run when the folder already exists.
Run the deterministic bootstrap tool:
xlator declare-target-ruleset <domain> <ruleset_name>
The tool reads specs/suggested_targets/<ruleset_name>.yaml and writes the three bootstrap files atomically.
Open a :::important fence. Relay the tool's stdout verbatim. Close the fence.
If the tool exits non-zero, emit :::error with the captured stderr and stop.
Suggest the next step:
:::next_step
Next: Run /refine-guidance <domain> to populate descriptive guidance files.
:::
| File | Action |
|---|---|
$DOMAINS_DIR/<domain>/specs/naming-manifest.yaml | Created (or overwritten) |
$DOMAINS_DIR/<domain>/specs/guidance/metadata.yaml | Created (or overwritten) |
$DOMAINS_DIR/<domain>/specs/guidance/prompt-context.yaml | Created (or overwritten) |
naming-manifest.yaml entries carry observations: when the suggestion file supplies it — the tool passes the suggestion entry's observations: list through verbatim via _entry_subset (one entry per observed (policy_phrase, source_doc, section) triple). Synthesized outputs that have no source observation land with observations: absent. Scalar policy_phrase: / source_doc: / section: keys on a suggestion entry are dropped silently (matching the existing "every other key is dropped" rule); the v3.0 manifest schema records provenance only inside observations: triples.type:, optional:, and enum_variants: (post-U7 type extension) on a manifest entry start as whatever the suggestion file supplies, or absent when the suggestion omits them. The tool preserves what the suggestion provides; /extract-ruleset Step 7's analyst-confirmation step populates the remainder once the analyst confirms inferred types against policy-doc context. Seeded entries without type: are tolerated by downstream consumers (/catala-emit-tests and the test-creation skills default to string with a stderr WARN).