[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H0876SFMVVJJV7CTSTACWV":3,"skill-same:01M6H0876SFMVVJJV7CTSTACWV":85},{"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":31,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":14,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":70,"install":71,"resources":84},"01M6H0876SFMVVJJV7CTSTACWV","autoresearch",null,"Autonomous iterative experimentation loop for any programming task. Guides the user through defining goals, measurable metrics, and scope constraints, then runs an autonomous loop of code changes, testing, measuring, and keeping\u002Fdiscarding results. Inspired by Karpathy's autoresearch. USE FOR: autonomous improvement, iterative optimization, experiment loop, auto research, performance tuning, automated experimentation, hill climbing, try things automatically, optimize code, run experiments, autonomous coding loop. DO NOT USE FOR: one-shot tasks, simple bug fixes, code review, or tasks without a measurable metric.","ibragimov-oasis\u002Fname-navigator","ibragimov-oasis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F240665573?v=4","01M6DF78Y45R8228FHAZ7G6JXM","IBRAGIMOV MUKHAMMADJON","01M6DF792RGGYNSN2BMSED45SJ",0,"MIT","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fautoresearch\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"loop","guides","scope","project","artifact","optimize","auto","karpathy","autonomous","access","code review","code","run","tasks","copilot","performance","terminal","review","testing","2026-11-10 10:12:30",false,"---\nname: autoresearch\ndescription: 'Autonomous iterative experimentation loop for any programming task. Guides the user through defining goals, measurable metrics, and scope constraints, then runs an autonomous loop of code changes, testing, measuring, and keeping\u002Fdiscarding results. Inspired by Karpathy''s autoresearch. USE FOR: autonomous improvement, iterative optimization, experiment loop, auto research, performance tuning, automated experimentation, hill climbing, try things automatically, optimize code, run experiments, autonomous coding loop. DO NOT USE FOR: one-shot tasks, simple bug fixes, code review, or tasks without a measurable metric.'\nlicense: MIT\ncompatibility: Requires git. The project must be a git repository. Requires terminal access to run commands.\nmetadata:\n  author: luiscantero\n  inspired-by: https:\u002F\u002Fgithub.com\u002Fkarpathy\u002Fautoresearch\ntags:\n  - domain\u002Fagents\n  - artifact\u002Fskill\n  - source\u002Fskills-copilot\n---\n\n# Autoresearch: Autonomous Iterative Experimentation\n\nAn autonomous experimentation loop for any programming task. You define the goal and how to measure it; the agent iterates autonomously -- modifying code, running experiments, measuring results, and keeping or discarding changes -- until interrupted.\n\nThis skill is inspired by [Karpathy's autoresearch](https:\u002F\u002Fgithub.com\u002Fkarpathy\u002Fautoresearch), generalized from ML training to **any programming task with a measurable outcome**.\n\n---\n\n## Agent Behavior Rules\n\n1. **DO** guide the user through the Setup phase interactively before starting the loop.\n2. **DO** establish a baseline measurement before making any changes.\n3. **DO** commit every experiment attempt before running it (so it can be reverted cleanly).\n4. **DO** keep a results log (TSV) tracking every experiment.\n5. **DO** revert changes that do not improve the metric (git reset to last known good).\n6. **DO** run autonomously once the loop starts -- never pause to ask \"should I continue?\".\n7. **DO NOT** modify files the user marked as out-of-scope.\n8. **DO NOT** skip the measurement step -- every experiment must be measured.\n9. **DO NOT** keep changes that regress the metric unless the user explicitly allowed trade-offs.\n10. **DO NOT** install new dependencies or make environment changes unless the user approved it.\n\n---\n\n## Phase 1: Setup (Interactive)\n\nBefore any experimentation begins, work with the user to establish these parameters.\nAsk the user directly for each item. Do not assume or skip any.\n\n### 1.1 Define the Goal\n\nAsk the user:\n\n> **What are you trying to improve or optimize?**\n>\n> Examples: execution time, memory usage, binary size, test pass rate, code coverage,\n> API response latency, throughput, error rate, benchmark score, build time, bundle size,\n> lines of code, cyclomatic complexity, etc.\n\nRecord the user's answer as the **goal**.\n\n### 1.2 Define the Metric\n\nAsk the user:\n\n> **How do we measure success? What exact command produces the metric?**\n>\n> I need:\n> 1. **The command** to run (e.g., `dotnet test`, `npm run benchmark`, `time .\u002Fbuild.sh`, `pytest --tb=short`)\n> 2. **How to extract the metric** from the output (e.g., a regex pattern, a specific line, a JSON field)\n> 3. **Direction**: Is lower better or higher better?\n>\n> Example: \"Run `dotnet test --logger trx`, count passing tests. Higher is better.\"\n> Example: \"Run `hyperfine '.\u002Fmy-program'`, extract mean time. Lower is better.\"\n\nRecord:\n- `METRIC_COMMAND`: the command to run\n- `METRIC_EXTRACTION`: how to extract the numeric metric from output\n- `METRIC_DIRECTION`: `lower_is_better` or `higher_is_better`\n\n### 1.3 Define the Scope\n\nAsk the user:\n\n> **Which files or directories am I allowed to modify?**\n>\n> And which files are OFF LIMITS (read-only)?\n\nRecord:\n- `IN_SCOPE_FILES`: files\u002Fdirs the agent may edit\n- `OUT_OF_SCOPE_FILES`: files\u002Fdirs that must not be modified\n\n### 1.4 Define Constraints\n\nAsk the user:\n\n> **Are there any constraints I should respect?**\n>\n> Examples:\n> - Time budget per experiment (e.g., \"each run should take \u003C 2 minutes\")\n> - No new dependencies\n> - Must keep all existing tests passing\n> - Must not change the public API\n> - Must maintain backward compatibility\n> - VRAM\u002Fmemory limit\n> - Code complexity limits (prefer simpler solutions)\n\nRecord as `CONSTRAINTS`.\n\n### 1.5 Define the Experiment Budget (Optional)\n\nAsk the user:\n\n> **How many experiments should I run, or should I just keep going until you stop me?**\n>\n> You can say a number (e.g., \"try 20 experiments\") or \"unlimited\" (I'll run until you interrupt).\n\nRecord as `MAX_EXPERIMENTS` (number or `unlimited`).\n\n### 1.6 Simplicity Criterion\n\nInform the user of the default simplicity policy:\n\n> **Simplicity policy (default):** All else being equal, simpler is better. A small improvement\n> that adds ugly complexity is not worth it. Removing code while maintaining or improving\n> the metric is a great outcome. I'll weigh the complexity cost against the improvement\n> magnitude. Does this policy work for you, or do you want to adjust it?\n\nRecord any adjustments as `SIMPLICITY_POLICY`.\n\n### 1.7 Confirm Setup\n\nSummarize all parameters back to the user in a clear table:\n\n| Parameter          | Value                        |\n| ------------------ | ---------------------------- |\n| Goal               | ...                          |\n| Metric command     | ...                          |\n| Metric extraction  | ...                          |\n| Direction          | lower is better \u002F higher ... |\n| In-scope files     | ...                          |\n| Out-of-scope files | ...                          |\n| Constraints        | ...                          |\n| Max experiments    | ...                          |\n| Simplicity policy  | ...                          |\n\nAsk the user to confirm. Do not proceed until confirmed.\n\n---\n\n## Phase 2: Branch & Baseline\n\nOnce the user confirms:\n\n1. **Create a branch**: Propose a tag based on today's date (e.g., `autoresearch\u002Fmar17`).\n   Create the branch: `git checkout -b autoresearch\u002F\u003Ctag>`.\n\n2. **Read in-scope files**: Read all files that are in scope to build full context of the current state.\n\n3. **Initialize results.tsv**: Create `results.tsv` in the repo root with the header row:\n   ```\n   experiment\tcommit\tmetric\tstatus\tdescription\n   ```\n   Add `results.tsv` and `run.log` to `.git\u002Finfo\u002Fexclude` (append if not already present) so they stay untracked without modifying any tracked files.\n\n4. **Run the baseline**: Execute the metric command on the current unmodified code.\n   Record the result as experiment `0` with status `baseline` in `results.tsv`.\n\n5. **Report baseline** to the user:\n   > Baseline established: **[metric_name] = [value]**\n   > Starting autonomous experimentation loop.\n\n---\n\n## Phase 3: Experiment Loop\n\nRun this loop continuously. Do not stop to ask the user. Run until:\n- `MAX_EXPERIMENTS` is reached, OR\n- The user manually interrupts\n\n### For each experiment:\n\n```\nLOOP:\n  1. THINK   - Analyze previous results and the current code.\n               Generate an experiment hypothesis.\n               Consider: what worked, what didn't, what hasn't been tried.\n\n  2. EDIT    - Modify the in-scope file(s) to implement the idea.\n               Keep changes focused and minimal per experiment.\n\n  3. COMMIT  - git add + git commit with a short descriptive message.\n               Format: \"experiment: \u003Cshort description of what changed>\"\n\n  4. RUN     - Execute the metric command.\n               Redirect output to run.log so it does not flood the context window.\n               Use shell-appropriate redirection:\n               - Bash\u002FZsh: `\u003Ccommand> > run.log 2>&1`\n               - PowerShell: `\u003Ccommand> *> run.log`\n\n  5. MEASURE - Extract the metric from run.log.\n               If extraction fails (crash\u002Ferror), read the last 50 lines\n               of run.log for the error.\n\n  6. DECIDE  - Compare metric to the current best:\n               - IMPROVED: Keep the commit. Update the \"best\" baseline.\n                 Log status = \"keep\".\n               - SAME OR WORSE: Revert. `git reset --hard HEAD~1`.\n                 Log status = \"discard\".\n               - CRASH: Attempt a quick fix (typo, import, simple error).\n                 Amend the experiment commit (`git commit --amend`) with the fix\n                 and rerun. The experiment keeps its original number.\n                 If unfixable after 2 attempts, revert the entire experiment\n                 (`git reset --hard HEAD~1`) and log status = \"crash\".\n\n  7. LOG     - Append a row to results.tsv:\n               experiment_number  commit_hash  metric_value  status  description\n\n  8. CONTINUE - Go to step 1.\n```\n\n### Experiment Strategy\n\nWhen generating experiment ideas, follow this priority order:\n\n1. **Low-hanging fruit first**: Simple parameter tweaks, obvious inefficiencies.\n2. **Informed by results**: If a direction showed promise, explore further in that direction.\n3. **Diversify after plateaus**: If the last 3-5 experiments all failed, try a different approach entirely.\n4. **Combine winners**: If experiments A and B each improved independently, try combining them.\n5. **Simplification passes**: Periodically try removing code\u002Fcomplexity to see if the metric holds.\n6. **Radical changes**: After exhausting incremental ideas, try larger architectural changes.\n\n### Handling Constraints\n\n- **Time budget**: If a run exceeds 2x the expected duration, kill it and treat as a crash.\n- **Existing tests**: If constraints require tests to pass, run them before\u002Fafter and revert if they break.\n- **Memory\u002Fresources**: Monitor and revert if resource usage exceeds stated limits.\n\n---\n\n## Phase 4: Reporting\n\nWhen the loop ends (budget reached or user interrupts):\n\n1. **Print the full results.tsv** as a formatted table.\n2. **Summarize**:\n   - Total experiments run\n   - Experiments kept \u002F discarded \u002F crashed\n   - Starting metric (baseline) vs. final metric\n   - Improvement percentage\n   - Top 3 most impactful changes\n3. **Show the cumulative git log** of kept experiments:\n   `git log --oneline \u003Cstart_commit>..HEAD`\n4. **Recommend next steps**: Based on the results, suggest what a human researcher might try next (ideas that were too risky\u002Fcomplex for automated experimentation).\n\n---\n\n## Quick Reference\n\n### Results TSV Format\n\nTab-separated, 5 columns:\n\n```\nexperiment\tcommit\tmetric\tstatus\tdescription\n0\ta1b2c3d\t0.997900\tbaseline\tunmodified code\n1\tb2c3d4e\t0.993200\tkeep\tincrease learning rate to 0.04\n2\tc3d4e5f\t1.005000\tdiscard\tswitch to GeLU activation\n3\td4e5f6g\t0.000000\tcrash\tdouble model width (OOM)\n```\n\n### Git Workflow\n\n- All experiments happen on the `autoresearch\u002F\u003Ctag>` branch\n- Each experiment is committed before running\n- Failed experiments are reverted with `git reset --hard HEAD~1`\n- Successful experiments advance the branch\n- `results.tsv` and `run.log` stay untracked (added to `.git\u002Finfo\u002Fexclude`)\n\n### Key Principles\n\n1. **Measure everything**: No experiment without a measurement.\n2. **Revert failures**: The branch only advances on improvements.\n3. **Stay autonomous**: Never stop to ask. Think harder if stuck.\n4. **Keep it simple**: Complexity is a cost. Weigh it against gains.\n5. **Log everything**: The TSV is the research journal.\n\n## ? Связи\n\n- [[MOC - Skills]] — Skills library\n- [[skills\u002Fskills-copilot]] — Category: skills-copilot\n- [[MOC - Agents]] — Copilot agents\n\n","# Autoresearch: Autonomous Iterative Experimentation\n\nAn autonomous experimentation loop for any programming task. You define the goal and how to measure it; the agent iterates autonomously -- modifying code, running experiments, measuring results, and keeping or discarding changes -- until interrupted.\n\nThis skill is inspired by [Karpathy's autoresearch](https:\u002F\u002Fgithub.com\u002Fkarpathy\u002Fautoresearch), generalized from ML training to **any programming task with a measurable outcome**.\n\n---\n\n## Agent Behavior Rules\n\n1. **DO** guide the user through the Setup phase interactively before starting the loop.\n2. **DO** establish a baseline measurement before making any changes.\n3. **DO** commit every experiment attempt before running it (so it can be reverted cleanly).\n4. **DO** keep a results log (TSV) tracking every experiment.\n5. **DO** revert changes that do not improve the metric (git reset to last known good).\n6. **DO** run autonomously once the loop starts -- never pause to ask \"should I continue?\".\n7. **DO NOT** modify files the user marked as out-of-scope.\n8. **DO NOT** skip the measurement step -- every experiment must be measured.\n9. **DO NOT** keep changes that regress the metric unless the user explicitly allowed trade-offs.\n10. **DO NOT** install new dependencies or make environment changes unless the user approved it.\n\n---\n\n## Phase 1: Setup (Interactive)\n\nBefore any experimentation begins, work with the user to establish these parameters.\nAsk the user directly for each item. Do not assume or skip any.\n\n### 1.1 Define the Goal\n\nAsk the user:\n\n> **What are you trying to improve or optimize?**\n>\n> Examples: execution time, memory usage, binary size, test pass rate, code coverage,\n> API response latency, throughput, error rate, benchmark score, build time, bundle size,\n> lines of code, cyclomatic complexity, etc.\n\nRecord the user's answer as the **goal**.\n\n### 1.2 Define the Metric\n\nAsk the user:\n\n> **How do we measure success? What exact command produces the metric?**\n>\n> I need:\n> 1. **The command** to run (e.g., `dotnet test`, `npm run benchmark`, `time .\u002Fbuild.sh`, `pytest --tb=short`)\n> 2. **How to extract the metric** from the output (e.g., a regex pattern, a specific line, a JSON field)\n> 3. **Direction**: Is lower better or higher better?\n>\n> Example: \"Run `dotnet test --logger trx`, count passing tests. Higher is better.\"\n> Example: \"Run `hyperfine '.\u002Fmy-program'`, extract mean time. Lower is better.\"\n\nRecord:\n- `METRIC_COMMAND`: the command to run\n- `METRIC_EXTRACTION`: how to extract the numeric metric from output\n- `METRIC_DIRECTION`: `lower_is_better` or `higher_is_better`\n\n### 1.3 Define the Scope\n\nAsk the user:\n\n> **Which files or directories am I allowed to modify?**\n>\n> And which files are OFF LIMITS (read-only)?\n\nRecord:\n- `IN_SCOPE_FILES`: files\u002Fdirs the agent may edit\n- `OUT_OF_SCOPE_FILES`: files\u002Fdirs that must not be modified\n\n### 1.4 Define Constraints\n\nAsk the user:\n\n> **Are there any constraints I should respect?**\n>\n> Examples:\n> - Time budget per experiment (e.g., \"each run should take \u003C 2 minutes\")\n> - No new dependencies\n> - Must keep all existing tests passing\n> - Must not change the public API\n> - Must maintain backward compatibility\n> - VRAM\u002Fmemory limit\n> - Code complexity limits (prefer simpler solutions)\n\nRecord as `CONSTRAINTS`.\n\n### 1.5 Define the Experiment Budget (Optional)\n\nAsk the user:\n\n> **How many experiments should I run, or should I just keep going until you stop me?**\n>\n> You can say a number (e.g., \"try 20 experiments\") or \"unlimited\" (I'll run until you interrupt).\n\nRecord as `MAX_EXPERIMENTS` (number or `unlimited`).\n\n### 1.6 Simplicity Criterion\n\nInform the user of the default simplicity policy:\n\n> **Simplicity policy (default):** All else being equal, simpler is better. A small improvement\n> that adds ugly complexity is not worth it. Removing code while maintaining or improving\n> the metric is a great outcome. I'll weigh the complexity cost against the improvement\n> magnitude. Does this policy work for you, or do you want to adjust it?\n\nRecord any adjustments as `SIMPLICITY_POLICY`.\n\n### 1.7 Confirm Setup\n\nSummarize all parameters back to the user in a clear table:\n\n| Parameter          | Value                        |\n| ------------------ | ---------------------------- |\n| Goal               | ...                          |\n| Metric command     | ...                          |\n| Metric extraction  | ...                          |\n| Direction          | lower is better \u002F higher ... |\n| In-scope files     | ...                          |\n| Out-of-scope files | ...                          |\n| Constraints        | ...                          |\n| Max experiments    | ...                          |\n| Simplicity policy  | ...                          |\n\nAsk the user to confirm. Do not proceed until confirmed.\n\n---\n\n## Phase 2: Branch & Baseline\n\nOnce the user confirms:\n\n1. **Create a branch**: Propose a tag based on today's date (e.g., `autoresearch\u002Fmar17`).\n   Create the branch: `git checkout -b autoresearch\u002F\u003Ctag>`.\n\n2. **Read in-scope files**: Read all files that are in scope to build full context of the current state.\n\n3. **Initialize results.tsv**: Create `results.tsv` in the repo root with the header row:\n   ```\n   experiment\tcommit\tmetric\tstatus\tdescription\n   ```\n   Add `results.tsv` and `run.log` to `.git\u002Finfo\u002Fexclude` (append if not already present) so they stay untracked without modifying any tracked files.\n\n4. **Run the baseline**: Execute the metric command on the current unmodified code.\n   Record the result as experiment `0` with status `baseline` in `results.tsv`.\n\n5. **Report baseline** to the user:\n   > Baseline established: **[metric_name] = [value]**\n   > Starting autonomous experimentation loop.\n\n---\n\n## Phase 3: Experiment Loop\n\nRun this loop continuously. Do not stop to ask the user. Run until:\n- `MAX_EXPERIMENTS` is reached, OR\n- The user manually interrupts\n\n### For each experiment:\n\n```\nLOOP:\n  1. THINK   - Analyze previous results and the current code.\n               Generate an experiment hypothesis.\n               Consider: what worked, what didn't, what hasn't been tried.\n\n  2. EDIT    - Modify the in-scope file(s) to implement the idea.\n               Keep changes focused and minimal per experiment.\n\n  3. COMMIT  - git add + git commit with a short descriptive message.\n               Format: \"experiment: \u003Cshort description of what changed>\"\n\n  4. RUN     - Execute the metric command.\n               Redirect output to run.log so it does not flood the context window.\n               Use shell-appropriate redirection:\n               - Bash\u002FZsh: `\u003Ccommand> > run.log 2>&1`\n               - PowerShell: `\u003Ccommand> *> run.log`\n\n  5. MEASURE - Extract the metric from run.log.\n               If extraction fails (crash\u002Ferror), read the last 50 lines\n               of run.log for the error.\n\n  6. DECIDE  - Compare metric to the current best:\n               - IMPROVED: Keep the commit. Update the \"best\" baseline.\n                 Log status = \"keep\".\n               - SAME OR WORSE: Revert. `git reset --hard HEAD~1`.\n                 Log status = \"discard\".\n               - CRASH: Attempt a quick fix (typo, import, simple error).\n                 Amend the experiment commit (`git commit --amend`) with the fix\n                 and rerun. The experiment keeps its original number.\n                 If unfixable after 2 attempts, revert the entire experiment\n                 (`git reset --hard HEAD~1`) and log status = \"crash\".\n\n  7. LOG     - Append a row to results.tsv:\n               experiment_number  commit_hash  metric_value  status  description\n\n  8. CONTINUE - Go to step 1.\n```\n\n### Experiment Strategy\n\nWhen generating experiment ideas, follow this priority order:\n\n1. **Low-hanging fruit first**: Simple parameter tweaks, obvious inefficiencies.\n2. **Informed by results**: If a direction showed promise, explore further in that direction.\n3. **Diversify after plateaus**: If the last 3-5 experiments all failed, try a different approach entirely.\n4. **Combine winners**: If experiments A and B each improved independently, try combining them.\n5. **Simplification passes**: Periodically try removing code\u002Fcomplexity to see if the metric holds.\n6. **Radical changes**: After exhausting incremental ideas, try larger architectural changes.\n\n### Handling Constraints\n\n- **Time budget**: If a run exceeds 2x the expected duration, kill it and treat as a crash.\n- **Existing tests**: If constraints require tests to pass, run them before\u002Fafter and revert if they break.\n- **Memory\u002Fresources**: Monitor and revert if resource usage exceeds stated limits.\n\n---\n\n## Phase 4: Reporting\n\nWhen the loop ends (budget reached or user interrupts):\n\n1. **Print the full results.tsv** as a formatted table.\n2. **Summarize**:\n   - Total experiments run\n   - Experiments kept \u002F discarded \u002F crashed\n   - Starting metric (baseline) vs. final metric\n   - Improvement percentage\n   - Top 3 most impactful changes\n3. **Show the cumulative git log** of kept experiments:\n   `git log --oneline \u003Cstart_commit>..HEAD`\n4. **Recommend next steps**: Based on the results, suggest what a human researcher might try next (ideas that were too risky\u002Fcomplex for automated experimentation).\n\n---\n\n## Quick Reference\n\n### Results TSV Format\n\nTab-separated, 5 columns:\n\n```\nexperiment\tcommit\tmetric\tstatus\tdescription\n0\ta1b2c3d\t0.997900\tbaseline\tunmodified code\n1\tb2c3d4e\t0.993200\tkeep\tincrease learning rate to 0.04\n2\tc3d4e5f\t1.005000\tdiscard\tswitch to GeLU activation\n3\td4e5f6g\t0.000000\tcrash\tdouble model width (OOM)\n```\n\n### Git Workflow\n\n- All experiments happen on the `autoresearch\u002F\u003Ctag>` branch\n- Each experiment is committed before running\n- Failed experiments are reverted with `git reset --hard HEAD~1`\n- Successful experiments advance the branch\n- `results.tsv` and `run.log` stay untracked (added to `.git\u002Finfo\u002Fexclude`)\n\n### Key Principles\n\n1. **Measure everything**: No experiment without a measurement.\n2. **Revert failures**: The branch only advances on improvements.\n3. **Stay autonomous**: Never stop to ask. Think harder if stuck.\n4. **Keep it simple**: Complexity is a cost. Weigh it against gains.\n5. **Log everything**: The TSV is the research journal.\n\n## ? Связи\n\n- [[MOC - Skills]] — Skills library\n- [[skills\u002Fskills-copilot]] — Category: skills-copilot\n- [[MOC - Agents]] — Copilot agents\n\n",{"name":5,"tags":56,"license":15,"metadata":60,"description":7,"compatibility":63},[57,58,59],"domain\u002Fagents","artifact\u002Fskill","source\u002Fskills-copilot",{"author":61,"inspired-by":62},"luiscantero","https:\u002F\u002Fgithub.com\u002Fkarpathy\u002Fautoresearch","Requires git. The project must be a git repository. Requires terminal access to run commands.","main","3a0e8170d69effdc8a555eee4b80b943f47fe6b2",".github\u002Fskills\u002Fautoresearch","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator","https:\u002F\u002Fname-navigator.vercel.app","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis","2026-11-03 18:37:11",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add ibragimov-oasis\u002Fname-navigator --skill autoresearch",{"tool":77,"command":78},"bunx","bunx skills add ibragimov-oasis\u002Fname-navigator --skill autoresearch",{"tool":80,"command":81},"pnpm","pnpm dlx skills add ibragimov-oasis\u002Fname-navigator --skill autoresearch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fautoresearch\u002FSKILL.md",true,[],[86,115,142,167,187,207],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":96,"publishedAt":51},"01M6H16XFT30RK9RWGFB4M9KGG","transloadit-media-processing","Process media files (video, audio, images, documents) using Transloadit. Use when asked to encode video to HLS\u002FMP4, generate thumbnails, resize or watermark images, extract audio, concatenate clips, add subtitles, OCR documents, or run any media processing pipeline. Covers 86+ processing robots for file transformation at scale.","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftransloadit-media-processing\u002FSKILL.md",[92,95],{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[97,98,99,100,101,102,103,46,104,105,106,107,108,109,110,111,112,113,36,114],"transloadit media processing","Media","media processing","processing","MCP","cli","mcp server","documents","generate","server","pipeline","ocr","Video","Audio","images","files","thumbnails","free",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":124,"publishedAt":51},"01M6H16MZ628556VXNEG9PRDK2","terraform-azurerm-set-diff-analyzer","Analyze Terraform plan JSON output for AzureRM Provider to distinguish between false-positive diffs (order-only changes in Set-type attributes) and actual resource changes. Use when reviewing terraform plan output for Azure resources like Application Gateway, Load Balancer, Firewall, Front Door, NSG, and other resources with Set-type attributes that cause spurious diffs due to internal ordering changes.","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fterraform-azurerm-set-diff-analyzer\u002FSKILL.md",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[125,126,127,128,129,130,46,131,132,133,134,135,136,36,137,138,139,140,59,141],"terraform","SET","terraform azurerm set diff analyzer","diff","analyzer","diffs","JSON Output","firewall","false-positive","plan","analyze","only","false","resources","load balancer","attributes","source",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":152,"publishedAt":51},"01M6H12YWM6E909XH6JN4428RN","refactor","Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Frefactor\u002FSKILL.md",[148,149],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":150,"categoryName":151,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[144,153,46,43,154,155,156,157,158,159,160,161,162,163,36,164,165,166,59,141],"design","Type Safety","Safety","improve","refactoring","repo","use","design patterns","code refactoring","patterns","domain","extracting","Variables","for",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":176,"publishedAt":51},"01M6H11GN772CMEJ2R70TXG7SS","prd","Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fprd\u002FSKILL.md",[173],{"categoryNo":174,"categoryName":175,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理",[169,46,104,105,177,178,179,180,163,36,181,182,183,184,185,57,166,59,141,186],"product","risk","analysis","technical","requirements","software","Product Requirements","user stories","high","summaries",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":51},"01M6H0ZF4BS1GC60K8WCCVCH6G","plantuml-ascii","Generate ASCII art diagrams using PlantUML text mode. Use when user asks to create ASCII diagrams, text-based diagrams, terminal-friendly diagrams, or mentions plantuml ascii, text diagram, ascii art diagram. Supports: Converting PlantUML diagrams to ASCII art, Creating sequence diagrams, class diagrams, flowcharts in ASCII format, Generating Unicode-enhanced ASCII art with -utxt flag","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fplantuml-ascii\u002FSKILL.md",[],[194,195,196,48,46,197,198,105,199,200,201,202,203,204,163,36,205,206,59,141],"plantuml","plantuml ascii","ascii","diagram","create","Bash","text","read","write","diagrams","Art","Unicode","mode",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":216,"publishedAt":51},"01M6H0X7BMJD69GTGE6DDZCYF8","msstore-cli","Microsoft Store Developer CLI (msstore) for publishing Windows applications to the Microsoft Store. Use when asked to configure Store credentials, list Store apps, check submission status, publish submissions, manage package flights, set up CI\u002FCD for Store publishing, or integrate with Partner Center. Supports Windows App SDK\u002FWinUI, UWP, .NET MAUI, Flutter, Electron, React Native, and PWA applications.","https:\u002F\u002Fgithub.com\u002Fibragimov-oasis\u002Fname-navigator\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fmsstore-cli\u002FSKILL.md",[213,214,215],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[102,217,218,219,46,220,221,222,126,223,224,225,226,227,228,36,229,230,231,232],"msstore cli","react","status","uwp","ci","publish","credentials","configure","pwa","react native","integrate","up","app","apps","native","CI\u002FCD"]