declare-target-ruleset

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

1. Domain argument provided?

   • NO → List all directories matching $DOMAINS_DIR/*/ as a numbered menu and prompt: :::user_input Available domains:
     1. snap
     2. ak_doh Which domain? Enter a number or domain name: ::: Await the user's response and use it as <domain>. Then continue.

2. Domain folder exists?

   • NO → :::error Domain not found: $DOMAINS_DIR// ::: Then stop.

3. 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.

4. 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/.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:
     2. Which ruleset file? Enter a number or file name: ::: Await the user's response and use the resolved stem as ``. Then continue.

5. 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

1. Ensure the guidance/ folder exists and seed CLAUDE.md:

   xlator ensure-guidance <domain>
   

   This is idempotent — safe to run when the folder already exists.

2. 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.

3. Suggest the next step:

   :::next_step Next: Run /refine-guidance <domain> to populate descriptive guidance files. :::

Output

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).