[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXWX3RG7YDYPVCKESE04KJ":3,"skill-same:01M6DXWX3RG7YDYPVCKESE04KJ":124},{"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":23,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":67},"01M6DXWX3RG7YDYPVCKESE04KJ","database-lens",null,"Database review lens for evaluating migration safety, schema design, query correctness, and data integrity. Used by review orchestrators — not invoked directly.","atomicinnovation\u002Faccelerator","atomicinnovation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F65866524?v=4","01M6DXP513JV585FN2QPNR6079","Atomic","01M6DXP55MPK99YVZ2HGMEN991",34,"MIT","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fdatabase-lens\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"database","lens","database lens","schema design","for","true","correctness","data integrity","false","query","design","migration","schema","integrity","Safety","data","review","2026-11-10 10:12:30",false,"---\nname: database-lens\ndescription: Database review lens for evaluating migration safety, schema\n  design, query correctness, and data integrity. Used by review\n  orchestrators — not invoked directly.\nuser-invocable: false\ndisable-model-invocation: true\n---\n\n# Database Lens\n\nReview as a database administrator bringing expert knowledge of the specific\ndatabase technology in use to ensure changes are correct from the database's\nperspective. Infer the database engine from the codebase (migrations, ORM\nconfiguration, connection strings, SQL dialect) and apply engine-specific\nknowledge — Postgres advisory locks differ from MySQL table locks, SQLite has\ndifferent concurrency constraints, and so on.\n\n## Core Responsibilities\n\n1. **Evaluate Migration Safety and Rollback Strategy**\n\n- Assess whether migrations can be rolled back without data loss\n- Check for locking implications on large tables (ALTER TABLE on millions of\n  rows, full table scans during migration)\n- Verify zero-downtime compatibility (can the migration run while the\n  application serves traffic?)\n- Evaluate data backfill strategies for correctness and performance\n- Check for idempotency — can the migration be safely re-run?\n- Assess whether migration order dependencies are explicit\n- Apply engine-specific migration knowledge (e.g., Postgres concurrent index\n  creation, MySQL online DDL capabilities, SQLite schema alteration\n  limitations)\n\n2. **Assess Schema Design and Data Integrity**\n\n- Evaluate normalisation level — is it appropriate for the access patterns?\n- Check for appropriate constraints (NOT NULL, UNIQUE, CHECK, foreign keys)\n- Assess index strategy — are indexes aligned with query patterns?\n- Verify referential integrity across related tables\n- Evaluate column type appropriateness (varchar length, numeric precision,\n  timestamp timezone handling)\n- Check for appropriate default values and nullable columns\n- Apply engine-specific type and constraint knowledge (e.g., Postgres\n  enumerated types, MySQL storage engine differences, engine-specific data\n  type semantics)\n\n3. **Review Query Correctness and Fitness**\n\n- Assess query correctness (JOIN conditions, WHERE clauses, GROUP BY, NULL\n  handling)\n- Identify N+1 query patterns and missing batch operations\n- Check for unbounded result sets (missing LIMIT\u002Fpagination)\n- Evaluate query plans for missing indexes or full table scans\n- Assess whether queries use parameterised inputs (not string concatenation)\n- Check for appropriate use of transactions and isolation levels\n- Apply engine-specific query knowledge (e.g., Postgres CTEs vs MySQL\n  derived tables, engine-specific optimizer behaviour, dialect-specific\n  NULL handling)\n\n4. **Evaluate Connection and Transaction Management**\n\n- Assess connection pool configuration and sizing\n- Check for proper transaction scoping (not holding transactions open during\n  I\u002FO or user interaction)\n- Evaluate deadlock potential from transaction ordering\n- Verify that connections are released in all code paths (including error\n  paths)\n- Check for appropriate use of read replicas vs primary for read\u002Fwrite\n  separation\n- Apply engine-specific connection and transaction knowledge (e.g., Postgres\n  connection limits and pgbouncer patterns, MySQL connection thread model,\n  engine-specific isolation level semantics)\n\n**Boundary note**: Algorithmic efficiency and general resource management are\nassessed by the performance lens. This lens focuses specifically on\n*database-layer* concerns — schema, queries, migrations, and data integrity.\nSQL injection and data exposure are assessed by the security lens. This lens\nfocuses on whether queries are *correct and fit for purpose*, not whether they\nare *safe from attack*.\n\n## Key Evaluation Questions\n\n**Migration safety** (when the change includes database migrations or schema\nchanges):\n\n- **Rollback safety**: If this migration failed halfway through in\n  production, what data would be lost or corrupted, and can the migration be\n  reversed? (Watch for: destructive column drops without backup, data type\n  changes that lose precision, missing down migrations.)\n- **Locking impact**: If this migration runs on a table with 10 million rows\n  during peak traffic, what locks will it acquire and for how long? (Watch\n  for: ALTER TABLE adding NOT NULL columns, full table rewrites, missing\n  concurrent index creation.)\n- **Zero-downtime compatibility**: Can the old application version and the\n  new application version both run against this schema simultaneously?\n  (Watch for: column renames without aliases, removed columns still\n  referenced, constraint additions that reject existing data.)\n\n**Schema design** (when the change introduces or modifies database tables):\n\n- **Constraint completeness**: What invalid data could be inserted into this\n  table that the schema doesn't prevent? (Watch for: missing NOT NULL on\n  required fields, missing UNIQUE constraints, missing CHECK constraints,\n  absent foreign keys.)\n- **Index fitness**: For each query that will hit this table, is there an\n  index that supports it without a full table scan? (Watch for: missing\n  indexes on foreign keys, missing composite indexes for multi-column\n  queries, over-indexing that slows writes.)\n\n**Query correctness** (always applicable when database interaction is present):\n\n- **NULL handling**: What happens to this query's results if any of the\n  joined or filtered columns contain NULL? (Watch for: NULL in NOT IN\n  subqueries, NULL equality comparisons, NULL in aggregate functions,\n  missing COALESCE.)\n- **Result set bounds**: What happens when this query returns 1 million rows\n  instead of 10? (Watch for: missing pagination, unbounded IN clauses,\n  missing LIMIT, eager loading of relationships.)\n- **N+1 patterns**: Is this query executed inside a loop where a single\n  batch query would suffice? (Watch for: ORM lazy loading in loops, missing\n  JOIN or subquery, individual lookups for related records.)\n\n**Transaction management** (when the change uses explicit transactions or\nmodifies data):\n\n- **Transaction scope**: What is the longest this transaction could be held\n  open, and what other operations would it block? (Watch for: transactions\n  spanning HTTP calls, user interactions inside transactions, long-running\n  computations under lock.)\n\n## Important Guidelines\n\n- **Explore the codebase** for existing database patterns, ORM conventions,\n  and migration practices\n- **Infer the database engine** from migrations, ORM config, connection\n  strings, and SQL dialect — apply engine-specific expertise\n- **Be pragmatic** — focus on data integrity risks and migration hazards that\n  could cause production incidents, not theoretical schema perfection\n- **Rate confidence** on each finding — distinguish definite data integrity\n  risks from schema improvement suggestions\n- **Consider the data scale** — a missing index on a 100-row lookup table is\n  irrelevant; on a 100-million-row table it's critical\n- **Check existing migrations** — understand the migration history and\n  conventions before flagging patterns\n- **Assess migration risk proportionally** — a new table with no existing\n  data has lower migration risk than altering a high-traffic table\n\n## What NOT to Do\n\n- Don't review architecture, security, performance, code quality, standards,\n  test coverage, usability, documentation, correctness, compatibility,\n  portability, or safety — those are other lenses\n- Don't assess SQL injection or data exposure — that is the security lens\n- Don't assess general algorithmic efficiency — that is the performance lens\n- Don't review ORM code quality or design patterns — that is the code\n  quality lens\n- Don't assess whether database tests exist — that is the test coverage lens\n- Don't recommend schema changes for theoretical normalisation purity —\n  denormalisation is appropriate when access patterns demand it\n- Don't flag missing indexes without considering write overhead\n\nRemember: You're evaluating whether the database layer will maintain data\nintegrity under all conditions — safe migrations, sound schema design,\ncorrect queries, and disciplined transaction management. The best database\nwork prevents the 3am incident where data is silently corrupted.\n","# Database Lens\n\nReview as a database administrator bringing expert knowledge of the specific\ndatabase technology in use to ensure changes are correct from the database's\nperspective. Infer the database engine from the codebase (migrations, ORM\nconfiguration, connection strings, SQL dialect) and apply engine-specific\nknowledge — Postgres advisory locks differ from MySQL table locks, SQLite has\ndifferent concurrency constraints, and so on.\n\n## Core Responsibilities\n\n1. **Evaluate Migration Safety and Rollback Strategy**\n\n- Assess whether migrations can be rolled back without data loss\n- Check for locking implications on large tables (ALTER TABLE on millions of\n  rows, full table scans during migration)\n- Verify zero-downtime compatibility (can the migration run while the\n  application serves traffic?)\n- Evaluate data backfill strategies for correctness and performance\n- Check for idempotency — can the migration be safely re-run?\n- Assess whether migration order dependencies are explicit\n- Apply engine-specific migration knowledge (e.g., Postgres concurrent index\n  creation, MySQL online DDL capabilities, SQLite schema alteration\n  limitations)\n\n2. **Assess Schema Design and Data Integrity**\n\n- Evaluate normalisation level — is it appropriate for the access patterns?\n- Check for appropriate constraints (NOT NULL, UNIQUE, CHECK, foreign keys)\n- Assess index strategy — are indexes aligned with query patterns?\n- Verify referential integrity across related tables\n- Evaluate column type appropriateness (varchar length, numeric precision,\n  timestamp timezone handling)\n- Check for appropriate default values and nullable columns\n- Apply engine-specific type and constraint knowledge (e.g., Postgres\n  enumerated types, MySQL storage engine differences, engine-specific data\n  type semantics)\n\n3. **Review Query Correctness and Fitness**\n\n- Assess query correctness (JOIN conditions, WHERE clauses, GROUP BY, NULL\n  handling)\n- Identify N+1 query patterns and missing batch operations\n- Check for unbounded result sets (missing LIMIT\u002Fpagination)\n- Evaluate query plans for missing indexes or full table scans\n- Assess whether queries use parameterised inputs (not string concatenation)\n- Check for appropriate use of transactions and isolation levels\n- Apply engine-specific query knowledge (e.g., Postgres CTEs vs MySQL\n  derived tables, engine-specific optimizer behaviour, dialect-specific\n  NULL handling)\n\n4. **Evaluate Connection and Transaction Management**\n\n- Assess connection pool configuration and sizing\n- Check for proper transaction scoping (not holding transactions open during\n  I\u002FO or user interaction)\n- Evaluate deadlock potential from transaction ordering\n- Verify that connections are released in all code paths (including error\n  paths)\n- Check for appropriate use of read replicas vs primary for read\u002Fwrite\n  separation\n- Apply engine-specific connection and transaction knowledge (e.g., Postgres\n  connection limits and pgbouncer patterns, MySQL connection thread model,\n  engine-specific isolation level semantics)\n\n**Boundary note**: Algorithmic efficiency and general resource management are\nassessed by the performance lens. This lens focuses specifically on\n*database-layer* concerns — schema, queries, migrations, and data integrity.\nSQL injection and data exposure are assessed by the security lens. This lens\nfocuses on whether queries are *correct and fit for purpose*, not whether they\nare *safe from attack*.\n\n## Key Evaluation Questions\n\n**Migration safety** (when the change includes database migrations or schema\nchanges):\n\n- **Rollback safety**: If this migration failed halfway through in\n  production, what data would be lost or corrupted, and can the migration be\n  reversed? (Watch for: destructive column drops without backup, data type\n  changes that lose precision, missing down migrations.)\n- **Locking impact**: If this migration runs on a table with 10 million rows\n  during peak traffic, what locks will it acquire and for how long? (Watch\n  for: ALTER TABLE adding NOT NULL columns, full table rewrites, missing\n  concurrent index creation.)\n- **Zero-downtime compatibility**: Can the old application version and the\n  new application version both run against this schema simultaneously?\n  (Watch for: column renames without aliases, removed columns still\n  referenced, constraint additions that reject existing data.)\n\n**Schema design** (when the change introduces or modifies database tables):\n\n- **Constraint completeness**: What invalid data could be inserted into this\n  table that the schema doesn't prevent? (Watch for: missing NOT NULL on\n  required fields, missing UNIQUE constraints, missing CHECK constraints,\n  absent foreign keys.)\n- **Index fitness**: For each query that will hit this table, is there an\n  index that supports it without a full table scan? (Watch for: missing\n  indexes on foreign keys, missing composite indexes for multi-column\n  queries, over-indexing that slows writes.)\n\n**Query correctness** (always applicable when database interaction is present):\n\n- **NULL handling**: What happens to this query's results if any of the\n  joined or filtered columns contain NULL? (Watch for: NULL in NOT IN\n  subqueries, NULL equality comparisons, NULL in aggregate functions,\n  missing COALESCE.)\n- **Result set bounds**: What happens when this query returns 1 million rows\n  instead of 10? (Watch for: missing pagination, unbounded IN clauses,\n  missing LIMIT, eager loading of relationships.)\n- **N+1 patterns**: Is this query executed inside a loop where a single\n  batch query would suffice? (Watch for: ORM lazy loading in loops, missing\n  JOIN or subquery, individual lookups for related records.)\n\n**Transaction management** (when the change uses explicit transactions or\nmodifies data):\n\n- **Transaction scope**: What is the longest this transaction could be held\n  open, and what other operations would it block? (Watch for: transactions\n  spanning HTTP calls, user interactions inside transactions, long-running\n  computations under lock.)\n\n## Important Guidelines\n\n- **Explore the codebase** for existing database patterns, ORM conventions,\n  and migration practices\n- **Infer the database engine** from migrations, ORM config, connection\n  strings, and SQL dialect — apply engine-specific expertise\n- **Be pragmatic** — focus on data integrity risks and migration hazards that\n  could cause production incidents, not theoretical schema perfection\n- **Rate confidence** on each finding — distinguish definite data integrity\n  risks from schema improvement suggestions\n- **Consider the data scale** — a missing index on a 100-row lookup table is\n  irrelevant; on a 100-million-row table it's critical\n- **Check existing migrations** — understand the migration history and\n  conventions before flagging patterns\n- **Assess migration risk proportionally** — a new table with no existing\n  data has lower migration risk than altering a high-traffic table\n\n## What NOT to Do\n\n- Don't review architecture, security, performance, code quality, standards,\n  test coverage, usability, documentation, correctness, compatibility,\n  portability, or safety — those are other lenses\n- Don't assess SQL injection or data exposure — that is the security lens\n- Don't assess general algorithmic efficiency — that is the performance lens\n- Don't review ORM code quality or design patterns — that is the code\n  quality lens\n- Don't assess whether database tests exist — that is the test coverage lens\n- Don't recommend schema changes for theoretical normalisation purity —\n  denormalisation is appropriate when access patterns demand it\n- Don't flag missing indexes without considering write overhead\n\nRemember: You're evaluating whether the database layer will maintain data\nintegrity under all conditions — safe migrations, sound schema design,\ncorrect queries, and disciplined transaction management. The best database\nwork prevents the 3am incident where data is silently corrupted.\n",{"name":5,"description":7,"user-invocable":42,"disable-model-invocation":46},true,"main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Freview\u002Flenses\u002Fdatabase-lens",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-12 04:07:28",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":46},[57,60,63],{"tool":58,"command":59},"npx","npx skills add atomicinnovation\u002Faccelerator --skill database-lens",{"tool":61,"command":62},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill database-lens",{"tool":64,"command":65},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill database-lens","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fdatabase-lens\u002FSKILL.md",[68,74,78,82,86,90,96,100,104,108,112,116,120],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"EXAMPLES.md","REFERENCE","参考文档",10689,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002FEXAMPLES.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"REFERENCE.md",6486,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002FREFERENCE.md",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fperformance_guide.md",10433,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Freferences\u002Fperformance_guide.md",{"path":83,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Freact_patterns.md",12370,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Freferences\u002Freact_patterns.md",{"path":87,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fstate_management.md",10678,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Freferences\u002Fstate_management.md",{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"scripts\u002Fcreate_api_client.ts","SCRIPT","脚本",7550,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Fscripts\u002Fcreate_api_client.ts",{"path":97,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":98,"sourceHtmlUrl":99},"scripts\u002Fcreate_utils.ts",9897,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Fscripts\u002Fcreate_utils.ts",{"path":101,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":102,"sourceHtmlUrl":103},"scripts\u002Fdeploy.sh",2790,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Fscripts\u002Fdeploy.sh",{"path":105,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":106,"sourceHtmlUrl":107},"scripts\u002Foptimize_build.ts",3675,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Fscripts\u002Foptimize_build.ts",{"path":109,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":110,"sourceHtmlUrl":111},"scripts\u002Fscaffold_component.tsx",8310,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Fscripts\u002Fscaffold_component.tsx",{"path":113,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":114,"sourceHtmlUrl":115},"scripts\u002Fsetup_linting.ts",3269,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Fscripts\u002Fsetup_linting.ts",{"path":117,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":118,"sourceHtmlUrl":119},"scripts\u002Fsetup_state.ts",13568,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Fscripts\u002Fsetup_state.ts",{"path":121,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":122,"sourceHtmlUrl":123},"scripts\u002Fsetup_testing.ts",4882,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__404kidwiz--frontend-developer-skill\u002Fscripts\u002Fsetup_testing.ts",[125,158,183,205,220,245],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":139,"publishedAt":41},"01M70S7PFGVATJREBFEGPJB718","explore-pr","Build an interactive, design-first and picture-first exploration page for a pull request — its architecture, abstractions and design decisions drawn as diagrams, a guided tour in reading order with code as the evidence, an attention map of where the risk sits, a ledger of its riskiest operations, prior review findings re-checked against the code, and simulations specific to the PR — with the reviewer's verdicts and notes saved. Use when the user wants to explore, understand or review a large pull request or its design, asks for a review page, walkthrough or visual explanation of a PR, or is struggling to review a big change.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fexplore-pr\u002FSKILL.md",[131,134],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[140,141,142,143,144,145,146,147,34,148,149,150,151,152,153,154,155,40,156,157],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","map","when","number","URL","Bash","code","architecture","reviewer","notes","change",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":41},"01M6DY04WBTMFV96JMBP5ZXVFX","update-work-item","Update fields (status, priority, tags, parent, etc.) of an existing work item. Use to transition status, change priority, manage tags, or edit any frontmatter field. No transition enforcement — arbitrary changes are allowed.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002FSKILL.md",[],[165,166,167,168,169,170,171,152,157,172,173,174,175,176,177,178,179,180,181,182],"work","update","update work item","work item","enforcement","manage","use","config","edit","validate","status","transition","frontmatter","Existing","tags","changes","fields","op",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":41},"01M6DY0106CF15CYEJHZM14GBZ","sync-work-items","Reconcile local work items in meta\u002Fwork\u002F with the active remote tracker named by work.integration. Use when the user wants to sync, push, or pull work items to or from Jira or Linear, preview what a sync would change, or reconcile divergent local and remote state.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items\u002FSKILL.md",[],[165,190,191,192,193,194,195,152,196,157,197,198,199,200,201,202,203,172,204,177,149],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"publishedAt":41},"01M6HNF86984S4XK21Q26VZA21","sync-work-items-recovery","Recovery procedures for work sync failures that need a person — terminal rows, refused pending pushes and refused orders. Read by sync-work-items — not invoked directly.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items-recovery\u002FSKILL.md",[],[212,165,213,190,191,214,28,215,216,217,29,32,218,219],"sync work items recovery","recovery","work-items","terminal","read","person","orders","pending",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":229,"publishedAt":41},"01M6DXZWH7PR72VCEXSSD4XNK4","stress-test-work-item","Interactively stress-test a work item by grilling the user on scope, assumptions, acceptance criteria, edge cases, and dependencies to surface issues, gaps, and flawed assumptions before implementation is planned.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002FSKILL.md",[226],{"categoryNo":227,"categoryName":228,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[230,231,165,232,168,233,234,235,236,237,238,152,239,240,172,174,241,242,243,150,244,177],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","user","gaps",{"skillNo":246,"name":247,"nameZh":6,"description":248,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":249,"categories":250,"keywords":251,"publishedAt":41},"01M6DXZRQWHTWV1G9PTTHCGGYA","review-work-item","Review a work item through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a work item before implementation or escalation.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",[],[40,165,252,168,253,254,171,152,255,256,172,174,241,243,257,149,258,259,177,260],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path"]