OpenArc Entry
Use this as the first stop when the user says "use OpenArc" or asks for repository governance without naming a specific skill.
Fast Routing
Map the user's request to the narrowest skill:
| User Intent |
Use |
| "Set up OpenArc here" |
repository-governance, then profile-specific governance skills as needed |
| "What is missing?" / "Audit this repo" |
repository-governance in read-only audit mode, then run the scan helper if available |
| "Clarify this request" / "New feature" / "New goal" |
clarification-gate, then route to PRD, spec, plan, or implementation |
| "Fix this bug" / routine implementation |
Implement directly when scope, constraints, and validation are clear |
| "Write PRD" |
product-governance |
| "Write spec" |
spec-workflow |
| "Plan implementation" |
planning-engine |
| "Define design system" |
design-governance |
| "Define brand" |
brand-governance |
| "Organize assets" |
assets-governance |
| "Migrate existing workspace" |
workspace-migration |
| "Version this change" |
version-governance |
| "Branch, commit, or PR" |
release-workflow; stop after the requested git/PR work |
| "Release or publish" |
release-workflow; require an explicit release request and confirmation |
| "Prepare for open source" |
open-source-maintenance |
Default First Pass
For a new or unfamiliar repository:
- Scan existing files before writing.
- Use the detected
repo_profile to separate required, relevant, and optional governance.
- For an
unknown profile, use only a README and one agent guide as the minimum baseline; report missing files, but create them only when setup is explicitly requested. Do not infer product, design, brand, spec, plan, task, or archive needs from the profile alone.
- Report what already exists, what is profile-relevant missing, and what conflicts.
- Choose the smallest next action:
- direct implementation for routine work with clear scope and validation
- clarification only for material unknowns
- one spec when behavior, acceptance criteria, or compatibility needs durable alignment
- one plan when sequencing, migration, rollback, or validation risk needs structure
docs/TASKS.md only for work spanning multiple stages, people, or agents- bootstrap or migration only when explicitly requested
- Ask only for decisions that materially affect output.
Helper Scripts
If this plugin's scripts/openarc.py is available, prefer:
python3 plugins/openarc/scripts/openarc.py scan .
python3 plugins/openarc/scripts/openarc.py doctor plugins/openarc
Use script output as evidence, not as a replacement for judgment.
Rules
- Do not load every OpenArc skill by default.
- Treat audit, review, scan, and "what is missing?" requests as read-only. Report findings without creating or modifying files.
- Write governance files only when the user explicitly requests setup, initialization, apply, repair, or migration work.
- A branch, commit, or PR request does not authorize a release. Trigger or publish a release only after an explicit release request and confirmation.
- Do not create all governance docs unless the user asks for full setup.
- Do not make governance setup, a spec, a plan, or tasks prerequisites for routine implementation.
- Use
clarification-gate before PRD, spec, plan, or implementation work only when material product, behavior, compatibility, migration, or risk decisions remain unresolved.
- Use
docs/specs/* as the canonical spec location and docs/TASKS.md as the canonical active task source.
- Do not require
docs/DESIGN.md, docs/BRAND.md, or docs/assets/* for script, CLI, automation, library, or docs-only repositories unless the repo already has UI or brand signals.
- Prefer a small first useful artifact over a complete governance dump.
- Existing repository conventions win over OpenArc templates.
1---2name: openarc3description: Use when a user asks to use OpenArc generally, initialize governance, improve repository continuity, audit governance drift, migrate an existing workspace, or choose which OpenArc skill should handle a request.4---56# OpenArc Entry78Use this as the first stop when the user says "use OpenArc" or asks for repository governance without naming a specific skill.910## Fast Routing1112Map the user's request to the narrowest skill:1314| User Intent | Use |15| --- | --- |16| "Set up OpenArc here" | `repository-governance`, then profile-specific governance skills as needed |17| "What is missing?" / "Audit this repo" | `repository-governance` in read-only audit mode, then run the scan helper if available |18| "Clarify this request" / "New feature" / "New goal" | `clarification-gate`, then route to PRD, spec, plan, or implementation |19| "Fix this bug" / routine implementation | Implement directly when scope, constraints, and validation are clear |20| "Write PRD" | `product-governance` |21| "Write spec" | `spec-workflow` |22| "Plan implementation" | `planning-engine` |23| "Define design system" | `design-governance` |24| "Define brand" | `brand-governance` |25| "Organize assets" | `assets-governance` |26| "Migrate existing workspace" | `workspace-migration` |27| "Version this change" | `version-governance` |28| "Branch, commit, or PR" | `release-workflow`; stop after the requested git/PR work |29| "Release or publish" | `release-workflow`; require an explicit release request and confirmation |30| "Prepare for open source" | `open-source-maintenance` |3132## Default First Pass3334For a new or unfamiliar repository:35361. Scan existing files before writing.372. Use the detected `repo_profile` to separate required, relevant, and optional governance.383. For an `unknown` profile, use only a README and one agent guide as the minimum baseline; report missing files, but create them only when setup is explicitly requested. Do not infer product, design, brand, spec, plan, task, or archive needs from the profile alone.394. Report what already exists, what is profile-relevant missing, and what conflicts.405. Choose the smallest next action:41 - direct implementation for routine work with clear scope and validation42 - clarification only for material unknowns43 - one spec when behavior, acceptance criteria, or compatibility needs durable alignment44 - one plan when sequencing, migration, rollback, or validation risk needs structure45 - `docs/TASKS.md` only for work spanning multiple stages, people, or agents46 - bootstrap or migration only when explicitly requested476. Ask only for decisions that materially affect output.4849## Helper Scripts5051If this plugin's `scripts/openarc.py` is available, prefer:5253```bash54python3 plugins/openarc/scripts/openarc.py scan .55python3 plugins/openarc/scripts/openarc.py doctor plugins/openarc56```5758Use script output as evidence, not as a replacement for judgment.5960## Rules6162- Do not load every OpenArc skill by default.63- Treat audit, review, scan, and "what is missing?" requests as read-only. Report findings without creating or modifying files.64- Write governance files only when the user explicitly requests setup, initialization, apply, repair, or migration work.65- A branch, commit, or PR request does not authorize a release. Trigger or publish a release only after an explicit release request and confirmation.66- Do not create all governance docs unless the user asks for full setup.67- Do not make governance setup, a spec, a plan, or tasks prerequisites for routine implementation.68- Use `clarification-gate` before PRD, spec, plan, or implementation work only when material product, behavior, compatibility, migration, or risk decisions remain unresolved.69- Use `docs/specs/*` as the canonical spec location and `docs/TASKS.md` as the canonical active task source.70- Do not require `docs/DESIGN.md`, `docs/BRAND.md`, or `docs/assets/*` for script, CLI, automation, library, or docs-only repositories unless the repo already has UI or brand signals.71- Prefer a small first useful artifact over a complete governance dump.72- Existing repository conventions win over OpenArc templates.
Yipxiyi