القائمة
Switch the openspecPath in .claude/project-context.json by picking one of the registered projects from a menu, instead of hand-editing the absolute path.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | set-openspec-path |
| description | Switch the openspecPath in .claude/project-context.json by picking one of the registered projects from a menu, instead of hand-editing the absolute path. |
| disable-model-invocation | true |
| allowed-tools | Read Write |
Update openspecPath in .claude/project-context.json so the SessionStart hook
injects the chosen project's openspec docs folder. This replaces hand-editing
the absolute path with a menu choice.
Steps:
Read .claude/project-context.json from the current project root.
setup-project-context
first and stop.Collect the projects array (entries with a non-empty path). Present the
choices to the user with AskUserQuestion:
name (falling back to
path), with the resulting <path>/openspec shown in the description.openspecPath to "" — the hook then falls back to
<project-root>/openspec automatically.projects is empty, tell the user there are no registered projects to
pick from and stop.Write the result back into .claude/project-context.json:
openspecPath to <chosen project path>/openspec
(forward slashes, no trailing slash).openspecPath to "".roleBasedDelegation, projects, ordering,
formatting) unchanged — only the openspecPath value is modified.Report the new openspecPath value and remind the user:
/reload-plugins
does not re-run SessionStart, so start a new session or /clear.openspec folder, the hook automatically falls
back to the working-directory openspec at injection time.Record an architecture/design decision as an ADR (Architecture Decision Record) in the target repository's docs/adr/. Use when the user wants to document a design decision, its alternatives and consequences, or says "record this decision" / "write an ADR".
Generate a self-contained HTML manual-testing guide for an implemented change — environment setup, a visual test-flow diagram, step-by-step scenarios with expected results, and interactive pass/fail checkboxes with a Markdown results export. Use when the user wants to verify an implementation by hand, asks "how do I test this", or wants a verification document for a feature/branch/PR.
Generate a self-contained HTML onboarding tour of a repository — architecture diagram, directory map, key flow walkthroughs, and a recommended reading order — for new team members. Use when the user wants onboarding material, asks for a codebase overview/architecture tour, or wants to explain a repo to someone new.
Generate a self-contained HTML code-review guide for the current changes — big-picture overview, architecture diagram of affected modules, a file/class responsibility map, and an annotated change walkthrough — so a reviewer can grasp the whole implementation before diving into the diff. Use when the user wants review material for a branch/PR, asks to "explain the changes for review", or wants a visual summary of what was implemented where.
Investigate a reported bug to its root cause — reproduce, trace the code path, identify the defect with evidence, assess blast radius, and propose fix candidates without changing code. Use when the user reports or pastes a bug/defect/unexpected behavior and wants it diagnosed, or asks "why is X happening".
Capture a reusable, non-obvious project insight into the rules home where it will auto-inject in future sessions. Use when investigation or implementation surfaces knowledge worth persisting (a gotcha, a convention, the "why" behind a decision), or when the user asks to remember a project learning.