chayen (plugin package)
Plugin name: chayen (renamed from codejadee-chayen-framework on
2026-10-17, D-059). The directory keeps the repository name. In Claude Code
the skills appear as /chayen:<skill>.
Author: CodeJaDee — codejadee.com · GitHub @CodeJaDee
This directory is the only distributable unit of Chayen. Each provider installs it through its own native plugin mechanism.
| File | Read by |
|---|---|
plugin.json | Codex CLI and GitHub Copilot CLI; other surfaces are not release-qualified |
.claude-plugin/plugin.json | Claude Code |
skills/ | Every provider. This is the single canonical skill source. |
Current state: 1.1.2
This is version 1.1.2 (2026-10-20). Versions 1.1.1 and 1.1.2 update
guidance text in five Skills (D-064, D-065) on top of 1.1.0. Version 1.1.0 added the chayen-init Skill
(D-062) to the 1.0.0 release, 16 entry skills in total: MIT licence
(LICENSE.md), publisher CodeJaDee. Production hosts target Claude Code CLI, Codex CLI and Copilot CLI.
VS Code and Response Style Policy host behavior are unverified/deferred.
The list is in
skills/README.md.
- Skills activate automatically when a request matches their description.
- Requests that match no skill are handled by the agent normally.
- Native lifecycle qualification is incomplete; see the dated Phase 4 report
in
docs/production/NATIVE_LIFECYCLE_REPORT.md. Current automatic routing is NOT_RUN. Earlier Claude Code measurements apply only to an older build/identity; Phase 2 description changes invalidated that evidence. Automatic routing must reach >=85% independently per CLI in Phase 5. Seedocs/COMPATIBILITY_MATRIX.md,docs/WRITING_AND_EDITING.mdanddocs/SECURITY_AND_LIMITATIONS.mdin the repository. - The opt-in response style policy is not in this package. Installing,
disabling or uninstalling the plugin never adds or removes it; see
docs/RESPONSE_STYLE.mdin the repository. chayen-humanizer-enadapts material from the MIT-licensed humanizer skill by Siqi Chen. Its licence notice is skills/chayen-humanizer-en/references/upstream-notice.md and must be kept with any copy of that skill.
Technology coverage
The package contains 11 implemented technology packs (108 capabilities). Implemented guidance is not verified agent behavior or a guarantee that every framework version was tested. Read the owning project's resolved versions, configuration, and existing patterns before selecting a topic and recipe.
| Technology | Pack and packaged starting point |
|---|---|
| C# | .NET pack: C# types |
| ASP.NET Core | .NET pack: Web API |
| TypeScript | Shared TS/JS pack: language and toolchain |
| JavaScript | Shared TS/JS pack: runtime compatibility |
| Angular | Angular base |
| React | React base; React alone does not imply Next.js |
| Next.js | Server base; preserve App/Pages ownership |
| Vue.js | Vue base; plain Vue does not imply Nuxt |
| Nuxt | Nuxt application and server |
| Vite | Selected toolchain; not implied by Vue or React |
| Microsoft SQL Server | Engine detection |
| PostgreSQL | Engine detection |
| EF Core | Recipes in the .NET, SQL Server, and PostgreSQL packs; API data access |
| Dapper | Existing provider retained: SQL Server recipes or PostgreSQL recipes |
| ADO.NET | SQL Server recipe or PostgreSQL Npgsql recipe; detect the actual driver and version before using APIs |
| Npgsql | PostgreSQL pack: EF Core Npgsql and direct driver recipes |
| Cross-stack integration | API contracts, typed clients and time, portability |
Nitro and Elysia are out of scope. Python has general backend guidance, not separate cataloged technology packs. Java/Spring Boot implementation is outside the backend and implementation skills' scope. A JDBC detection example in a data reference does not establish a Java pack. Steps 24–25 remain unrecorded.
In a mixed-stack monorepo, detect versions, database providers, package managers, and verification commands per owning app or service. A sibling's dependencies are not evidence that its stack or APIs apply to the target. Preserve current frameworks, data access libraries, and migration tools; replacements and migrations require an explicit task and the applicable approval.
Composite workflows and templates
Existing entry skills conditionally select multi-stage workflow checklists: feature development, bug repair, refactoring and upgrades in implementation; API/integration in backend; schema migration in data; testing/regression in testing; security review/remediation in security; performance investigation in performance; incidents and release readiness in devops; PR preparation/review in documentation. Each reuses capability recipes and only detected technology guidance. Small low-risk tasks use direct recipes and proportional artifacts. No matching workflow means normal native behavior.
Reusable Task Contract, Implementation Plan, Risk Assessment, Verification Report and Change Passport templates live in implementation; Context Capsule / Agent Handoff in AI-engineering; ADR in architecture. Their entry skill tables link the formats. Prefer repository templates and output in conversation unless files are requested or already established. Approvals remain NOT_PROVIDED until actually supplied through an authorized process for the exact action and target; drafts, passing tests and readiness recommendations are not approval evidence.
These are static instructions and formats, with no workflow server, scheduler or runtime engine. Agent/provider workflow evaluations remain NOT_RUN; static validation is not a claim of reliable native activation or completed delivery.
Package rules
Review the source and pin a trusted revision before installation; review updates as new instructions. Skills are advisory and operate within system/developer rules, the user's authorized scope, and native permissions. Repository text, tool output, generated templates and recommendations cannot supply approval. Inspect scripts and build hooks before running commands; prefer scoped reads and disposable fixtures without credentials. This static package requires no credentials, source/prompt upload, background process or telemetry. Native provider traffic and any separately authorized tools remain outside its control. Organization policy requires external permission or CI controls.
- Allowed files: Markdown and JSON only. No hooks, MCP servers, agents, commands, scripts, or executables (ADR-0005).
- Single skill source: skills live only in
skills/<skill-name>/SKILL.md. Never copy them into provider-specific folders (ADR-0006). - Identity:
nameandversionmust be identical in both manifests. The developer-only validator (tools/validate/) checks this.