Stats
Actions
Tags
From ai-writing-plugin
中文优先指导 fsr document type work，同时保留 functional safety requirement、safety goal、ASIL、source tier、provenance、sample/reference、HITL、final-report、TSC-deferred 和 candidate-update boundaries。
How this skill is triggered — by the user, by Claude, or both
Slash command
/ai-writing-plugin:fsrThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this guideline for `task_type: fsr`.
Use this guideline for task_type: fsr.
默认用中文解释 FSR workflow、Safety Goal traceability、ASIL inheritance、requirement completeness、verification method 和 open confirmations。保留 fsr、Functional Safety Requirements、Safety Goals、ASIL、TSC deferred、HITL、NEEDS_USER_CONFIRMATION 等英文关键术语。
如果功能安全材料为英文，可以保留原文需求语句和引用片段；用户说明优先中文。不要把 FSR candidate wording 写成 safety requirement approval、compliance approval 或 TSC output。
This Skill.md is guideline material only. It must use the plugin workflow and must call the Python deterministic engine through write-run or /ai-writing-plugin:write. It is not prompt-only execution, and it does not replace artifact contracts, schema validation, source index, evidence trace, review, verify, HITL trace, or candidate update state control.
FSR supports review-ready Functional Safety Requirements packages. The input materials normally include item definition context, confirmed Safety Goals, a supplied HARA summary or safety-goal trace extract, project constraints, templates, checklists, references, and sample document shapes.
The FSR document type can draft and organize functional safety requirement candidates. It must not approve safety requirements, confirm compliance, validate ASIL inheritance, or claim the requirement set is complete without project source evidence or HITL.
There is no automatic professional approval in this workflow.
fsr is an official L3 built-in document type backed by built-in DocumentTypeRules, fixtures, regression tests, committed eval cases, and this domain guideline.
The command layer remains generic. There is no fsr-specific pipeline, no fsr_pipeline.py, and no duplicated workflow. The project rule is one plugin, one pipeline.
TSC deferred: Phase N8 does not create a TSC document type, TSC Skill, TSC fixture, TSC profile, or technical safety concept workflow.
Recommended inputs:
item_definition_source.md as sourcesafety_goals_source.md as sourcehara_summary_source.md or a safety-goal trace extract as sourcefsr_template.md as templatefsr_checklist.md as checklistfsr_reference.md as referencefsr_sample.md as sampleOnly source inputs can support project facts. HITL / explicit human confirmation is T0 when captured by the workflow.
The FSR default sections are:
The table should keep requirement identifiers, requirement statements, linked Safety Goals, ASIL, rationale, verification method, evidence source, and confirmation status traceable. Missing inputs become open items.
FSR critical claim categories include:
These require source or HITL. If evidence or a recorded human decision is missing, keep NEEDS_USER_CONFIRMATION.
Do not automatically finalize:
Safety Goals and ASIL can be carried from project source material, but the final professional conclusion still needs human review. A HARA summary may support the trace it explicitly contains; it must not be used as a blanket approval for all FSR content.
The following are forbidden final claims unless explicit T0/T1 support and a separate human approval process allow them:
These are warning examples, not recommended output.
fsr_reference.md is T3; it may support methodology or terminology but must not prove project-specific Safety Goals, ASIL, requirement wording, verification status, completeness, compliance, or approval.fsr_sample.md is T4; it can guide structure, style, section granularity, and table shape only.sample is not a fact source. sample is not fact source. reference cannot prove project facts. T3/T4/T5 cannot support critical claim by themselves. Every critical claim needs provenance and a source tier.
Review focus includes:
Verification focus includes:
Do not create a TSC document. Do not create technical safety requirements. Do not create a technical safety concept report. Do not create technical safety mechanisms as final facts. Do not create an FSR-specific pipeline.
Downstream technical allocation may be listed as a future open item only when the source material justifies that boundary note. It must not become a TSC deliverable.
candidate update artifacts may be generated only as proposed / inactive material.
candidate_profile_update.yaml, candidate_skill_patch.md, and promotion reports must not auto-apply changes, must not overwrite stable Skill.md, and must not promote profiles without explicit human approval and eval gate evidence in a later workflow.
Use the existing deterministic Python engine. Do not add heavy dependencies. no RAG. no LangChain. no vector DB. Do not add a complex agent framework.
.venv/bin/python -m ai_writing_plugin write-run --task examples/fsr_demo_fixture/task.yaml
npx claudepluginhub exquisite0828/ai_writer_plugin --plugin ai-writing-pluginGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.