[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HFSXE36DYJ4H8N5KG80EQ":3,"skill-same:01M71HFSXE36DYJ4H8N5KG80EQ":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M71HFSXE36DYJ4H8N5KG80EQ","memory-management",null,"Lightweight agent memory for non-Guild projects. Maintains project decisions and error patterns in a flat .agent-memory\u002F directory so future sessions can learn from past work. EN triggers: \u002Fmemory, agent memory, project memory, remember this, record decision, capture learning. PT triggers: \u002Fmemória, memória do agente, memória do projeto, lembrar disso, registrar decisão, capturar aprendizado. Do NOT use for: Guild projects (use guild-commit-learning), large knowledge bases, or replacing a proper wiki.","runecraftai\u002Farcanum","runecraftai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F279098826?v=4","01M71HBGS1RCAJ490RAYST7M00","01M71HBGT1CB94MNS6T6SGAZKW",1,"CC-BY-4.0","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fmemory-management\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"management","memory management","memory","past","directory","capture learning","work","commit","learn","wiki","knowledge","decision","agent-memory","project","pt","error patterns","projects","registrar","error","project memory","2026-11-10 10:12:30",false,"---\nname: memory-management\ndescription: >\n  Lightweight agent memory for non-Guild projects. Maintains project decisions\n  and error patterns in a flat .agent-memory\u002F directory so future sessions\n  can learn from past work.\n  EN triggers: \u002Fmemory, agent memory, project memory, remember this, record decision, capture learning.\n  PT triggers: \u002Fmemória, memória do agente, memória do projeto, lembrar disso, registrar decisão, capturar aprendizado.\n  Do NOT use for: Guild projects (use guild-commit-learning), large knowledge bases, or replacing a proper wiki.\nlicense: CC-BY-4.0\n---\n\n# memory-management\n\nLightweight agent memory for non-Guild projects. Maintains project decisions and error patterns in a flat `.agent-memory\u002F` directory.\n\n```\nDECIDE → SELECT FILE → FORMAT ENTRY → WRITE → VERIFY\n```\n\n---\n\n## Overview\n\nThis skill maintains two flat files in `.agent-memory\u002F` so AI agents can persist learnings across sessions. It is intentionally simpler than Guild's `guild-commit-learning` — designed for solo developers and small teams that do not run the full Guild orchestration system.\n\nNo archive subfolder, no promotion rules, no index maintenance. Two files, one directory, one format.\n\n---\n\n## Directory Structure\n\n```\n.agent-memory\u002F\n├── project_decisions.md    # Architectural decisions, conventions, rationale\n└── error_patterns.md       # Bugs encountered, root causes, fixes applied\n```\n\nCreate the directory and both files on first use. Do not create any subdirectories or additional files.\n\n---\n\n## When to Use\n\nWrite to `.agent-memory\u002F` when:\n\n- A feature is complete and the decisions behind it are not obvious from code\n- A tricky bug was fixed and the root-cause discovery is worth preserving\n- An architectural choice was made (library selection, pattern adoption, API design)\n- A convention was established that future sessions should follow\n- You want the next agent session to know what you learned\n\nDo not write when:\n\n- The change is trivial and self-evident from the code\n- The information duplicates what is already in ADRs, README, or docs\n- You are on a Guild project (use `guild-commit-learning` instead)\n\n---\n\n## Process\n\n### Step 1: Decide\n\nAsk: Is this worth remembering?\n\n- Does it have cross-session value?\n- Is it not obvious from reading the code?\n- Would knowing this save future time?\n\nIf the answer to all three is yes, proceed.\n\n### Step 2: Select the Right File\n\n| If the entry is about... | Write to... |\n|--------------------------|-------------|\n| Architectural decisions, library choices, pattern adoption, API design, conventions, rationale for a technical choice | `project_decisions.md` |\n| Bugs encountered, root causes, fixes applied, symptoms, how to prevent recurrence | `error_patterns.md` |\n\nWhen in doubt, prefer `project_decisions.md` for anything structural and `error_patterns.md` for anything reactive (discovered through failure).\n\n### Step 3: Format the Entry\n\nUse one consistent format for both files. Append new entries at the top so the most recent learning appears first.\n\n```markdown\n## [Title] (YYYY-MM-DD)\n\n**Context**: [what was happening — the situation, the task, the system state]\n\n**Decision\u002FDiscovery**: [what was decided or found — the thing worth remembering]\n\n**Rationale**: [why this matters — alternatives considered, future impact, prevention]\n```\n\nRules for good entries:\n\n- **Title** is specific and searchable. Prefer \"Why the auth service uses RS256 instead of HS256\" over \"Auth decision\".\n- **Context** gives enough background to understand the entry without reading the full codebase.\n- **Decision\u002FDiscovery** states the conclusion clearly. One entry = one idea.\n- **Rationale** explains the why. An entry without rationale is just a fact; with rationale it is a lesson.\n- **No secrets.** Never capture API keys, tokens, passwords, or internal URLs.\n\n### Step 4: Write\n\nRead the target file first. Append the new entry at the top, leaving one blank line before the previous entry.\n\n```bash\n# Create directory and files if they do not exist\nmkdir -p .agent-memory\n[ ! -f .agent-memory\u002Fproject_decisions.md ] && echo \"# Project Decisions\\n\" > .agent-memory\u002Fproject_decisions.md\n[ ! -f .agent-memory\u002Ferror_patterns.md ] && echo \"# Error Patterns\\n\" > .agent-memory\u002Ferror_patterns.md\n```\n\n### Step 5: Keep It Current\n\nWhen re-reading entries for context:\n\n- **Update** entries that have changed (e.g., a decision was revisited and reversed). Add a note like *(Updated: YYYY-MM-DD)* and describe what changed.\n- **Remove** entries that are no longer relevant (e.g., a bug fixed by a library upgrade).\n- **Merge** entries that cover the same topic. Prefer one good entry over two partial ones.\n\n---\n\n## Example Entries\n\n### project_decisions.md\n\n```markdown\n## Adopted Zod v4 for runtime validation (2026-07-15)\n\n**Context**: Evaluating validation libraries for the new API layer. Needed runtime type checking with TypeScript inference.\n\n**Decision\u002FDiscovery**: Chose Zod v4 over Yup and io-ts. Zod's TypeScript integration is tighter, the API is simpler, and v4 adds string formats and better error messages.\n\n**Rationale**: Yup has more plugins but weaker TypeScript inference. io-ts is powerful but harder to teach. Zod v4 strikes the right balance for a team that values type safety but not functional programming purity.\n```\n\n```markdown\n## REST over GraphQL for internal services (2026-07-10)\n\n**Context**: Designing inter-service communication for the new orders platform.\n\n**Decision\u002FDiscovery**: REST with OpenAPI schemas, not GraphQL. Internal services need simple request\u002Fresponse contracts; GraphQL adds query complexity without benefit for machine-to-machine calls.\n\n**Rationale**: GraphQL excels when a single client needs flexible data shapes. Our internal consumers are other services with fixed needs. REST + OpenAPI gives us contract generation and simpler caching.\n```\n\n### error_patterns.md\n\n```markdown\n## SQLite \"database is locked\" under concurrent writes (2026-07-16)\n\n**Context**: Integration tests started failing with SQLITE_BUSY after adding parallel test workers.\n\n**Decision\u002FDiscovery**: Root cause was multiple workers opening write transactions on the same SQLite file. SQLite serializes writes — concurrent writers get \"database is locked\".\n\n**Rationale**: Fix was setting `busyTimeout` to 5000ms and adding `WAL` journal mode. For future: if write concurrency grows, switch to a client-server database. SQLite is fine for reads but serializes writes by design.\n```\n\n```markdown\n## Environment variable leak in CI logs (2026-07-14)\n\n**Context**: CI logs were printing full environment variables when a build script failed, exposing DATABASE_URL and API keys.\n\n**Decision\u002FDiscovery**: The build script used `console.log(process.env)` in its error handler. Secrets appeared in plaintext in the CI job output.\n\n**Rationale**: Removed the full env dump. Replaced with a filtered log that redacts values matching known secret key patterns. Added a pre-commit hook that scans for `process.env` in logging statements.\n```\n\n---\n\n## Verification\n\nAfter writing to `.agent-memory\u002F`:\n\n- [ ] Both `.agent-memory\u002Fproject_decisions.md` and `.agent-memory\u002Ferror_patterns.md` exist\n- [ ] New entry is at the top of the correct file\n- [ ] Entry has a dated title, Context, Decision\u002FDiscovery, and Rationale sections\n- [ ] Entry has enough context to be useful standalone — a new session can understand it without reading the full codebase\n- [ ] No secrets, tokens, passwords, or internal URLs captured\n- [ ] Entry does not duplicate information already in ADRs, README, or docs\n\n---\n\n## When Not to Use This Skill\n\n- **Guild projects.** Use `guild-commit-learning` instead — it integrates with Guild's orchestration, analytics, and knowledge graph.\n- **Large knowledge bases.** Two flat files do not scale to team-wide knowledge management. When you outgrow this, consider a wiki, Notion, or Guild.\n- **Replacing proper documentation.** `.agent-memory\u002F` complements ADRs and READMEs — it does not replace them. Decisions that affect the team or public API still belong in ADRs.\n\n---\n\n## See Also\n\n- `guild-commit-learning` — Full Guild-integrated memory system with archive, promotion rules, and index maintenance\n- `spec-driven` — Feature workflow that produces specs worth recording as decisions\n- `code-review-and-quality` — Reviews that surface bugs worth capturing in `error_patterns.md`\n","# memory-management\n\nLightweight agent memory for non-Guild projects. Maintains project decisions and error patterns in a flat `.agent-memory\u002F` directory.\n\n```\nDECIDE → SELECT FILE → FORMAT ENTRY → WRITE → VERIFY\n```\n\n---\n\n## Overview\n\nThis skill maintains two flat files in `.agent-memory\u002F` so AI agents can persist learnings across sessions. It is intentionally simpler than Guild's `guild-commit-learning` — designed for solo developers and small teams that do not run the full Guild orchestration system.\n\nNo archive subfolder, no promotion rules, no index maintenance. Two files, one directory, one format.\n\n---\n\n## Directory Structure\n\n```\n.agent-memory\u002F\n├── project_decisions.md    # Architectural decisions, conventions, rationale\n└── error_patterns.md       # Bugs encountered, root causes, fixes applied\n```\n\nCreate the directory and both files on first use. Do not create any subdirectories or additional files.\n\n---\n\n## When to Use\n\nWrite to `.agent-memory\u002F` when:\n\n- A feature is complete and the decisions behind it are not obvious from code\n- A tricky bug was fixed and the root-cause discovery is worth preserving\n- An architectural choice was made (library selection, pattern adoption, API design)\n- A convention was established that future sessions should follow\n- You want the next agent session to know what you learned\n\nDo not write when:\n\n- The change is trivial and self-evident from the code\n- The information duplicates what is already in ADRs, README, or docs\n- You are on a Guild project (use `guild-commit-learning` instead)\n\n---\n\n## Process\n\n### Step 1: Decide\n\nAsk: Is this worth remembering?\n\n- Does it have cross-session value?\n- Is it not obvious from reading the code?\n- Would knowing this save future time?\n\nIf the answer to all three is yes, proceed.\n\n### Step 2: Select the Right File\n\n| If the entry is about... | Write to... |\n|--------------------------|-------------|\n| Architectural decisions, library choices, pattern adoption, API design, conventions, rationale for a technical choice | `project_decisions.md` |\n| Bugs encountered, root causes, fixes applied, symptoms, how to prevent recurrence | `error_patterns.md` |\n\nWhen in doubt, prefer `project_decisions.md` for anything structural and `error_patterns.md` for anything reactive (discovered through failure).\n\n### Step 3: Format the Entry\n\nUse one consistent format for both files. Append new entries at the top so the most recent learning appears first.\n\n```markdown\n## [Title] (YYYY-MM-DD)\n\n**Context**: [what was happening — the situation, the task, the system state]\n\n**Decision\u002FDiscovery**: [what was decided or found — the thing worth remembering]\n\n**Rationale**: [why this matters — alternatives considered, future impact, prevention]\n```\n\nRules for good entries:\n\n- **Title** is specific and searchable. Prefer \"Why the auth service uses RS256 instead of HS256\" over \"Auth decision\".\n- **Context** gives enough background to understand the entry without reading the full codebase.\n- **Decision\u002FDiscovery** states the conclusion clearly. One entry = one idea.\n- **Rationale** explains the why. An entry without rationale is just a fact; with rationale it is a lesson.\n- **No secrets.** Never capture API keys, tokens, passwords, or internal URLs.\n\n### Step 4: Write\n\nRead the target file first. Append the new entry at the top, leaving one blank line before the previous entry.\n\n```bash\n# Create directory and files if they do not exist\nmkdir -p .agent-memory\n[ ! -f .agent-memory\u002Fproject_decisions.md ] && echo \"# Project Decisions\\n\" > .agent-memory\u002Fproject_decisions.md\n[ ! -f .agent-memory\u002Ferror_patterns.md ] && echo \"# Error Patterns\\n\" > .agent-memory\u002Ferror_patterns.md\n```\n\n### Step 5: Keep It Current\n\nWhen re-reading entries for context:\n\n- **Update** entries that have changed (e.g., a decision was revisited and reversed). Add a note like *(Updated: YYYY-MM-DD)* and describe what changed.\n- **Remove** entries that are no longer relevant (e.g., a bug fixed by a library upgrade).\n- **Merge** entries that cover the same topic. Prefer one good entry over two partial ones.\n\n---\n\n## Example Entries\n\n### project_decisions.md\n\n```markdown\n## Adopted Zod v4 for runtime validation (2026-07-15)\n\n**Context**: Evaluating validation libraries for the new API layer. Needed runtime type checking with TypeScript inference.\n\n**Decision\u002FDiscovery**: Chose Zod v4 over Yup and io-ts. Zod's TypeScript integration is tighter, the API is simpler, and v4 adds string formats and better error messages.\n\n**Rationale**: Yup has more plugins but weaker TypeScript inference. io-ts is powerful but harder to teach. Zod v4 strikes the right balance for a team that values type safety but not functional programming purity.\n```\n\n```markdown\n## REST over GraphQL for internal services (2026-07-10)\n\n**Context**: Designing inter-service communication for the new orders platform.\n\n**Decision\u002FDiscovery**: REST with OpenAPI schemas, not GraphQL. Internal services need simple request\u002Fresponse contracts; GraphQL adds query complexity without benefit for machine-to-machine calls.\n\n**Rationale**: GraphQL excels when a single client needs flexible data shapes. Our internal consumers are other services with fixed needs. REST + OpenAPI gives us contract generation and simpler caching.\n```\n\n### error_patterns.md\n\n```markdown\n## SQLite \"database is locked\" under concurrent writes (2026-07-16)\n\n**Context**: Integration tests started failing with SQLITE_BUSY after adding parallel test workers.\n\n**Decision\u002FDiscovery**: Root cause was multiple workers opening write transactions on the same SQLite file. SQLite serializes writes — concurrent writers get \"database is locked\".\n\n**Rationale**: Fix was setting `busyTimeout` to 5000ms and adding `WAL` journal mode. For future: if write concurrency grows, switch to a client-server database. SQLite is fine for reads but serializes writes by design.\n```\n\n```markdown\n## Environment variable leak in CI logs (2026-07-14)\n\n**Context**: CI logs were printing full environment variables when a build script failed, exposing DATABASE_URL and API keys.\n\n**Decision\u002FDiscovery**: The build script used `console.log(process.env)` in its error handler. Secrets appeared in plaintext in the CI job output.\n\n**Rationale**: Removed the full env dump. Replaced with a filtered log that redacts values matching known secret key patterns. Added a pre-commit hook that scans for `process.env` in logging statements.\n```\n\n---\n\n## Verification\n\nAfter writing to `.agent-memory\u002F`:\n\n- [ ] Both `.agent-memory\u002Fproject_decisions.md` and `.agent-memory\u002Ferror_patterns.md` exist\n- [ ] New entry is at the top of the correct file\n- [ ] Entry has a dated title, Context, Decision\u002FDiscovery, and Rationale sections\n- [ ] Entry has enough context to be useful standalone — a new session can understand it without reading the full codebase\n- [ ] No secrets, tokens, passwords, or internal URLs captured\n- [ ] Entry does not duplicate information already in ADRs, README, or docs\n\n---\n\n## When Not to Use This Skill\n\n- **Guild projects.** Use `guild-commit-learning` instead — it integrates with Guild's orchestration, analytics, and knowledge graph.\n- **Large knowledge bases.** Two flat files do not scale to team-wide knowledge management. When you outgrow this, consider a wiki, Notion, or Guild.\n- **Replacing proper documentation.** `.agent-memory\u002F` complements ADRs and READMEs — it does not replace them. Decisions that affect the team or public API still belong in ADRs.\n\n---\n\n## See Also\n\n- `guild-commit-learning` — Full Guild-integrated memory system with archive, promotion rules, and index maintenance\n- `spec-driven` — Feature workflow that produces specs worth recording as decisions\n- `code-review-and-quality` — Reviews that surface bugs worth capturing in `error_patterns.md`\n",{"name":5,"license":14,"description":43},"Lightweight agent memory for non-Guild projects. Maintains project decisions and error patterns in a flat .agent-memory\u002F directory so future sessions can learn from past work. EN triggers: \u002Fmemory, agent memory, project memory, remember this, record decision, capture learning. PT triggers: \u002Fmemória, memória do agente, memória do projeto, lembrar disso, registrar decisão, capturar aprendizado. Do NOT use for: Guild projects (use guild-commit-learning), large knowledge bases, or replacing a proper wiki.\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Fmemory-management",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add runecraftai\u002Farcanum --skill memory-management",{"tool":57,"command":58},"bunx","bunx skills add runecraftai\u002Farcanum --skill memory-management",{"tool":60,"command":61},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill memory-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fmemory-management\u002FSKILL.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"README.md","REFERENCE","参考文档",626,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fmemory-management\u002FREADME.md",[72,102,125,151,171,195],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":83,"publishedAt":38},"01M71HGTN9FRQ3WEZMVVX7C3VZ","using-agent-skills","Discovers and invokes the right @runecraft\u002Fspells skill for the current task. Use when starting a session, when a request is ambiguous about which workflow to apply, or when you need to pick among the 13-skill Arcanum catalog. EN triggers: \u002Fskill, which skill, pick a skill, what skill should I use, skill discovery, meta skill. PT triggers: qual skill, qual habilidade, descobrir skill, qual fluxo usar. Do NOT use for: actual implementation work (route to the specific skill instead), unrelated standalone tasks outside the Arcanum catalog, or runtime-specific configuration (e.g., opencode.json \u002F Claude Code plugin paths).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fusing-agent-skills\u002FSKILL.md",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[84,85,86,32,87,88,89,90,91,92,93,94,95,24,96,97,98,99,100,101],"using agent skills","standalone","which","pick","Meta","when","workflow","you","code","tasks","skill discovery","route","unrelated","opencode","request","paths","a skill","ambiguous",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":38},"01M71HGPD6N9JH2G8EVBXJR77X","typescript-patterns","TypeScript best practices and patterns for type-safe, maintainable code. Covers discriminated unions, generics, const assertions, type narrowing, and common anti-patterns. Extends (does not override) project tsconfig. EN triggers: \u002Ftypescript, TypeScript patterns, TS best practices, type safety, discriminated unions, generics, type narrowing. PT triggers: \u002Ftypescript, padrões TypeScript, boas práticas TS, segurança de tipos, unions discriminadas, genéricos. Do NOT use for: JavaScript-only projects, runtime performance, or replacing project tsconfig rules.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftypescript-patterns\u002FSKILL.md",[],[109,110,111,112,34,113,32,114,31,115,116,117,118,119,120,121,122,123,92,124],"typescript","patterns","typescript patterns","do","for","runtime","performance","en","maintainable code","triggers","only","use","assertions","Rules","best practices","common",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":137,"publishedAt":38},"01M71HGJAKX4TFN0PECYPJ9S38","test-driven-development","Drives development with tests — fail first, then make them pass, then refactor. Use when implementing any logic, fixing any bug, or changing any behavior. EN triggers: \u002Ftest, write tests first, TDD, prove it, 80\u002F15\u002F5 pyramid, Beyonce Rule. PT triggers: \u002Fteste, testes primeiro, provar com teste, pirâmide 80\u002F15\u002F5. Do NOT use for: production incident triage (use \u002Fdebug), or cosmetic-only changes with no behavioral surface.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[131,134],{"categoryNo":132,"categoryName":133,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":135,"categoryName":136,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000008","测试与质量",[138,139,140,141,32,142,143,144,119,89,145,146,147,148,149,112,113,116,118,150],"test driven development","development","test","driven","incident","implementing","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":38},"01M71HGC1H4JQFJWH613XTJC59","spec-driven","Feature planning and implementation with 4 adaptive phases — Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, and requirement traceability. Features an independent Verifier (author != verifier, evidence-or-zero), persistent decision log (STATE.md), and test-coverage-matrix-driven tests, plus a self-improving lessons layer that turns verification failures into reusable project-local guidance. Stack-agnostic. Use when planning features (requirements, design, task breakdown), implementing with verification and atomic commits, or validating\u002Fverifying an implementation against a spec. Triggers (PT\u002FEN): \"specify feature\", \"vamos especificar\", \"discutir feature\", \"discutir este caso\", \"design\", \"design da feature\", \"tarefas\", \"quebrar em tarefas\", \"implementar\", \"build\", \"validar\", \"verify work\", \"UAT\", \"validar implementação\", \"record decision\", \"pause work\", \"pausar trabalho\", \"resume work\", \"retomar trabalho\". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (treat as Complex scope: discuss gray areas + architecture-focused design).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002FSKILL.md",[],[158,159,141,160,161,162,163,32,31,29,143,164,165,166,167,168,89,169,93,170],"spec driven","spec","coverage","complexity","task breakdown","scope","local","design","self-improving","auto","atomic commits","analysis","architecture",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":181,"publishedAt":38},"01M71HG5CSP04F29HRAG7XVYKG","skill-forge","Designs, authors, validates, and optimizes new Agent Skills from scratch. Use when creating a new skill, packaging a workflow as a skill, improving a skill's triggering accuracy, or evaluating whether a skill improves output quality. Covers the full lifecycle: DISCOVER, DESIGN, AUTHOR, VALIDATE, OPTIMIZE, DELIVER. Produces skills that follow the open SKILL.md format (YAML frontmatter + Markdown body, progressive disclosure, validation loops). EN triggers: \u002Fforge, create a skill, write a skill, build a skill, new skill, author a skill, package this as a skill, validate a skill, improve skill triggering, optimize skill description, evaluate skill quality. PT triggers: \u002Fforge, criar uma skill, escrever uma skill, construir uma skill, nova skill, empacotar como skill, validar skill, melhorar disparo, otimizar descrição de skill. Do NOT use for: discovering which existing skill to apply (use a dispatch\u002Fmeta skill), planning feature implementation, or designing software architecture.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fskill-forge\u002FSKILL.md",[177,180],{"categoryNo":178,"categoryName":179,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},[182,183,184,86,185,186,32,187,88,188,189,165,170,190,191,145,192,100,193,194],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","create","de","software","new skill","full",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":38},"01M71HG1RAQY3GXX0Q5TMW0XD6","shipping-and-launch","Prepares production launches with a pre-launch checklist, staged rollout, monitoring, and a rollback strategy — plus feature flag lifecycle (off → internal → beta → GA). Use when deploying a feature to production for the first time, releasing a significant change, or planning a rollout. EN triggers: \u002Fship, pre-launch checklist, staged rollout, feature flag, rollback plan, monitoring. PT triggers: \u002Fshippar, checklist pré-lançamento, rollout gradual, feature flag, plano de rollback. Do NOT use for: pre-production development work, or one-off internal tools with no user exposure.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fshipping-and-launch\u002FSKILL.md",[],[202,203,204,32,205,206,89,207,208,209,210,24,211,212,213,214,191,215,216,217],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","plan","change","exposure","plano","ship","Tools","pre-launch"]