[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CNC4XKDX0R77KJ4AAVV4RX":3,"skill-same:01M6CNC4XKDX0R77KJ4AAVV4RX":185},{"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":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":41,"install":42,"resources":54},"01M6CNC4XKDX0R77KJ4AAVV4RX","archrip-scan",null,"Scan codebase and generate architecture diagram data","yida29\u002Farchrip","yida29","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F26829774?v=4","01M6CNBNXVC8D2SWGB774Y97ZE","yida","01M6CNBP1TGZ21SGQ3ZY626QHH",1,"MIT","https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Farchrip-scan\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"scan","archrip scan","directory","architecture","diagram","architecture diagram","generate","data","instructions","2026-11-10 10:12:30",false,"---\nname: archrip-scan\ndescription: Scan codebase and generate architecture diagram data\nuser-invocable: true\nargument-hint: \"[directory or instructions]\"\n---\n\n# archrip scan — Analyze codebase architecture\n\nAnalyze the current codebase and generate `.archrip\u002Farchitecture.json`.\n\n**Language rule:** Respond in the same language as the user's message or `$ARGUMENTS`. If no user text is available, detect the project's primary language from README\u002Fdocs and match it. The `architecture.json` fields (labels, descriptions) should also use that language.\n\n## Phase 1: Project Discovery\n1. Read top-level files (package.json, composer.json, go.mod, Cargo.toml, pom.xml, pyproject.toml, etc.)\n2. Identify language, framework, source root\n3. List directory structure (2 levels deep)\n4. Auto-detect `sourceUrl`: Run `git remote get-url origin` and convert to browse URL:\n   - `git@github.com:org\u002Frepo.git` → `https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fblob\u002Fmain\u002F{filePath}`\n   - `https:\u002F\u002Fgithub.com\u002Forg\u002Frepo.git` → `https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fblob\u002Fmain\u002F{filePath}`\n   - `git@gitlab.com:org\u002Frepo.git` → `https:\u002F\u002Fgitlab.com\u002Forg\u002Frepo\u002F-\u002Fblob\u002Fmain\u002F{filePath}`\n   - If no git remote, leave empty (ask in Phase 7)\n\n## Phase 2: Documentation Discovery\nRead existing documentation to understand architecture context:\n1. Check for: README.md, CLAUDE.md, docs\u002F, doc\u002F, wiki\u002F, ARCHITECTURE.md, CONTRIBUTING.md, ADR\u002F\n2. For each document, extract and take notes on:\n   - **Business context**: What problem does this system solve? Who are the users?\n   - **Component responsibilities**: What each module\u002Fservice does and why it exists\n   - **Design decisions & constraints**: Why certain patterns\u002Flibraries were chosen, known limitations\n   - **Data flow**: How data moves through the system (request lifecycle, event flow, etc.)\n   - **External integrations**: What external services are used, why, and how\n   - **Non-functional requirements**: SLAs, performance targets, security policies\n   - **Deployment & infrastructure**: Hosting, CI\u002FCD, environment details\n3. Keep these notes — you will use them in Phase 4 to write rich node\u002Fedge descriptions and metadata\n\n## Phase 3: Layer Identification\nAssign each component a `layer` integer. The rule: **higher layer = closer to domain core (more stable, fewer external dependencies). Lower layer = closer to external world (more volatile, I\u002FO-bound).**\n\n**Reference mappings** (layer numbers in parentheses — adapt to actual project structure):\n\nMVC \u002F Layered:\n- Laravel: External(0) → Controllers(1) → Services(2) → Domain(3)\n- Rails: External(0) → Controllers(1) → Services(2) → Domain(3)\n- Django: External(0) → Views(1) → Serializers(2) → Services(3) → Domain(4)\n- Spring Boot: External(0) → Controllers(1) → Services(2) → Repositories(3) → Domain(4)\n- NestJS: External(0) → Controllers(1) → Services(2) → Repositories(3) → Domain(4)\n- Next.js App Router: External(0) → Route Handlers\u002FPages(1) → Components(2) → Hooks\u002FServices(3) → Data Access(4)\n- FastAPI: External(0) → Routers(1) → Services(2) → Repositories(3) → Domain(4)\n\nDDD \u002F Clean Architecture \u002F Hexagonal (use `\"layout\": \"concentric\"`):\n- Generic: External(0) → Adapters(1) [Inbound (HTTP handlers, CLI), Outbound (DB impl, API clients)] → Application Core(2) [Use Cases \u002F Application Services, Ports] → Domain(3)\n- Go (Hex): External(0) → Adapters(1) [Handlers, Repositories] → Application Core(2) [Use Cases, Ports] → Domain(3)\n- Flutter (Clean): External(0) → Data Sources(1) → Repositories(2) → Use Cases(3) → Domain(4)\n- Note: Ports are interfaces owned by the **application core** (use cases \u002F application services; sometimes placed in domain, but not required). Adapters implement outbound Ports and call inbound Ports. For layering, Ports should be at the same layer as the application core (or 1 step closer to Domain), never at the adapter layer.\n\nCQRS \u002F Event-Driven:\n- CQRS: External(0) → Command Handlers \u002F Query Handlers(1) → Application Services(2) → Domain(3). Command and Query sides share the same layer structure but separate models\n- Event Sourcing: External(0) → Command Handlers(1) → Event Store(2) → Projections(3) → Read Models(4)\n- Event-Driven (Motia, Temporal, etc.): External(0) → API Steps(1) → Event Steps(2) → Services(3) → Domain(4)\n\nServerless \u002F Microservices:\n- SST\u002FLambda: External(0) → Infrastructure(1) [sst.config.ts, CloudFormation] → API Gateway(2) → Lambda Handlers(3) → Services(4) → Domain(5)\n- Microservices: External(0) → Infrastructure(1) [Terraform, Pulumi, K8s manifests] → Gateway\u002FBFF(2) → Service Boundaries(3) → Internal Services(4) → Shared Domain(5)\n\nModular Monolith:\n- Generic: External(0) → Module APIs(1) [public interfaces] → Module Internal Services(2) → Shared Kernel \u002F Domain(3)\n\nFor unlisted frameworks: group by directory responsibility and apply the abstract rule above.\n\n## Phase 4: Read Key Files\nFor each layer, read representative files to extract:\n- Component names and purposes\n- Dependencies (imports, injections)\n- Public methods\u002Froutes\n- Database schemas (from migrations or entity definitions)\n- SQL queries \u002F ORM operations (from repositories, DAOs, or query builders)\n\n**Granularity: one node per real component.** Resist the urge to bundle siblings into umbrella nodes (e.g. a single `domain-shared-models` covering 9 entities, or one `adpt-shared-repos` for every repository implementation). Each Controller, UseCase, abstract Repository, Repository implementation, and Domain Entity is normally its own node. See [schema-reference.md → Node Granularity](schema-reference.md#node-granularity-avoid-over-collapsing) for the exact rule of thumb.\n\n**Repository → Port pattern:** in DDD\u002FHexagonal projects, every abstract Repository in `domains\u002F` becomes a `port` node (layer = application core), and every concrete implementation in `infrastructures\u002F` becomes an `adapter` node (outer layer). The use case depends on the port; the adapter `implements` the port. See [schema-reference.md → Repository → Port pattern](schema-reference.md#repository--port-pattern-ddd--hexagonal) for the canonical shape.\n\n**Enrich descriptions from documentation:** Cross-reference code with your Phase 2 notes.\nFor each component, compose a `description` (1-3 sentences) that covers:\n- **What**: Its responsibility (from code analysis)\n- **Why**: Business context or design rationale (from docs)\n- **How**: Key implementation details, constraints, or patterns worth noting\n\nA good description tells the reader something they cannot see from the label alone.\n- BAD: \"User service\" (just echoes the label)\n- GOOD: \"Handles user registration, login, and profile management. Uses JWT for session tokens with 24h expiry. Password hashing via bcrypt (cost=12).\"\n\nAlso identify metadata candidates:\n- SLA\u002Fperformance notes → `metadata` with `type: \"list\"`\n- Related doc links → `metadata` with `type: \"link\"`\n- Infrastructure details (Lambda ARN, DB engine, etc.) → `metadata` with `type: \"code\"` or `\"text\"`\n- SQL queries or ORM operations → edge `metadata` with `type: \"code\"` or `\"list\"` (see Phase 5)\n\n**Do NOT read every file.** Focus on entry points, core logic, interfaces, and data models.\n\n## Phase 5: Map Relationships\nFor each component, identify:\n- What it depends on (imports, constructor injection)\n- What depends on it\n- External service connections\n\n**Edge type matters.** `dependency` \u002F `implements` \u002F `relation` are not interchangeable. In particular, `implements` edges always flow `adapter → port` — never adapter → entity, adapter → adapter, or adapter → database. If you cannot point an `implements` edge at a `port` node, the abstraction is missing from the diagram and should be added. See [schema-reference.md → Edge type semantics](schema-reference.md#edge-type-semantics).\n\n**Connectivity check:** After mapping, verify every node has at least one edge. If a node is orphaned:\n- DTOs\u002Fentities → connect to the service or adapter that references them\n- External services → connect to the adapter\u002Fcontroller that integrates with them\n- Entities → connect to the repository\u002Fadapter that references them\n- Database nodes → connect to the adapter\u002Frepository that queries them\n- Infrastructure nodes → connect to the adapter\u002Fservice they provision\n\n**Edge enrichment — SQL \u002F query details:**\nFor edges connecting a service\u002Fadapter\u002Frepository to a database or entity node, include query information:\n- `description`: summarize what data operation this edge performs (e.g., \"Queries active users by email with JOIN on roles\")\n- `metadata`: include representative SQL or ORM queries found in the source code\n\nExample:\n```json\n{\n  \"source\": \"adpt-user-repo\",\n  \"target\": \"db-users\",\n  \"type\": \"dependency\",\n  \"description\": \"CRUD operations on users table; filters by email and status with role JOIN\",\n  \"metadata\": [\n    { \"label\": \"Queries\", \"value\": [\"SELECT u.*, r.name FROM users u JOIN roles r ON u.role_id = r.id WHERE u.email = ?\", \"INSERT INTO users (name, email, role_id) VALUES (?, ?, ?)\"], \"type\": \"list\" },\n    { \"label\": \"ORM\", \"value\": \"User::with('role')->where('email', $email)->first()\", \"type\": \"code\" }\n  ]\n}\n```\n\nGuidelines:\n- Include the most representative 2-3 queries (not every query)\n- For ORMs (Eloquent, Drizzle, Prisma, etc.), use `type: \"code\"` with the ORM syntax\n- For raw SQL, use `type: \"list\"` with individual queries\n- Parameterize values (use `?` or `:param` placeholders, not literals)\n\n## Phase 6: Identify Use Cases\nGroup related components into user-facing features.\n\n## Phase 7: Draft Review — STOP and ask the developer\n\n**IMPORTANT: Do NOT proceed to Phase 8 until the developer responds. You MUST stop here and wait for input.**\n\nPresent a summary of what you found:\n- **Documents read**: List all docs you read in Phase 2 (e.g., README.md, CLAUDE.md, docs\u002Farchitecture.md)\n- List of discovered nodes (grouped by layer\u002Fcategory)\n- List of discovered use cases\n- External services found\n\nThen ask:\n- Are there other documents you should read? (e.g., docs\u002F, wiki\u002F, design docs)\n- Are there missing components, external services, or use cases?\n- Should anything be excluded?\n- `sourceUrl` auto-detected as: `\u003Cdetected-url>` — correct? (If not detected, ask for the `sourceUrl` template, e.g., `https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fblob\u002Fmain\u002F{filePath}`)\n\nEnd your message with: **\"Please review and reply with corrections, or type 'go' to generate.\"**\n\n**Do NOT write architecture.json yet. Wait for the developer to respond.**\n\nIf the developer replies with corrections, apply them and present the updated summary. Repeat until they say \"go\" \u002F \"ok\" \u002F \"skip\".\n\n## Phase 8: Generate architecture.json\nOnly run this phase AFTER the developer has approved the draft in Phase 7.\n\nCreate `.archrip\u002F` directory if it doesn't exist, then write the complete `.archrip\u002Farchitecture.json` following the schema, incorporating developer feedback.\n\nFor the complete schema specification (field names, node\u002Fedge rules, layout selection), see [schema-reference.md](schema-reference.md).\n\nAfter writing the file:\n1. Run `npx archrip serve` in the terminal (auto-builds if needed, opens browser)\n2. Tell the developer: Run `\u002Farchrip-update` to make further adjustments (add\u002Fremove nodes, fix relationships, etc.)\n\n$ARGUMENTS\n","# archrip scan — Analyze codebase architecture\n\nAnalyze the current codebase and generate `.archrip\u002Farchitecture.json`.\n\n**Language rule:** Respond in the same language as the user's message or `$ARGUMENTS`. If no user text is available, detect the project's primary language from README\u002Fdocs and match it. The `architecture.json` fields (labels, descriptions) should also use that language.\n\n## Phase 1: Project Discovery\n1. Read top-level files (package.json, composer.json, go.mod, Cargo.toml, pom.xml, pyproject.toml, etc.)\n2. Identify language, framework, source root\n3. List directory structure (2 levels deep)\n4. Auto-detect `sourceUrl`: Run `git remote get-url origin` and convert to browse URL:\n   - `git@github.com:org\u002Frepo.git` → `https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fblob\u002Fmain\u002F{filePath}`\n   - `https:\u002F\u002Fgithub.com\u002Forg\u002Frepo.git` → `https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fblob\u002Fmain\u002F{filePath}`\n   - `git@gitlab.com:org\u002Frepo.git` → `https:\u002F\u002Fgitlab.com\u002Forg\u002Frepo\u002F-\u002Fblob\u002Fmain\u002F{filePath}`\n   - If no git remote, leave empty (ask in Phase 7)\n\n## Phase 2: Documentation Discovery\nRead existing documentation to understand architecture context:\n1. Check for: README.md, CLAUDE.md, docs\u002F, doc\u002F, wiki\u002F, ARCHITECTURE.md, CONTRIBUTING.md, ADR\u002F\n2. For each document, extract and take notes on:\n   - **Business context**: What problem does this system solve? Who are the users?\n   - **Component responsibilities**: What each module\u002Fservice does and why it exists\n   - **Design decisions & constraints**: Why certain patterns\u002Flibraries were chosen, known limitations\n   - **Data flow**: How data moves through the system (request lifecycle, event flow, etc.)\n   - **External integrations**: What external services are used, why, and how\n   - **Non-functional requirements**: SLAs, performance targets, security policies\n   - **Deployment & infrastructure**: Hosting, CI\u002FCD, environment details\n3. Keep these notes — you will use them in Phase 4 to write rich node\u002Fedge descriptions and metadata\n\n## Phase 3: Layer Identification\nAssign each component a `layer` integer. The rule: **higher layer = closer to domain core (more stable, fewer external dependencies). Lower layer = closer to external world (more volatile, I\u002FO-bound).**\n\n**Reference mappings** (layer numbers in parentheses — adapt to actual project structure):\n\nMVC \u002F Layered:\n- Laravel: External(0) → Controllers(1) → Services(2) → Domain(3)\n- Rails: External(0) → Controllers(1) → Services(2) → Domain(3)\n- Django: External(0) → Views(1) → Serializers(2) → Services(3) → Domain(4)\n- Spring Boot: External(0) → Controllers(1) → Services(2) → Repositories(3) → Domain(4)\n- NestJS: External(0) → Controllers(1) → Services(2) → Repositories(3) → Domain(4)\n- Next.js App Router: External(0) → Route Handlers\u002FPages(1) → Components(2) → Hooks\u002FServices(3) → Data Access(4)\n- FastAPI: External(0) → Routers(1) → Services(2) → Repositories(3) → Domain(4)\n\nDDD \u002F Clean Architecture \u002F Hexagonal (use `\"layout\": \"concentric\"`):\n- Generic: External(0) → Adapters(1) [Inbound (HTTP handlers, CLI), Outbound (DB impl, API clients)] → Application Core(2) [Use Cases \u002F Application Services, Ports] → Domain(3)\n- Go (Hex): External(0) → Adapters(1) [Handlers, Repositories] → Application Core(2) [Use Cases, Ports] → Domain(3)\n- Flutter (Clean): External(0) → Data Sources(1) → Repositories(2) → Use Cases(3) → Domain(4)\n- Note: Ports are interfaces owned by the **application core** (use cases \u002F application services; sometimes placed in domain, but not required). Adapters implement outbound Ports and call inbound Ports. For layering, Ports should be at the same layer as the application core (or 1 step closer to Domain), never at the adapter layer.\n\nCQRS \u002F Event-Driven:\n- CQRS: External(0) → Command Handlers \u002F Query Handlers(1) → Application Services(2) → Domain(3). Command and Query sides share the same layer structure but separate models\n- Event Sourcing: External(0) → Command Handlers(1) → Event Store(2) → Projections(3) → Read Models(4)\n- Event-Driven (Motia, Temporal, etc.): External(0) → API Steps(1) → Event Steps(2) → Services(3) → Domain(4)\n\nServerless \u002F Microservices:\n- SST\u002FLambda: External(0) → Infrastructure(1) [sst.config.ts, CloudFormation] → API Gateway(2) → Lambda Handlers(3) → Services(4) → Domain(5)\n- Microservices: External(0) → Infrastructure(1) [Terraform, Pulumi, K8s manifests] → Gateway\u002FBFF(2) → Service Boundaries(3) → Internal Services(4) → Shared Domain(5)\n\nModular Monolith:\n- Generic: External(0) → Module APIs(1) [public interfaces] → Module Internal Services(2) → Shared Kernel \u002F Domain(3)\n\nFor unlisted frameworks: group by directory responsibility and apply the abstract rule above.\n\n## Phase 4: Read Key Files\nFor each layer, read representative files to extract:\n- Component names and purposes\n- Dependencies (imports, injections)\n- Public methods\u002Froutes\n- Database schemas (from migrations or entity definitions)\n- SQL queries \u002F ORM operations (from repositories, DAOs, or query builders)\n\n**Granularity: one node per real component.** Resist the urge to bundle siblings into umbrella nodes (e.g. a single `domain-shared-models` covering 9 entities, or one `adpt-shared-repos` for every repository implementation). Each Controller, UseCase, abstract Repository, Repository implementation, and Domain Entity is normally its own node. See [schema-reference.md → Node Granularity](schema-reference.md#node-granularity-avoid-over-collapsing) for the exact rule of thumb.\n\n**Repository → Port pattern:** in DDD\u002FHexagonal projects, every abstract Repository in `domains\u002F` becomes a `port` node (layer = application core), and every concrete implementation in `infrastructures\u002F` becomes an `adapter` node (outer layer). The use case depends on the port; the adapter `implements` the port. See [schema-reference.md → Repository → Port pattern](schema-reference.md#repository--port-pattern-ddd--hexagonal) for the canonical shape.\n\n**Enrich descriptions from documentation:** Cross-reference code with your Phase 2 notes.\nFor each component, compose a `description` (1-3 sentences) that covers:\n- **What**: Its responsibility (from code analysis)\n- **Why**: Business context or design rationale (from docs)\n- **How**: Key implementation details, constraints, or patterns worth noting\n\nA good description tells the reader something they cannot see from the label alone.\n- BAD: \"User service\" (just echoes the label)\n- GOOD: \"Handles user registration, login, and profile management. Uses JWT for session tokens with 24h expiry. Password hashing via bcrypt (cost=12).\"\n\nAlso identify metadata candidates:\n- SLA\u002Fperformance notes → `metadata` with `type: \"list\"`\n- Related doc links → `metadata` with `type: \"link\"`\n- Infrastructure details (Lambda ARN, DB engine, etc.) → `metadata` with `type: \"code\"` or `\"text\"`\n- SQL queries or ORM operations → edge `metadata` with `type: \"code\"` or `\"list\"` (see Phase 5)\n\n**Do NOT read every file.** Focus on entry points, core logic, interfaces, and data models.\n\n## Phase 5: Map Relationships\nFor each component, identify:\n- What it depends on (imports, constructor injection)\n- What depends on it\n- External service connections\n\n**Edge type matters.** `dependency` \u002F `implements` \u002F `relation` are not interchangeable. In particular, `implements` edges always flow `adapter → port` — never adapter → entity, adapter → adapter, or adapter → database. If you cannot point an `implements` edge at a `port` node, the abstraction is missing from the diagram and should be added. See [schema-reference.md → Edge type semantics](schema-reference.md#edge-type-semantics).\n\n**Connectivity check:** After mapping, verify every node has at least one edge. If a node is orphaned:\n- DTOs\u002Fentities → connect to the service or adapter that references them\n- External services → connect to the adapter\u002Fcontroller that integrates with them\n- Entities → connect to the repository\u002Fadapter that references them\n- Database nodes → connect to the adapter\u002Frepository that queries them\n- Infrastructure nodes → connect to the adapter\u002Fservice they provision\n\n**Edge enrichment — SQL \u002F query details:**\nFor edges connecting a service\u002Fadapter\u002Frepository to a database or entity node, include query information:\n- `description`: summarize what data operation this edge performs (e.g., \"Queries active users by email with JOIN on roles\")\n- `metadata`: include representative SQL or ORM queries found in the source code\n\nExample:\n```json\n{\n  \"source\": \"adpt-user-repo\",\n  \"target\": \"db-users\",\n  \"type\": \"dependency\",\n  \"description\": \"CRUD operations on users table; filters by email and status with role JOIN\",\n  \"metadata\": [\n    { \"label\": \"Queries\", \"value\": [\"SELECT u.*, r.name FROM users u JOIN roles r ON u.role_id = r.id WHERE u.email = ?\", \"INSERT INTO users (name, email, role_id) VALUES (?, ?, ?)\"], \"type\": \"list\" },\n    { \"label\": \"ORM\", \"value\": \"User::with('role')->where('email', $email)->first()\", \"type\": \"code\" }\n  ]\n}\n```\n\nGuidelines:\n- Include the most representative 2-3 queries (not every query)\n- For ORMs (Eloquent, Drizzle, Prisma, etc.), use `type: \"code\"` with the ORM syntax\n- For raw SQL, use `type: \"list\"` with individual queries\n- Parameterize values (use `?` or `:param` placeholders, not literals)\n\n## Phase 6: Identify Use Cases\nGroup related components into user-facing features.\n\n## Phase 7: Draft Review — STOP and ask the developer\n\n**IMPORTANT: Do NOT proceed to Phase 8 until the developer responds. You MUST stop here and wait for input.**\n\nPresent a summary of what you found:\n- **Documents read**: List all docs you read in Phase 2 (e.g., README.md, CLAUDE.md, docs\u002Farchitecture.md)\n- List of discovered nodes (grouped by layer\u002Fcategory)\n- List of discovered use cases\n- External services found\n\nThen ask:\n- Are there other documents you should read? (e.g., docs\u002F, wiki\u002F, design docs)\n- Are there missing components, external services, or use cases?\n- Should anything be excluded?\n- `sourceUrl` auto-detected as: `\u003Cdetected-url>` — correct? (If not detected, ask for the `sourceUrl` template, e.g., `https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fblob\u002Fmain\u002F{filePath}`)\n\nEnd your message with: **\"Please review and reply with corrections, or type 'go' to generate.\"**\n\n**Do NOT write architecture.json yet. Wait for the developer to respond.**\n\nIf the developer replies with corrections, apply them and present the updated summary. Repeat until they say \"go\" \u002F \"ok\" \u002F \"skip\".\n\n## Phase 8: Generate architecture.json\nOnly run this phase AFTER the developer has approved the draft in Phase 7.\n\nCreate `.archrip\u002F` directory if it doesn't exist, then write the complete `.archrip\u002Farchitecture.json` following the schema, incorporating developer feedback.\n\nFor the complete schema specification (field names, node\u002Fedge rules, layout selection), see [schema-reference.md](schema-reference.md).\n\nAfter writing the file:\n1. Run `npx archrip serve` in the terminal (auto-builds if needed, opens browser)\n2. Tell the developer: Run `\u002Farchrip-update` to make further adjustments (add\u002Fremove nodes, fix relationships, etc.)\n\n$ARGUMENTS\n",{"name":5,"description":7,"argument-hint":33,"user-invocable":34},"[directory or instructions]",true,"main","5a62325f7d5f614ee9ffbb6d5ab7db8fecb465b0","skills\u002Farchrip-scan",0,"https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip","https:\u002F\u002Fgithub.com\u002Fyida29","2026-11-12 04:05:53",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":34},[44,47,50],{"tool":45,"command":46},"npx","npx skills add yida29\u002Farchrip --skill archrip-scan",{"tool":48,"command":49},"bunx","bunx skills add yida29\u002Farchrip --skill archrip-scan",{"tool":51,"command":52},"pnpm","pnpm dlx skills add yida29\u002Farchrip --skill archrip-scan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Farchrip-scan\u002FSKILL.md",[55,61,65,69,73,77,81,85,89,93,97,101,105,109,113,117,121,127,131,135,139,143,147,151,155,159,163,167,171,177,181],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"assets\u002Fexamples\u002Fcell_summary_example.md","ASSET","资产文件",8876,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fexamples\u002Fcell_summary_example.md",{"path":62,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":63,"sourceHtmlUrl":64},"assets\u002Fexamples\u002Fmedical_structured_abstract.md",12073,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fexamples\u002Fmedical_structured_abstract.md",{"path":66,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":67,"sourceHtmlUrl":68},"assets\u002Fexamples\u002Fnature_abstract_examples.md",8953,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fexamples\u002Fnature_abstract_examples.md",{"path":70,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":71,"sourceHtmlUrl":72},"assets\u002Fexamples\u002Fneurips_introduction_example.md",8778,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fexamples\u002Fneurips_introduction_example.md",{"path":74,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":75,"sourceHtmlUrl":76},"assets\u002Fgrants\u002Fnih_specific_aims.tex",9245,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fgrants\u002Fnih_specific_aims.tex",{"path":78,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":79,"sourceHtmlUrl":80},"assets\u002Fgrants\u002Fnsf_proposal_template.tex",13884,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fgrants\u002Fnsf_proposal_template.tex",{"path":82,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":83,"sourceHtmlUrl":84},"assets\u002Fjournals\u002Felsarticle-harv.bst",30002,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Felsarticle-harv.bst",{"path":86,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":87,"sourceHtmlUrl":88},"assets\u002Fjournals\u002Felsarticle-num-names.bst",28896,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Felsarticle-num-names.bst",{"path":90,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":91,"sourceHtmlUrl":92},"assets\u002Fjournals\u002Felsarticle-num.bst",29462,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Felsarticle-num.bst",{"path":94,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":95,"sourceHtmlUrl":96},"assets\u002Fjournals\u002Felsarticle-template-harv.tex",8518,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Felsarticle-template-harv.tex",{"path":98,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":99,"sourceHtmlUrl":100},"assets\u002Fjournals\u002Felsarticle-template-num-names.tex",8428,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Felsarticle-template-num-names.tex",{"path":102,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":103,"sourceHtmlUrl":104},"assets\u002Fjournals\u002Felsarticle-template-num.tex",8424,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Felsarticle-template-num.tex",{"path":106,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":107,"sourceHtmlUrl":108},"assets\u002Fjournals\u002Fnature_article.tex",6434,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Fnature_article.tex",{"path":110,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":111,"sourceHtmlUrl":112},"assets\u002Fjournals\u002Fneurips_article.tex",9318,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Fneurips_article.tex",{"path":114,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":115,"sourceHtmlUrl":116},"assets\u002Fjournals\u002Fplos_one.tex",11907,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fjournals\u002Fplos_one.tex",{"path":118,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":119,"sourceHtmlUrl":120},"assets\u002Fposters\u002Fbeamerposter_academic.tex",8569,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fassets\u002Fposters\u002Fbeamerposter_academic.tex",{"path":122,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":125,"sourceHtmlUrl":126},"references\u002Fcell_press_style.md","REFERENCE","参考文档",14703,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fcell_press_style.md",{"path":128,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":129,"sourceHtmlUrl":130},"references\u002Fconferences_formatting.md",7785,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fconferences_formatting.md",{"path":132,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":133,"sourceHtmlUrl":134},"references\u002Fcs_conference_style.md",16146,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fcs_conference_style.md",{"path":136,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":137,"sourceHtmlUrl":138},"references\u002Fgrants_requirements.md",10100,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fgrants_requirements.md",{"path":140,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":141,"sourceHtmlUrl":142},"references\u002Fjournals_formatting.md",9191,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fjournals_formatting.md",{"path":144,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":145,"sourceHtmlUrl":146},"references\u002Fmedical_journal_styles.md",16236,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fmedical_journal_styles.md",{"path":148,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":149,"sourceHtmlUrl":150},"references\u002Fml_conference_style.md",18779,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fml_conference_style.md",{"path":152,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":153,"sourceHtmlUrl":154},"references\u002Fnature_science_style.md",13821,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fnature_science_style.md",{"path":156,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":157,"sourceHtmlUrl":158},"references\u002Fposters_guidelines.md",17479,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fposters_guidelines.md",{"path":160,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":161,"sourceHtmlUrl":162},"references\u002Freviewer_expectations.md",16288,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Freviewer_expectations.md",{"path":164,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":165,"sourceHtmlUrl":166},"references\u002Fvenue_writing_styles.md",12972,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Freferences\u002Fvenue_writing_styles.md",{"path":168,"resourceType":123,"resourceTypeDesc":124,"sizeBytes":169,"sourceHtmlUrl":170},"schema-reference.md",7847,"https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Farchrip-scan\u002Fschema-reference.md",{"path":172,"resourceType":173,"resourceTypeDesc":174,"sizeBytes":175,"sourceHtmlUrl":176},"scripts\u002Fcustomize_template.py","SCRIPT","脚本",7149,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fscripts\u002Fcustomize_template.py",{"path":178,"resourceType":173,"resourceTypeDesc":174,"sizeBytes":179,"sourceHtmlUrl":180},"scripts\u002Fquery_template.py",8077,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fscripts\u002Fquery_template.py",{"path":182,"resourceType":173,"resourceTypeDesc":174,"sizeBytes":183,"sourceHtmlUrl":184},"scripts\u002Fvalidate_format.py",10874,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fvenue-templates\u002Fscripts\u002Fvalidate_format.py",[186,205,220,241,252,261],{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":197,"publishedAt":28},"01M6CNCP1G0EWPEG4HMAQ9Z4AD","review-ux-diagnostics","Review UX and diagnostics (errors, hints, verbose mode)","https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Freview-ux-diagnostics\u002FSKILL.md",[192],{"categoryNo":193,"categoryName":194,"taxonomyType":195,"taxonomyTypeDesc":196},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[198,199,200,201,202,203,204],"review","review ux diagnostics","ux","diagnostics","git","notes","diff",{"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":28},"01M6CNCM7K3S2710FJP16G0SSE","review-typescript-strict","TypeScript Strict Modeガイドラインを適用してコードレビュー・修正を行う。","https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Freview-typescript-strict\u002FSKILL.md",[],[212,198,213,214,215,216,217,218,219],"typescript strict","typescript","review typescript strict","grep","check","file","read","edit",{"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":231,"publishedAt":28},"01M6CNCJAY371WT8PYMTQPJ4KW","review-test-strategy","Review test strategy and regression resistance","https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Freview-test-strategy\u002FSKILL.md",[226],{"categoryNo":227,"categoryName":228,"taxonomyType":229,"taxonomyTypeDesc":230},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[232,233,234,235,198,236,237,203,238,239,240],"strategy","test strategy","review test strategy","test","package","command","flow","regression","repo",{"skillNo":242,"name":243,"nameZh":6,"description":244,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":245,"categories":246,"keywords":247,"publishedAt":28},"01M6CNCGCTBMAWM2NPF5KAVFVK","review-supply-chain","Review supply-chain and code-execution risks","https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Freview-supply-chain\u002FSKILL.md",[],[248,198,249,203,202,250,251,204],"review supply chain","code","supply-chain","execution",{"skillNo":253,"name":254,"nameZh":6,"description":255,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":256,"categories":257,"keywords":258,"publishedAt":28},"01M6CNCE6C1XXP746XW9P7MV56","review-srp","Review codebase for SRP (Single Responsibility) and boundaries","https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Freview-srp\u002FSKILL.md",[],[198,259,203,260,202,204],"review srp","pr",{"skillNo":262,"name":263,"nameZh":6,"description":264,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":265,"categories":266,"keywords":267,"publishedAt":28},"01M6CNCCGEFSJ6YCDQNTTZT81J","review-schema-first","Review schema as a single source of truth (Schema-first)","https:\u002F\u002Fgithub.com\u002Fyida29\u002Farchrip\u002Fblob\u002Fmain\u002Fskills\u002Freview-schema-first\u002FSKILL.md",[],[198,268,269,270,203,202,204],"first","schema","review schema first"]