{"owner":"midwayjs","repo":"midway","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"<!-- OPENSPEC:START -->\n# OpenSpec Instructions\n\nThese instructions are for AI assistants working in this project.\n\nAlways open `@/openspec/AGENTS.md` when the request:\n- Mentions planning or proposals (words like proposal, spec, change, plan)\n- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work\n- Sounds ambiguous and you need the authoritative spec before coding\n\nUse `@/openspec/AGENTS.md` to learn:\n- How to create and apply change proposals\n- Spec format and conventions\n- Project structure and guidelines\n\nKeep this managed block so 'openspec update' can refresh the instructions.\n\n<!-- OPENSPEC:END -->\n\n# Repository Guide for Agents\n\n## Project overview\n- Midway v4 monorepo managed by lerna + pnpm workspace.\n- TypeScript 5, built with `tsc`, tested with `jest`.\n- IoC container implementation lives in `packages/core` (MidwayContainer, DecoratorManager, MetadataManager).\n\n## Code rules\n- Each component is an independent npm package and can communicate via DI.\n- New/changed components must include tests. Run `npm run test` in the package.\n- Use `mwts` for linting (`npm run lint:fix` when needed).\n- After code changes, rerun the relevant lint command and keep necessary lint-fix output in the patch instead of reverting it casually.\n- Add meaningful comments for functions/classes/interfaces/enums.\n\n## Docs rules\n- Current docs live under `site/docs` (Docusaurus).\n- Match existing doc style/tone/structure for consistency.\n- Show dependency installation in both bash (npm) and JSON `package.json` forms.\n- Doc changes do not require a build check.\n- For component docs, write for beginners first: start from what the component solves, when to use it, and the simplest working path, then go deeper into advanced usage, configuration, and extension points. Prefer tutorial-style progression over API-only lists.\n\n## Practical tips\n- Prefer `pnpm -C <package> test` to scope tests.\n- Keep changes aligned with existing patterns in the targeted package.\n- Pull request titles must use standard commit format, such as `feat: xxx` or `fix: xxx`.\n"},"files":{"AGENTS.md":"<!-- OPENSPEC:START -->\n# OpenSpec Instructions\n\nThese instructions are for AI assistants working in this project.\n\nAlways open `@/openspec/AGENTS.md` when the request:\n- Mentions planning or proposals (words like proposal, spec, change, plan)\n- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work\n- Sounds ambiguous and you need the authoritative spec before coding\n\nUse `@/openspec/AGENTS.md` to learn:\n- How to create and apply change proposals\n- Spec format and conventions\n- Project structure and guidelines\n\nKeep this managed block so 'openspec update' can refresh the instructions.\n\n<!-- OPENSPEC:END -->\n\n# Repository Guide for Agents\n\n## Project overview\n- Midway v4 monorepo managed by lerna + pnpm workspace.\n- TypeScript 5, built with `tsc`, tested with `jest`.\n- IoC container implementation lives in `packages/core` (MidwayContainer, DecoratorManager, MetadataManager).\n\n## Code rules\n- Each component is an independent npm package and can communicate via DI.\n- New/changed components must include tests. Run `npm run test` in the package.\n- Use `mwts` for linting (`npm run lint:fix` when needed).\n- After code changes, rerun the relevant lint command and keep necessary lint-fix output in the patch instead of reverting it casually.\n- Add meaningful comments for functions/classes/interfaces/enums.\n\n## Docs rules\n- Current docs live under `site/docs` (Docusaurus).\n- Match existing doc style/tone/structure for consistency.\n- Show dependency installation in both bash (npm) and JSON `package.json` forms.\n- Doc changes do not require a build check.\n- For component docs, write for beginners first: start from what the component solves, when to use it, and the simplest working path, then go deeper into advanced usage, configuration, and extension points. Prefer tutorial-style progression over API-only lists.\n\n## Practical tips\n- Prefer `pnpm -C <package> test` to scope tests.\n- Keep changes aligned with existing patterns in the targeted package.\n- Pull request titles must use standard commit format, such as `feat: xxx` or `fix: xxx`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"<!-- OPENSPEC:START -->\n# OpenSpec Instructions\n\nThese instructions are for AI assistants working in this project.\n\nAlways open `@/openspec/AGENTS.md` when the request:\n- Mentions planning or proposals (words like proposal, spec, change, plan)\n- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work\n- Sounds ambiguous and you need the authoritative spec before coding\n\nUse `@/openspec/AGENTS.md` to learn:\n- How to create and apply change proposals\n- Spec format and conventions\n- Project structure and guidelines\n\nKeep this managed block so 'openspec update' can refresh the instructions.\n\n<!-- OPENSPEC:END -->\n\n# Repository Guide for Agents\n\n## Project overview\n- Midway v4 monorepo managed by lerna + pnpm workspace.\n- TypeScript 5, built with `tsc`, tested with `jest`.\n- IoC container implementation lives in `packages/core` (MidwayContainer, DecoratorManager, MetadataManager).\n\n## Code rules\n- Each component is an independent npm package and can communicate via DI.\n- New/changed components must include tests. Run `npm run test` in the package.\n- Use `mwts` for linting (`npm run lint:fix` when needed).\n- After code changes, rerun the relevant lint command and keep necessary lint-fix output in the patch instead of reverting it casually.\n- Add meaningful comments for functions/classes/interfaces/enums.\n\n## Docs rules\n- Current docs live under `site/docs` (Docusaurus).\n- Match existing doc style/tone/structure for consistency.\n- Show dependency installation in both bash (npm) and JSON `package.json` forms.\n- Doc changes do not require a build check.\n- For component docs, write for beginners first: start from what the component solves, when to use it, and the simplest working path, then go deeper into advanced usage, configuration, and extension points. Prefer tutorial-style progression over API-only lists.\n\n## Practical tips\n- Prefer `pnpm -C <package> test` to scope tests.\n- Keep changes aligned with existing patterns in the targeted package.\n- Pull request titles must use standard commit format, such as `feat: xxx` or `fix: xxx`.\n","category":"root","tokens":527}]}