[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FWFQQ2N3Z6QNFTEXY0C3XT":3,"skill-same:01M6FWFQQ2N3Z6QNFTEXY0C3XT":49},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":22,"linkOnly":23,"markdownContent":24,"markdownBody":25,"frontMatter":26,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":13,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M6FWFQQ2N3Z6QNFTEXY0C3XT","context-driven-development",null,"reikiplanet\u002Fdaoskills","reikiplanet","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F96377599?v=4","01M6CVWCMD740YHQDK7E9QYBW4","Reiki Planet","01M6CVWCS4KXVA2CWFVJ43EAXK",0,"MIT","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fother\u002Fcontext-driven-development\u002FSKILL.md",[],[18,19,20,21],"development","context","context driven development","driven","2026-11-10 10:12:30",false,"---\nname: context-driven-development\ndescription: \"Use this skill when working with Conductor's context-driven\"\n  development methodology, managing project context artifacts, or understanding\n  the relationship between product.md, tech-stack.md, and workflow.md files.\nmetadata:\n  version: 1.0.0\nrisk: unknown\nsource: community\n---\n\n# Context-Driven Development\n\nGuide for implementing and maintaining context as a managed artifact alongside code, enabling consistent AI interactions and team alignment through structured project documentation.\n\n## Do not use this skill when\n\n- The task is unrelated to context-driven development\n- You need a different domain or tool outside this scope\n\n## Instructions\n\n- Clarify goals, constraints, and required inputs.\n- Apply relevant best practices and validate outcomes.\n- Provide actionable steps and verification.\n- If detailed examples are required, open `resources\u002Fimplementation-playbook.md`.\n\n## Use this skill when\n\n- Setting up new projects with Conductor\n- Understanding the relationship between context artifacts\n- Maintaining consistency across AI-assisted development sessions\n- Onboarding team members to an existing Conductor project\n- Deciding when to update context documents\n- Managing greenfield vs brownfield project contexts\n\n## Core Philosophy\n\nContext-Driven Development treats project context as a first-class artifact managed alongside code. Instead of relying on ad-hoc prompts or scattered documentation, establish a persistent, structured foundation that informs all AI interactions.\n\nKey principles:\n\n1. **Context precedes code**: Define what you're building and how before implementation\n2. **Living documentation**: Context artifacts evolve with the project\n3. **Single source of truth**: One canonical location for each type of information\n4. **AI alignment**: Consistent context produces consistent AI behavior\n\n## The Workflow\n\nFollow the **Context → Spec & Plan → Implement** workflow:\n\n1. **Context Phase**: Establish or verify project context artifacts exist and are current\n2. **Specification Phase**: Define requirements and acceptance criteria for work units\n3. **Planning Phase**: Break specifications into phased, actionable tasks\n4. **Implementation Phase**: Execute tasks following established workflow patterns\n\n## Artifact Relationships\n\n### product.md - Defines WHAT and WHY\n\nPurpose: Captures product vision, goals, target users, and business context.\n\nContents:\n\n- Product name and one-line description\n- Problem statement and solution approach\n- Target user personas\n- Core features and capabilities\n- Success metrics and KPIs\n- Product roadmap (high-level)\n\nUpdate when:\n\n- Product vision or goals change\n- New major features are planned\n- Target audience shifts\n- Business priorities evolve\n\n### product-guidelines.md - Defines HOW to Communicate\n\nPurpose: Establishes brand voice, messaging standards, and communication patterns.\n\nContents:\n\n- Brand voice and tone guidelines\n- Terminology and glossary\n- Error message conventions\n- User-facing copy standards\n- Documentation style\n\nUpdate when:\n\n- Brand guidelines change\n- New terminology is introduced\n- Communication patterns need refinement\n\n### tech-stack.md - Defines WITH WHAT\n\nPurpose: Documents technology choices, dependencies, and architectural decisions.\n\nContents:\n\n- Primary languages and frameworks\n- Key dependencies with versions\n- Infrastructure and deployment targets\n- Development tools and environment\n- Testing frameworks\n- Code quality tools\n\nUpdate when:\n\n- Adding new dependencies\n- Upgrading major versions\n- Changing infrastructure\n- Adopting new tools or patterns\n\n### workflow.md - Defines HOW to Work\n\nPurpose: Establishes development practices, quality gates, and team workflows.\n\nContents:\n\n- Development methodology (TDD, etc.)\n- Git workflow and commit conventions\n- Code review requirements\n- Testing requirements and coverage targets\n- Quality assurance gates\n- Deployment procedures\n\nUpdate when:\n\n- Team practices evolve\n- Quality standards change\n- New workflow patterns are adopted\n\n### tracks.md - Tracks WHAT'S HAPPENING\n\nPurpose: Registry of all work units with status and metadata.\n\nContents:\n\n- Active tracks with current status\n- Completed tracks with completion dates\n- Track metadata (type, priority, assignee)\n- Links to individual track directories\n\nUpdate when:\n\n- New tracks are created\n- Track status changes\n- Tracks are completed or archived\n\n## Context Maintenance Principles\n\n### Keep Artifacts Synchronized\n\nEnsure changes in one artifact reflect in related documents:\n\n- New feature in product.md → Update tech-stack.md if new dependencies needed\n- Completed track → Update product.md to reflect new capabilities\n- Workflow change → Update all affected track plans\n\n### Update tech-stack.md When Adding Dependencies\n\nBefore adding any new dependency:\n\n1. Check if existing dependencies solve the need\n2. Document the rationale for new dependencies\n3. Add version constraints\n4. Note any configuration requirements\n\n### Update product.md When Features Complete\n\nAfter completing a feature track:\n\n1. Move feature from \"planned\" to \"implemented\" in product.md\n2. Update any affected success metrics\n3. Document any scope changes from original plan\n\n### Verify Context Before Implementation\n\nBefore starting any track:\n\n1. Read all context artifacts\n2. Flag any outdated information\n3. Propose updates before proceeding\n4. Confirm context accuracy with stakeholders\n\n## Greenfield vs Brownfield Handling\n\n### Greenfield Projects (New)\n\nFor new projects:\n\n1. Run `\u002Fconductor:setup` to create all artifacts interactively\n2. Answer questions about product vision, tech preferences, and workflow\n3. Generate initial style guides for chosen languages\n4. Create empty tracks registry\n\nCharacteristics:\n\n- Full control over context structure\n- Define standards before code exists\n- Establish patterns early\n\n### Brownfield Projects (Existing)\n\nFor existing codebases:\n\n1. Run `\u002Fconductor:setup` with existing codebase detection\n2. System analyzes existing code, configs, and documentation\n3. Pre-populate artifacts based on discovered patterns\n4. Review and refine generated context\n\nCharacteristics:\n\n- Extract implicit context from existing code\n- Reconcile existing patterns with desired patterns\n- Document technical debt and modernization plans\n- Preserve working patterns while establishing standards\n\n## Benefits\n\n### Team Alignment\n\n- New team members onboard faster with explicit context\n- Consistent terminology and conventions across the team\n- Shared understanding of product goals and technical decisions\n\n### AI Consistency\n\n- AI assistants produce aligned outputs across sessions\n- Reduced need to re-explain context in each interaction\n- Predictable behavior based on documented standards\n\n### Institutional Memory\n\n- Decisions and rationale are preserved\n- Context survives team changes\n- Historical context informs future decisions\n\n### Quality Assurance\n\n- Standards are explicit and verifiable\n- Deviations from context are detectable\n- Quality gates are documented and enforceable\n\n## Directory Structure\n\n```\nconductor\u002F\n├── index.md              # Navigation hub linking all artifacts\n├── product.md            # Product vision and goals\n├── product-guidelines.md # Communication standards\n├── tech-stack.md         # Technology preferences\n├── workflow.md           # Development practices\n├── tracks.md             # Work unit registry\n├── setup_state.json      # Resumable setup state\n├── code_styleguides\u002F     # Language-specific conventions\n│   ├── python.md\n│   ├── typescript.md\n│   └── ...\n└── tracks\u002F\n    └── \u003Ctrack-id>\u002F\n        ├── spec.md\n        ├── plan.md\n        ├── metadata.json\n        └── index.md\n```\n\n## Context Lifecycle\n\n1. **Creation**: Initial setup via `\u002Fconductor:setup`\n2. **Validation**: Verify before each track\n3. **Evolution**: Update as project grows\n4. **Synchronization**: Keep artifacts aligned\n5. **Archival**: Document historical decisions\n\n## Context Validation Checklist\n\nBefore starting implementation on any track, validate context:\n\n### Product Context\n\n- [ ] product.md reflects current product vision\n- [ ] Target users are accurately described\n- [ ] Feature list is up to date\n- [ ] Success metrics are defined\n\n### Technical Context\n\n- [ ] tech-stack.md lists all current dependencies\n- [ ] Version numbers are accurate\n- [ ] Infrastructure targets are correct\n- [ ] Development tools are documented\n\n### Workflow Context\n\n- [ ] workflow.md describes current practices\n- [ ] Quality gates are defined\n- [ ] Coverage targets are specified\n- [ ] Commit conventions are documented\n\n### Track Context\n\n- [ ] tracks.md shows all active work\n- [ ] No stale or abandoned tracks\n- [ ] Dependencies between tracks are noted\n\n## Common Anti-Patterns\n\nAvoid these context management mistakes:\n\n### Stale Context\n\nProblem: Context documents become outdated and misleading.\nSolution: Update context as part of each track's completion process.\n\n### Context Sprawl\n\nProblem: Information scattered across multiple locations.\nSolution: Use the defined artifact structure; resist creating new document types.\n\n### Implicit Context\n\nProblem: Relying on knowledge not captured in artifacts.\nSolution: If you reference something repeatedly, add it to the appropriate artifact.\n\n### Context Hoarding\n\nProblem: One person maintains context without team input.\nSolution: Review context artifacts in pull requests; make updates collaborative.\n\n### Over-Specification\n\nProblem: Context becomes so detailed it's impossible to maintain.\nSolution: Keep artifacts focused on decisions that affect AI behavior and team alignment.\n\n## Integration with Development Tools\n\n### IDE Integration\n\nConfigure your IDE to display context files prominently:\n\n- Pin conductor\u002Fproduct.md for quick reference\n- Add tech-stack.md to project notes\n- Create snippets for common patterns from style guides\n\n### Git Hooks\n\nConsider pre-commit hooks that:\n\n- Warn when dependencies change without tech-stack.md update\n- Remind to update product.md when feature branches merge\n- Validate context artifact syntax\n\n### CI\u002FCD Integration\n\nInclude context validation in pipelines:\n\n- Check tech-stack.md matches actual dependencies\n- Verify links in context documents resolve\n- Ensure tracks.md status matches git branch state\n\n## Session Continuity\n\nConductor supports multi-session development through context persistence:\n\n### Starting a New Session\n\n1. Read index.md to orient yourself\n2. Check tracks.md for active work\n3. Review relevant track's plan.md for current task\n4. Verify context artifacts are current\n\n### Ending a Session\n\n1. Update plan.md with current progress\n2. Note any blockers or decisions made\n3. Commit in-progress work with clear status\n4. Update tracks.md if status changed\n\n### Handling Interruptions\n\nIf interrupted mid-task:\n\n1. Mark task as `[~]` with note about stopping point\n2. Commit work-in-progress to feature branch\n3. Document any uncommitted decisions in plan.md\n\n## Best Practices\n\n1. **Read context first**: Always read relevant artifacts before starting work\n2. **Small updates**: Make incremental context changes, not massive rewrites\n3. **Link decisions**: Reference context when making implementation choices\n4. **Version context**: Commit context changes alongside code changes\n5. **Review context**: Include context artifact reviews in code reviews\n6. **Validate regularly**: Run context validation checklist before major work\n7. **Communicate changes**: Notify team when context artifacts change significantly\n8. **Preserve history**: Use git to track context evolution over time\n9. **Question staleness**: If context feels wrong, investigate and update\n10. **Keep it actionable**: Every context item should inform a decision or behavior\n","# Context-Driven Development\n\nGuide for implementing and maintaining context as a managed artifact alongside code, enabling consistent AI interactions and team alignment through structured project documentation.\n\n## Do not use this skill when\n\n- The task is unrelated to context-driven development\n- You need a different domain or tool outside this scope\n\n## Instructions\n\n- Clarify goals, constraints, and required inputs.\n- Apply relevant best practices and validate outcomes.\n- Provide actionable steps and verification.\n- If detailed examples are required, open `resources\u002Fimplementation-playbook.md`.\n\n## Use this skill when\n\n- Setting up new projects with Conductor\n- Understanding the relationship between context artifacts\n- Maintaining consistency across AI-assisted development sessions\n- Onboarding team members to an existing Conductor project\n- Deciding when to update context documents\n- Managing greenfield vs brownfield project contexts\n\n## Core Philosophy\n\nContext-Driven Development treats project context as a first-class artifact managed alongside code. Instead of relying on ad-hoc prompts or scattered documentation, establish a persistent, structured foundation that informs all AI interactions.\n\nKey principles:\n\n1. **Context precedes code**: Define what you're building and how before implementation\n2. **Living documentation**: Context artifacts evolve with the project\n3. **Single source of truth**: One canonical location for each type of information\n4. **AI alignment**: Consistent context produces consistent AI behavior\n\n## The Workflow\n\nFollow the **Context → Spec & Plan → Implement** workflow:\n\n1. **Context Phase**: Establish or verify project context artifacts exist and are current\n2. **Specification Phase**: Define requirements and acceptance criteria for work units\n3. **Planning Phase**: Break specifications into phased, actionable tasks\n4. **Implementation Phase**: Execute tasks following established workflow patterns\n\n## Artifact Relationships\n\n### product.md - Defines WHAT and WHY\n\nPurpose: Captures product vision, goals, target users, and business context.\n\nContents:\n\n- Product name and one-line description\n- Problem statement and solution approach\n- Target user personas\n- Core features and capabilities\n- Success metrics and KPIs\n- Product roadmap (high-level)\n\nUpdate when:\n\n- Product vision or goals change\n- New major features are planned\n- Target audience shifts\n- Business priorities evolve\n\n### product-guidelines.md - Defines HOW to Communicate\n\nPurpose: Establishes brand voice, messaging standards, and communication patterns.\n\nContents:\n\n- Brand voice and tone guidelines\n- Terminology and glossary\n- Error message conventions\n- User-facing copy standards\n- Documentation style\n\nUpdate when:\n\n- Brand guidelines change\n- New terminology is introduced\n- Communication patterns need refinement\n\n### tech-stack.md - Defines WITH WHAT\n\nPurpose: Documents technology choices, dependencies, and architectural decisions.\n\nContents:\n\n- Primary languages and frameworks\n- Key dependencies with versions\n- Infrastructure and deployment targets\n- Development tools and environment\n- Testing frameworks\n- Code quality tools\n\nUpdate when:\n\n- Adding new dependencies\n- Upgrading major versions\n- Changing infrastructure\n- Adopting new tools or patterns\n\n### workflow.md - Defines HOW to Work\n\nPurpose: Establishes development practices, quality gates, and team workflows.\n\nContents:\n\n- Development methodology (TDD, etc.)\n- Git workflow and commit conventions\n- Code review requirements\n- Testing requirements and coverage targets\n- Quality assurance gates\n- Deployment procedures\n\nUpdate when:\n\n- Team practices evolve\n- Quality standards change\n- New workflow patterns are adopted\n\n### tracks.md - Tracks WHAT'S HAPPENING\n\nPurpose: Registry of all work units with status and metadata.\n\nContents:\n\n- Active tracks with current status\n- Completed tracks with completion dates\n- Track metadata (type, priority, assignee)\n- Links to individual track directories\n\nUpdate when:\n\n- New tracks are created\n- Track status changes\n- Tracks are completed or archived\n\n## Context Maintenance Principles\n\n### Keep Artifacts Synchronized\n\nEnsure changes in one artifact reflect in related documents:\n\n- New feature in product.md → Update tech-stack.md if new dependencies needed\n- Completed track → Update product.md to reflect new capabilities\n- Workflow change → Update all affected track plans\n\n### Update tech-stack.md When Adding Dependencies\n\nBefore adding any new dependency:\n\n1. Check if existing dependencies solve the need\n2. Document the rationale for new dependencies\n3. Add version constraints\n4. Note any configuration requirements\n\n### Update product.md When Features Complete\n\nAfter completing a feature track:\n\n1. Move feature from \"planned\" to \"implemented\" in product.md\n2. Update any affected success metrics\n3. Document any scope changes from original plan\n\n### Verify Context Before Implementation\n\nBefore starting any track:\n\n1. Read all context artifacts\n2. Flag any outdated information\n3. Propose updates before proceeding\n4. Confirm context accuracy with stakeholders\n\n## Greenfield vs Brownfield Handling\n\n### Greenfield Projects (New)\n\nFor new projects:\n\n1. Run `\u002Fconductor:setup` to create all artifacts interactively\n2. Answer questions about product vision, tech preferences, and workflow\n3. Generate initial style guides for chosen languages\n4. Create empty tracks registry\n\nCharacteristics:\n\n- Full control over context structure\n- Define standards before code exists\n- Establish patterns early\n\n### Brownfield Projects (Existing)\n\nFor existing codebases:\n\n1. Run `\u002Fconductor:setup` with existing codebase detection\n2. System analyzes existing code, configs, and documentation\n3. Pre-populate artifacts based on discovered patterns\n4. Review and refine generated context\n\nCharacteristics:\n\n- Extract implicit context from existing code\n- Reconcile existing patterns with desired patterns\n- Document technical debt and modernization plans\n- Preserve working patterns while establishing standards\n\n## Benefits\n\n### Team Alignment\n\n- New team members onboard faster with explicit context\n- Consistent terminology and conventions across the team\n- Shared understanding of product goals and technical decisions\n\n### AI Consistency\n\n- AI assistants produce aligned outputs across sessions\n- Reduced need to re-explain context in each interaction\n- Predictable behavior based on documented standards\n\n### Institutional Memory\n\n- Decisions and rationale are preserved\n- Context survives team changes\n- Historical context informs future decisions\n\n### Quality Assurance\n\n- Standards are explicit and verifiable\n- Deviations from context are detectable\n- Quality gates are documented and enforceable\n\n## Directory Structure\n\n```\nconductor\u002F\n├── index.md              # Navigation hub linking all artifacts\n├── product.md            # Product vision and goals\n├── product-guidelines.md # Communication standards\n├── tech-stack.md         # Technology preferences\n├── workflow.md           # Development practices\n├── tracks.md             # Work unit registry\n├── setup_state.json      # Resumable setup state\n├── code_styleguides\u002F     # Language-specific conventions\n│   ├── python.md\n│   ├── typescript.md\n│   └── ...\n└── tracks\u002F\n    └── \u003Ctrack-id>\u002F\n        ├── spec.md\n        ├── plan.md\n        ├── metadata.json\n        └── index.md\n```\n\n## Context Lifecycle\n\n1. **Creation**: Initial setup via `\u002Fconductor:setup`\n2. **Validation**: Verify before each track\n3. **Evolution**: Update as project grows\n4. **Synchronization**: Keep artifacts aligned\n5. **Archival**: Document historical decisions\n\n## Context Validation Checklist\n\nBefore starting implementation on any track, validate context:\n\n### Product Context\n\n- [ ] product.md reflects current product vision\n- [ ] Target users are accurately described\n- [ ] Feature list is up to date\n- [ ] Success metrics are defined\n\n### Technical Context\n\n- [ ] tech-stack.md lists all current dependencies\n- [ ] Version numbers are accurate\n- [ ] Infrastructure targets are correct\n- [ ] Development tools are documented\n\n### Workflow Context\n\n- [ ] workflow.md describes current practices\n- [ ] Quality gates are defined\n- [ ] Coverage targets are specified\n- [ ] Commit conventions are documented\n\n### Track Context\n\n- [ ] tracks.md shows all active work\n- [ ] No stale or abandoned tracks\n- [ ] Dependencies between tracks are noted\n\n## Common Anti-Patterns\n\nAvoid these context management mistakes:\n\n### Stale Context\n\nProblem: Context documents become outdated and misleading.\nSolution: Update context as part of each track's completion process.\n\n### Context Sprawl\n\nProblem: Information scattered across multiple locations.\nSolution: Use the defined artifact structure; resist creating new document types.\n\n### Implicit Context\n\nProblem: Relying on knowledge not captured in artifacts.\nSolution: If you reference something repeatedly, add it to the appropriate artifact.\n\n### Context Hoarding\n\nProblem: One person maintains context without team input.\nSolution: Review context artifacts in pull requests; make updates collaborative.\n\n### Over-Specification\n\nProblem: Context becomes so detailed it's impossible to maintain.\nSolution: Keep artifacts focused on decisions that affect AI behavior and team alignment.\n\n## Integration with Development Tools\n\n### IDE Integration\n\nConfigure your IDE to display context files prominently:\n\n- Pin conductor\u002Fproduct.md for quick reference\n- Add tech-stack.md to project notes\n- Create snippets for common patterns from style guides\n\n### Git Hooks\n\nConsider pre-commit hooks that:\n\n- Warn when dependencies change without tech-stack.md update\n- Remind to update product.md when feature branches merge\n- Validate context artifact syntax\n\n### CI\u002FCD Integration\n\nInclude context validation in pipelines:\n\n- Check tech-stack.md matches actual dependencies\n- Verify links in context documents resolve\n- Ensure tracks.md status matches git branch state\n\n## Session Continuity\n\nConductor supports multi-session development through context persistence:\n\n### Starting a New Session\n\n1. Read index.md to orient yourself\n2. Check tracks.md for active work\n3. Review relevant track's plan.md for current task\n4. Verify context artifacts are current\n\n### Ending a Session\n\n1. Update plan.md with current progress\n2. Note any blockers or decisions made\n3. Commit in-progress work with clear status\n4. Update tracks.md if status changed\n\n### Handling Interruptions\n\nIf interrupted mid-task:\n\n1. Mark task as `[~]` with note about stopping point\n2. Commit work-in-progress to feature branch\n3. Document any uncommitted decisions in plan.md\n\n## Best Practices\n\n1. **Read context first**: Always read relevant artifacts before starting work\n2. **Small updates**: Make incremental context changes, not massive rewrites\n3. **Link decisions**: Reference context when making implementation choices\n4. **Version context**: Commit context changes alongside code changes\n5. **Review context**: Include context artifact reviews in code reviews\n6. **Validate regularly**: Run context validation checklist before major work\n7. **Communicate changes**: Notify team when context artifacts change significantly\n8. **Preserve history**: Use git to track context evolution over time\n9. **Question staleness**: If context feels wrong, investigate and update\n10. **Keep it actionable**: Every context item should inform a decision or behavior\n",{},"master","dff58085da947e81e8418c922055644bf0082b1b","other\u002Fcontext-driven-development","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills","https:\u002F\u002Fgithub.com\u002Freikiplanet","https:\u002F\u002Fwww.reiki-planet.com","Reiki Planet Game","2026-03-29 06:02:29",{"source":7,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add reikiplanet\u002Fdaoskills --skill context-driven-development",{"tool":41,"command":42},"bunx","bunx skills add reikiplanet\u002Fdaoskills --skill context-driven-development",{"tool":44,"command":45},"pnpm","pnpm dlx skills add reikiplanet\u002Fdaoskills --skill context-driven-development","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fother\u002Fcontext-driven-development\u002FSKILL.md",true,[],[50,76,88,103,123,146],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":56,"publishedAt":22},"01M6G614JTEQJHPT8AKK3YQ18S","web-games","Web browser game development principles. Framework selection, WebGPU, optimization, PWA.","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fweb-games\u002FSKILL.md",[],[57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,18,75],"games","web games","web","grep","principles","selection","community","framework selection","edit","write","read","pwa","game","web browser","game development","Optimization","framework","browser","webgpu",{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":22},"01M6G611H2YGV0GZFP90D38ZMJ","vr-ar","VR\u002FAR development principles. Comfort, interaction, performance requirements.","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fvr-ar\u002FSKILL.md",[],[83,84,18,85,86,63,65,66,67,60,87,61],"ar","vr ar","interaction","requirements","performance",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":22},"01M6G60XNMHAMV1SV0EJ1CX0AY","templates","Project scaffolding templates for new applications. Use when creating new projects from scratch. Contains 12 templates for various tech stacks.","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Ftemplates\u002FSKILL.md",[],[90,95,96,97,98,99,63,100,67,101,102,60],"project scaffolding","From Scratch","tech","project","scaffolding","use","projects","applications",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":22},"01M6G60T0GATMK3Q5H8GDC1Z8S","wcag-audit-patterns","Conduct WCAG 2.2 accessibility audits with automated testing, manual verification, and remediation guidance. Use when auditing websites for accessibility, fixing WCAG violations, or implementing ac...","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fskills\u002Fsecurity\u002Fwcag-audit-patterns\u002FSKILL.md",[],[110,111,112,113,114,63,115,116,117,118,100,119,120,121,122],"wcag audit patterns","wcag audit","patterns","WCAG","audit","manual","with","automated testing","guidance","remediation","verification","accessibility","testing",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":22},"01M6G60PMCHW1FRZ63F931QK3R","vulnerability-scanner","Advanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping, risk prioritization.","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fskills\u002Fsecurity\u002Fvulnerability-scanner\u002FSKILL.md",[],[130,131,132,133,134,135,136,137,63,67,60,138,61,139,140,141,142,143,144,145],"scanner","vulnerability scanner","vulnerability","prioritization","2025","mapping","chain","supply chain","Bash","analysis","risk","owasp","supply chain security","security","supply","advanced",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":22},"01M6G60JZBB8DK0W3DSG1WNMZK","threat-modeling-expert","Expert in threat modeling methodologies, security architecture review, and risk assessment. Masters STRIDE, PASTA, attack trees, and security requirement extraction. Use for security architecture r...","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fskills\u002Fsecurity\u002Fthreat-modeling-expert\u002FSKILL.md",[],[153,154,155,156,157,158,159,160,143,100,161,162,163,63,164,165,166,140,167,168],"modeling","threat modeling expert","threat modeling","expert","threat","risk assessment","architecture review","architecture","security architecture review","trees","security architecture","security requirement extraction","assessment","extraction","review","stride"]