Positioning
This Skill is the pre-step before writing a legal Skill—through Socratic questioning, it helps you transform scattered "experience/materials/intuition" into a structured, consumable-by-general skill-creator and other downstream compilers' Legal Skill Brief v1(see standard-prompt-output.md). This Skill does not directly generate Skill files, and only produces a Brief fed to the downstream compiler.
Division of labor：
legal-skill-alignment(this Skill): responsible for "thinking clearly about what to do"—structuring the intent.- General
skill-creator(or the legal-domain Skill orchestrator available in your environment): responsible for "making it"—compiling the Brief into SKILL.md / references / scripts.
Methodology: question-set/v1 (currently default five questions)
This Skill currently implements question-set/v1(five-question instance)—aligning goals from five key dimensions:
| # | Element | Problem solved | Corresponding field in Brief v1 |
|---|---|---|---|
| 1 | What is input | What data this Skill consumes | ## 二、1. 输入什么（Inputs） |
| 2 | What is output | What the product looks like | ## 二、2. 输出什么（Outputs） |
| 3 | Processing logic | How to get from input to output | ## 二、3. 处理逻辑（Workflow） |
| 4 | Delivered to whom(v1 split into three sub-items) | Who uses it, who it represents, who it is written for | ## 二、4. 向谁交付（Context.Delivery） |
| 5 | What knowledge support is needed | Legal basis, templates, risk checklists, style preferences | ## 二、5. 需要哪些知识支撑（Knowledge Base） |
Questions 4 and 5 are the two questions added relative to the "classic three questions"—Delivered to whomdetermines tone and level of detail,What knowledge support is neededdetermines whether this Skill is an "empty-shell template" or "real substance with meat".
Why it is called question-set/v1 rather than the "five-question method"
- Not locked to a number: v1 is the current default instance (5 questions); in the future v2 can expand to 6 questions / 7 questions / reduce to 4 questions, without changing the Skill name.
- Versioned constraints: what v1 locks is not the number of questions, but thecompleteness rules(see below) andfield semantics(such as "question 4 split into three sub-items" below).
- Expansion method: modify the question count in this SKILL.md + the corresponding references, and release a new version (e.g.,
question-set/v2）。
The three sub-items of question 4 in v1
Question 4 in v1 is split into three types of roles; the three areoften confused, and must be clarified separately:
| Sub-item | Meaning | Typical values | What it determines |
|---|---|---|---|
operator |
The role directly using this Skill | Lawyer / paralegal / in-house counsel / compliance specialist / AI operator | What tools can be invoked / which fields are visible |
represented_party |
The party whose interests the Skill output substantially serves | Plaintiff / defendant / employer / acquirer | Content stance / interest preference / confidentiality level |
output_audience |
Reader of the final document | Judge / opposing counsel / client / regulator | Tone / level of detail / terminology density |
Most common mistake: writing output_audience as represented_party(e.g., mistakenly filling "judge" into represented_party). The judge is the reader, not the party being represented.
Completeness rules (required reading for question-set/v1)
The following rules must be satisfied before producing a Brief. Completeness isalignment internal constraint, it does not block downstream consumers from receiving it (downstream does not perform schema validation), butit blocks alignment itself from determining it as "handover-ready"。
Non-goals
This Skill does not：
- Does not replace legal judgment: The clarified handling logic and risk list must be finally confirmed by a practicing lawyer.
- Does not produce the final document: Only produces a Brief; downstream compilation is what produces the Skill file.
- Does not perform compliance review: The content of the Brief does not constitute legal advice or a compliance commitment.
- Does not verify the currency of legal sources: The effective dates of legal sources are marked by the user in
effective_dateandverification_status; unconfirmed ones are markedunverified。
Prohibited
- Fabricating statutes / cases is prohibited: Every legal source citation must be traceable; those for which the original text URL or local original text path cannot be provided are marked
verification_status: unverified。 - Hardcoding case facts as general rules is prohibited: Rules reverse-inferred from a single sample must be marked "to be supplemented" and are not directly treated as general conclusions.
- Making value judgments on behalf of the user is prohibited: The party's stance / strategic choices / risk preference are to be confirmed by the user rather than inferred by alignment.
- Silently inferring gaps is prohibited: Every inferred element must be marked in the "to be confirmed list" with its inference basis and confirmation method.
Success Criteria and status determination (Success Criteria, split into two statuses as of v1.0.2)
The handover-readiness of a Brief is determined bytwo independent statuses, to avoid the ambiguity of "fields complete but contains a blocker yet marked handover-ready":
structurally_complete(structurally complete)
A Brief is determined to be structurally_complete = true：
- All five questions have an answer (explicit answer / inferred answer / marked "to be supplemented", one of the three)
- Legal source entries carry
effective_dateandverification_status(even if the value isunverified） - The material traceability quality field has been filled in (including
unrated) - The security and desensitization description paragraph has been filled in (even if there is no sensitive information, fill in "no sensitive information identified")
- The to-be-confirmed list has been classified according to
blocker/warning;
structurally_completeonly looks at "whether fields are complete + whether marked",and does not look at whether blockers are cleared. A Brief containing a "to be supplemented" mark can still satisfy this status.
handoff_ready(handover-ready)
On the basis of structurally_complete = true ,and only if the blocker items in the to-be-confirmed list = 0, is it determined to be handoff_ready = true。
If any of the following situations exists,handoff_ready = false(even if structurally_complete = true）：
operatoris unconfirmed (only warning-level marked "to be supplemented"do notcounts as unconfirmed; but completely blank or without any basis for inference counts as a blocker)- any of the five questions is completely blank and not marked "to be supplemented" (which also results in
structurally_complete = false） - the Brief output involves specific legal advice, but there is no traceable original text of the key legal source (
source_urlorsource_file）
Sole determination of missing key legal sources: as long as the Brief will produce specific legal advice (including legal opinions, litigation/defense strategies, complaints or answers, finalized contracts or review conclusions, and compliance rectification recommendations that need to be made based on legal sources), and the corresponding key legal sources do not have an original URL or a local original text path, one must be registered blocker, and determine handoff_ready = false. Whether the jurisdiction is known or can be inferred does not change this conclusion. For purely procedural organization, material archiving, or tool-type Briefs that do not contain specific legal advice, the missing original text of the legal source may be registered as warning。
State transition rules (core fix in v1.0.2, resolving T-014 ambiguity)
| Current state | Number of blockers in the to-be-confirmed list | Action |
|---|---|---|
structurally_complete = false |
— | Return to the corresponding step to complete the fields,do notdeliver |
structurally_complete = true，handoff_ready = false |
≥ 1 | At deliverymustexplicitly mark at the top of the Brief and in the to-be-confirmed list: "contains blockers, downstream direct compilation is not recommended"; the user decides whether to force handover |
structurally_complete = true，handoff_ready = true |
0 | Can be delivered normally; warning items may remain |
Uniqueness of determination: any Agent reading the same Brief, as long as it follows the above rules, must have a consistent determination result for structurally_complete / handoff_ready . If there is a disagreement where "one Agent determines it can be handed over, another determines it cannot", handoff_ready = (blocker 数 = 0) shall prevail.
Failure Conditions
If the following situations occur, the Brief shouldbe determined as structurally_complete = false rather than delivered：
- Any of the five questions is completely blank and not marked "to be supplemented"
- Involves a final legal conclusion but does not state "requires review by a practicing lawyer"
- The materials contain obviously sensitive information (ID card / mobile phone number / real name of a party) but the desensitization status is not stated
Missing key legal sources does not change the field completeness determination of
structurally_complete; as long as the gap has been truthfully listed asblocker, it should be determined asstructurally_complete = true、handoff_ready = false, and it must not be written at the same time as structurally incomplete and handoverable with warnings.
Human Review
The following outputsmustbe reviewed by a practicing lawyer (linked to the T-010 safety boundary):
- Final legal opinion / complaint / answer / finalized contract
- Litigation response strategy recommendations
- Compliance rectification recommendations (involving regulatory reporting)
- Contract review conclusions for high-value subject matter (contract amount / claim amount > a certain threshold; a threshold table for the user team is recommended)
Workflow
Step 0: Determination path (do first) + safety pre-check
Read the user's first message and determine which path to take:
| User speech characteristics | Path |
|---|---|
| Mentions "this is my sample/SOP/Q&A/historical document/case", or pasted/uploaded materials | Has materials path |
| Says "I want to make an XX skill but don't know how to start" "I have experience in my head but have never organized it" "teach me how to do it" | No materials path |
| Satisfies both | First follow the path with materials, then use interviews to fill the gaps |
Safety pre-check(required regardless of which path is taken):
- Sensitive material identification: Check whether the content uploaded or pasted by the user contains obviously sensitive information (see the "Sensitive Material Identification Checklist" at the top of alignment-strategies.md ).
- Desensitization prompt: If there is sensitive information, prompt the user: "Detected [sensitive information type], please confirm whether it has been desensitized / whether you need this Skill to assist with desensitization (prompt only, do not automatically rewrite the original file)".
- External transfer confirmation: By default,do notupload / share with any external service. If external retrieval or services are needed,you mustexplicitly ask the user for confirmation.
Do not force the path with materials when there are no materials—it will produce an empty Brief.
Step 0.5: Negative trigger determination (mandatory since v1.0.4)
After determining the pathand before starting the interview/clarification, you must first use the table below to exclude scenarios in which this Skillshould not be triggered. If any row matches,do not enterthe alignment process, and wrap up according to the "suggested destination" (do not produce a Brief).
| User input characteristics | Determination | Suggested destination |
|---|---|---|
| Non-legal Skill creation (video download / reading notes / general tools / content creation) | ❌ Not triggered | General skill-creator or tool-type skills |
| A complete executable Brief has already been provided and there is an explicit request to "compile directly / generate directly, don't ask me" | ❌ Not triggered | Hand directly to skill-creator for compilation |
| Only asking "what is a skill / how to install it / is it suitable for me" (usage consultation) | ❌ Not triggered | General help documentation / skill-manager |
Gray-area scenarios(if the table below is matched, you mustask follow-up questions first before determining, and must not directly trigger or refuse):
| User input characteristics | Follow-up question wording | Leaning |
|---|---|---|
| "Help a lawyer make a case management tool" | "Is the core legal business workflow, or general scheduling/project management?" | Legal business workflow → triggered; general scheduling → not triggered |
| "Review contract clause compliance, but go through technical compliance" | Point out that "technical compliance ≠ legal compliance" | Not triggered |
| "Turn the company approval process into a skill" | "Does the process involve legal judgment (contract/compliance/labor relations)?" | Involves → triggered; pure OA → not triggered |
The sole principle for gray-area determination:whether the scenario involves the legal domain(contract/litigation/compliance/due diligence/intellectual property/labor/corporate/family/tax/criminal). When uncertain, ask the user "Are you trying to turn legal experience into a Skill?"—if the answer is no, do not trigger.
Step 1A: Path with materials—multi-category clarification
1A.1 Material classification (expanded to composable types since v1)
v1 expands material classification from three categories toseven composable types(Original 3 categories retained and 4 new categories added):
| Category | Identifying features | Clarify key points |
|---|---|---|
| Sample (sample) | Finished legal documents: attorney letters, complaints, contracts, review opinions | Extract structural skeleton + style features + risk point checklist |
| Process SOP (sop) | Step-by-step documents: case handling procedures, review checklists, court appearance preparation | Extract decision points + branch conditions + quality checkpoints |
| Q&A (qa) | Question and answer: client consultations, training Q&A, internal FAQ | Extract high-frequency questions + standard answers + exception scenarios |
| Rules package (rules) | Structured rules: threshold tables, judgment criteria, compliance checklists | Extract thresholds and judgment logic + sources + scope of application |
| Dialogue revision records (revisions) | Historical conversations / repeated revision traces: lawyer-client communications, manuscript revision annotations | Extract style preferences + feedback revision tendencies + common pitfalls to avoid |
| Tools and data sources (tools-data) | Tool outputs, API data, database snapshots | Extract input/output formats + data sources + linkage methods |
| Original legal sources (authorities) | Legal provisions, judicial interpretations, original case texts, regulatory documents | Extract legal source timeliness + scope of application + citation format |
Migration notes: v0.x supports only the first three categories; starting from v1, the latter four categories are also formal material types. Each references (alignment-strategies.md) provides the complete clarification strategy for each category.
1A.2 Domain / Stage / Task Identification (orthogonal tags starting from v1)
v0.x enforces a single "legal template skeleton." Starting from v1, this changes toorthogonal tags— four dimensions are selected independently:
| Dimension | Description | Typical values |
|---|---|---|
| Task action type (action) | What action the Skill performs | Drafting / review / negotiation / litigation / defense / due diligence / scanning / extraction / organization / monitoring |
| Legal domain (domain) | Legal branch involved | Contract / litigation / compliance / due diligence / intellectual property / labor / corporate / family / tax / criminal / other |
| Procedural stage (stage) | Time or procedural position | See legal-domain-mapping.md stage enum |
| Document type (doc_type) | Output form | demand-letter / complaint / answer / contract-review / compliance-report / tool / data-pack |
Starting from v1, all Skills are no longer forced to choose a single legal template skeleton. A cross-domain task can simultaneously carry multiple
domaintags; non-document / tool-type tasks usedoc_type: toolordata-packidentifiers.
1A.3 Five guiding completion questions
After clarification, show the user the elements already extracted from the materials,clearly point out the gaps(usually the three sub-items of question 4 "deliver to whom" and the legal source timeliness of question 5 "knowledge support"), and guide the user to fill them in. Ask only 1-2 gaps at a time; do not throw out five empty fields at once and scare the user away.
1A.4 Completion Strategy for Elements Not Covered by Materials
When the materials do not directly reflect a certain element, handle it according to the following strategy,do not silently infer：
| Element | There are clues in the materials | There are no clues in the materials |
|---|---|---|
Question 4 operator |
Infer from the usage scenario, list the basis for the inference,ask the user to confirm | Switch to interview mode, use interview-guide.md Question 4 to guide the user to complete it |
Question 4 represented_party |
Infer from the document header / signature block / stance,ask the user to confirm | Complete in interview mode; a common error is mistakenly filling in judge (the judge is output_audience） |
Question 4 output_audience |
Infer from the document's language style / citation format,ask the user to confirm | Complete in interview mode |
Question 5 Legal source effective_date |
Extract from the version number / citation date marked in the materials | Mark unverified + list in the pending confirmation list |
| Question 3 Decision points | Extract steps from the SOP + infer decision points from the samples | Mark "decision points are inferred from samples and may miss branches" |
Key principle: Inference is not scary; what is scary is not telling the user "this part is my inference." Each inferred element must be marked in the "pending confirmation list" with the basis for the inference and the method of confirmation.
Step 1B: No-materials path—Socratic interview
Do not assume the user has any materials. Through question-by-question guidance, dig out the answers to the five questions from the user's "experiential intuition."
The interview follows three iron rules:
- One question at a time: Do not list five questions at once; the user will give up.
- Give anchors, not answers: Pair each question with 2-3 specific examples to help association, but do not make decisions for the user.
- Keep asking until it is specific: If the user says "help clients" → ask further "at which stage, in what role, and in what scenario do they need help."
Question 4 is split into three sub-questions in v1 for successive interviews (see interview-guide.md）：
- 4a：
operator— Who will directly use this Skill? - 4b：
represented_party— Whose stance does the Skill serve? - 4c：
output_audience— Who will ultimately see the output?
Question 5 is newly added in v1Legal source timeliness confirmationsub-question (see interview-guide.md): the effective date / jurisdiction / whether the legal basis is currently valid.
Step 2: Identify a set of orthogonal tags
Whether it is the materials path or the interview path, it must ultimately land on a set oforthogonal tags:
- Task action type: review / drafting / scanning / extraction / ... (see legal-domain-mapping.md）
- Legal domain: contract / litigation / compliance / ...
- Procedural stage: see the stage enumeration
- Output form：text-document / table / tool / data-pack
Tag combination examples：
- Labor contract review = review + labor + non_litigation + text-document
- App data compliance scan = scan + compliance + post_launch + table
- Evidence organizer = organize + litigation + first_instance + data-pack (Non-document type）
- IP enforcement strategy = strategy + IP + enforcement + text-document
No longer enforce a 'single legal template skeleton', so that cross-domain / tool-type tasks can be routed correctly.
Step 3: Produce legal-skill-brief/v1
Assemble the answers to the five questions into a Legal Skill Brief v1, with the format following standard-prompt-output.md。
Key constraints of Brief v1：
- The top of the Brief must be marked with
legal-skill-brief/v1andquestion-set/v1versions. - Context metadata (
skill_family/jurisdiction/stage/operator/represented_party/output_audience/doc_type/tags) isoptional metadata—downstream consumers may omit reading it, but not reading it does not affect the completeness of the Brief. - All five question elements must be present; none may be missing. If an element still cannot be determined after the interview, mark it
[待用户确认]and list it in the 'to-be-confirmed list' at the end classified byblocker/warning,do not fabricate。 - Legal source entriesmustinclude
effective_date(effective date) /jurisdiction/verification_statusthree columns,verifiedentries must have the证据column added (see above). - Thresholds and judgment criteriamustinclude
source(source). - Material provenance quality mustbe filled in (
unratedalso counts). - Security and desensitization statement sectionmustbe filled in (even if there is no sensitive information, fill in 'no sensitive information identified').
- Identifiers
skill_familyuse kebab-case(e.g.,labor-contract-review); stage / role / doc_type use snake_case. - Error-prevention check of the three sub-items of Question 4 (mandatory since v1.0.4, corresponding to C-06): Before assembling the Brief,mustperform a mutual-exclusivity check on
operator/represented_party/output_audience, and append a line 'Error-prevention check' at the end of Section II.4 of the Brief: confirm one by one that (a) none of the three is empty, (b)represented_partyis not a reader-type role (judges/opposing counsel/regulatory authorities areoutput_audience，absolutely notfilled intorepresented_party）、(c)operatorandoutput_audienceare not confused. If any item is in doubt, it must not be silently let pass; it must be marked as blocker or warning in the 'to-be-confirmed list'. - Structured degradation for missing legal sources (mandatory since v1.0.6, corresponding to C-07/C-08): When the materials or interviewdo not provide any original text of authorities legal sources(only legal provision names, or no legal source clues at all), the Section II.5 legal basis tablemustexplicitly write a placeholder in the first row: 'Original legal source text missing: the following entries are all
unverified, to be upgraded after the user supplements authoritative sources', and each legal source rowverification_statusmust uniformlyunverified、effective_datefill inunverified（must notfabricate an effective date based on the name). If the Brief will produce specific legal advice, it must registerblocker('key original legal source text missing') in the 'to-be-confirmed list' and determinehandoff_ready = false; otherwise register warning ('legal source timeliness not verified'). A known or locatable jurisdiction cannot lower the blocker level. - Do not register empty-shell legal source rows (finding#1 backfill, mandatory since v1.0.5, corresponding to C-07/C-08 refinement): Every row of the Section II.5 legal basis tableMustbe a "locatable, concrete legal source"—at minimum possessing
jurisdiction+ an identifiable statute/document identifier (article number, full document title, or case docket number) +effective_date/verification_statusthree columns. When the material provides only alegal source topic or regulation name(e.g., "Personal Information Protection Law"), but no article number, no original text, and no applicable reference,must notregister an empty-shell entry of "name + all three columns blankunverified" merely to fill out the table; the correct approach is: only transcribe that name as a "lead to be supplemented" in the degraded first-row placeholder, and clearly list in the "items to be confirmed" that "the specific article number/applicable version of the XX Law needs to be supplemented," and only after the user supplements it should a formal legal source row be registered. Exception: if the material has already named the jurisdiction and the name is sufficient to locate the scope of the legal source (e.g., case-03 clearly specifies CN + four regulation names), the name row may be transcribed buteffective_date/verification_statusmust stillunverified, and it must be noted as "name only, article number and effective date to be supplemented," andmust notwrite any specific legal conclusion on that basis.
Step 4: Delivery and Handoff
- Present the Brief to the user for confirmation.
- After the user confirms,clearly indicatethat the next step may invoke:
- General
skill-creator(natural-language intent friendly) - or a legal-domain Skill orchestrator available in your environment (routing-decision friendly)
- General
- This Skill does not directly produce SKILL.md / references / scripts—that is the downstream's job.
Five-Question Element Self-Check List
Before producing the Brief,mustcheck item by item:
- Question 1 What is input: necessary inputs and optional inputs are listed, and information sources are marked
- Question 2 What is output: output format, word count/structure requirements, quality standards, and output form are specified
- Question 3 Processing logic: main steps, decision points, optional branches, and exception paths are written
- Question 4 To whom delivered (v1 three sub-items):
-
operatorspecified or marked "to be supplemented" -
represented_partyspecified or marked "to be supplemented" (not to be confused withoutput_audienceconfused） -
output_audiencespecified or marked "to be supplemented" - trigger scenario + tone and style are written
-
- Question 5 Knowledge support: legal sources carry three columns (jurisdiction / effective_date / verification_status); template sources; risk list; style preferences
- Context metadata: identifier uses kebab-case; stage / role / doc_type use snake_case
- Rule engine (if applicable): thresholds and judgment criteria carry source
- Material traceability: quality field is filled in
- Security and desensitization: sensitive information status, external transmission policy, and high-risk conclusion review are written
- Items to be confirmed: classified by blocker / warning
- Status determination: mark
structurally_completeandhandoff_ready(see the completeness rules section)
If any item is missing or ambiguous, return to the corresponding step to complete it,do not let a half-finished product pass。handoff_ready = false , the number of blockers must be explicitly marked at the top of the Brief.
Security and Compliance Boundaries
This Skill follows the following security constraints when processing user materials (consistent with standard-prompt-output.md 's "V. Security and Desensitization Notes" paragraph):
Sensitive Material Handling
- Do not assume by default that the user has desensitized: When processing historical documents, consultation records, or internal SOPs, proactively identify clearly sensitive information (see alignment-strategies.md top "Sensitive Material Identification Checklist").
- Prompt but do not automatically rewrite the original file: After discovering sensitive information, prompt the user to desensitize and ask for their confirmation; do not modify user-provided content without authorization.
- Use desensitized expressions by default in the Brief: When real names / amounts / case names provided by the user are cited in the Brief, it is recommended to replace them with desensitized forms (e.g., "buyer/seller", "Company XX").
Prohibit external transmission by default
- Any external retrieval / upload / sharing must be explicitly confirmed by the user. The default behavior is no external transmission, no upload, and no calling of external APIs.
- If online retrieval is needed (e.g., to check the latest judicial interpretations),inform the user first, then execute。
Legal Source Time Point and Version
- Each legal source citationmustinclude
effective_date（effective date, not the adoption date / promulgation date) andjurisdiction(jurisdiction). - Legal sources whose timeliness the user has not confirmed are marked as
verification_status: unverified，not treated as a certain basisfor output. - Where regulatory rules / industry standards are involved, the most recent update date must be additionally noted.
- verified evidence threshold(as of v1.0.2): legal sources marked
verifiedmust meet the minimum evidence requirements (source_url/source_file+verified_by+verified_at+version_as_of); when there is only the name of a legal provision or it is reverse-inferred from samples,must notbe upgraded toverified(see standard-prompt-output.md）。
High-risk conclusions must be reviewed by a practicing lawyer
The following outputs must be marked in the Brief as "requires review by a practicing lawyer":
- Final legal opinions / complaints / statements of defense / contract finalization documents
- Litigation and response strategy recommendations (involving procedural choices and limitation period determinations)
- Compliance remediation recommendations (involving regulatory reporting or major business changes)
- Contract review conclusions for high-value subject matter (as defined in the user team's threshold table)
alignment does not replacelawyer review; nor do the Skills compiled downstream replace it.
Input Requirements
This Skill accepts the following inputs:
- Material path: User-provided file path (supports .md / .txt / .docx)
- Pasted content: Samples / SOPs / Q&A / rules / dialogue revisions / tool data / original legal source texts directly pasted by the user
- Scenario description: The user describes in natural language "I want to make an XX skill"
- Mixed: Any combination of the above
Output Requirements
- One Legal Skill Brief v1(markdown format, following standard-prompt-output.md）
- The Brief must have a "Pending Confirmation List" appended at the end (categorized by blocker / warning)
- Clearly prompt to call the general-purpose
skill-creator(or the legal domain Skill orchestrator) to complete compilation
Applicable Scenarios
- A lawyer turns a certain type of document accumulated over many years into a reusable Skill
- A law firm consolidates internal SOPs into a team-level Skill
- Distill reusable Q&A Skills from client consultation records
- Legal trainers turn course methodologies into Skills
- Consolidate rule packages / threshold tables into executable Skills
- Package tools / data sources into callable Skills
- Cross-domain tasks (composite Skills involving contracts + litigation + compliance at the same time)
- Any scenario of "I have experience/materials and want to make a Skill but don't know how to start"
Boundaries
- Does not directly generate Skill files: only produces Brief v1, and compilation is handed off downstream.
- Does not replace legal judgment: the clarified "handling logic" and "risk checklist" must be finally confirmed by a practicing lawyer.
- Does not make inferences with insufficient evidence: conclusions that materials or interviews are insufficient to support are marked
[需补充], without speculation. - Does not disclose user data externally: by default no external services are called; external operations require explicit user confirmation.
- Does not verify the currency of legal sources: whether a legal source is currently effective is marked by the user in
effective_date/verification_status, and alignment does not make judgments for the user.
Scenarios that should not trigger (negative boundaries, T-017)
The following scenariosshould nottrigger this Skill:
- Non-legal Skill creation: the upfront alignment for general tool-type, content creation-type, and non-legal business process-type Skills is not handled by this Skill. Judgment criterion: whether the scenario involves the legal domain (contracts / litigation / compliance / due diligence / IP / labor / corporate / family / tax / criminal).
- The user has already provided a complete executable Brief and explicitly requests direct compilation: when the user has already given a structurally complete Brief and explicitly says "compile directly / generate SKILL.md directly", it should be handed directly to skill-creator, without going through this Skill's alignment process.
- The user is only asking "what is a Skill / how to use a Skill": this is a usage inquiry, not creation upfront alignment, and does not trigger.
If you are unsure whether it should trigger, first ask the user "Are you trying to turn legal experience into a Skill?" — if the answer is no, it does not trigger.