@fission-ai/openspec 1.9.0 → 1.11.0

package/dist/core/parsers/requirement-blocks.js

@@ -115,12 +115,14 @@ export function parseDeltaSpec(content) {
         sink: skippedHeaders,
     });
     const removedNames = parseRemovedNames(removedLookup.body);
+    const removedBlocks = parseRequirementBlocksFromSection(removedLookup.body);
     const renamedPairs = parseRenamedPairs(renamedLookup.body);
     skippedHeaders.sort((a, b) => a.line - b.line);
     return {
         added,
         modified,
         removed: removedNames,
+        removedBlocks,
         renamed: renamedPairs,
         skippedHeaders,
         sectionPresence: {

package/dist/core/profiles.d.ts

@@ -20,7 +20,7 @@ export type CoreWorkflowId = (typeof CORE_WORKFLOWS)[number];
  * Resolves which workflows should be active for a given profile configuration.
  *
  * - 'core' profile always returns CORE_WORKFLOWS
- * - 'custom' profile returns the provided customWorkflows, or empty array if not provided
+ * - 'custom' profile returns the provided customWorkflows and required dependencies
  */
 export declare function getProfileWorkflows(profile: Profile, customWorkflows?: string[]): readonly string[];
 //# sourceMappingURL=profiles.d.ts.map

package/dist/core/profiles.js

@@ -30,11 +30,20 @@ export const ALL_WORKFLOWS = [
  * Resolves which workflows should be active for a given profile configuration.
  *
  * - 'core' profile always returns CORE_WORKFLOWS
- * - 'custom' profile returns the provided customWorkflows, or empty array if not provided
+ * - 'custom' profile returns the provided customWorkflows and required dependencies
  */
 export function getProfileWorkflows(profile, customWorkflows) {
     if (profile === 'custom') {
-        return customWorkflows ?? [];
+        const workflows = customWorkflows ?? [];
+        const syncDependentIndex = workflows.findIndex((workflow) => workflow === 'archive' || workflow === 'bulk-archive');
+        if (syncDependentIndex !== -1 && !workflows.includes('sync')) {
+            return [
+                ...workflows.slice(0, syncDependentIndex),
+                'sync',
+                ...workflows.slice(syncDependentIndex),
+            ];
+        }
+        return workflows;
     }
     return CORE_WORKFLOWS;
 }

package/dist/core/shared/tool-detection.js

@@ -10,8 +10,8 @@ import { CommandAdapterRegistry, generateCommands } from '../command-generation/
 import { getCommandContents } from './skill-generation.js';
 import { getGlobalConfig } from '../global-config.js';
 import { getProfileWorkflows, ALL_WORKFLOWS } from '../profiles.js';
-import { isSharedSkillTargetActive, readSharedSkillTarget, reconcileSharedSkillTargets, } from '../shared-skill-target.js';
-import { shouldGenerateCommandsForTool, shouldGenerateSkillsForTool, } from '../command-surface.js';
+import { isSharedSkillTargetActive, hasLegacySkills, readSharedSkillTarget, reconcileSharedSkillTargets, } from '../shared-skill-target.js';
+import { shouldGenerateCommandsForTool, shouldGenerateSkillsForTool, resolveCommandSurfaceCapability, } from '../command-surface.js';
 import { getSkillCapableTools, resolveToolSkillsDir, toolSupportsSkills, } from './skill-paths.js';
 /**
  * Names of skill directories created by openspec init.
@@ -272,12 +272,18 @@ export function getConfiguredTools(projectRoot) {
             return false;
         return (getToolSkillStatus(projectRoot, t.value).configured ||
             toolHasAnyConfiguredCommand(projectRoot, t.value) ||
+            (resolveCommandSurfaceCapability(t.value) === 'adapter-backed' &&
+                hasLegacySkills(projectRoot, t)) ||
             (Boolean(t.skillsDir) &&
                 readSharedSkillTarget(projectRoot, t.skillsDir) === t.value));
     });
     const activeProjectTools = new Set(reconcileSharedSkillTargets(projectRoot, configured.filter((tool) => tool.skillsDir)).map((tool) => tool.value));
     return configured
-        .filter((tool) => tool.globalSkillsDir || activeProjectTools.has(tool.value))
+        .filter((tool) => tool.globalSkillsDir ||
+        toolHasAnyConfiguredCommand(projectRoot, tool.value) ||
+        (resolveCommandSurfaceCapability(tool.value) === 'adapter-backed' &&
+            hasLegacySkills(projectRoot, tool)) ||
+        activeProjectTools.has(tool.value))
         .map((tool) => tool.value);
 }
 /**

package/dist/core/shared-skill-target.d.ts

@@ -1,6 +1,19 @@
 import { type AIToolOption } from './config.js';
 /** Reads a valid-looking marker value without letting linked roots escape. */
 export declare function readSharedSkillTarget(projectPath: string, skillsDir: string): string | undefined;
+/** Whether a tool still has an allowlisted managed skill under an old root. */
+export declare function hasLegacySkills(projectPath: string, tool: AIToolOption): boolean;
+/**
+ * Chooses the one selected tool that may render each physical skills root.
+ * Command files are not part of this arbitration: tools that share a skills
+ * root can still write their own command surface elsewhere under that root.
+ *
+ * Existing compatible owners win. On a new root, prefer a skills-native
+ * renderer over an adapter-backed renderer because its references remain
+ * usable by every consumer of the shared tree. Codex is the best fresh owner
+ * because its renderer includes both Codex and generic skill invocation forms.
+ */
+export declare function resolveSharedSkillWriters(projectPath: string, tools: AIToolOption[]): Set<string>;
 /**
  * A shared skill root can only hold one rendered variant of each skill.
  * Keep the writer recorded so later updates do not infer every tool that

package/dist/core/shared-skill-target.js

@@ -2,6 +2,7 @@ import path from 'path';
 import * as fs from 'fs';
 import { AI_TOOLS, OPENSPEC_SKILL_NAMES } from './config.js';
 import { FileSystemUtils } from '../utils/file-system.js';
+import { resolveCommandSurfaceCapability } from './command-surface.js';
 const TARGET_MARKER = '.openspec-target';
 /** Returns the ownership-marker path for one shared skills root. */
 function markerPath(projectPath, skillsDir) {
@@ -19,7 +20,7 @@ export function readSharedSkillTarget(projectPath, skillsDir) {
     }
 }
 /** Whether a tool still has an allowlisted managed skill under an old root. */
-function hasLegacySkills(projectPath, tool) {
+export function hasLegacySkills(projectPath, tool) {
     return (tool.legacySkillsDirs ?? []).some((root) => {
         const skillsDir = path.join(projectPath, root, 'skills');
         return OPENSPEC_SKILL_NAMES.some((skillName) => {
@@ -69,6 +70,47 @@ function hasCurrentSkills(projectPath, skillsDir) {
         }
     });
 }
+/**
+ * Chooses the one selected tool that may render each physical skills root.
+ * Command files are not part of this arbitration: tools that share a skills
+ * root can still write their own command surface elsewhere under that root.
+ *
+ * Existing compatible owners win. On a new root, prefer a skills-native
+ * renderer over an adapter-backed renderer because its references remain
+ * usable by every consumer of the shared tree. Codex is the best fresh owner
+ * because its renderer includes both Codex and generic skill invocation forms.
+ */
+export function resolveSharedSkillWriters(projectPath, tools) {
+    const byRoot = new Map();
+    const writers = new Set();
+    for (const tool of tools) {
+        if (!tool.skillsDir)
+            continue;
+        const group = byRoot.get(tool.skillsDir) ?? [];
+        group.push(tool);
+        byRoot.set(tool.skillsDir, group);
+    }
+    for (const [root, unsortedGroup] of byRoot) {
+        const group = [...unsortedGroup].sort((left, right) => AI_TOOLS.indexOf(left) - AI_TOOLS.indexOf(right));
+        if (group.length === 1) {
+            writers.add(group[0].value);
+            continue;
+        }
+        const skillsNative = group.filter((tool) => resolveCommandSurfaceCapability(tool.value) !== 'adapter-backed');
+        const preferredPool = skillsNative.length > 0 ? skillsNative : group;
+        const marked = readSharedSkillTarget(projectPath, root);
+        const inferred = inferSharedSkillTarget(projectPath, root);
+        const owner = preferredPool.find((tool) => tool.value === marked) ??
+            preferredPool.find((tool) => tool.value === inferred) ??
+            (hasCurrentSkills(projectPath, root)
+                ? preferredPool.find((tool) => tool.value === 'agents')
+                : undefined) ??
+            preferredPool.find((tool) => tool.value === 'codex') ??
+            preferredPool[0];
+        writers.add(owner.value);
+    }
+    return writers;
+}
 /**
  * A shared skill root can only hold one rendered variant of each skill.
  * Keep the writer recorded so later updates do not infer every tool that

package/dist/core/specs-apply.js

@@ -12,7 +12,7 @@ import { extractRequirementsSection, findMissingCurrentScenarios, foldRequiremen
 import { findMainSpecStructureIssues } from './parsers/spec-structure.js';
 import { buildCodeFenceMask } from './parsers/code-fence.js';
 import { MarkdownParser } from './parsers/markdown-parser.js';
-import { MIN_PURPOSE_LENGTH } from './validation/constants.js';
+import { MIN_PURPOSE_LENGTH, PURPOSE_PLACEHOLDER_PREFIX, PURPOSE_PLACEHOLDER_SUFFIX, } from './validation/constants.js';
 import { discoverSpecFiles } from '../utils/spec-discovery.js';
 import { FileSystemUtils } from '../utils/file-system.js';
 function isLexicallyWithin(allowedDirectory, targetPath) {
@@ -254,10 +254,12 @@ export async function buildUpdatedSpec(update, changeName, options = {}) {
     for (const block of parts.bodyBlocks) {
         nameToBlock.set(normalizeRequirementName(block.name), block);
     }
+    // Keep source blocks immutable for loss attribution. This parallel key list
+    // carries only positional identity as renames change lookup keys.
+    const orderedKeys = parts.bodyBlocks.map((block) => normalizeRequirementName(block.name));
     // Apply operations in order: RENAMED → REMOVED → MODIFIED → ADDED
     // RENAMED
     let renamedApplied = 0;
-    const renamedTargets = new Map();
     for (const r of plan.renamed) {
         const from = normalizeRequirementName(r.from);
         const to = normalizeRequirementName(r.to);
@@ -291,7 +293,12 @@ export async function buildUpdatedSpec(update, changeName, options = {}) {
         };
         nameToBlock.delete(from);
         nameToBlock.set(to, renamedBlock);
-        renamedTargets.set(from, to);
+        // A Map delete+set moves the renamed block to insertion-order tail. Carry
+        // its new key in the source slot instead; chained renames update it again.
+        const orderIndex = orderedKeys.indexOf(from);
+        if (orderIndex >= 0) {
+            orderedKeys[orderIndex] = to;
+        }
         renamedApplied++;
     }
     // REMOVED
@@ -364,8 +371,9 @@ export async function buildUpdatedSpec(update, changeName, options = {}) {
     // Recompose requirements section preserving original ordering where possible
     const keptOrder = [];
     const seen = new Set();
-    for (const block of parts.bodyBlocks) {
-        const key = normalizeRequirementName(block.name);
+    for (let index = 0; index < parts.bodyBlocks.length; index++) {
+        const block = parts.bodyBlocks[index];
+        const key = orderedKeys[index];
         const replacement = nameToBlock.get(key);
         if (replacement) {
             keptOrder.push(replacement);
@@ -377,8 +385,7 @@ export async function buildUpdatedSpec(update, changeName, options = {}) {
         // full absorbed suffix. RENAMED carries the original raw content under a
         // new map key, and MODIFIED may repeat the suffix deliberately; neither is
         // data loss.
-        const renamedTarget = renamedTargets.get(key);
-        const replacementFromOriginal = replacement ?? (renamedTarget ? nameToBlock.get(renamedTarget) : undefined);
+        const replacementFromOriginal = replacement;
         if (replacementFromOriginal !== block) {
             const foreign = firstForeignTail(block.raw);
             const replacementRaw = replacementFromOriginal?.raw;
@@ -917,7 +924,8 @@ function readableOverview(skeleton, specName) {
  */
 export function buildSpecSkeleton(specFolderName, changeName, purpose) {
     const titleBase = specFolderName;
-    const purposeBody = purpose?.trim() || `TBD - created by archiving change ${changeName}. Update Purpose after archive.`;
+    const purposeBody = purpose?.trim() ||
+        `${PURPOSE_PLACEHOLDER_PREFIX}${changeName}${PURPOSE_PLACEHOLDER_SUFFIX}`;
     return `# ${titleBase} Specification\n\n## Purpose\n${purposeBody}\n\n## Requirements\n`;
 }
 //# sourceMappingURL=specs-apply.js.map

package/dist/core/templates/workflows/explore.js

@@ -5,7 +5,7 @@ export function getExploreSkillTemplate() {
         description: 'Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.',
         instructions: `Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
 
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing. For a new change, scaffold it first as described below.
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. For a new change, scaffold it first as described below.
 
 **This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
 
@@ -48,22 +48,25 @@ Depending on what the user brings, you might:
 
 **Visualize**
 \`\`\`
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
++------------------------------------------+
+|     Use ASCII diagrams liberally         |
++------------------------------------------+
+|                                          |
+|   [State A] -------> [State B]           |
+|       |                                  |
+|       v                                  |
+|   [State C]                              |
+|                                          |
+|   System diagrams, state machines,       |
+|   data flows, architecture sketches,     |
+|   dependency graphs, comparison tables   |
+|                                          |
++------------------------------------------+
 \`\`\`
 
+**Draw with plain ASCII only** — borders \`+\` \`-\` \`|\`, arrows \`-->\` \`<--\` \`^\` \`v\`, markers \`*\` \`x\`.
+Unicode diagram glyphs can render at different widths across terminals, fonts, and locales, so padded boxes and aligned tables can drift. Keep every diagram character ASCII.
+
 **Surface risks and unknowns**
 - Identify what could go wrong
 - Find gaps in understanding
@@ -164,17 +167,17 @@ User: I'm thinking about adding real-time collaboration
 You: Real-time collab is a big space. Let me think about this...
 
       COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
+      ============================================
 
       Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
+          |                   |                 |
+          v                   v                 v
+      +--------+         +--------+        +--------+
+      |Presence|         |Cursors |        |  CRDT  |
+      |  "3    |         | Multi  |        |Conflict|
+      |online" |         | select |        |  free  |
+      +--------+         +--------+        +--------+
+          |                   |                 |
        trivial            moderate           complex
 
       Where's your head at?
@@ -186,27 +189,27 @@ User: The auth system is a mess
 
 You: [reads codebase]
 
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
+     +---------------------------------------------+
+     |              CURRENT AUTH FLOW              |
+     +---------------------------------------------+
+                        |
+          +-------------+-------------+
+          v             v             v
+     +---------+  +---------+  +---------+
+     | Google  |  |  GitHub |  |  Email  |
+     |  OAuth  |  |  OAuth  |  |  Magic  |
+     +----+----+  +----+----+  +----+----+
+          |             |             |
+          +-------------+-------------+
+                        v
+                  +-----------+
+                  |  Session  |
+                  +-----+-----+
+                        |
+                        v
+                  +-----------+
+                  |   Perms   |
+                  +-----------+
 
      I see three tangles. Which one's burning?
 \`\`\`
@@ -238,19 +241,19 @@ User: A CLI tool that tracks local dev environments
 
 You: That changes everything.
 
-     ┌─────────────────────────────────────────────────┐
-     │          CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
+     +-------------------------------------------------+
+     |          CLI TOOL DATA STORAGE                  |
+     +-------------------------------------------------+
 
      Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
+     - No daemon running
+     - Must work offline
+     - Single user
 
                   SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
+     Deployment   embedded        needs server
+     Offline      yes             no
+     Single file  yes             no
 
      SQLite. Not even close.
 
@@ -290,11 +293,11 @@ But this summary is optional. Sometimes the thinking IS the value.
 
 ## Guardrails
 
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or \`openspec/config.yaml\` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not.
 - **Don't fake understanding** - If something is unclear, dig deeper
 - **Don't rush** - Discovery is thinking time, not task time
 - **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including \`openspec new change\` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write.
 - **Don't manually scaffold changes** - Never create a new change directory under \`openspec/changes/\` by hand. Always use \`openspec new change "<name>"\` (with \`--store <id>\` when applicable) so required metadata such as \`.openspec.yaml\` is created before writing artifacts.
 - **Do visualize** - A good diagram is worth many paragraphs
 - **Do explore the codebase** - Ground discussions in reality
@@ -312,7 +315,7 @@ export function getOpsxExploreCommandTemplate() {
         tags: ['workflow', 'explore', 'experimental', 'thinking'],
         content: `Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
 
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing. For a new change, scaffold it first as described below.
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. For a new change, scaffold it first as described below.
 
 **This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
 
@@ -362,22 +365,25 @@ Depending on what the user brings, you might:
 
 **Visualize**
 \`\`\`
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
++------------------------------------------+
+|     Use ASCII diagrams liberally         |
++------------------------------------------+
+|                                          |
+|   [State A] -------> [State B]           |
+|       |                                  |
+|       v                                  |
+|   [State C]                              |
+|                                          |
+|   System diagrams, state machines,       |
+|   data flows, architecture sketches,     |
+|   dependency graphs, comparison tables   |
+|                                          |
++------------------------------------------+
 \`\`\`
 
+**Draw with plain ASCII only** — borders \`+\` \`-\` \`|\`, arrows \`-->\` \`<--\` \`^\` \`v\`, markers \`*\` \`x\`.
+Unicode diagram glyphs can render at different widths across terminals, fonts, and locales, so padded boxes and aligned tables can drift. Keep every diagram character ASCII.
+
 **Surface risks and unknowns**
 - Identify what could go wrong
 - Find gaps in understanding
@@ -486,11 +492,11 @@ When things crystallize, you might offer a summary - but it's optional. Sometime
 
 ## Guardrails
 
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or \`openspec/config.yaml\` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not.
 - **Don't fake understanding** - If something is unclear, dig deeper
 - **Don't rush** - Discovery is thinking time, not task time
 - **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including \`openspec new change\` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write.
 - **Don't manually scaffold changes** - Never create a new change directory under \`openspec/changes/\` by hand. Always use \`openspec new change "<name>"\` (with \`--store <id>\` when applicable) so required metadata such as \`.openspec.yaml\` is created before writing artifacts.
 - **Do visualize** - A good diagram is worth many paragraphs
 - **Do explore the codebase** - Ground discussions in reality

package/dist/core/templates/workflows/feedback.js

@@ -39,6 +39,7 @@ export function getFeedbackSkillTemplate() {
 5. **Submit on confirmation**
    - Use the \`openspec feedback\` command to submit
    - Format: \`openspec feedback "title" --body "body content"\`
+   - The command preserves the title text in the issue body and shortens long GitHub issue titles
    - The command will automatically add metadata (version, platform, timestamp)
 
 **Example Draft**

package/dist/core/templates/workflows/onboard.js

@@ -374,12 +374,12 @@ Here are the implementation tasks:
 
 ## 1. [Category or file]
 
-- [ ] 1.1 [Specific task]
-- [ ] 1.2 [Specific task]
+- [ ] 1.1 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]
+- [ ] 1.2 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]
 
-## 2. Verify
+## 2. Integration Verification
 
-- [ ] 2.1 [Verification step]
+- [ ] 2.1 Verify [broader integration or system behavior] with [end-to-end test or observable result]
 
 ---