[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CSN6Q511ZX02X490WFJFFC":3,"skill-same:01M6CSN6Q511ZX02X490WFJFFC":57},{"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":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":14,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":40,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M6CSN6Q511ZX02X490WFJFFC","openspec-bulk-archive-change",null,"Archive multiple completed changes at once. Use when archiving several parallel changes.","psacc\u002Fomnisess","psacc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F171010?v=4","01M6CSN1C11CTRR5G2Q0MCH0SE","Paolo Sacconier","01M6CSN1G116PZV68PYSN0WD31",1,"MIT","https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopenspec-bulk-archive-change\u002FSKILL.md",[],[19,20,21,22,23,24,25],"change","openspec bulk archive change","archive","openspec","cli","parallel","use","2026-11-10 10:12:30",false,"---\nname: openspec-bulk-archive-change\ndescription: Archive multiple completed changes at once. Use when archiving several parallel changes.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n  author: openspec\n  version: \"1.0\"\n  generatedBy: \"1.1.1\"\n---\n\nArchive multiple completed changes in a single operation.\n\nThis skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.\n\n**Input**: None required (prompts for selection)\n\n**Steps**\n\n1. **Get active changes**\n\n   Run `openspec list --json` to get all active changes.\n\n   If no active changes exist, inform user and stop.\n\n2. **Prompt for change selection**\n\n   Use **AskUserQuestion tool** with multi-select to let user choose changes:\n   - Show each change with its schema\n   - Include an option for \"All changes\"\n   - Allow any number of selections (1+ works, 2+ is the typical use case)\n\n   **IMPORTANT**: Do NOT auto-select. Always let the user choose.\n\n3. **Batch validation - gather status for all selected changes**\n\n   For each selected change, collect:\n\n   a. **Artifact status** - Run `openspec status --change \"\u003Cname>\" --json`\n      - Parse `schemaName` and `artifacts` list\n      - Note which artifacts are `done` vs other states\n\n   b. **Task completion** - Read `openspec\u002Fchanges\u002F\u003Cname>\u002Ftasks.md`\n      - Count `- [ ]` (incomplete) vs `- [x]` (complete)\n      - If no tasks file exists, note as \"No tasks\"\n\n   c. **Delta specs** - Check `openspec\u002Fchanges\u002F\u003Cname>\u002Fspecs\u002F` directory\n      - List which capability specs exist\n      - For each, extract requirement names (lines matching `### Requirement: \u003Cname>`)\n\n4. **Detect spec conflicts**\n\n   Build a map of `capability -> [changes that touch it]`:\n\n   ```\n   auth -> [change-a, change-b]  \u003C- CONFLICT (2+ changes)\n   api  -> [change-c]            \u003C- OK (only 1 change)\n   ```\n\n   A conflict exists when 2+ selected changes have delta specs for the same capability.\n\n5. **Resolve conflicts agentically**\n\n   **For each conflict**, investigate the codebase:\n\n   a. **Read the delta specs** from each conflicting change to understand what each claims to add\u002Fmodify\n\n   b. **Search the codebase** for implementation evidence:\n      - Look for code implementing requirements from each delta spec\n      - Check for related files, functions, or tests\n\n   c. **Determine resolution**:\n      - If only one change is actually implemented -> sync that one's specs\n      - If both implemented -> apply in chronological order (older first, newer overwrites)\n      - If neither implemented -> skip spec sync, warn user\n\n   d. **Record resolution** for each conflict:\n      - Which change's specs to apply\n      - In what order (if both)\n      - Rationale (what was found in codebase)\n\n6. **Show consolidated status table**\n\n   Display a table summarizing all changes:\n\n   ```\n   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |\n   |---------------------|-----------|-------|---------|-----------|--------|\n   | schema-management   | Done      | 5\u002F5   | 2 delta | None      | Ready  |\n   | project-config      | Done      | 3\u002F3   | 1 delta | None      | Ready  |\n   | add-oauth           | Done      | 4\u002F4   | 1 delta | auth (!)  | Ready* |\n   | add-verify-skill    | 1 left    | 2\u002F5   | None    | None      | Warn   |\n   ```\n\n   For conflicts, show the resolution:\n   ```\n   * Conflict resolution:\n     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)\n   ```\n\n   For incomplete changes, show warnings:\n   ```\n   Warnings:\n   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks\n   ```\n\n7. **Confirm batch operation**\n\n   Use **AskUserQuestion tool** with a single confirmation:\n\n   - \"Archive N changes?\" with options based on status\n   - Options might include:\n     - \"Archive all N changes\"\n     - \"Archive only N ready changes (skip incomplete)\"\n     - \"Cancel\"\n\n   If there are incomplete changes, make clear they'll be archived with warnings.\n\n8. **Execute archive for each confirmed change**\n\n   Process changes in the determined order (respecting conflict resolution):\n\n   a. **Sync specs** if delta specs exist:\n      - Use the openspec-sync-specs approach (agent-driven intelligent merge)\n      - For conflicts, apply in resolved order\n      - Track if sync was done\n\n   b. **Perform the archive**:\n      ```bash\n      mkdir -p openspec\u002Fchanges\u002Farchive\n      mv openspec\u002Fchanges\u002F\u003Cname> openspec\u002Fchanges\u002Farchive\u002FYYYY-MM-DD-\u003Cname>\n      ```\n\n   c. **Track outcome** for each change:\n      - Success: archived successfully\n      - Failed: error during archive (record error)\n      - Skipped: user chose not to archive (if applicable)\n\n9. **Display summary**\n\n   Show final results:\n\n   ```\n   ## Bulk Archive Complete\n\n   Archived 3 changes:\n   - schema-management-cli -> archive\u002F2026-01-19-schema-management-cli\u002F\n   - project-config -> archive\u002F2026-01-19-project-config\u002F\n   - add-oauth -> archive\u002F2026-01-19-add-oauth\u002F\n\n   Skipped 1 change:\n   - add-verify-skill (user chose not to archive incomplete)\n\n   Spec sync summary:\n   - 4 delta specs synced to main specs\n   - 1 conflict resolved (auth: applied both in chronological order)\n   ```\n\n   If any failures:\n   ```\n   Failed 1 change:\n   - some-change: Archive directory already exists\n   ```\n\n**Conflict Resolution Examples**\n\nExample 1: Only one implemented\n```\nConflict: specs\u002Fauth\u002Fspec.md touched by [add-oauth, add-jwt]\n\nChecking add-oauth:\n- Delta adds \"OAuth Provider Integration\" requirement\n- Searching codebase... found src\u002Fauth\u002Foauth.ts implementing OAuth flow\n\nChecking add-jwt:\n- Delta adds \"JWT Token Handling\" requirement\n- Searching codebase... no JWT implementation found\n\nResolution: Only add-oauth is implemented. Will sync add-oauth specs only.\n```\n\nExample 2: Both implemented\n```\nConflict: specs\u002Fapi\u002Fspec.md touched by [add-rest-api, add-graphql]\n\nChecking add-rest-api (created 2026-01-10):\n- Delta adds \"REST Endpoints\" requirement\n- Searching codebase... found src\u002Fapi\u002Frest.ts\n\nChecking add-graphql (created 2026-01-15):\n- Delta adds \"GraphQL Schema\" requirement\n- Searching codebase... found src\u002Fapi\u002Fgraphql.ts\n\nResolution: Both implemented. Will apply add-rest-api specs first,\nthen add-graphql specs (chronological order, newer takes precedence).\n```\n\n**Output On Success**\n\n```\n## Bulk Archive Complete\n\nArchived N changes:\n- \u003Cchange-1> -> archive\u002FYYYY-MM-DD-\u003Cchange-1>\u002F\n- \u003Cchange-2> -> archive\u002FYYYY-MM-DD-\u003Cchange-2>\u002F\n\nSpec sync summary:\n- N delta specs synced to main specs\n- No conflicts (or: M conflicts resolved)\n```\n\n**Output On Partial Success**\n\n```\n## Bulk Archive Complete (partial)\n\nArchived N changes:\n- \u003Cchange-1> -> archive\u002FYYYY-MM-DD-\u003Cchange-1>\u002F\n\nSkipped M changes:\n- \u003Cchange-2> (user chose not to archive incomplete)\n\nFailed K changes:\n- \u003Cchange-3>: Archive directory already exists\n```\n\n**Output When No Changes**\n\n```\n## No Changes to Archive\n\nNo active changes found. Use `\u002Fopsx:new` to create a new change.\n```\n\n**Guardrails**\n- Allow any number of changes (1+ is fine, 2+ is the typical use case)\n- Always prompt for selection, never auto-select\n- Detect spec conflicts early and resolve by checking codebase\n- When both changes are implemented, apply specs in chronological order\n- Skip spec sync only when implementation is missing (warn user)\n- Show clear per-change status before confirming\n- Use single confirmation for entire batch\n- Track and report all outcomes (success\u002Fskip\u002Ffail)\n- Preserve .openspec.yaml when moving to archive\n- Archive directory target uses current date: YYYY-MM-DD-\u003Cname>\n- If archive target exists, fail that change but continue with others\n","Archive multiple completed changes in a single operation.\n\nThis skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.\n\n**Input**: None required (prompts for selection)\n\n**Steps**\n\n1. **Get active changes**\n\n   Run `openspec list --json` to get all active changes.\n\n   If no active changes exist, inform user and stop.\n\n2. **Prompt for change selection**\n\n   Use **AskUserQuestion tool** with multi-select to let user choose changes:\n   - Show each change with its schema\n   - Include an option for \"All changes\"\n   - Allow any number of selections (1+ works, 2+ is the typical use case)\n\n   **IMPORTANT**: Do NOT auto-select. Always let the user choose.\n\n3. **Batch validation - gather status for all selected changes**\n\n   For each selected change, collect:\n\n   a. **Artifact status** - Run `openspec status --change \"\u003Cname>\" --json`\n      - Parse `schemaName` and `artifacts` list\n      - Note which artifacts are `done` vs other states\n\n   b. **Task completion** - Read `openspec\u002Fchanges\u002F\u003Cname>\u002Ftasks.md`\n      - Count `- [ ]` (incomplete) vs `- [x]` (complete)\n      - If no tasks file exists, note as \"No tasks\"\n\n   c. **Delta specs** - Check `openspec\u002Fchanges\u002F\u003Cname>\u002Fspecs\u002F` directory\n      - List which capability specs exist\n      - For each, extract requirement names (lines matching `### Requirement: \u003Cname>`)\n\n4. **Detect spec conflicts**\n\n   Build a map of `capability -> [changes that touch it]`:\n\n   ```\n   auth -> [change-a, change-b]  \u003C- CONFLICT (2+ changes)\n   api  -> [change-c]            \u003C- OK (only 1 change)\n   ```\n\n   A conflict exists when 2+ selected changes have delta specs for the same capability.\n\n5. **Resolve conflicts agentically**\n\n   **For each conflict**, investigate the codebase:\n\n   a. **Read the delta specs** from each conflicting change to understand what each claims to add\u002Fmodify\n\n   b. **Search the codebase** for implementation evidence:\n      - Look for code implementing requirements from each delta spec\n      - Check for related files, functions, or tests\n\n   c. **Determine resolution**:\n      - If only one change is actually implemented -> sync that one's specs\n      - If both implemented -> apply in chronological order (older first, newer overwrites)\n      - If neither implemented -> skip spec sync, warn user\n\n   d. **Record resolution** for each conflict:\n      - Which change's specs to apply\n      - In what order (if both)\n      - Rationale (what was found in codebase)\n\n6. **Show consolidated status table**\n\n   Display a table summarizing all changes:\n\n   ```\n   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |\n   |---------------------|-----------|-------|---------|-----------|--------|\n   | schema-management   | Done      | 5\u002F5   | 2 delta | None      | Ready  |\n   | project-config      | Done      | 3\u002F3   | 1 delta | None      | Ready  |\n   | add-oauth           | Done      | 4\u002F4   | 1 delta | auth (!)  | Ready* |\n   | add-verify-skill    | 1 left    | 2\u002F5   | None    | None      | Warn   |\n   ```\n\n   For conflicts, show the resolution:\n   ```\n   * Conflict resolution:\n     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)\n   ```\n\n   For incomplete changes, show warnings:\n   ```\n   Warnings:\n   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks\n   ```\n\n7. **Confirm batch operation**\n\n   Use **AskUserQuestion tool** with a single confirmation:\n\n   - \"Archive N changes?\" with options based on status\n   - Options might include:\n     - \"Archive all N changes\"\n     - \"Archive only N ready changes (skip incomplete)\"\n     - \"Cancel\"\n\n   If there are incomplete changes, make clear they'll be archived with warnings.\n\n8. **Execute archive for each confirmed change**\n\n   Process changes in the determined order (respecting conflict resolution):\n\n   a. **Sync specs** if delta specs exist:\n      - Use the openspec-sync-specs approach (agent-driven intelligent merge)\n      - For conflicts, apply in resolved order\n      - Track if sync was done\n\n   b. **Perform the archive**:\n      ```bash\n      mkdir -p openspec\u002Fchanges\u002Farchive\n      mv openspec\u002Fchanges\u002F\u003Cname> openspec\u002Fchanges\u002Farchive\u002FYYYY-MM-DD-\u003Cname>\n      ```\n\n   c. **Track outcome** for each change:\n      - Success: archived successfully\n      - Failed: error during archive (record error)\n      - Skipped: user chose not to archive (if applicable)\n\n9. **Display summary**\n\n   Show final results:\n\n   ```\n   ## Bulk Archive Complete\n\n   Archived 3 changes:\n   - schema-management-cli -> archive\u002F2026-01-19-schema-management-cli\u002F\n   - project-config -> archive\u002F2026-01-19-project-config\u002F\n   - add-oauth -> archive\u002F2026-01-19-add-oauth\u002F\n\n   Skipped 1 change:\n   - add-verify-skill (user chose not to archive incomplete)\n\n   Spec sync summary:\n   - 4 delta specs synced to main specs\n   - 1 conflict resolved (auth: applied both in chronological order)\n   ```\n\n   If any failures:\n   ```\n   Failed 1 change:\n   - some-change: Archive directory already exists\n   ```\n\n**Conflict Resolution Examples**\n\nExample 1: Only one implemented\n```\nConflict: specs\u002Fauth\u002Fspec.md touched by [add-oauth, add-jwt]\n\nChecking add-oauth:\n- Delta adds \"OAuth Provider Integration\" requirement\n- Searching codebase... found src\u002Fauth\u002Foauth.ts implementing OAuth flow\n\nChecking add-jwt:\n- Delta adds \"JWT Token Handling\" requirement\n- Searching codebase... no JWT implementation found\n\nResolution: Only add-oauth is implemented. Will sync add-oauth specs only.\n```\n\nExample 2: Both implemented\n```\nConflict: specs\u002Fapi\u002Fspec.md touched by [add-rest-api, add-graphql]\n\nChecking add-rest-api (created 2026-01-10):\n- Delta adds \"REST Endpoints\" requirement\n- Searching codebase... found src\u002Fapi\u002Frest.ts\n\nChecking add-graphql (created 2026-01-15):\n- Delta adds \"GraphQL Schema\" requirement\n- Searching codebase... found src\u002Fapi\u002Fgraphql.ts\n\nResolution: Both implemented. Will apply add-rest-api specs first,\nthen add-graphql specs (chronological order, newer takes precedence).\n```\n\n**Output On Success**\n\n```\n## Bulk Archive Complete\n\nArchived N changes:\n- \u003Cchange-1> -> archive\u002FYYYY-MM-DD-\u003Cchange-1>\u002F\n- \u003Cchange-2> -> archive\u002FYYYY-MM-DD-\u003Cchange-2>\u002F\n\nSpec sync summary:\n- N delta specs synced to main specs\n- No conflicts (or: M conflicts resolved)\n```\n\n**Output On Partial Success**\n\n```\n## Bulk Archive Complete (partial)\n\nArchived N changes:\n- \u003Cchange-1> -> archive\u002FYYYY-MM-DD-\u003Cchange-1>\u002F\n\nSkipped M changes:\n- \u003Cchange-2> (user chose not to archive incomplete)\n\nFailed K changes:\n- \u003Cchange-3>: Archive directory already exists\n```\n\n**Output When No Changes**\n\n```\n## No Changes to Archive\n\nNo active changes found. Use `\u002Fopsx:new` to create a new change.\n```\n\n**Guardrails**\n- Allow any number of changes (1+ is fine, 2+ is the typical use case)\n- Always prompt for selection, never auto-select\n- Detect spec conflicts early and resolve by checking codebase\n- When both changes are implemented, apply specs in chronological order\n- Skip spec sync only when implementation is missing (warn user)\n- Show clear per-change status before confirming\n- Use single confirmation for entire batch\n- Track and report all outcomes (success\u002Fskip\u002Ffail)\n- Preserve .openspec.yaml when moving to archive\n- Archive directory target uses current date: YYYY-MM-DD-\u003Cname>\n- If archive target exists, fail that change but continue with others\n",{"name":5,"license":15,"metadata":31,"description":7,"compatibility":34},{"author":22,"version":32,"generatedBy":33},"1.0","1.1.1","Requires openspec CLI.","main","ef52a1fa5af69c0357cc554044ba40801d76165d",".claude\u002Fskills\u002Fopenspec-bulk-archive-change","https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess","https:\u002F\u002Fgithub.com\u002Fpsacc","http:\u002F\u002Fpaolo.sacconier.net","brain in a jar","2026-11-05 20:37:15",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add psacc\u002Fomnisess --skill openspec-bulk-archive-change",{"tool":49,"command":50},"bunx","bunx skills add psacc\u002Fomnisess --skill openspec-bulk-archive-change",{"tool":52,"command":53},"pnpm","pnpm dlx skills add psacc\u002Fomnisess --skill openspec-bulk-archive-change","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopenspec-bulk-archive-change\u002FSKILL.md",true,[],[58,83,105,121,138,154],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":26},"01M6CSQGP57Y6A3RC0FMQ7SNGK","stats","Show tool-call counts and file-I\u002FO activity from the transcript SQLite index.\nAggregates Read\u002FWrite\u002FEdit file paths, line counts, token usage, and error flags\nacross a time window (default 7d) or for a single session.\nUse this skill when asked which tools were used most, which files saw the most\nactivity, how many tokens were spent, or to inspect a single session's\ntool-call summary.\nTrigger phrases: \"session stats\", \"tool stats\", \"what tools did I use\",\n\"tool usage\", \"files touched\", \"token usage\", \"stats for last week\",\n\"summarize tool calls\", \"session tool breakdown\".","https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess\u002Fblob\u002Fmain\u002Fskills\u002Fomnisess-stats\u002FSKILL.md",[],[60,65,66,67,68,69,70,71,72,73,74,75,25,76,77,78,79,80,81,82],"transcript","file","sqlite","how","Bash","tool","json","read","write","edit","session","files","default","show","flags","call","aggregates","time",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":26},"01M6CSQDESFF8YP0CMETN519FE","skills-audit","Classify agent skills by usage tier (Keep \u002F Borderline \u002F Archive \u002F Unknown) using\nClaude Code session JSONL transcripts as the signal source. Read-only — never\nmodifies skills, sessions, or any file on disk.\nUse this skill when asked to audit skills, find unused skills, classify skills,\ncheck which skills get used, produce a skill usage report, or prune skills.\nTrigger phrases: \"audit skills\", \"find unused skills\", \"classify skills\",\n\"which skills do I use\", \"skill usage report\", \"prune skills\",\n\"what skills are unused\", \"skills I can remove\", \"trim my skill list\".\nOutput is a recommendation (Keep \u002F Borderline \u002F Archive) — acting on it is always\na manual step.","https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess\u002Fblob\u002Fmain\u002Fskills\u002Fomnisess-skills-audit\u002FSKILL.md",[],[90,91,92,93,94,95,66,96,69,97,98,21,99,100,75,101,25,102,103,104],"audit","skills audit","sessions","code","my skill","produce","disk","markdown","skill usage","find","check","remove","never","only","do",{"skillNo":106,"name":78,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":26},"01M6CSQB2H38WJ1FKHFT4FQWQB","Show the full detail of a single AI coding session by its ID.\nSession IDs are in the format \u003Ctool>:\u003Cid> (e.g., claude:5c3f2742, cursor:a1b2c3d4).\nUse this skill when asked to show a specific session, inspect a session, read a session,\nor view the messages in a session.\nTrigger phrases: \"show session\", \"open session\", \"inspect session\", \"read session\",\n\"show me claude:5c3f2742\", \"view session details\", \"what happened in session\".","https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess\u002Fblob\u002Fmain\u002Fskills\u002Fomnisess-show\u002FSKILL.md",[],[78,111,112,113,114,69,70,115,116,72,117,118,75,25,119,120],"messages","ids","open","show me","format","coding","view","cursor","ai coding","me",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":26},"01M6CSQ8M3MRDR8EDAJMWZPKKH","search","Full-text search across all AI coding sessions (Claude Code, Cursor, Codex, GitHub Copilot CLI).\nUse this skill when asked to search sessions, find a conversation about a topic,\nlook up what was discussed in past sessions, or find sessions mentioning specific code or concepts.\nTrigger phrases: \"search sessions\", \"find sessions about\", \"look up in sessions\",\n\"what did I discuss about\", \"find conversation about\", \"search my history\".","https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess\u002Fblob\u002Fmain\u002Fskills\u002Fomnisess-search\u002FSKILL.md",[],[123,23,128,129,92,130,131,93,69,132,116,133,99,118,25,134,135,119,136,137],"github","codex","github copilot","copilot","text","history","up","look","conversation","query",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":26},"01M6CSQ5R6430D028Q9G41EX5Q","recap","Produce a structured markdown briefing of AI coding sessions for a given time window.\nGroups sessions by project and summarizes each group with intent, outcome, and status.\nUse this skill when asked to recap recent coding work, summarize today's sessions,\nshow what was worked on, or produce a daily\u002Fweekly session summary.\nTrigger phrases: \"recap\", \"what did I work on\", \"daily summary\", \"session summary\",\n\"summarize my sessions\", \"what sessions did I have today\", \"coding recap\".\nThis is the sessions-only public version — no Slack, Jira, or Granola integration.","https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess\u002Fblob\u002Fmain\u002Fskills\u002Fomnisess-recap\u002FSKILL.md",[],[140,145,92,146,95,69,97,147,148,149,75,25,150,103,151,119,152,78,153,82],"slack","session summary","work on","work","outcome","version","daily","intent","granola",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":26},"01M6CSQ31NYJNFR7R4WPYCXB2M","ps","Show live Claude Code and Codex sessions as a process tree, grouped by\nshared ancestor chain up to launchd. Covers Claude CLI sessions, Claude\nDesktop agent mode, and Codex sessions (CLI TUI + Codex.app threads).\nUse this skill when asked about the process tree, ancestor lineage, which\nterminal or tmux window a Claude or Codex session is running in, or what's\ncurrently running.\nTrigger phrases: \"process tree\", \"what's running\", \"lineage\", \"ancestor chain\",\n\"which terminal is my claude in\", \"tmux tree\", \"claude process tree\",\n\"codex process tree\", \"session lineage\".\nmacOS-only: on other platforms the command prints \"unsupported\" and exits 0.","https:\u002F\u002Fgithub.com\u002Fpsacc\u002Fomnisess\u002Fblob\u002Fmain\u002Fskills\u002Fomnisess-ps\u002FSKILL.md",[],[161,162,23,163,164,129,92,165,93,166,69,167,168,75,169,25,170,103,134,78],"PS","macos","terminal","tmux","desktop","lineage","tui","command","process","launchd"]