| name | declare-target-ruleset |
| description | Declare Ruleset Input-Output from a Suggestion File |
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.
Input
/declare-target-ruleset <domain> [<ruleset_name>]
Read ../../core/output-fencing.md now.
Pre-flight
-
Domain argument provided?
- NO → List all directories matching
$DOMAINS_DIR/*/ as a numbered menu and prompt:
:::user_input
Available domains:
- snap
- ak_doh
Which domain? Enter a number or domain name:
:::
Await the user's response and use it as
<domain>. Then continue.
-
Domain folder exists?
- NO →
:::error
Domain not found: $DOMAINS_DIR//
:::
Then stop.
-
suggested_targets/ directory exists and has at least one .yaml file?
- Directory absent or empty →
:::error
No ruleset files found. Run /suggest-target-ruleset first.
:::
Then stop.
-
Ruleset file resolved:
- If
<ruleset_name> was provided: check $DOMAINS_DIR/<domain>/specs/suggested_targets/<ruleset_name>.yaml exists.
- NOT FOUND →
:::error
Ruleset file not found: $DOMAINS_DIR//specs/suggested_targets/<ruleset_name>.yaml
Available ruleset files:
- .yaml
- .yaml
:::
Then stop.
- If
<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:
-
-
Which ruleset file? Enter a number or file name:
:::
Await the user's response and use the resolved stem as <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.
Process
-
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.
:::
Output
| 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) |
Common Mistakes to Avoid
- Seeded
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 metadata fields are nullable at seed time —
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).