[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ME2BKBJE87TY6F12EX2ASG":3,"skill-same:01M6ME2BKBJE87TY6F12EX2ASG":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6ME2BKBJE87TY6F12EX2ASG","openspec-onboard",null,"Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work. Also use when the user says \"openspec onboard\" or \"opsx onboard\".","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1554,"MIT","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Falexeyco\u002Foh-my-openspec\u002Fskills\u002Fopenspec-onboard\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"openspec onboard","onboard","openspec","use","when","codebase","for","with","complete","cycle","narration","cli","user","work","Bash","onboarding","workflow","2026-11-10 10:12:30",false,"---\nname: openspec-onboard\ndescription: Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work. Also use when the user says \"openspec onboard\" or \"opsx onboard\".\nallowed-tools: Bash(openspec:*)\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n  author: openspec\n  version: \"1.0\"\n  generatedBy: \"1.16.1\"\n---\n\nGuide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.\n\n**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store \u003Cid>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store \u003Cid>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change \"\u003Cname>\" --json --store \"\u003Cid>\"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec\u002F` root.\n\n**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store \u003Cid>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `\"root\": null` means it is not - there is no `openspec\u002F` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.\n\nOne `\"root\": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec\u002Fconfig.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.\n\nOtherwise, with no root, what happens next depends on how this workflow was reached:\n\n- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.\n- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store \u003Cid>`), or continue without OpenSpec for this request. Wait for their answer.\n\nIn both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec\u002F` files, and do not let a command create it.\n\n---\n\n## Preflight\n\nBefore starting, check if the OpenSpec CLI is installed:\n\n```bash\n# Unix\u002FmacOS\nopenspec --version 2>&1 || echo \"CLI_NOT_INSTALLED\"\n# Windows (PowerShell)\n# if (Get-Command openspec -ErrorAction SilentlyContinue) { openspec --version } else { echo \"CLI_NOT_INSTALLED\" }\n```\n\n**If CLI not installed:**\n> OpenSpec CLI is not installed. Install it first, then come back to `\u002Fopenspec-onboard`.\n\nStop here if not installed.\n\n---\n\n## Phase 1: Welcome\n\nDisplay:\n\n```\n## Welcome to OpenSpec!\n\nI'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.\n\n**What we'll do:**\n1. Pick a small, real task in your codebase\n2. Explore the problem briefly\n3. Create a change (the container for our work)\n4. Build the artifacts: proposal → specs → design → tasks\n5. Implement the tasks\n6. Archive the completed change\n\n**Time:** ~15-20 minutes\n\nLet's start by finding something to work on.\n```\n\n---\n\n## Phase 2: Task Selection\n\n### Codebase Analysis\n\nScan the codebase for small improvement opportunities. Look for:\n\n1. **TODO\u002FFIXME comments** - Search for `TODO`, `FIXME`, `HACK`, `XXX` in code files\n2. **Missing error handling** - `catch` blocks that swallow errors, risky operations without try-catch\n3. **Functions without tests** - Cross-reference `src\u002F` with test directories\n4. **Type issues** - `any` types in TypeScript files (`: any`, `as any`)\n5. **Debug artifacts** - `console.log`, `console.debug`, `debugger` statements in non-debug code\n6. **Missing validation** - User input handlers without validation\n\nAlso check recent git activity:\n```bash\n# Unix\u002FmacOS\ngit log --oneline -10 2>\u002Fdev\u002Fnull || echo \"No git history\"\n# Windows (PowerShell)\n# git log --oneline -10 2>$null; if ($LASTEXITCODE -ne 0) { echo \"No git history\" }\n```\n\n### Present Suggestions\n\nFrom your analysis, present 3-4 specific suggestions:\n\n```\n## Task Suggestions\n\nBased on scanning your codebase, here are some good starter tasks:\n\n**1. [Most promising task]**\n   Location: `src\u002Fpath\u002Fto\u002Ffile.ts:42`\n   Scope: ~1-2 files, ~20-30 lines\n   Why it's good: [brief reason]\n\n**2. [Second task]**\n   Location: `src\u002Fanother\u002Ffile.ts`\n   Scope: ~1 file, ~15 lines\n   Why it's good: [brief reason]\n\n**3. [Third task]**\n   Location: [location]\n   Scope: [estimate]\n   Why it's good: [brief reason]\n\n**4. Something else?**\n   Tell me what you'd like to work on.\n\nWhich task interests you? (Pick a number or describe your own)\n```\n\n**If nothing found:** Fall back to asking what the user wants to build:\n> I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?\n\n### Scope Guardrail\n\nIf the user picks or describes something too large (major feature, multi-day work):\n\n```\nThat's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.\n\nFor learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.\n\n**Options:**\n1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?\n2. **Pick something else** - One of the other suggestions, or a different small task?\n3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.\n\nWhat would you prefer?\n```\n\nLet the user override if they insist—this is a soft guardrail.\n\n---\n\n## Phase 3: Explore Demo\n\nOnce a task is selected, briefly demonstrate explore mode:\n\n```\nBefore we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.\n```\n\nSpend 1-2 minutes investigating the relevant code:\n- Read the file(s) involved\n- Draw a quick ASCII diagram if it helps\n- Note any considerations\n\n```\n## Quick Exploration\n\n[Your brief analysis—what you found, any considerations]\n\n┌─────────────────────────────────────────┐\n│   [Optional: ASCII diagram if helpful]  │\n└─────────────────────────────────────────┘\n\nExplore mode (`\u002Fopenspec-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.\n\nNow let's create a change to hold our work.\n```\n\n**PAUSE** - Wait for user acknowledgment before proceeding.\n\n---\n\n## Phase 4: Create the Change\n\n**EXPLAIN:**\n```\n## Creating a Change\n\nA \"change\" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives at the `changeRoot` reported by `openspec status --change \"\u003Cname>\" --json` and holds your artifacts—proposal, specs, design, tasks.\n\nLet me create one for our task.\n```\n\n**DO:** Create the change with a derived kebab-case name:\n```bash\nopenspec new change \"\u003Cderived-name>\"\n```\n\n**SHOW:**\n```\nCreated: \u003CchangeRoot from status JSON>\n\nThe folder structure:\n```\n\u003CchangeRoot>\u002F\n├── proposal.md    ← Why we're doing this (empty, we'll fill it)\n├── design.md      ← How we'll build it (empty)\n├── specs\u002F         ← Detailed requirements (empty)\n└── tasks.md       ← Implementation checklist (empty)\n```\n\nNow let's fill in the first artifact—the proposal.\n```\n\n---\n\n## Phase 5: Proposal\n\n**EXPLAIN:**\n```\n## The Proposal\n\nThe proposal captures **why** we're making this change and **what** it involves at a high level. It's the \"elevator pitch\" for the work.\n\nI'll draft one based on our task.\n```\n\n**DO:** Draft the proposal content (don't save yet):\n\n`\u003Ccapability-path>` is the spec directory relative to `specs\u002F` (for example,\n`user-auth` or `identity\u002Fuser-auth`). Use the exact existing path for modified\ncapabilities. For new capabilities, follow the project's established spec\norganization.\n\n```\nHere's a draft proposal:\n\n---\n\n# Proposal\n\n## Why\n\n[1-2 sentences explaining the problem\u002Fopportunity]\n\n## What Changes\n\n[Bullet points of what will be different]\n\n## Capabilities\n\n### New Capabilities\n- `\u003Ccapability-path>`: [brief description]\n\n### Modified Capabilities\n\u003C!-- If modifying existing behavior -->\n- `\u003Cexisting-capability-path>`: [brief description]\n\n## Impact\n\n- `src\u002Fpath\u002Fto\u002Ffile.ts`: [what changes]\n- [other files if applicable]\n\n---\n\nDoes this capture the intent? I can adjust before we save it.\n```\n\n**PAUSE** - Wait for user approval\u002Ffeedback.\n\nAfter approval, save the proposal:\n```bash\nopenspec instructions proposal --change \"\u003Cname>\" --json\n```\nThen write the content to the `resolvedOutputPath` from `openspec instructions proposal --change \"\u003Cname>\" --json`.\n\n```\nProposal saved. This is your \"why\" document—you can always come back and refine it as understanding evolves.\n\nNext up: specs.\n```\n\n---\n\n## Phase 6: Specs\n\n**EXPLAIN:**\n```\n## Specs\n\nSpecs define **what** we're building in precise, testable terms. They use a requirement\u002Fscenario format that makes expected behavior crystal clear.\n\nFor a small task like this, we might only need one spec file.\n```\n\n**DO:** Resolve where the spec file should be created:\n```bash\nopenspec instructions specs --change \"\u003Cname>\" --json\n# Use resolvedOutputPath from the JSON. If it is a glob, choose the concrete file path using the schema instruction and the change's context.\n```\n\nDraft the spec content:\n\n```\nHere's the spec:\n\n---\n\n# Spec Delta\n\n## ADDED Requirements\n\n### Requirement: \u003CName>\n\n\u003CDescription of what the system should do>\n\n#### Scenario: \u003CScenario name>\n\n- **WHEN** \u003Ctrigger condition>\n- **THEN** \u003Cexpected outcome>\n- **AND** \u003Cadditional outcome if needed>\n\n---\n\nThis format—WHEN\u002FTHEN\u002FAND—makes requirements testable. You can literally read them as test cases.\n```\n\nSave to the concrete file path chosen from `resolvedOutputPath`.\n\n---\n\n## Phase 7: Design\n\n**EXPLAIN:**\n```\n## Design\n\nThe design captures **how** we'll build it—technical decisions, tradeoffs, approach.\n\nFor small changes, this might be brief. That's fine—not every change needs deep design discussion.\n```\n\n**DO:** Draft design.md:\n\n```\nHere's the design:\n\n---\n\n# Design\n\n## Context\n\n[Brief context about the current state]\n\n## Goals \u002F Non-Goals\n\n**Goals:**\n- [What we're trying to achieve]\n\n**Non-Goals:**\n- [What's explicitly out of scope]\n\n## Decisions\n\n### Decision 1: [Key decision]\n\n[Explanation of approach and rationale]\n\n---\n\nFor a small task, this captures the key decisions without over-engineering.\n```\n\nSave to the `resolvedOutputPath` from `openspec instructions design --change \"\u003Cname>\" --json`.\n\n---\n\n## Phase 8: Tasks\n\n**EXPLAIN:**\n```\n## Tasks\n\nFinally, we break the work into implementation tasks—checkboxes that drive the apply phase.\n\nThese should be small, clear, and in logical order. Each group carries the tests and documentation for its own work - the last group is only for integration checks.\n```\n\n**DO:** Generate tasks based on specs and design:\n\n```\nHere are the implementation tasks:\n\n---\n\n# Tasks\n\n## 1. [Category or file]\n\n- [ ] 1.1 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]\n- [ ] 1.2 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]\n\n## 2. Integration Verification\n\n- [ ] 2.1 Verify [broader integration or system behavior] with [end-to-end test or observable result]\n\n---\n\nEach checkbox becomes a unit of work in the apply phase. Does this task breakdown look right?\n```\n\n**PAUSE** - Wait for user approval\u002Ffeedback.\n\nAfter approval, save to the `resolvedOutputPath` from `openspec instructions tasks --change \"\u003Cname>\" --json`.\n\nThen ask:\n> \"Tasks are saved. Ready to implement?\"\n\n**PAUSE** - Wait for user to confirm before implementation.\n\n---\n\n## Phase 9: Apply (Implementation)\n\n**EXPLAIN:**\n```\n## Implementation\n\nNow we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs\u002Fdesign informed the approach.\n```\n\n**DO:** For each task:\n\n1. Announce: \"Working on task N: [description]\"\n2. Implement the change in the codebase\n3. Reference specs\u002Fdesign naturally: \"The spec says X, so I'm doing Y\"\n4. Mark complete in tasks.md: `- [ ]` → `- [x]`\n5. Brief status: \"✓ Task N complete\"\n\nKeep narration light—don't over-explain every line of code.\n\nAfter all tasks:\n\n```\n## Implementation Complete\n\nAll tasks done:\n- [x] Task 1\n- [x] Task 2\n- [x] ...\n\nThe change is implemented! One more step—let's archive it.\n```\n\n---\n\n## Phase 10: Archive\n\n**EXPLAIN:**\n```\n## Archiving\n\nWhen a change is complete, we archive it. The archive path is derived from `planningHome.changesDir` and the date.\n\nArchived changes become your project's decision history—you can always find them later to understand why something was built a certain way.\n```\n\n**DO:** Archive the change (`--yes` answers the confirmation prompts, which you cannot answer from a tool call):\n```bash\nopenspec archive \"\u003Cname>\" --yes\n```\n\n**SHOW:**\n```\nArchived to: `\u003CplanningHome.changesDir>\u002Farchive\u002F\u003Ctarget-name>\u002F` (the target name prepends today's date, unless the name already starts with a `YYYY-MM-DD-` prefix — then it is kept as-is, no second date)\n\nThe change is now part of your project's history. The code is in your codebase, the decision record is preserved.\n```\n\n---\n\n## Phase 11: Recap & Next Steps\n\n```\n## Congratulations!\n\nYou just completed a full OpenSpec cycle:\n\n1. **Explore** - Thought through the problem\n2. **New** - Created a change container\n3. **Proposal** - Captured WHY\n4. **Specs** - Defined WHAT in detail\n5. **Design** - Decided HOW\n6. **Tasks** - Broke it into steps\n7. **Apply** - Implemented the work\n8. **Archive** - Preserved the record\n\nThis same rhythm works for any size change—a small fix or a major feature.\n\n---\n\n## Command Reference\n\n**The commands you have installed:**\n\n | Command          | What it does                               |\n |------------------|--------------------------------------------|\n | `\u002Fopenspec-propose` | Create a change and generate all artifacts |\n | `\u002Fopenspec-explore` | Think through problems before\u002Fduring work  |\n | `\u002Fopenspec-apply-change`   | Implement tasks from a change              |\n | `\u002Fopenspec-archive-change` | Archive a completed change                 |\n | `\u002Fopenspec-new-change`     | Start a new change, one artifact at a time |\n | `\u002Fopenspec-continue-change` | Continue working on an existing change    |\n | `\u002Fopenspec-ff-change`      | Fast-forward: create all artifacts at once |\n | `\u002Fopenspec-verify-change`  | Verify implementation matches artifacts    |\n\n---\n\n## What's Next?\n\nTry `\u002Fopenspec-propose` on something you actually want to build. You've got the rhythm now!\n```\n\n---\n\n## Graceful Exit Handling\n\n### User wants to stop mid-way\n\nIf the user says they need to stop, want to pause, or seem disengaged:\n\n```\nNo problem! Your change is saved at the `changeRoot` reported by `openspec status --change \"\u003Cname>\" --json`.\n\nTo pick up where we left off later, `openspec status --change \"\u003Cname>\" --json` shows exactly where the change stands.\n- `\u002Fopenspec-continue-change \u003Cname>` - Resume artifact creation\n- `\u002Fopenspec-apply-change \u003Cname>` - Jump to implementation (if tasks exist)\n\nThe work won't be lost. Come back whenever you're ready.\n```\n\nExit gracefully without pressure.\n\n### User just wants command reference\n\nIf the user says they just want to see the commands or skip the tutorial:\n\n```\n## OpenSpec Quick Reference\n\n**The commands you have installed:**\n\n | Command                  | What it does                               |\n |--------------------------|--------------------------------------------|\n | `\u002Fopenspec-propose \u003Cname>`  | Create a change and generate all artifacts |\n | `\u002Fopenspec-explore`         | Think through problems (no code changes)   |\n | `\u002Fopenspec-apply-change \u003Cname>`    | Implement tasks                            |\n | `\u002Fopenspec-archive-change \u003Cname>`  | Archive when done                          |\n | `\u002Fopenspec-new-change \u003Cname>`      | Start a new change, step by step           |\n | `\u002Fopenspec-continue-change \u003Cname>` | Continue an existing change                |\n | `\u002Fopenspec-ff-change \u003Cname>`       | Fast-forward: all artifacts at once        |\n | `\u002Fopenspec-verify-change \u003Cname>`   | Verify implementation                      |\n\nTry `\u002Fopenspec-propose` to start your first change.\n```\n\nExit gracefully.\n\n---\n\n## Guardrails\n\n- **Follow the EXPLAIN → DO → SHOW → PAUSE pattern** at key transitions (after explore, after proposal draft, after tasks, after archive)\n- **Keep narration light** during implementation—teach without lecturing\n- **Don't skip phases** even if the change is small—the goal is teaching the workflow\n- **Pause for acknowledgment** at marked points, but don't over-pause\n- **Handle exits gracefully**—never pressure the user to continue\n- **Use real codebase tasks**—don't simulate or use fake examples\n- **Adjust scope gently**—guide toward smaller tasks but respect user choice\n","Guide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.\n\n**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store \u003Cid>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store \u003Cid>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change \"\u003Cname>\" --json --store \"\u003Cid>\"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec\u002F` root.\n\n**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store \u003Cid>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `\"root\": null` means it is not - there is no `openspec\u002F` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.\n\nOne `\"root\": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec\u002Fconfig.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.\n\nOtherwise, with no root, what happens next depends on how this workflow was reached:\n\n- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.\n- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store \u003Cid>`), or continue without OpenSpec for this request. Wait for their answer.\n\nIn both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec\u002F` files, and do not let a command create it.\n\n---\n\n## Preflight\n\nBefore starting, check if the OpenSpec CLI is installed:\n\n```bash\n# Unix\u002FmacOS\nopenspec --version 2>&1 || echo \"CLI_NOT_INSTALLED\"\n# Windows (PowerShell)\n# if (Get-Command openspec -ErrorAction SilentlyContinue) { openspec --version } else { echo \"CLI_NOT_INSTALLED\" }\n```\n\n**If CLI not installed:**\n> OpenSpec CLI is not installed. Install it first, then come back to `\u002Fopenspec-onboard`.\n\nStop here if not installed.\n\n---\n\n## Phase 1: Welcome\n\nDisplay:\n\n```\n## Welcome to OpenSpec!\n\nI'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.\n\n**What we'll do:**\n1. Pick a small, real task in your codebase\n2. Explore the problem briefly\n3. Create a change (the container for our work)\n4. Build the artifacts: proposal → specs → design → tasks\n5. Implement the tasks\n6. Archive the completed change\n\n**Time:** ~15-20 minutes\n\nLet's start by finding something to work on.\n```\n\n---\n\n## Phase 2: Task Selection\n\n### Codebase Analysis\n\nScan the codebase for small improvement opportunities. Look for:\n\n1. **TODO\u002FFIXME comments** - Search for `TODO`, `FIXME`, `HACK`, `XXX` in code files\n2. **Missing error handling** - `catch` blocks that swallow errors, risky operations without try-catch\n3. **Functions without tests** - Cross-reference `src\u002F` with test directories\n4. **Type issues** - `any` types in TypeScript files (`: any`, `as any`)\n5. **Debug artifacts** - `console.log`, `console.debug`, `debugger` statements in non-debug code\n6. **Missing validation** - User input handlers without validation\n\nAlso check recent git activity:\n```bash\n# Unix\u002FmacOS\ngit log --oneline -10 2>\u002Fdev\u002Fnull || echo \"No git history\"\n# Windows (PowerShell)\n# git log --oneline -10 2>$null; if ($LASTEXITCODE -ne 0) { echo \"No git history\" }\n```\n\n### Present Suggestions\n\nFrom your analysis, present 3-4 specific suggestions:\n\n```\n## Task Suggestions\n\nBased on scanning your codebase, here are some good starter tasks:\n\n**1. [Most promising task]**\n   Location: `src\u002Fpath\u002Fto\u002Ffile.ts:42`\n   Scope: ~1-2 files, ~20-30 lines\n   Why it's good: [brief reason]\n\n**2. [Second task]**\n   Location: `src\u002Fanother\u002Ffile.ts`\n   Scope: ~1 file, ~15 lines\n   Why it's good: [brief reason]\n\n**3. [Third task]**\n   Location: [location]\n   Scope: [estimate]\n   Why it's good: [brief reason]\n\n**4. Something else?**\n   Tell me what you'd like to work on.\n\nWhich task interests you? (Pick a number or describe your own)\n```\n\n**If nothing found:** Fall back to asking what the user wants to build:\n> I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?\n\n### Scope Guardrail\n\nIf the user picks or describes something too large (major feature, multi-day work):\n\n```\nThat's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.\n\nFor learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.\n\n**Options:**\n1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?\n2. **Pick something else** - One of the other suggestions, or a different small task?\n3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.\n\nWhat would you prefer?\n```\n\nLet the user override if they insist—this is a soft guardrail.\n\n---\n\n## Phase 3: Explore Demo\n\nOnce a task is selected, briefly demonstrate explore mode:\n\n```\nBefore we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.\n```\n\nSpend 1-2 minutes investigating the relevant code:\n- Read the file(s) involved\n- Draw a quick ASCII diagram if it helps\n- Note any considerations\n\n```\n## Quick Exploration\n\n[Your brief analysis—what you found, any considerations]\n\n┌─────────────────────────────────────────┐\n│   [Optional: ASCII diagram if helpful]  │\n└─────────────────────────────────────────┘\n\nExplore mode (`\u002Fopenspec-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.\n\nNow let's create a change to hold our work.\n```\n\n**PAUSE** - Wait for user acknowledgment before proceeding.\n\n---\n\n## Phase 4: Create the Change\n\n**EXPLAIN:**\n```\n## Creating a Change\n\nA \"change\" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives at the `changeRoot` reported by `openspec status --change \"\u003Cname>\" --json` and holds your artifacts—proposal, specs, design, tasks.\n\nLet me create one for our task.\n```\n\n**DO:** Create the change with a derived kebab-case name:\n```bash\nopenspec new change \"\u003Cderived-name>\"\n```\n\n**SHOW:**\n```\nCreated: \u003CchangeRoot from status JSON>\n\nThe folder structure:\n```\n\u003CchangeRoot>\u002F\n├── proposal.md    ← Why we're doing this (empty, we'll fill it)\n├── design.md      ← How we'll build it (empty)\n├── specs\u002F         ← Detailed requirements (empty)\n└── tasks.md       ← Implementation checklist (empty)\n```\n\nNow let's fill in the first artifact—the proposal.\n```\n\n---\n\n## Phase 5: Proposal\n\n**EXPLAIN:**\n```\n## The Proposal\n\nThe proposal captures **why** we're making this change and **what** it involves at a high level. It's the \"elevator pitch\" for the work.\n\nI'll draft one based on our task.\n```\n\n**DO:** Draft the proposal content (don't save yet):\n\n`\u003Ccapability-path>` is the spec directory relative to `specs\u002F` (for example,\n`user-auth` or `identity\u002Fuser-auth`). Use the exact existing path for modified\ncapabilities. For new capabilities, follow the project's established spec\norganization.\n\n```\nHere's a draft proposal:\n\n---\n\n# Proposal\n\n## Why\n\n[1-2 sentences explaining the problem\u002Fopportunity]\n\n## What Changes\n\n[Bullet points of what will be different]\n\n## Capabilities\n\n### New Capabilities\n- `\u003Ccapability-path>`: [brief description]\n\n### Modified Capabilities\n\u003C!-- If modifying existing behavior -->\n- `\u003Cexisting-capability-path>`: [brief description]\n\n## Impact\n\n- `src\u002Fpath\u002Fto\u002Ffile.ts`: [what changes]\n- [other files if applicable]\n\n---\n\nDoes this capture the intent? I can adjust before we save it.\n```\n\n**PAUSE** - Wait for user approval\u002Ffeedback.\n\nAfter approval, save the proposal:\n```bash\nopenspec instructions proposal --change \"\u003Cname>\" --json\n```\nThen write the content to the `resolvedOutputPath` from `openspec instructions proposal --change \"\u003Cname>\" --json`.\n\n```\nProposal saved. This is your \"why\" document—you can always come back and refine it as understanding evolves.\n\nNext up: specs.\n```\n\n---\n\n## Phase 6: Specs\n\n**EXPLAIN:**\n```\n## Specs\n\nSpecs define **what** we're building in precise, testable terms. They use a requirement\u002Fscenario format that makes expected behavior crystal clear.\n\nFor a small task like this, we might only need one spec file.\n```\n\n**DO:** Resolve where the spec file should be created:\n```bash\nopenspec instructions specs --change \"\u003Cname>\" --json\n# Use resolvedOutputPath from the JSON. If it is a glob, choose the concrete file path using the schema instruction and the change's context.\n```\n\nDraft the spec content:\n\n```\nHere's the spec:\n\n---\n\n# Spec Delta\n\n## ADDED Requirements\n\n### Requirement: \u003CName>\n\n\u003CDescription of what the system should do>\n\n#### Scenario: \u003CScenario name>\n\n- **WHEN** \u003Ctrigger condition>\n- **THEN** \u003Cexpected outcome>\n- **AND** \u003Cadditional outcome if needed>\n\n---\n\nThis format—WHEN\u002FTHEN\u002FAND—makes requirements testable. You can literally read them as test cases.\n```\n\nSave to the concrete file path chosen from `resolvedOutputPath`.\n\n---\n\n## Phase 7: Design\n\n**EXPLAIN:**\n```\n## Design\n\nThe design captures **how** we'll build it—technical decisions, tradeoffs, approach.\n\nFor small changes, this might be brief. That's fine—not every change needs deep design discussion.\n```\n\n**DO:** Draft design.md:\n\n```\nHere's the design:\n\n---\n\n# Design\n\n## Context\n\n[Brief context about the current state]\n\n## Goals \u002F Non-Goals\n\n**Goals:**\n- [What we're trying to achieve]\n\n**Non-Goals:**\n- [What's explicitly out of scope]\n\n## Decisions\n\n### Decision 1: [Key decision]\n\n[Explanation of approach and rationale]\n\n---\n\nFor a small task, this captures the key decisions without over-engineering.\n```\n\nSave to the `resolvedOutputPath` from `openspec instructions design --change \"\u003Cname>\" --json`.\n\n---\n\n## Phase 8: Tasks\n\n**EXPLAIN:**\n```\n## Tasks\n\nFinally, we break the work into implementation tasks—checkboxes that drive the apply phase.\n\nThese should be small, clear, and in logical order. Each group carries the tests and documentation for its own work - the last group is only for integration checks.\n```\n\n**DO:** Generate tasks based on specs and design:\n\n```\nHere are the implementation tasks:\n\n---\n\n# Tasks\n\n## 1. [Category or file]\n\n- [ ] 1.1 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]\n- [ ] 1.2 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]\n\n## 2. Integration Verification\n\n- [ ] 2.1 Verify [broader integration or system behavior] with [end-to-end test or observable result]\n\n---\n\nEach checkbox becomes a unit of work in the apply phase. Does this task breakdown look right?\n```\n\n**PAUSE** - Wait for user approval\u002Ffeedback.\n\nAfter approval, save to the `resolvedOutputPath` from `openspec instructions tasks --change \"\u003Cname>\" --json`.\n\nThen ask:\n> \"Tasks are saved. Ready to implement?\"\n\n**PAUSE** - Wait for user to confirm before implementation.\n\n---\n\n## Phase 9: Apply (Implementation)\n\n**EXPLAIN:**\n```\n## Implementation\n\nNow we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs\u002Fdesign informed the approach.\n```\n\n**DO:** For each task:\n\n1. Announce: \"Working on task N: [description]\"\n2. Implement the change in the codebase\n3. Reference specs\u002Fdesign naturally: \"The spec says X, so I'm doing Y\"\n4. Mark complete in tasks.md: `- [ ]` → `- [x]`\n5. Brief status: \"✓ Task N complete\"\n\nKeep narration light—don't over-explain every line of code.\n\nAfter all tasks:\n\n```\n## Implementation Complete\n\nAll tasks done:\n- [x] Task 1\n- [x] Task 2\n- [x] ...\n\nThe change is implemented! One more step—let's archive it.\n```\n\n---\n\n## Phase 10: Archive\n\n**EXPLAIN:**\n```\n## Archiving\n\nWhen a change is complete, we archive it. The archive path is derived from `planningHome.changesDir` and the date.\n\nArchived changes become your project's decision history—you can always find them later to understand why something was built a certain way.\n```\n\n**DO:** Archive the change (`--yes` answers the confirmation prompts, which you cannot answer from a tool call):\n```bash\nopenspec archive \"\u003Cname>\" --yes\n```\n\n**SHOW:**\n```\nArchived to: `\u003CplanningHome.changesDir>\u002Farchive\u002F\u003Ctarget-name>\u002F` (the target name prepends today's date, unless the name already starts with a `YYYY-MM-DD-` prefix — then it is kept as-is, no second date)\n\nThe change is now part of your project's history. The code is in your codebase, the decision record is preserved.\n```\n\n---\n\n## Phase 11: Recap & Next Steps\n\n```\n## Congratulations!\n\nYou just completed a full OpenSpec cycle:\n\n1. **Explore** - Thought through the problem\n2. **New** - Created a change container\n3. **Proposal** - Captured WHY\n4. **Specs** - Defined WHAT in detail\n5. **Design** - Decided HOW\n6. **Tasks** - Broke it into steps\n7. **Apply** - Implemented the work\n8. **Archive** - Preserved the record\n\nThis same rhythm works for any size change—a small fix or a major feature.\n\n---\n\n## Command Reference\n\n**The commands you have installed:**\n\n | Command          | What it does                               |\n |------------------|--------------------------------------------|\n | `\u002Fopenspec-propose` | Create a change and generate all artifacts |\n | `\u002Fopenspec-explore` | Think through problems before\u002Fduring work  |\n | `\u002Fopenspec-apply-change`   | Implement tasks from a change              |\n | `\u002Fopenspec-archive-change` | Archive a completed change                 |\n | `\u002Fopenspec-new-change`     | Start a new change, one artifact at a time |\n | `\u002Fopenspec-continue-change` | Continue working on an existing change    |\n | `\u002Fopenspec-ff-change`      | Fast-forward: create all artifacts at once |\n | `\u002Fopenspec-verify-change`  | Verify implementation matches artifacts    |\n\n---\n\n## What's Next?\n\nTry `\u002Fopenspec-propose` on something you actually want to build. You've got the rhythm now!\n```\n\n---\n\n## Graceful Exit Handling\n\n### User wants to stop mid-way\n\nIf the user says they need to stop, want to pause, or seem disengaged:\n\n```\nNo problem! Your change is saved at the `changeRoot` reported by `openspec status --change \"\u003Cname>\" --json`.\n\nTo pick up where we left off later, `openspec status --change \"\u003Cname>\" --json` shows exactly where the change stands.\n- `\u002Fopenspec-continue-change \u003Cname>` - Resume artifact creation\n- `\u002Fopenspec-apply-change \u003Cname>` - Jump to implementation (if tasks exist)\n\nThe work won't be lost. Come back whenever you're ready.\n```\n\nExit gracefully without pressure.\n\n### User just wants command reference\n\nIf the user says they just want to see the commands or skip the tutorial:\n\n```\n## OpenSpec Quick Reference\n\n**The commands you have installed:**\n\n | Command                  | What it does                               |\n |--------------------------|--------------------------------------------|\n | `\u002Fopenspec-propose \u003Cname>`  | Create a change and generate all artifacts |\n | `\u002Fopenspec-explore`         | Think through problems (no code changes)   |\n | `\u002Fopenspec-apply-change \u003Cname>`    | Implement tasks                            |\n | `\u002Fopenspec-archive-change \u003Cname>`  | Archive when done                          |\n | `\u002Fopenspec-new-change \u003Cname>`      | Start a new change, step by step           |\n | `\u002Fopenspec-continue-change \u003Cname>` | Continue an existing change                |\n | `\u002Fopenspec-ff-change \u003Cname>`       | Fast-forward: all artifacts at once        |\n | `\u002Fopenspec-verify-change \u003Cname>`   | Verify implementation                      |\n\nTry `\u002Fopenspec-propose` to start your first change.\n```\n\nExit gracefully.\n\n---\n\n## Guardrails\n\n- **Follow the EXPLAIN → DO → SHOW → PAUSE pattern** at key transitions (after explore, after proposal draft, after tasks, after archive)\n- **Keep narration light** during implementation—teach without lecturing\n- **Don't skip phases** even if the change is small—the goal is teaching the workflow\n- **Pause for acknowledgment** at marked points, but don't over-pause\n- **Handle exits gracefully**—never pressure the user to continue\n- **Use real codebase tasks**—don't simulate or use fake examples\n- **Adjust scope gently**—guide toward smaller tasks but respect user choice\n",{"name":5,"license":15,"metadata":41,"description":7,"allowed-tools":44,"compatibility":45},{"author":21,"version":42,"generatedBy":43},"1.0","1.16.1","Bash(openspec:*)","Requires openspec CLI.","main","f620abaff09061f8c8b1f1559dca3fdd031a32e5","plugins\u002Falexeyco\u002Foh-my-openspec\u002Fskills\u002Fopenspec-onboard",468,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-11 02:22:54",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill openspec-onboard",{"tool":62,"command":63},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill openspec-onboard",{"tool":65,"command":66},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill openspec-onboard","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Falexeyco\u002Foh-my-openspec\u002Fskills\u002Fopenspec-onboard\u002FSKILL.md",true,[],[71,97,121,155,174,188],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":75,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":36},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[79,80,81,82,83,84,85,86,87,88,89,23,90,91,92,93,94,30,95,96],"search","deja search","error","ready","never","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","merge","past",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":75,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":36},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[104,105,106,107,84,108,109,110,111,112,113,114,115,93,26,116,117,118,119,120],"reflect","deja reflect","brew","remember","project rules","project","session","end","reflection","Rules","decisions","review","record","github","next","https","node",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":75,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":138,"publishedAt":36},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[127,132,135],{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":133,"categoryName":134,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":136,"categoryName":137,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000023","Skill与智能体开发",[123,139,140,141,142,143,109,144,85,145,146,147,148,23,149,150,151,152,153,154],"Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","URL","image","mcp server","schedule","api","publish",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":75,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":36},"01M71569ZM2X3H5RBFK8PVKMK2","review-study","Review a QuestionPunk survey before launch for wording, answer choices, branching, and missing settings. Use for check my survey or review this draft before publishing.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Freview-study\u002FSKILL.md",[],[162,163,115,25,164,165,166,167,22,168,169,170,171,172,173],"study","review study","answer","missing","survey","publishing","check","draft","settings","launch","my","branching",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":75,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":36},"01M71567GV0C35YQBY0DPGR86B","manage-study","Find QuestionPunk studies, check status, publish an explicitly requested draft, or retrieve its participant link. Use for find my survey, publish this study, or how many people responded.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Fmanage-study\u002FSKILL.md",[],[181,162,182,25,166,22,183,168,169,154,184,185,186,187,172],"manage study","manage","people","how","find","link","status",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":75,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":36},"01M71565A8TCA01AZQZRGRYMFZ","create-study","Create a saved QuestionPunk survey draft from a research brief or edit specified questions. Use for requests such as make a customer feedback survey or shorten my onboarding study.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Fcreate-study\u002FSKILL.md",[],[195,162,196,197,198,199,25,200,166,201,22,202,203,169,204,205,206,207,208,172],"create study","create","brief","as","feedback","customer feedback","research brief","shorten","saved","research","requests","customer","questions","edit"]