Code authoring router
Before editing, preserve the repository's current VCS state and inspect repository facts to select the construction
guidance that matches the affected code. A generic request such as “결제 기능 추가해줘” is an implementation
signal, not proof of a technology stack.
Resolve project policy
If root vulpora.config.json exists, validate and apply its locale and vcs policy. Otherwise use the portable
defaults: follow the user and repository language, auto-detect the hosted VCS and default branch only when needed,
and preserve the current branch and worktree.
Do not create, switch, fetch, fast-forward, push, or open a change request merely because implementation was
requested. Prepare a child branch only when the user/repository requires it or vcs.prepareBranch is true. In
that opt-in path, use the configured provider and base branch (auto means the remote default, never an assumed
develop), and preserve dirty or diverged work. The GitLab-specific git-flow skill may be used only when GitLab
is proven and its house style matches the project policy.
Record the resolved policy and any branch action with the routing evidence.
Detect and route
- Inspect project instructions, build files, dependency catalogs, source extensions, migration directories, mappings, query builders, and nearby tests.
- Record the evidence paths and choose every installed, applicable authoring skill:
| Repository and task evidence |
Load before editing |
| Actual Kotlin source in the affected module, supported by its build settings; the change edits Kotlin code |
kotlin-code-authoring |
| Java source in the affected module, including Java/Spring |
Repository-local Java authoring and test conventions; java-spring-review-workflow for Spring review if installed |
| PostgreSQL driver/dialect plus affected SQL, repository query, schema, or migration |
postgres-code-authoring |
| SQL Server driver/dialect plus affected T-SQL, stored procedure, schema, index, or migration |
mssql-code-authoring |
| OpenSearch client/dependency plus affected mapping, Query DSL, pipeline, index setting, or search behavior |
opensearch-code-authoring |
- Multiple skills may apply to one feature. Load each selected skill before the first edit in its lane and use only the relevant KB topics. If a matching skill is not installed, report the recommendation and continue with repository-local guidance rather than inventing a dependency.
- Put
base_branch, work_branch, required_authoring_skills, and evidence paths in plans or implementation handoffs so delegated agents apply the same constraints.
Do not select a technology from the feature wording alone. If no supported stack has repository evidence, continue with repository-local conventions without inventing an authoring skill.
Gradle Kotlin DSL, buildSrc, and convention plugins do not establish Kotlin application usage. Exclude installed
skill/agent bundles and evaluation fixtures from service-stack evidence. In mixed modules, route each affected file
by its implementation/test language; Kotlin-only test skills must not be applied to Java work.
Read stack detection when evidence is mixed or the feature crosses multiple persistence/search boundaries.
Verify
Before completion, confirm that the configured VCS policy was preserved, every changed implementation lane used
its available routed authoring skill, and the repository-provided formatter, lint, compile, and focused tests ran
where applicable.
1---2name: code-authoring-router3description: Route generic feature, bug-fix, refactor, and implementation requests to installed code-authoring skills after detecting repository stack evidence. Use even when the user only names the desired behavior and does not mention Kotlin, Spring, PostgreSQL, Microsoft SQL Server, or OpenSearch; do not use for review-only requests.4---56# Code authoring router78Before editing, preserve the repository's current VCS state and inspect repository facts to select the construction9guidance that matches the affected code. A generic request such as “결제 기능 추가해줘” is an implementation10signal, not proof of a technology stack.1112## Resolve project policy1314If root `vulpora.config.json` exists, validate and apply its `locale` and `vcs` policy. Otherwise use the portable15defaults: follow the user and repository language, auto-detect the hosted VCS and default branch only when needed,16and preserve the current branch and worktree.1718Do not create, switch, fetch, fast-forward, push, or open a change request merely because implementation was19requested. Prepare a child branch only when the user/repository requires it or `vcs.prepareBranch` is `true`. In20that opt-in path, use the configured provider and base branch (`auto` means the remote default, never an assumed21`develop`), and preserve dirty or diverged work. The GitLab-specific `git-flow` skill may be used only when GitLab22is proven and its house style matches the project policy.2324Record the resolved policy and any branch action with the routing evidence.2526## Detect and route27281. Inspect project instructions, build files, dependency catalogs, source extensions, migration directories, mappings, query builders, and nearby tests.292. Record the evidence paths and choose every installed, applicable authoring skill:3031| Repository and task evidence | Load before editing |32|---|---|33| Actual Kotlin source in the affected module, supported by its build settings; the change edits Kotlin code | `kotlin-code-authoring` |34| Java source in the affected module, including Java/Spring | Repository-local Java authoring and test conventions; `java-spring-review-workflow` for Spring review if installed |35| PostgreSQL driver/dialect plus affected SQL, repository query, schema, or migration | `postgres-code-authoring` |36| SQL Server driver/dialect plus affected T-SQL, stored procedure, schema, index, or migration | `mssql-code-authoring` |37| OpenSearch client/dependency plus affected mapping, Query DSL, pipeline, index setting, or search behavior | `opensearch-code-authoring` |38393. Multiple skills may apply to one feature. Load each selected skill before the first edit in its lane and use only the relevant KB topics. If a matching skill is not installed, report the recommendation and continue with repository-local guidance rather than inventing a dependency.404. Put `base_branch`, `work_branch`, `required_authoring_skills`, and evidence paths in plans or implementation handoffs so delegated agents apply the same constraints.4142Do not select a technology from the feature wording alone. If no supported stack has repository evidence, continue with repository-local conventions without inventing an authoring skill.4344Gradle Kotlin DSL, `buildSrc`, and convention plugins do not establish Kotlin application usage. Exclude installed45skill/agent bundles and evaluation fixtures from service-stack evidence. In mixed modules, route each affected file46by its implementation/test language; Kotlin-only test skills must not be applied to Java work.4748Read [stack detection](reference/kb/stack-detection.md) when evidence is mixed or the feature crosses multiple persistence/search boundaries.4950## Verify5152Before completion, confirm that the configured VCS policy was preserved, every changed implementation lane used53its available routed authoring skill, and the repository-provided formatter, lint, compile, and focused tests ran54where applicable.
ch4570