[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71CD4CVWD7S465E7B9WP1YA":3,"skill-same:01M71CD4CVWD7S465E7B9WP1YA":80},{"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":28,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":65,"updatedAt":66,"install":67,"resources":79},"01M71CD4CVWD7S465E7B9WP1YA","sharingan",null,"User-invoked reverse-engineering + enhancement protocol for any source artifact: repos, codebases, docs, PDFs, screenshots, specs, workflows. Observe deeply, extract underlying technique (not property), expose weaknesses, then rebuild as a legally clean, Yuri OS \u002F Yuri-aligned diamond design via 9-phase pipeline. Use when the user says \"activate Sharingan\", \"reverse-engineer this\", \"copy the technique not the code\", or wants to deeply understand and rebuild an artifact from first principles.","nexuslinkproductions\u002Fyuri-os","nexuslinkproductions","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273246263?v=4","01M718YX9NZRCW50B59B8ZVDKN","Marcel Spatz","01M718YXAQ7530F4B1VKN6SFQV",2,"MIT","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fsharingan\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[5,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"code","screenshots","enhancement","source","os","repos","artifact","rebuild","phase","activate","first principles","when","workflows","design","clean","engineer","pipeline","observe","reverse-engineering","2026-11-10 10:12:30",false,"---\nname: sharingan\ndisable-model-invocation: true\ndescription: \"User-invoked reverse-engineering + enhancement protocol for any source artifact: repos, codebases, docs, PDFs, screenshots, specs, workflows. Observe deeply, extract underlying technique (not property), expose weaknesses, then rebuild as a legally clean, Yuri OS \u002F Yuri-aligned diamond design via 9-phase pipeline. Use when the user says \\\"activate Sharingan\\\", \\\"reverse-engineer this\\\", \\\"copy the technique not the code\\\", or wants to deeply understand and rebuild an artifact from first principles.\"\ntriggers:\n  - \"\u002Fsharingan\"\n  - \"sharingan\"\n  - \"\u002Fsr\"\nscope: harness\ninvocation: ability\n---\n\n# Sharingan\n\n## Core identity\n\nYou are activating the **Sharingan Protocol**: observe deeply, copy only the underlying technique, expose weaknesses, then reconstruct the concept into a stronger, cleaner, better engineered artifact for **Yuri OS \u002F Yuri**.\n\nThis is inspired by Kakashi's \"copy ninja\" concept, but the operating rule is precise:\n\n> Extract the pattern, not the property. Improve the system, not merely imitate the surface.\n\nYou must never blindly clone. You must never launder copyrighted, proprietary, or license-incompatible material. You may analyze public or user-provided artifacts, extract ideas, architecture, patterns, workflows, and failure modes, then create an original implementation or blueprint that is better suited to Yuri OS \u002F Yuri.\n\nUse high reasoning \u002F extended thinking if available. Reason internally, but expose only concise reasoning summaries, evidence, decisions, and artifacts.\n\n---\n\n## Invocation\n\nUse this skill directly:\n\n```text\n\u002Fsharingan \u003Csource or target>\n```\n\nExamples:\n\n```text\n\u002Fsharingan https:\u002F\u002Fgithub.com\u002Forg\u002Frepo --target \"adapt into Yuri OS plugin\"\n\u002Fsharingan .\u002Fexternal-repos\u002Fcool-tool --target \"rebuild as Yuri skill\"\n\u002Fsharingan .\u002Fdocs\u002Fresearch-paper.pdf --target \"turn into implementation blueprint\"\n\u002Fsharingan \"this landing page \u002F workflow \u002F screenshot \u002F spec\" --target \"extract pattern and improve\"\n```\n\nIf arguments are vague, infer a reasonable target from the current project context and proceed. Ask only when a missing constraint would materially change the result.\n\n---\n\n## Prime directive\n\nGiven any source artifact, produce a better, cleaner, legally safe, Yuri-compatible version by following this chain:\n\n```text\nobserve -> decompose -> audit -> abstract -> enrich -> redesign -> implement\u002Fplan -> validate -> document\n```\n\nThe final outcome must be more useful than the original. The user wants the \"rough blueprint\" refined into a diamond.\n\n---\n\n## Non-negotiable boundaries\n\n### Legal and ethical gate\n\nBefore extracting or rebuilding anything, classify the source:\n\n- **Permissive \u002F open source:** Respect license terms, attribution, notices, and dependency obligations.\n- **Restrictive \u002F unclear license:** Do not copy code, text, assets, or unique expression. Create a clean-room conceptual spec and original implementation plan.\n- **Proprietary \u002F private:** Only analyze if the user has authorization. Do not reproduce protected material beyond what is necessary for critique.\n- **Generated \u002F mixed sources:** Treat license as uncertain unless proven otherwise.\n\nAlways preserve attribution requirements. If the source is not safely reusable, say so and continue with a clean-room reconstruction.\n\n### Security gate\n\nTreat every external artifact as hostile until inspected.\n\nNever run install scripts, package lifecycle hooks, downloaded binaries, migration scripts, shell scripts, or networked commands without first explaining the risk and inspecting the relevant files.\n\nPrefer static analysis first:\n\n```text\nread files -> inspect manifests -> inspect scripts -> inspect permissions -> inspect network behavior -> then run safe commands\n```\n\nIf execution is needed, prefer a sandbox, temporary clone, isolated environment, disabled lifecycle hooks, and read-only inspection.\n\n### Non-destructive operation\n\nNever overwrite the user's system directly as a first move.\n\nUse this order:\n\n1. Inspect current workspace.\n2. Check git status if available.\n3. Create a plan.\n4. Create a branch, patch directory, or separate output folder.\n5. Apply changes in small reversible steps.\n6. Show diffs or artifact summaries before declaring success.\n\nIf no git repository exists, create a working folder:\n\n```text\n.sharingan\u002F\u003Csource-name>\u002F\u003Ctimestamp>\u002F\n```\n\nFor YURI projects, prefer:\n\n```text\n\u003CYURI_ROOT>\u002F.sharingan\u002F\u003Csource-name>\u002F\u003Ctimestamp>\u002F\n```\n\n---\n\n## Source intake protocol\n\nIdentify the source type and choose the correct ingestion path.\n\n### GitHub repo or local codebase\n\nCollect:\n\n- README and docs\n- license\n- package manifests\n- dependency graph\n- file tree\n- architecture entry points\n- tests\n- CI\u002FCD files\n- build scripts\n- security-sensitive files\n- examples and demos\n- issue patterns if available\n- public API surface\n\n**For local codebases in YURI:** Run GitNexus tools first (before grep):\n- `gitnexus_query({query: \"architecture\"})` — get execution flows\n- `gitnexus_context({name: \"symbolName\"})` — get callers\u002Fcallees\n- `gitnexus_impact({target: \"functionName\", direction: \"upstream\"})` — understand blast radius\n\nDo not judge from README alone. Many repos market well but fail structurally.\n\n### Documentation, specs, papers, PDFs, markdown, Notion exports\n\nCollect:\n\n- table of contents\n- claims\n- definitions\n- methods\n- diagrams\u002Ftables\n- assumptions\n- implementation steps\n- missing operational details\n- contradictions\n- unstated dependencies\n- reusable conceptual patterns\n\nTurn dense documents into an actionable engineering blueprint.\n\n### Screenshots, UI, product pages, workflows\n\nCollect:\n\n- visible structure\n- hierarchy\n- interaction pattern\n- information architecture\n- UX intent\n- likely backend assumptions\n- design tokens if inferable\n- conversion \u002F usability logic\n- accessibility risks\n- missing states\n\nDo not copy visuals directly. Extract design principles and rebuild original components.\n\n### Datasets, schemas, configs, logs\n\nCollect:\n\n- schema\n- field semantics\n- data quality issues\n- missing values\n- edge cases\n- validation rules\n- privacy\u002Fsecurity concerns\n- transformation opportunities\n- automatable workflows\n\n### Prompts, agents, skills, workflows\n\nCollect:\n\n- role framing\n- trigger conditions\n- operating loop\n- tool assumptions\n- guardrails\n- memory behavior\n- failure handling\n- output contracts\n- evaluation method\n\nThen harden it into a reusable, testable system component.\n\n---\n\n## Sharingan execution phases\n\n### Phase 0: Activation brief\n\nStart every run with a compact brief:\n\n```markdown\n## Sharingan Activation Brief\n- Source:\n- Source type:\n- Target outcome:\n- Reuse status:\n- Risk level:\n- Workspace impact:\n- Planned output artifacts:\n```\n\nIf the source cannot be accessed, state exactly what is missing and continue with any available material.\n\n---\n\n### Phase 1: Observe\n\nCreate a source map.\n\nFor repos, include:\n\n```markdown\n## Source Map\n- Purpose:\n- Main entry points:\n- Core modules:\n- Data flow:\n- External dependencies:\n- Build\u002Ftest commands:\n- Documentation quality:\n- License:\n- First suspicious signals:\n```\n\nFor non-code artifacts, include:\n\n```markdown\n## Source Map\n- Artifact type:\n- Core idea:\n- Structural sections:\n- Key claims or patterns:\n- Inputs and outputs:\n- Hidden assumptions:\n- Reusable techniques:\n- First suspicious signals:\n```\n\n---\n\n### Phase 2: Copy-eye decomposition\n\nExtract the underlying technique. Separate surface from mechanism.\n\nUse this table:\n\n```markdown\n| Layer | What the source does | Why it works | What is reusable | What must not be copied |\n|---|---|---|---|---|\n| Surface |  |  |  |  |\n| Workflow |  |  |  |  |\n| Architecture |  |  |  |  |\n| Data model |  |  |  |  |\n| Interface |  |  |  |  |\n| Execution logic |  |  |  |  |\n| Evaluation |  |  |  |  |\n```\n\nThe \"technique\" is usually not the code. It is the repeatable strategy underneath the code.\n\n---\n\n### Phase 3: Weakness and gap audit\n\nBe ruthless but fair. Do not assume something is bad just because it is simple. Simplicity is only a weakness when it blocks correctness, safety, scale, or maintainability.\n\nAudit categories:\n\n```markdown\n## Weakness Audit\n| Category | Finding | Evidence | Severity | Fix direction |\n|---|---|---:|---|---|\n| Architecture |  |  |  |  |\n| Security |  |  |  |  |\n| Reliability |  |  |  |  |\n| Performance |  |  |  |  |\n| Data model |  |  |  |  |\n| UX\u002FDX |  |  |  |  |\n| Testing |  |  |  |  |\n| Documentation |  |  |  |  |\n| Maintainability |  |  |  |  |\n| Yuri\u002FYuri fit |  |  |  |  |\n```\n\nLook specifically for:\n\n- missing tests\n- fragile abstractions\n- unclear data ownership\n- weak error handling\n- implicit global state\n- hardcoded paths\u002Fsecrets\n- unsafe shell execution\n- dependency bloat\n- poor observability\n- no rollback strategy\n- no migration path\n- README claims not backed by code\n- unhandled edge cases\n- unclear license posture\n- poor extensibility\n- no self-improvement loop\n- weak agent\u002Ftool permissions\n- prompt injection exposure\n- lack of deterministic validation\n\n---\n\n### Phase 4: Abstract into clean-room blueprint\n\nCreate a license-safe blueprint that captures the mechanism without copying protected expression.\n\n```markdown\n## Clean-Room Blueprint\n- Problem solved:\n- Core technique:\n- Required inputs:\n- Required outputs:\n- Minimal viable architecture:\n- Ideal architecture:\n- Data contracts:\n- Control flow:\n- Required tools:\n- Failure modes:\n- Validation strategy:\n- Extension points:\n```\n\nFor repo-inspired builds, describe new modules and interfaces using original names, unless the source license clearly permits reuse and reuse is intentional.\n\n---\n\n### Phase 5: Yuri OS \u002F Yuri enrichment\n\nRefine the blueprint through Yuri\u002FYuri standards.\n\nApply these lenses:\n\n- **Symbiotic integration:** Can this enhance an existing OS without replacing it?\n- **Non-destructive injection:** Can it be added without breaking current workflows?\n- **Self-improvement:** Does it produce session reports, failure logs, and improvement suggestions?\n- **Memory compatibility:** Can outputs become semantic, procedural, or episodic memory?\n- **Agent compatibility:** Can it be decomposed into orchestrator\u002Fsubagent roles?\n- **Cybersecurity:** Are tool permissions, sandboxing, secrets, and network access controlled?\n- **Observability:** Can every important action be logged, replayed, and audited?\n- **Modularity:** Can parts be swapped without rewriting the system?\n- **Recovery:** Can failed runs roll back safely?\n- **Enterprise readiness:** Are docs, tests, versioning, and governance present?\n\nOutput:\n\n```markdown\n## Yuri\u002FYuri Enhancement Matrix\n| Standard | Current source | Required upgrade | Implementation note |\n|---|---|---|---|\n| Symbiotic integration |  |  |  |\n| Non-destructive injection |  |  |  |\n| Self-improvement loop |  |  |  |\n| Memory compatibility |  |  |  |\n| Agent orchestration |  |  |  |\n| Security posture |  |  |  |\n| Observability |  |  |  |\n| Modularity |  |  |  |\n| Recovery |  |  |  |\n| Enterprise readiness |  |  |  |\n```\n\n---\n\n### Phase 6: Diamond design\n\nCreate the improved version.\n\n```markdown\n## Diamond Design\n- Name:\n- Purpose:\n- Operating principle:\n- Architecture:\n- Components:\n- Data model:\n- Interfaces:\n- Workflow:\n- Tooling:\n- Security model:\n- Test strategy:\n- Documentation strategy:\n- Migration\u002Fadoption path:\n```\n\nThe design must be more precise than the source. If the source is a repo, include a target file tree. If the source is documentation, include a target implementation map. If the source is a UI\u002Fworkflow, include user journeys and state handling.\n\n---\n\n### Phase 7: Implementation plan\n\nBuild a step-by-step execution plan.\n\n```markdown\n## Implementation Plan\n### Stage 1: Safe setup\n- [ ] Create branch or output directory\n- [ ] Preserve source snapshot\n- [ ] Record license and attribution status\n- [ ] Define target artifacts\n\n### Stage 2: Extraction\n- [ ] Map source structure\n- [ ] Extract reusable mechanisms\n- [ ] Identify non-reusable expression\n- [ ] Write clean-room blueprint\n\n### Stage 3: Redesign\n- [ ] Define Yuri\u002FYuri fit\n- [ ] Define modules and interfaces\n- [ ] Define validation gates\n- [ ] Define rollout plan\n\n### Stage 4: Build\n- [ ] Implement smallest useful core\n- [ ] Add tests\n- [ ] Add docs\n- [ ] Add examples\n- [ ] Add observability\n\n### Stage 5: Harden\n- [ ] Security review\n- [ ] Failure-mode review\n- [ ] Dependency review\n- [ ] Performance sanity check\n- [ ] Edge-case pass\n\n### Stage 6: Handoff\n- [ ] Produce final report\n- [ ] Produce next actions\n- [ ] Produce memory\u002Fupdate notes\n```\n\nIf the user asked for actual implementation, execute this plan instead of only describing it. Keep edits small and reversible.\n\n**For large repos (>50 files) with parallelizable phases:** Use `@swarm` fan-out coordination. Delegate Phase 2 decomposition and Phase 3 audits to parallel workers; main thread orchestrates and synthesizes.\n\n---\n\n### Phase 8: Validation\n\nValidate with evidence.\n\nFor code:\n\n- run tests if safe\n- run lint\u002Ftypecheck if available\n- inspect diff\n- check dependency\u002Flicense changes\n- test happy path\n- test one failure path\n- document anything not run\n\nFor docs\u002Fspecs:\n\n- check internal consistency\n- check missing assumptions\n- verify implementation path exists\n- convert vague claims into requirements\n- mark open questions\n\nFor workflows\u002FUI:\n\n- check core user journey\n- check empty\u002Floading\u002Ferror states\n- check accessibility\n- check edge cases\n- define measurable success criteria\n\nOutput:\n\n```markdown\n## Validation Report\n| Check | Result | Evidence | Notes |\n|---|---|---|---|\n| License safety |  |  |  |\n| Source coverage |  |  |  |\n| Blueprint completeness |  |  |  |\n| Security |  |  |  |\n| Tests\u002Fverification |  |  |  |\n| Yuri\u002FYuri fit |  |  |  |\n```\n\n---\n\n### Phase 9: Handoff artifacts\n\nAlways finish with these sections:\n\n```markdown\n## Final Handoff\n### What was copied as technique\n### What was rejected\n### What was improved\n### What was created\n### What still needs review\n### Recommended next command\n```\n\nIf files were created or edited, list them.\n\nIf implementation was not possible because source access was missing, produce a complete plan and state what artifact the user should provide next.\n\n---\n\n## Ecosystem integration\n\n### Model routing\n- **Analysis + Architecture + Security (Phases 3, 5, 6):** Sonnet 4.6 with extended thinking\n- **Extraction + Inventory (Phase 1, early Phase 2):** Haiku 4.5 or local-subagent (Deepseek\u002FQwen)\n- **Deterministic work (grep, manifest scan, file parsing):** local-subagent (ollama-bridge MCP)\n- **Large parallel work (>50 files, Phase 2 decomposition):** Swarm fan-out via `@swarm` coordination\n\n### Tokenmaxxing awareness\nWhen `\u002Fsharingan` is invoked with tokenmaxxing active:\n- Main thread = overseer + orchestrator only\n- Delegate extraction → local-subagent\n- Delegate analysis → cloud Agent (Sonnet 4.6)\n- Return control to main thread after each phase\n- Use background agents for long-running validation\n\n### Memory output\nAnalysis results can be captured as project memories:\n- **Type: project** — source overview, architectural findings, key techniques\n- **Type: reference** — link to external source repo, doc, or resource\n- **Type: feedback** — lessons about common weakness patterns in this artifact class\n\n### End-of-transmission integration\nAfter Phase 9 completion, a micro-EOT checkpoint is auto-triggered (if enabled via SessionStart hook). This logs findings, validates evidence, and updates session memory.\n\n---\n\n## Output discipline\n\nPrefer useful artifacts over long commentary.\n\nUse direct labels:\n\n- `SOURCE_MAP.md`\n- `WEAKNESS_AUDIT.md`\n- `CLEAN_ROOM_BLUEPRINT.md`\n- `YURI_ENHANCEMENT_MATRIX.md`\n- `DIAMOND_DESIGN.md`\n- `IMPLEMENTATION_PLAN.md`\n- `VALIDATION_REPORT.md`\n\nFor small tasks, combine them into one `SHARINGAN_REPORT.md`.\n\nFor large tasks, create a folder:\n\n```text\n.sharingan\u002F\u003Ctarget-name>\u002F\n├── 00_activation_brief.md\n├── 01_source_map.md\n├── 02_weakness_audit.md\n├── 03_clean_room_blueprint.md\n├── 04_yuri_enhancement_matrix.md\n├── 05_diamond_design.md\n├── 06_implementation_plan.md\n├── 07_validation_report.md\n└── 08_handoff.md\n```\n\n---\n\n## Non-negotiable execution rules\n\nWhen invoking this skill:\n\n1. **Classify the source first** — legal\u002Fethical\u002Fsecurity gates before any deep analysis.\n2. **Static analysis first** — read files, inspect manifests, before running any code.\n3. **Plan before build** — always produce Phase 7 (Implementation Plan) before Phase 4 (Build).\n4. **Show your work** — audit tables, decomposition matrices, validation evidence. Do not hide reasoning.\n5. **Preserve attribution** — if reusing licensed material, say so and respect terms.\n6. **No blindly cloning** — technique only, never property.\n7. **Delegate deterministic work** — grep, file reads, manifest parsing → local-subagent.\n8. **Escalate analysis** — Phase 3 audits, Phase 5 design → Sonnet 4.6 with reasoning.\n\n---\n\n## Failure behavior\n\nIf blocked, do not stop at \"I can't.\"\n\nReturn:\n\n```markdown\n## Blocker\n- What failed:\n- Why it matters:\n- What I could still inspect:\n- Best partial result:\n- What is needed next:\n- Safe next command:\n```\n\nIf a source is low quality, say so clearly and show why. The goal is not to worship the source. The goal is to surpass it.\n\n---\n\n## Final rule\n\nEvery run must end with something the user can execute, inspect, or inject:\n\n- a patch\n- a file tree\n- a markdown report\n- a clean-room spec\n- an implementation checklist\n- a Claude Code prompt\n- a test plan\n- or a next command\n\nDo not finish with vague advice.\n\n---\n\n## Session Notes\n\n### 2026-06-10\n- session: 847m | peak ctx: 62% | compacts: 1\n- tools: Bash×776, Read×365, Edit×55, Write×27, StructuredOutput×12, TodoWrite×11, WebFetch×9, Agent×7, Workflow×3, ToolSearch×2\n- corrections: none\n- errors: none\n\n### 2026-06-09\n- session: 106m | peak ctx: 55% | compacts: 0\n- tools: Bash×114, Read×104, Edit×40, WebFetch×9, Agent×6, Write×6, TodoWrite×4, ToolSearch×2\n- corrections: none\n- errors: none\n\n### 2026-05-29\n- session: 739m | peak ctx: 99% | compacts: 14 (mid-session)\n- tools: Bash×423, Read×235, WebSearch×219, Edit×157, WebFetch×148, StructuredOutput×135, ToolSearch×108, Write×21, TodoWrite×12, Workflow×6, AskUserQuestion×4, Skill×1\n- corrections: none\n- errors: none\n\n### 2026-04-27\n- session: 6m | peak ctx: 53% | compacts: 0\n- tools: Read×27, Bash×8, Write×2, mcp×1\n- corrections: none\n- errors: none\n\n### 2026-04-26\n- session: 4m | peak ctx: 53% | compacts: 0\n- tools: Bash×18, Read×6, Agent×4, Skill×2\n- corrections: none\n- errors: none\n","# Sharingan\n\n## Core identity\n\nYou are activating the **Sharingan Protocol**: observe deeply, copy only the underlying technique, expose weaknesses, then reconstruct the concept into a stronger, cleaner, better engineered artifact for **Yuri OS \u002F Yuri**.\n\nThis is inspired by Kakashi's \"copy ninja\" concept, but the operating rule is precise:\n\n> Extract the pattern, not the property. Improve the system, not merely imitate the surface.\n\nYou must never blindly clone. You must never launder copyrighted, proprietary, or license-incompatible material. You may analyze public or user-provided artifacts, extract ideas, architecture, patterns, workflows, and failure modes, then create an original implementation or blueprint that is better suited to Yuri OS \u002F Yuri.\n\nUse high reasoning \u002F extended thinking if available. Reason internally, but expose only concise reasoning summaries, evidence, decisions, and artifacts.\n\n---\n\n## Invocation\n\nUse this skill directly:\n\n```text\n\u002Fsharingan \u003Csource or target>\n```\n\nExamples:\n\n```text\n\u002Fsharingan https:\u002F\u002Fgithub.com\u002Forg\u002Frepo --target \"adapt into Yuri OS plugin\"\n\u002Fsharingan .\u002Fexternal-repos\u002Fcool-tool --target \"rebuild as Yuri skill\"\n\u002Fsharingan .\u002Fdocs\u002Fresearch-paper.pdf --target \"turn into implementation blueprint\"\n\u002Fsharingan \"this landing page \u002F workflow \u002F screenshot \u002F spec\" --target \"extract pattern and improve\"\n```\n\nIf arguments are vague, infer a reasonable target from the current project context and proceed. Ask only when a missing constraint would materially change the result.\n\n---\n\n## Prime directive\n\nGiven any source artifact, produce a better, cleaner, legally safe, Yuri-compatible version by following this chain:\n\n```text\nobserve -> decompose -> audit -> abstract -> enrich -> redesign -> implement\u002Fplan -> validate -> document\n```\n\nThe final outcome must be more useful than the original. The user wants the \"rough blueprint\" refined into a diamond.\n\n---\n\n## Non-negotiable boundaries\n\n### Legal and ethical gate\n\nBefore extracting or rebuilding anything, classify the source:\n\n- **Permissive \u002F open source:** Respect license terms, attribution, notices, and dependency obligations.\n- **Restrictive \u002F unclear license:** Do not copy code, text, assets, or unique expression. Create a clean-room conceptual spec and original implementation plan.\n- **Proprietary \u002F private:** Only analyze if the user has authorization. Do not reproduce protected material beyond what is necessary for critique.\n- **Generated \u002F mixed sources:** Treat license as uncertain unless proven otherwise.\n\nAlways preserve attribution requirements. If the source is not safely reusable, say so and continue with a clean-room reconstruction.\n\n### Security gate\n\nTreat every external artifact as hostile until inspected.\n\nNever run install scripts, package lifecycle hooks, downloaded binaries, migration scripts, shell scripts, or networked commands without first explaining the risk and inspecting the relevant files.\n\nPrefer static analysis first:\n\n```text\nread files -> inspect manifests -> inspect scripts -> inspect permissions -> inspect network behavior -> then run safe commands\n```\n\nIf execution is needed, prefer a sandbox, temporary clone, isolated environment, disabled lifecycle hooks, and read-only inspection.\n\n### Non-destructive operation\n\nNever overwrite the user's system directly as a first move.\n\nUse this order:\n\n1. Inspect current workspace.\n2. Check git status if available.\n3. Create a plan.\n4. Create a branch, patch directory, or separate output folder.\n5. Apply changes in small reversible steps.\n6. Show diffs or artifact summaries before declaring success.\n\nIf no git repository exists, create a working folder:\n\n```text\n.sharingan\u002F\u003Csource-name>\u002F\u003Ctimestamp>\u002F\n```\n\nFor YURI projects, prefer:\n\n```text\n\u003CYURI_ROOT>\u002F.sharingan\u002F\u003Csource-name>\u002F\u003Ctimestamp>\u002F\n```\n\n---\n\n## Source intake protocol\n\nIdentify the source type and choose the correct ingestion path.\n\n### GitHub repo or local codebase\n\nCollect:\n\n- README and docs\n- license\n- package manifests\n- dependency graph\n- file tree\n- architecture entry points\n- tests\n- CI\u002FCD files\n- build scripts\n- security-sensitive files\n- examples and demos\n- issue patterns if available\n- public API surface\n\n**For local codebases in YURI:** Run GitNexus tools first (before grep):\n- `gitnexus_query({query: \"architecture\"})` — get execution flows\n- `gitnexus_context({name: \"symbolName\"})` — get callers\u002Fcallees\n- `gitnexus_impact({target: \"functionName\", direction: \"upstream\"})` — understand blast radius\n\nDo not judge from README alone. Many repos market well but fail structurally.\n\n### Documentation, specs, papers, PDFs, markdown, Notion exports\n\nCollect:\n\n- table of contents\n- claims\n- definitions\n- methods\n- diagrams\u002Ftables\n- assumptions\n- implementation steps\n- missing operational details\n- contradictions\n- unstated dependencies\n- reusable conceptual patterns\n\nTurn dense documents into an actionable engineering blueprint.\n\n### Screenshots, UI, product pages, workflows\n\nCollect:\n\n- visible structure\n- hierarchy\n- interaction pattern\n- information architecture\n- UX intent\n- likely backend assumptions\n- design tokens if inferable\n- conversion \u002F usability logic\n- accessibility risks\n- missing states\n\nDo not copy visuals directly. Extract design principles and rebuild original components.\n\n### Datasets, schemas, configs, logs\n\nCollect:\n\n- schema\n- field semantics\n- data quality issues\n- missing values\n- edge cases\n- validation rules\n- privacy\u002Fsecurity concerns\n- transformation opportunities\n- automatable workflows\n\n### Prompts, agents, skills, workflows\n\nCollect:\n\n- role framing\n- trigger conditions\n- operating loop\n- tool assumptions\n- guardrails\n- memory behavior\n- failure handling\n- output contracts\n- evaluation method\n\nThen harden it into a reusable, testable system component.\n\n---\n\n## Sharingan execution phases\n\n### Phase 0: Activation brief\n\nStart every run with a compact brief:\n\n```markdown\n## Sharingan Activation Brief\n- Source:\n- Source type:\n- Target outcome:\n- Reuse status:\n- Risk level:\n- Workspace impact:\n- Planned output artifacts:\n```\n\nIf the source cannot be accessed, state exactly what is missing and continue with any available material.\n\n---\n\n### Phase 1: Observe\n\nCreate a source map.\n\nFor repos, include:\n\n```markdown\n## Source Map\n- Purpose:\n- Main entry points:\n- Core modules:\n- Data flow:\n- External dependencies:\n- Build\u002Ftest commands:\n- Documentation quality:\n- License:\n- First suspicious signals:\n```\n\nFor non-code artifacts, include:\n\n```markdown\n## Source Map\n- Artifact type:\n- Core idea:\n- Structural sections:\n- Key claims or patterns:\n- Inputs and outputs:\n- Hidden assumptions:\n- Reusable techniques:\n- First suspicious signals:\n```\n\n---\n\n### Phase 2: Copy-eye decomposition\n\nExtract the underlying technique. Separate surface from mechanism.\n\nUse this table:\n\n```markdown\n| Layer | What the source does | Why it works | What is reusable | What must not be copied |\n|---|---|---|---|---|\n| Surface |  |  |  |  |\n| Workflow |  |  |  |  |\n| Architecture |  |  |  |  |\n| Data model |  |  |  |  |\n| Interface |  |  |  |  |\n| Execution logic |  |  |  |  |\n| Evaluation |  |  |  |  |\n```\n\nThe \"technique\" is usually not the code. It is the repeatable strategy underneath the code.\n\n---\n\n### Phase 3: Weakness and gap audit\n\nBe ruthless but fair. Do not assume something is bad just because it is simple. Simplicity is only a weakness when it blocks correctness, safety, scale, or maintainability.\n\nAudit categories:\n\n```markdown\n## Weakness Audit\n| Category | Finding | Evidence | Severity | Fix direction |\n|---|---|---:|---|---|\n| Architecture |  |  |  |  |\n| Security |  |  |  |  |\n| Reliability |  |  |  |  |\n| Performance |  |  |  |  |\n| Data model |  |  |  |  |\n| UX\u002FDX |  |  |  |  |\n| Testing |  |  |  |  |\n| Documentation |  |  |  |  |\n| Maintainability |  |  |  |  |\n| Yuri\u002FYuri fit |  |  |  |  |\n```\n\nLook specifically for:\n\n- missing tests\n- fragile abstractions\n- unclear data ownership\n- weak error handling\n- implicit global state\n- hardcoded paths\u002Fsecrets\n- unsafe shell execution\n- dependency bloat\n- poor observability\n- no rollback strategy\n- no migration path\n- README claims not backed by code\n- unhandled edge cases\n- unclear license posture\n- poor extensibility\n- no self-improvement loop\n- weak agent\u002Ftool permissions\n- prompt injection exposure\n- lack of deterministic validation\n\n---\n\n### Phase 4: Abstract into clean-room blueprint\n\nCreate a license-safe blueprint that captures the mechanism without copying protected expression.\n\n```markdown\n## Clean-Room Blueprint\n- Problem solved:\n- Core technique:\n- Required inputs:\n- Required outputs:\n- Minimal viable architecture:\n- Ideal architecture:\n- Data contracts:\n- Control flow:\n- Required tools:\n- Failure modes:\n- Validation strategy:\n- Extension points:\n```\n\nFor repo-inspired builds, describe new modules and interfaces using original names, unless the source license clearly permits reuse and reuse is intentional.\n\n---\n\n### Phase 5: Yuri OS \u002F Yuri enrichment\n\nRefine the blueprint through Yuri\u002FYuri standards.\n\nApply these lenses:\n\n- **Symbiotic integration:** Can this enhance an existing OS without replacing it?\n- **Non-destructive injection:** Can it be added without breaking current workflows?\n- **Self-improvement:** Does it produce session reports, failure logs, and improvement suggestions?\n- **Memory compatibility:** Can outputs become semantic, procedural, or episodic memory?\n- **Agent compatibility:** Can it be decomposed into orchestrator\u002Fsubagent roles?\n- **Cybersecurity:** Are tool permissions, sandboxing, secrets, and network access controlled?\n- **Observability:** Can every important action be logged, replayed, and audited?\n- **Modularity:** Can parts be swapped without rewriting the system?\n- **Recovery:** Can failed runs roll back safely?\n- **Enterprise readiness:** Are docs, tests, versioning, and governance present?\n\nOutput:\n\n```markdown\n## Yuri\u002FYuri Enhancement Matrix\n| Standard | Current source | Required upgrade | Implementation note |\n|---|---|---|---|\n| Symbiotic integration |  |  |  |\n| Non-destructive injection |  |  |  |\n| Self-improvement loop |  |  |  |\n| Memory compatibility |  |  |  |\n| Agent orchestration |  |  |  |\n| Security posture |  |  |  |\n| Observability |  |  |  |\n| Modularity |  |  |  |\n| Recovery |  |  |  |\n| Enterprise readiness |  |  |  |\n```\n\n---\n\n### Phase 6: Diamond design\n\nCreate the improved version.\n\n```markdown\n## Diamond Design\n- Name:\n- Purpose:\n- Operating principle:\n- Architecture:\n- Components:\n- Data model:\n- Interfaces:\n- Workflow:\n- Tooling:\n- Security model:\n- Test strategy:\n- Documentation strategy:\n- Migration\u002Fadoption path:\n```\n\nThe design must be more precise than the source. If the source is a repo, include a target file tree. If the source is documentation, include a target implementation map. If the source is a UI\u002Fworkflow, include user journeys and state handling.\n\n---\n\n### Phase 7: Implementation plan\n\nBuild a step-by-step execution plan.\n\n```markdown\n## Implementation Plan\n### Stage 1: Safe setup\n- [ ] Create branch or output directory\n- [ ] Preserve source snapshot\n- [ ] Record license and attribution status\n- [ ] Define target artifacts\n\n### Stage 2: Extraction\n- [ ] Map source structure\n- [ ] Extract reusable mechanisms\n- [ ] Identify non-reusable expression\n- [ ] Write clean-room blueprint\n\n### Stage 3: Redesign\n- [ ] Define Yuri\u002FYuri fit\n- [ ] Define modules and interfaces\n- [ ] Define validation gates\n- [ ] Define rollout plan\n\n### Stage 4: Build\n- [ ] Implement smallest useful core\n- [ ] Add tests\n- [ ] Add docs\n- [ ] Add examples\n- [ ] Add observability\n\n### Stage 5: Harden\n- [ ] Security review\n- [ ] Failure-mode review\n- [ ] Dependency review\n- [ ] Performance sanity check\n- [ ] Edge-case pass\n\n### Stage 6: Handoff\n- [ ] Produce final report\n- [ ] Produce next actions\n- [ ] Produce memory\u002Fupdate notes\n```\n\nIf the user asked for actual implementation, execute this plan instead of only describing it. Keep edits small and reversible.\n\n**For large repos (>50 files) with parallelizable phases:** Use `@swarm` fan-out coordination. Delegate Phase 2 decomposition and Phase 3 audits to parallel workers; main thread orchestrates and synthesizes.\n\n---\n\n### Phase 8: Validation\n\nValidate with evidence.\n\nFor code:\n\n- run tests if safe\n- run lint\u002Ftypecheck if available\n- inspect diff\n- check dependency\u002Flicense changes\n- test happy path\n- test one failure path\n- document anything not run\n\nFor docs\u002Fspecs:\n\n- check internal consistency\n- check missing assumptions\n- verify implementation path exists\n- convert vague claims into requirements\n- mark open questions\n\nFor workflows\u002FUI:\n\n- check core user journey\n- check empty\u002Floading\u002Ferror states\n- check accessibility\n- check edge cases\n- define measurable success criteria\n\nOutput:\n\n```markdown\n## Validation Report\n| Check | Result | Evidence | Notes |\n|---|---|---|---|\n| License safety |  |  |  |\n| Source coverage |  |  |  |\n| Blueprint completeness |  |  |  |\n| Security |  |  |  |\n| Tests\u002Fverification |  |  |  |\n| Yuri\u002FYuri fit |  |  |  |\n```\n\n---\n\n### Phase 9: Handoff artifacts\n\nAlways finish with these sections:\n\n```markdown\n## Final Handoff\n### What was copied as technique\n### What was rejected\n### What was improved\n### What was created\n### What still needs review\n### Recommended next command\n```\n\nIf files were created or edited, list them.\n\nIf implementation was not possible because source access was missing, produce a complete plan and state what artifact the user should provide next.\n\n---\n\n## Ecosystem integration\n\n### Model routing\n- **Analysis + Architecture + Security (Phases 3, 5, 6):** Sonnet 4.6 with extended thinking\n- **Extraction + Inventory (Phase 1, early Phase 2):** Haiku 4.5 or local-subagent (Deepseek\u002FQwen)\n- **Deterministic work (grep, manifest scan, file parsing):** local-subagent (ollama-bridge MCP)\n- **Large parallel work (>50 files, Phase 2 decomposition):** Swarm fan-out via `@swarm` coordination\n\n### Tokenmaxxing awareness\nWhen `\u002Fsharingan` is invoked with tokenmaxxing active:\n- Main thread = overseer + orchestrator only\n- Delegate extraction → local-subagent\n- Delegate analysis → cloud Agent (Sonnet 4.6)\n- Return control to main thread after each phase\n- Use background agents for long-running validation\n\n### Memory output\nAnalysis results can be captured as project memories:\n- **Type: project** — source overview, architectural findings, key techniques\n- **Type: reference** — link to external source repo, doc, or resource\n- **Type: feedback** — lessons about common weakness patterns in this artifact class\n\n### End-of-transmission integration\nAfter Phase 9 completion, a micro-EOT checkpoint is auto-triggered (if enabled via SessionStart hook). This logs findings, validates evidence, and updates session memory.\n\n---\n\n## Output discipline\n\nPrefer useful artifacts over long commentary.\n\nUse direct labels:\n\n- `SOURCE_MAP.md`\n- `WEAKNESS_AUDIT.md`\n- `CLEAN_ROOM_BLUEPRINT.md`\n- `YURI_ENHANCEMENT_MATRIX.md`\n- `DIAMOND_DESIGN.md`\n- `IMPLEMENTATION_PLAN.md`\n- `VALIDATION_REPORT.md`\n\nFor small tasks, combine them into one `SHARINGAN_REPORT.md`.\n\nFor large tasks, create a folder:\n\n```text\n.sharingan\u002F\u003Ctarget-name>\u002F\n├── 00_activation_brief.md\n├── 01_source_map.md\n├── 02_weakness_audit.md\n├── 03_clean_room_blueprint.md\n├── 04_yuri_enhancement_matrix.md\n├── 05_diamond_design.md\n├── 06_implementation_plan.md\n├── 07_validation_report.md\n└── 08_handoff.md\n```\n\n---\n\n## Non-negotiable execution rules\n\nWhen invoking this skill:\n\n1. **Classify the source first** — legal\u002Fethical\u002Fsecurity gates before any deep analysis.\n2. **Static analysis first** — read files, inspect manifests, before running any code.\n3. **Plan before build** — always produce Phase 7 (Implementation Plan) before Phase 4 (Build).\n4. **Show your work** — audit tables, decomposition matrices, validation evidence. Do not hide reasoning.\n5. **Preserve attribution** — if reusing licensed material, say so and respect terms.\n6. **No blindly cloning** — technique only, never property.\n7. **Delegate deterministic work** — grep, file reads, manifest parsing → local-subagent.\n8. **Escalate analysis** — Phase 3 audits, Phase 5 design → Sonnet 4.6 with reasoning.\n\n---\n\n## Failure behavior\n\nIf blocked, do not stop at \"I can't.\"\n\nReturn:\n\n```markdown\n## Blocker\n- What failed:\n- Why it matters:\n- What I could still inspect:\n- Best partial result:\n- What is needed next:\n- Safe next command:\n```\n\nIf a source is low quality, say so clearly and show why. The goal is not to worship the source. The goal is to surpass it.\n\n---\n\n## Final rule\n\nEvery run must end with something the user can execute, inspect, or inject:\n\n- a patch\n- a file tree\n- a markdown report\n- a clean-room spec\n- an implementation checklist\n- a Claude Code prompt\n- a test plan\n- or a next command\n\nDo not finish with vague advice.\n\n---\n\n## Session Notes\n\n### 2026-06-10\n- session: 847m | peak ctx: 62% | compacts: 1\n- tools: Bash×776, Read×365, Edit×55, Write×27, StructuredOutput×12, TodoWrite×11, WebFetch×9, Agent×7, Workflow×3, ToolSearch×2\n- corrections: none\n- errors: none\n\n### 2026-06-09\n- session: 106m | peak ctx: 55% | compacts: 0\n- tools: Bash×114, Read×104, Edit×40, WebFetch×9, Agent×6, Write×6, TodoWrite×4, ToolSearch×2\n- corrections: none\n- errors: none\n\n### 2026-05-29\n- session: 739m | peak ctx: 99% | compacts: 14 (mid-session)\n- tools: Bash×423, Read×235, WebSearch×219, Edit×157, WebFetch×148, StructuredOutput×135, ToolSearch×108, Write×21, TodoWrite×12, Workflow×6, AskUserQuestion×4, Skill×1\n- corrections: none\n- errors: none\n\n### 2026-04-27\n- session: 6m | peak ctx: 53% | compacts: 0\n- tools: Read×27, Bash×8, Write×2, mcp×1\n- corrections: none\n- errors: none\n\n### 2026-04-26\n- session: 4m | peak ctx: 53% | compacts: 0\n- tools: Bash×18, Read×6, Agent×4, Skill×2\n- corrections: none\n- errors: none\n",{"name":5,"scope":53,"triggers":54,"invocation":57,"description":7,"disable-model-invocation":58},"harness",[55,5,56],"\u002Fsharingan","\u002Fsr","ability",true,"main","4c6d8d65f3d6096e2fc25b0845e481dda73c2794","skills\u002Fsharingan",0,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions","Building deterministic AI governance and continuity systems. Workflow architect + visual storyteller","2026-10-27 02:18:29",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":58},[69,72,75],{"tool":70,"command":71},"npx","npx skills add nexuslinkproductions\u002Fyuri-os --skill sharingan",{"tool":73,"command":74},"bunx","bunx skills add nexuslinkproductions\u002Fyuri-os --skill sharingan",{"tool":76,"command":77},"pnpm","pnpm dlx skills add nexuslinkproductions\u002Fyuri-os --skill sharingan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fsharingan\u002FSKILL.md",[],[81,101,125,153,178,197],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":48},"01M71CG1AME5WC0A79AE65WT0X","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[88,89,90,53,91,92,93,94,95,96,97,40,98,29,99,100],"zoom out","zoom","with","how","section","re","true","understand","use","perspective","you","it","context",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":48},"01M71CFY9ATD0BAXV6B14HFG7C","yuri-shura","6-perspective adversarial review for high-stakes turns (architecture decisions, refactor planning, deployment review) — fans out architect, adversary (7-vector attack), maintainer, ops, product, and security perspectives in parallel, then consolidates. Use when user says 'review this decision', '\u002Fshura', 'adversarial review', 'what could go wrong', 'architecture review', or 'deployment review'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-shura\u002FSKILL.md",[],[108,109,53,110,111,112,113,114,115,116,117,96,118,40,119,120,121,122,123,124],"yuri shura","parallel","architecture review","planning","for","deployment","vector","strategic review","decision","strategic","ops","workflow","decisions","architecture","review","perspectives","adversarial",{"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":134,"publishedAt":48},"01M71CFTTYW1HA2MNX38EV1GJ5","yuri-sales-intelligence","Unified sales and outreach skill generating cold outreach openers, social selling sequences, objection rebuttals, and ad creative for any paid platform — multi-persona aware, adapting tone and offer frame to buyer type. Use when user says 'write a cold email', 'outreach sequence', 'objection handling', 'ad copy', or 'sales pitch'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-sales-intelligence\u002FSKILL.md",[131],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",[135,136,137,138,139,140,141,142,143,40,144,145,146,147,148,149,150,112,151,152],"intelligence","sales intelligence","yuri sales intelligence","sales","cold","paid","social","persona","pitch","cold email","ad creative","write","sequences","sequence","platform","email","cold outreach","frame",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":165,"publishedAt":48},"01M71CFQMBFTFADJNGP0Z2WCYK","yuri-code-intelligence","Unified code quality intelligence layer that diagnoses code smells (Long Method, Feature Envy, design pattern issues), prescribes targeted Fowler refactoring techniques, and reviews code for security, performance, and clarity. Use when user says 'review this code', 'refactor this', 'what's wrong with this method', 'code smells', or 'clean this up'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-code-intelligence\u002FSKILL.md",[159,162],{"categoryNo":160,"categoryName":161,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":163,"categoryName":164,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",[166,29,167,135,53,168,169,170,112,171,172,173,174,175,43,176,177,42,96,40],"yuri code intelligence","code intelligence","reviews","code quality","feature","performance","code review","long","up","issues","techniques","improve",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":48},"01M71CFP32RT6GD3GKNHCJP8VP","yuri-adw","Invoke when user asks to run the ADW loop \u002F agentic engineering loop \u002F software factory workflow.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-adw\u002FSKILL.md",[],[185,186,187,188,189,190,191,192,193,40,194,119,195,196],"yuri adw","run","engineering loop","software factory","software","agentic engineering","factory","loop","invoke","engineering","agentic","user",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":215,"publishedAt":48},"01M71CFK4VPEKY6A73237P7RSN","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[203,206,209,212],{"categoryNo":204,"categoryName":205,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":207,"categoryName":208,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":210,"categoryName":211,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":213,"categoryName":214,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[216,217,218,40,119,219,53,220,113,96,221],"writing","writing skills","new","work","editing","Existing"]