{"owner":"wanasit","repo":"chrono","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":1373,"categories":["root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Agent Documentation - Project Setup & Architecture\n\nThis document provides a guide for AI agents working on `chrono` (chrono-node) to quickly understand the project context, layout, testing commands, and implementation constraints.\n\n## Project Overview\n`chrono` is a natural language date parser written in JavaScript/TypeScript. It extracts dates, times, and relative date expressions from free text.\n\n---\n\n## Technical Stack & Setup\n- **Language**: TypeScript / JavaScript (ES6 Modules and CommonJS outputs)\n- **Dependency Manager**: `npm`\n- **Testing Framework**: `jest`\n\n### Running Tests\nTo run the full test suite, execute:\n```bash\nnpm test\n```\nTo run tests silently:\n```bash\nnpm run test:silent\n```\n\n---\n\n## Directory Structure & Architecture\n\n```\nsrc/\n├── index.ts              # Main entry point and locale shortcut exports\n├── chrono.ts             # Main orchestrator class (Chrono, Parser, Refiner, Configuration)\n├── results.ts            # Core result models (ParsingResult, ParsingComponents)\n├── types.ts              # Global type definitions (ParsedResult, ParsingOption, ParsingReference)\n├── calculation/          # Arithmetic helpers (duration, weekdays)\n├── common/               # Locale-agnostic base parsers and refiners\n├── locales/              # Language-specific configurations, parsers, and refiners\n│   ├── de/\n│   ├── en/\n│   ├── zh/\n│   │   ├── hans/\n│   │   └── hant/\n│   └── ...\n└── utils/                # General utility functions\n```\n\n### Core Concepts\n1. **Parsers (`Parser`)**:\n   Implement `innerPattern()` to return the regular expression pattern, and `innerExtract(context, match)` to process matching strings and return a `ParsingResult`.\n2. **Refiners (`Refiner`)**:\n   Post-process and merge/filter the parsed results (e.g., merging separate date and time components, or resolving overlapping date ranges).\n3. **ParsingComponents (`ParsingComponents`)**:\n   Stores date and time elements (e.g., year, month, day, hour). Elements are marked as either explicitly assigned (`assign`) or implied (`imply`).\n\n---\n\n## Key Context & Caveats\n\n1. **Modular Parsers**:\n   Avoid overloading a single parser with multiple disparate concepts (e.g. mixing \"after/within\" with \"ago/before\"). Instead, introduce distinct, small parsers for each concern (e.g., `ZHHansDeadlineFormatParser` and `ZHHansAgoFormatParser`).\n\n2. **Locale Symmetry & Chinese (zh) Special Case**:\n   - The Chinese locale is a special case where we want Simplified (`zh.hans`) and Traditional (`zh.hant`) components to remain exactly synchronized. When implementing a parser/refiner or a test for Simplified Chinese (`zh.hans`), always implement the equivalent for Traditional Chinese (`zh.hant`) if relevant, translating characters accordingly (e.g., `几` vs `幾`, `个` vs `個`, `钟` vs `鐘`).\n   - English (`en`) is the most advanced locale in the library. Other locales are modeled after English but often lag behind.\n\n3. **Relative Date Arithmetic**:\n   Use helpers from `src/calculation/duration.ts` such as `addDuration` and `reverseDuration` to perform date calculations. When handling \"ago/before\" expressions, calculate the positive duration first, then reverse it using `reverseDuration`.\n\n4. **Abstract Parsers**:\n   Inherit from `AbstractParserWithWordBoundaryChecking` (or `AbstractParserWithLeftBoundaryChecking`) to inherit word boundary detection and clean regex boundary matching.\n\n5. **Testing Conventions**:\n   - **Spell out test cases individually**: Do NOT use loops (`for`, `forEach`), shared case tables, or `test.each`. Every test case should be in an explicit `test(...)` block using `testSingleCase(...)` (or `testUnexpectedResult(...)`). This ensures that test failure messages immediately highlight the exact broken input, line number, and expected vs actual values.\n   - Always pass a clear reference date (`refDate`) to `testSingleCase` to ensure deterministic execution of relative time tests.\n   - Assert the matched index (`result.index`) and text boundaries (`result.text`) to check for correct extraction when the text is embedded within sentences.\n   - The `result.index` check can be skipped if it is trivial (e.g., the input string is exactly equal to the expected matched text `result.text`).\n   - The `result.text` check may also be intentionally omitted on vague edge cases.\n\n6. **Commit & PR Scoping, and Design Philosophy**:\n   - **Chrono relies on human maintainer review; simplicity and consistency with existing patterns take precedence.**\n   - **Keep commits and PRs focused and incremental**: Avoid committing or bundling multiple unrelated changes together, both locally in git commits and in pull requests (e.g., mixing eras, holidays, and relative time expressions). If a change touches multiple concepts or features, break them down into separate, incremental commits and PRs. This keeps changes easy to review, simplifies regression analysis, and makes bug bisecting possible.\n   - **Avoid premature over-abstraction**: Do not introduce custom interfaces or heavy abstractions (e.g., per-locale holiday definitions, period managers) inside a single locale. Abstractions should be rare, conceptually solid, designed to work across all or most locales, and—most importantly—introduced on their own rather than bundled with specific feature implementations.\n\n---\n\n## Git & Commit Message Format\n\nFollow the Conventional Commits specification:\n```\n<type>(<scope>): <description>\n```\n- Example: `feat(zh): support past-tense relative time expressions (e.g. \"1小时前\")`\n- Example: `fix(en): support 'of' connector in weekday postfix`\n\n### Pre-commit Formatting\nRun the formatter before staging by executing:\n```bash\nnpm run prettier\n```\n*Note: Git commit runs `npm run prettier` and `npm run test:silent` automatically as a pre-commit hook.*\n\n---\n\n## AI Agent Tool & Command Guidelines\n\nTo ensure secure, auditable, and standard operations:\n- **Network Requests**: Do not run arbitrary commands to execute network calls. Use sandboxed tools or curl commands if external documentation is needed.\n- **Verification**: Always run `npm test` inside the workspace directory rather than trying to run temporary JS code blocks elsewhere to verify behaviors.\n"},"files":{"AGENTS.md":"# Agent Documentation - Project Setup & Architecture\n\nThis document provides a guide for AI agents working on `chrono` (chrono-node) to quickly understand the project context, layout, testing commands, and implementation constraints.\n\n## Project Overview\n`chrono` is a natural language date parser written in JavaScript/TypeScript. It extracts dates, times, and relative date expressions from free text.\n\n---\n\n## Technical Stack & Setup\n- **Language**: TypeScript / JavaScript (ES6 Modules and CommonJS outputs)\n- **Dependency Manager**: `npm`\n- **Testing Framework**: `jest`\n\n### Running Tests\nTo run the full test suite, execute:\n```bash\nnpm test\n```\nTo run tests silently:\n```bash\nnpm run test:silent\n```\n\n---\n\n## Directory Structure & Architecture\n\n```\nsrc/\n├── index.ts              # Main entry point and locale shortcut exports\n├── chrono.ts             # Main orchestrator class (Chrono, Parser, Refiner, Configuration)\n├── results.ts            # Core result models (ParsingResult, ParsingComponents)\n├── types.ts              # Global type definitions (ParsedResult, ParsingOption, ParsingReference)\n├── calculation/          # Arithmetic helpers (duration, weekdays)\n├── common/               # Locale-agnostic base parsers and refiners\n├── locales/              # Language-specific configurations, parsers, and refiners\n│   ├── de/\n│   ├── en/\n│   ├── zh/\n│   │   ├── hans/\n│   │   └── hant/\n│   └── ...\n└── utils/                # General utility functions\n```\n\n### Core Concepts\n1. **Parsers (`Parser`)**:\n   Implement `innerPattern()` to return the regular expression pattern, and `innerExtract(context, match)` to process matching strings and return a `ParsingResult`.\n2. **Refiners (`Refiner`)**:\n   Post-process and merge/filter the parsed results (e.g., merging separate date and time components, or resolving overlapping date ranges).\n3. **ParsingComponents (`ParsingComponents`)**:\n   Stores date and time elements (e.g., year, month, day, hour). Elements are marked as either explicitly assigned (`assign`) or implied (`imply`).\n\n---\n\n## Key Context & Caveats\n\n1. **Modular Parsers**:\n   Avoid overloading a single parser with multiple disparate concepts (e.g. mixing \"after/within\" with \"ago/before\"). Instead, introduce distinct, small parsers for each concern (e.g., `ZHHansDeadlineFormatParser` and `ZHHansAgoFormatParser`).\n\n2. **Locale Symmetry & Chinese (zh) Special Case**:\n   - The Chinese locale is a special case where we want Simplified (`zh.hans`) and Traditional (`zh.hant`) components to remain exactly synchronized. When implementing a parser/refiner or a test for Simplified Chinese (`zh.hans`), always implement the equivalent for Traditional Chinese (`zh.hant`) if relevant, translating characters accordingly (e.g., `几` vs `幾`, `个` vs `個`, `钟` vs `鐘`).\n   - English (`en`) is the most advanced locale in the library. Other locales are modeled after English but often lag behind.\n\n3. **Relative Date Arithmetic**:\n   Use helpers from `src/calculation/duration.ts` such as `addDuration` and `reverseDuration` to perform date calculations. When handling \"ago/before\" expressions, calculate the positive duration first, then reverse it using `reverseDuration`.\n\n4. **Abstract Parsers**:\n   Inherit from `AbstractParserWithWordBoundaryChecking` (or `AbstractParserWithLeftBoundaryChecking`) to inherit word boundary detection and clean regex boundary matching.\n\n5. **Testing Conventions**:\n   - **Spell out test cases individually**: Do NOT use loops (`for`, `forEach`), shared case tables, or `test.each`. Every test case should be in an explicit `test(...)` block using `testSingleCase(...)` (or `testUnexpectedResult(...)`). This ensures that test failure messages immediately highlight the exact broken input, line number, and expected vs actual values.\n   - Always pass a clear reference date (`refDate`) to `testSingleCase` to ensure deterministic execution of relative time tests.\n   - Assert the matched index (`result.index`) and text boundaries (`result.text`) to check for correct extraction when the text is embedded within sentences.\n   - The `result.index` check can be skipped if it is trivial (e.g., the input string is exactly equal to the expected matched text `result.text`).\n   - The `result.text` check may also be intentionally omitted on vague edge cases.\n\n6. **Commit & PR Scoping, and Design Philosophy**:\n   - **Chrono relies on human maintainer review; simplicity and consistency with existing patterns take precedence.**\n   - **Keep commits and PRs focused and incremental**: Avoid committing or bundling multiple unrelated changes together, both locally in git commits and in pull requests (e.g., mixing eras, holidays, and relative time expressions). If a change touches multiple concepts or features, break them down into separate, incremental commits and PRs. This keeps changes easy to review, simplifies regression analysis, and makes bug bisecting possible.\n   - **Avoid premature over-abstraction**: Do not introduce custom interfaces or heavy abstractions (e.g., per-locale holiday definitions, period managers) inside a single locale. Abstractions should be rare, conceptually solid, designed to work across all or most locales, and—most importantly—introduced on their own rather than bundled with specific feature implementations.\n\n---\n\n## Git & Commit Message Format\n\nFollow the Conventional Commits specification:\n```\n<type>(<scope>): <description>\n```\n- Example: `feat(zh): support past-tense relative time expressions (e.g. \"1小时前\")`\n- Example: `fix(en): support 'of' connector in weekday postfix`\n\n### Pre-commit Formatting\nRun the formatter before staging by executing:\n```bash\nnpm run prettier\n```\n*Note: Git commit runs `npm run prettier` and `npm run test:silent` automatically as a pre-commit hook.*\n\n---\n\n## AI Agent Tool & Command Guidelines\n\nTo ensure secure, auditable, and standard operations:\n- **Network Requests**: Do not run arbitrary commands to execute network calls. Use sandboxed tools or curl commands if external documentation is needed.\n- **Verification**: Always run `npm test` inside the workspace directory rather than trying to run temporary JS code blocks elsewhere to verify behaviors.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/wanasit/chrono/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Documentation - Project Setup & Architecture\n\nThis document provides a guide for AI agents working on `chrono` (chrono-node) to quickly understand the project context, layout, testing commands, and implementation constraints.\n\n## Project Overview\n`chrono` is a natural language date parser written in JavaScript/TypeScript. It extracts dates, times, and relative date expressions from free text.\n\n---\n\n## Technical Stack & Setup\n- **Language**: TypeScript / JavaScript (ES6 Modules and CommonJS outputs)\n- **Dependency Manager**: `npm`\n- **Testing Framework**: `jest`\n\n### Running Tests\nTo run the full test suite, execute:\n```bash\nnpm test\n```\nTo run tests silently:\n```bash\nnpm run test:silent\n```\n\n---\n\n## Directory Structure & Architecture\n\n```\nsrc/\n├── index.ts              # Main entry point and locale shortcut exports\n├── chrono.ts             # Main orchestrator class (Chrono, Parser, Refiner, Configuration)\n├── results.ts            # Core result models (ParsingResult, ParsingComponents)\n├── types.ts              # Global type definitions (ParsedResult, ParsingOption, ParsingReference)\n├── calculation/          # Arithmetic helpers (duration, weekdays)\n├── common/               # Locale-agnostic base parsers and refiners\n├── locales/              # Language-specific configurations, parsers, and refiners\n│   ├── de/\n│   ├── en/\n│   ├── zh/\n│   │   ├── hans/\n│   │   └── hant/\n│   └── ...\n└── utils/                # General utility functions\n```\n\n### Core Concepts\n1. **Parsers (`Parser`)**:\n   Implement `innerPattern()` to return the regular expression pattern, and `innerExtract(context, match)` to process matching strings and return a `ParsingResult`.\n2. **Refiners (`Refiner`)**:\n   Post-process and merge/filter the parsed results (e.g., merging separate date and time components, or resolving overlapping date ranges).\n3. **ParsingComponents (`ParsingComponents`)**:\n   Stores date and time elements (e.g., year, month, day, hour). Elements are marked as either explicitly assigned (`assign`) or implied (`imply`).\n\n---\n\n## Key Context & Caveats\n\n1. **Modular Parsers**:\n   Avoid overloading a single parser with multiple disparate concepts (e.g. mixing \"after/within\" with \"ago/before\"). Instead, introduce distinct, small parsers for each concern (e.g., `ZHHansDeadlineFormatParser` and `ZHHansAgoFormatParser`).\n\n2. **Locale Symmetry & Chinese (zh) Special Case**:\n   - The Chinese locale is a special case where we want Simplified (`zh.hans`) and Traditional (`zh.hant`) components to remain exactly synchronized. When implementing a parser/refiner or a test for Simplified Chinese (`zh.hans`), always implement the equivalent for Traditional Chinese (`zh.hant`) if relevant, translating characters accordingly (e.g., `几` vs `幾`, `个` vs `個`, `钟` vs `鐘`).\n   - English (`en`) is the most advanced locale in the library. Other locales are modeled after English but often lag behind.\n\n3. **Relative Date Arithmetic**:\n   Use helpers from `src/calculation/duration.ts` such as `addDuration` and `reverseDuration` to perform date calculations. When handling \"ago/before\" expressions, calculate the positive duration first, then reverse it using `reverseDuration`.\n\n4. **Abstract Parsers**:\n   Inherit from `AbstractParserWithWordBoundaryChecking` (or `AbstractParserWithLeftBoundaryChecking`) to inherit word boundary detection and clean regex boundary matching.\n\n5. **Testing Conventions**:\n   - **Spell out test cases individually**: Do NOT use loops (`for`, `forEach`), shared case tables, or `test.each`. Every test case should be in an explicit `test(...)` block using `testSingleCase(...)` (or `testUnexpectedResult(...)`). This ensures that test failure messages immediately highlight the exact broken input, line number, and expected vs actual values.\n   - Always pass a clear reference date (`refDate`) to `testSingleCase` to ensure deterministic execution of relative time tests.\n   - Assert the matched index (`result.index`) and text boundaries (`result.text`) to check for correct extraction when the text is embedded within sentences.\n   - The `result.index` check can be skipped if it is trivial (e.g., the input string is exactly equal to the expected matched text `result.text`).\n   - The `result.text` check may also be intentionally omitted on vague edge cases.\n\n6. **Commit & PR Scoping, and Design Philosophy**:\n   - **Chrono relies on human maintainer review; simplicity and consistency with existing patterns take precedence.**\n   - **Keep commits and PRs focused and incremental**: Avoid committing or bundling multiple unrelated changes together, both locally in git commits and in pull requests (e.g., mixing eras, holidays, and relative time expressions). If a change touches multiple concepts or features, break them down into separate, incremental commits and PRs. This keeps changes easy to review, simplifies regression analysis, and makes bug bisecting possible.\n   - **Avoid premature over-abstraction**: Do not introduce custom interfaces or heavy abstractions (e.g., per-locale holiday definitions, period managers) inside a single locale. Abstractions should be rare, conceptually solid, designed to work across all or most locales, and—most importantly—introduced on their own rather than bundled with specific feature implementations.\n\n---\n\n## Git & Commit Message Format\n\nFollow the Conventional Commits specification:\n```\n<type>(<scope>): <description>\n```\n- Example: `feat(zh): support past-tense relative time expressions (e.g. \"1小时前\")`\n- Example: `fix(en): support 'of' connector in weekday postfix`\n\n### Pre-commit Formatting\nRun the formatter before staging by executing:\n```bash\nnpm run prettier\n```\n*Note: Git commit runs `npm run prettier` and `npm run test:silent` automatically as a pre-commit hook.*\n\n---\n\n## AI Agent Tool & Command Guidelines\n\nTo ensure secure, auditable, and standard operations:\n- **Network Requests**: Do not run arbitrary commands to execute network calls. Use sandboxed tools or curl commands if external documentation is needed.\n- **Verification**: Always run `npm test` inside the workspace directory rather than trying to run temporary JS code blocks elsewhere to verify behaviors.\n","isInternal":false,"tokens":1373,"sizeBytes":6316}],"systemPromptSnippet":"<yakaai_skills repo=\"wanasit/chrono\">\n<!-- File: AGENTS.md (Tokens: ~1373 | Category: root-instruction) -->\n# Agent Documentation - Project Setup & Architecture\n\nThis document provides a guide for AI agents working on `chrono` (chrono-node) to quickly understand the project context, layout, testing commands, and implementation constraints.\n\n## Project Overview\n`chrono` is a natural language date parser written in JavaScript/TypeScript. It extracts dates, times, and relative date expressions from free text.\n\n---\n\n## Technical Stack & Setup\n- **Language**: TypeScript / JavaScript (ES6 Modules and CommonJS outputs)\n- **Dependency Manager**: `npm`\n- **Testing Framework**: `jest`\n\n### Running Tests\nTo run the full test suite, execute:\n```bash\nnpm test\n```\nTo run tests silently:\n```bash\nnpm run test:silent\n```\n\n---\n\n## Directory Structure & Architecture\n\n```\nsrc/\n├── index.ts              # Main entry point and locale shortcut exports\n├── chrono.ts             # Main orchestrator class (Chrono, Parser, Refiner, Configuration)\n├── results.ts            # Core result models (ParsingResult, ParsingComponents)\n├── types.ts              # Global type definitions (ParsedResult, ParsingOption, ParsingReference)\n├── calculation/          # Arithmetic helpers (duration, weekdays)\n├── common/               # Locale-agnostic base parsers and refiners\n├── locales/              # Language-specific configurations, parsers, and refiners\n│   ├── de/\n│   ├── en/\n│   ├── zh/\n│   │   ├── hans/\n│   │   └── hant/\n│   └── ...\n└── utils/                # General utility functions\n```\n\n### Core Concepts\n1. **Parsers (`Parser`)**:\n   Implement `innerPattern()` to return the regular expression pattern, and `innerExtract(context, match)` to process matching strings and return a `ParsingResult`.\n2. **Refiners (`Refiner`)**:\n   Post-process and merge/filter the parsed results (e.g., merging separate date and time components, or resolving overlapping date ranges).\n3. **ParsingComponents (`ParsingComponents`)**:\n   Stores date and time elements (e.g., year, month, day, hour). Elements are marked as either explicitly assigned (`assign`) or implied (`imply`).\n\n---\n\n## Key Context & Caveats\n\n1. **Modular Parsers**:\n   Avoid overloading a single parser with multiple disparate concepts (e.g. mixing \"after/within\" with \"ago/before\"). Instead, introduce distinct, small parsers for each concern (e.g., `ZHHansDeadlineFormatParser` and `ZHHansAgoFormatParser`).\n\n2. **Locale Symmetry & Chinese (zh) Special Case**:\n   - The Chinese locale is a special case where we want Simplified (`zh.hans`) and Traditional (`zh.hant`) components to remain exactly synchronized. When implementing a parser/refiner or a test for Simplified Chinese (`zh.hans`), always implement the equivalent for Traditional Chinese (`zh.hant`) if relevant, translating characters accordingly (e.g., `几` vs `幾`, `个` vs `個`, `钟` vs `鐘`).\n   - English (`en`) is the most advanced locale in the library. Other locales are modeled after English but often lag behind.\n\n3. **Relative Date Arithmetic**:\n   Use helpers from `src/calculation/duration.ts` such as `addDuration` and `reverseDuration` to perform date calculations. When handling \"ago/before\" expressions, calculate the positive duration first, then reverse it using `reverseDuration`.\n\n4. **Abstract Parsers**:\n   Inherit from `AbstractParserWithWordBoundaryChecking` (or `AbstractParserWithLeftBoundaryChecking`) to inherit word boundary detection and clean regex boundary matching.\n\n5. **Testing Conventions**:\n   - **Spell out test cases individually**: Do NOT use loops (`for`, `forEach`), shared case tables, or `test.each`. Every test case should be in an explicit `test(...)` block using `testSingleCase(...)` (or `testUnexpectedResult(...)`). This ensures that test failure messages immediately highlight the exact broken input, line number, and expected vs actual values.\n   - Always pass a clear reference date (`refDate`) to `testSingleCase` to ensure deterministic execution of relative time tests.\n   - Assert the matched index (`result.index`) and text boundaries (`result.text`) to check for correct extraction when the text is embedded within sentences.\n   - The `result.index` check can be skipped if it is trivial (e.g., the input string is exactly equal to the expected matched text `result.text`).\n   - The `result.text` check may also be intentionally omitted on vague edge cases.\n\n6. **Commit & PR Scoping, and Design Philosophy**:\n   - **Chrono relies on human maintainer review; simplicity and consistency with existing patterns take precedence.**\n   - **Keep commits and PRs focused and incremental**: Avoid committing or bundling multiple unrelated changes together, both locally in git commits and in pull requests (e.g., mixing eras, holidays, and relative time expressions). If a change touches multiple concepts or features, break them down into separate, incremental commits and PRs. This keeps changes easy to review, simplifies regression analysis, and makes bug bisecting possible.\n   - **Avoid premature over-abstraction**: Do not introduce custom interfaces or heavy abstractions (e.g., per-locale holiday definitions, period managers) inside a single locale. Abstractions should be rare, conceptually solid, designed to work across all or most locales, and—most importantly—introduced on their own rather than bundled with specific feature implementations.\n\n---\n\n## Git & Commit Message Format\n\nFollow the Conventional Commits specification:\n```\n<type>(<scope>): <description>\n```\n- Example: `feat(zh): support past-tense relative time expressions (e.g. \"1小时前\")`\n- Example: `fix(en): support 'of' connector in weekday postfix`\n\n### Pre-commit Formatting\nRun the formatter before staging by executing:\n```bash\nnpm run prettier\n```\n*Note: Git commit runs `npm run prettier` and `npm run test:silent` automatically as a pre-commit hook.*\n\n---\n\n## AI Agent Tool & Command Guidelines\n\nTo ensure secure, auditable, and standard operations:\n- **Network Requests**: Do not run arbitrary commands to execute network calls. Use sandboxed tools or curl commands if external documentation is needed.\n- **Verification**: Always run `npm test` inside the workspace directory rather than trying to run temporary JS code blocks elsewhere to verify behaviors.\n</yakaai_skills>"}