architext 0.0.4 → 0.0.5

package/dist/templates/en/rules/01_workflow.md

@@ -1,5 +1,5 @@
 ---
-description: Command Dispatcher & Workflow Controller. Handles /archi.start, /archi.plan, and mode transitions between Discussion, Planning, and Implementation.
+description: Command Dispatcher & Workflow Controller. Handles /archi.* routing and mode transitions.
 globs: **/*
 applyTo: **/*
 alwaysApply: true
@@ -9,85 +9,87 @@ alwaysApply: true
 
 > **Role**: Mode Switcher. Default to "General Architect" mode, only load specific protocol when explicit command is detected.
 
-> ⛔ **STOP CHECK** — Self-check before each response; stop immediately and explain if any item is triggered:
+> ⛔ **STOP CHECK** — Self-check before each response:
 > | Violation | Correct Action |
 > |:---|:---|
-> | Received `/archi.*` command but started executing without loading the protocol file | Stop → Load protocol file first |
-> | User request involves behavior change but code was modified directly | Stop → Route to the appropriate command |
-> | Ran a Terminal Gate command without confirming working directory (see `04_cli_tools.md`) | Stop → Pass Working Directory Gate first |
+> | Received `/archi.*` but started executing without loading protocol file | Stop → Load protocol file first |
+> | User request involves behavior change but code was modified directly | Stop → Load and execute the corresponding protocol |
+> | Ran `npx archi` without confirming working directory | Stop → Pass Working Directory Gate (see `04_cli_tools.md`) |
 
 ## 1. Explicit Command Routing
 
-**Trigger**: When user input starts with `/archi.`, immediately load the corresponding protocol template.
+**Trigger**: When user input starts with `/archi.`, immediately load the corresponding protocol.
 
-| Command | Target Template | Action |
-|:---|:---|:---|
-| `/archi.start` | `[[__DOCS_DIR__]]/prompts/start.md` | Load CPO → Project Initiation |
-| `/archi.inherit` | `[[__DOCS_DIR__]]/prompts/inherit.md` | Load Legacy Analyst → Reverse Engineering |
-| `/archi.scope` | `[[__DOCS_DIR__]]/prompts/scope.md` | Load Strategist → Requirement Decomposition |
-| `/archi.plan` | `[[__DOCS_DIR__]]/prompts/plan.md` | Load Planner → Deep Interview |
-| `/archi.edit` | `[[__DOCS_DIR__]]/prompts/edit.md` | Load Editor → Spec Modification |
-| `/archi.revise` | `[[__DOCS_DIR__]]/prompts/revise.md` | Load Chief Architect → Global Revision |
-| `/archi.code` | `[[__DOCS_DIR__]]/prompts/code.md` | Load Developer → Coding & Auditing |
-| `/archi.audit` | `[[__DOCS_DIR__]]/prompts/audit.md` | Load Chief Auditor → Deep Code Audit |
-| `/archi.fix` | `[[__DOCS_DIR__]]/prompts/fix.md` | Load Debugger → Diagnosis |
-| `/archi.map` | `[[__DOCS_DIR__]]/prompts/map.md` | Load Surveyor → Map Refresh |
-| `/archi.remove` | `[[__DOCS_DIR__]]/prompts/remove.md` | Load Surgeon → Task Decommission |
-| `/archi.help` | `[[__DOCS_DIR__]]/prompts/help.md` | Load Manual → Display Guide |
-
-> **Protocol Load Gate** (forbidden to skip; three steps must complete in order):
-> 1. **Read** target `.md` full text → if file not found, stop and output: `Protocol file not found, execution aborted`
-> 2. **Override** `00_system` partial settings
+| Command | Target Template |
+|:---|:---|
+| `/archi.start` | `[[__PROMPTS_PATH__]]/archi.start.md` |
+| `/archi.inherit` | `[[__PROMPTS_PATH__]]/archi.inherit.md` |
+| `/archi.scope` | `[[__PROMPTS_PATH__]]/archi.scope.md` |
+| `/archi.plan` | `[[__PROMPTS_PATH__]]/archi.plan.md` |
+| `/archi.edit` | `[[__PROMPTS_PATH__]]/archi.edit.md` |
+| `/archi.revise` | `[[__PROMPTS_PATH__]]/archi.revise.md` |
+| `/archi.code` | `[[__PROMPTS_PATH__]]/archi.code.md` |
+| `/archi.audit` | `[[__PROMPTS_PATH__]]/archi.audit.md` |
+| `/archi.fix` | `[[__PROMPTS_PATH__]]/archi.fix.md` |
+| `/archi.map` | `[[__PROMPTS_PATH__]]/archi.map.md` |
+| `/archi.remove` | `[[__PROMPTS_PATH__]]/archi.remove.md` |
+| `/archi.ref` | `[[__PROMPTS_PATH__]]/archi.ref.md` |
+| `/archi.recover` | `[[__PROMPTS_PATH__]]/archi.recover.md` |
+| `/archi.help` | `[[__PROMPTS_PATH__]]/archi.help.md` |
+
+> **Protocol Load Gate** (forbidden to skip, complete in order):
+> 1. **Read** target `.md` full text → if file not found, stop: `Protocol file not found, execution aborted`
+> 2. **Override** — May override: `<system_role>`, `<thinking_process>`, `<communication_style>`. Cannot override: `<core_philosophy>`, `<critical_protocols>`.
 > 3. **Execute** `<step_1>` — forbidden to execute any protocol content before step 1 is complete
 
 ---
 
-## 2. Natural Language Passthrough
-
-**Trigger**: User input is not `/archi.` command text.
+## 2. Natural Language Dispatch
 
-### 2.1 Intent Detection
+**Trigger**: User input is not an `/archi.` command and involves business changes.
 
-**Role**: Intelligent Dispatcher. Detect user intent and decide to execute directly or route to a command based on impact level.
-
-**Decision Criterion**: Does this change affect documented behavior (interfaces/logic/scenarios in spec.md, interactions/structure in ui.md, implementation steps in plan.json)?
+### §2.0 Non-protocol scenarios (answer directly)
 
 | Intent Type | Action |
 |:---|:---|
-| Pure conversation / code reading / architecture discussion | ✅ Answer directly, enhanced by base rules |
+| Pure conversation / code reading / architecture discussion | ✅ Answer directly |
 | Trivial edits (typo/comments/formatting/log messages) | ✅ Execute directly |
-| Behavior change (logic/interface/type/UI) | 🔀 Route → `/archi.edit` + `/archi.code` |
-| Bug fix | 🔀 Route → `/archi.fix` |
-| New feature | 🔀 Route → `/archi.scope` or `/archi.plan` |
-| Large-scale refactoring | 🔀 Route → `/archi.revise` |
 
-### 2.2 Guided Dispatch
+### §2.1 Pre-flight (triggered when business changes are involved)
 
-When routing (🔀), must:
-1. Explain in one sentence why a command is needed (which document would be affected)
-2. Recommend the specific command + parameters
-3. Ask the user whether to proceed
+1. Scan `roadmap.json` + `tasks/<ID>_*/` directory to match user intent to tasks.
+2. Determine protocol to load per the table below:
 
-> ⛔ **Prohibited**: Modifying code first and then suggesting the command as an afterthought. Violations require reverting the change and re-routing.
+| Check Result | Load Protocol | Confirmation |
+|:---|:---|:---|
+| No matching task in roadmap | `scope.md` | Inform "Let me help you scope this" then start |
+| Has task · no spec.md | `plan.md` | Inform "This task needs planning, I'll do it" then start |
+| Has spec+plan · status=active | `code.md` | Start directly (IDE native plan mode drives rhythm) |
+| status=done · user wants changes | `edit.md` | Inform "I'll update docs before changing code" then start |
+| User describes abnormal behavior | `fix.md` | Start diagnosis directly |
+| Affects >1 task or global assets | `revise.md` | Output impact assessment first, await confirmation |
 
-### 2.3 Unmanaged Code
+3. After loading protocol, follow §1 **Protocol Load Gate** (read full text → override → step_1).
 
-When the target of modification is not registered in `map.json` and has no corresponding Task:
-- Inform the user that the module is not managed
-- Suggest `/archi.inherit` or `/archi.scope` to bring it under management
-- After user confirms "temporary adjustment", proceed with direct modification
+### §2.2 Chain Continuation
 
-### 2.4 Base Rules
+Each protocol's Signoff Next Steps already points to the next protocol. AI must:
+- Proactively suggest next step ("Spec is ready, shall we start implementing?")
+- After user confirms, load next protocol and continue
 
-All scenarios (including routing and pure conversation) rely on the following base rules:
+| Transition | Chaining Rule |
+|:---|:---|
+| scope → plan | May chain (after scope, ask "Want to plan the first task?") |
+| plan → code | **Must await user confirmation** (spec is the most important checkpoint) |
+| code → audit | Built-in (code.md step_5 already has silent audit) |
 
-| Layer | File | Role |
-|:---|:---|:---|
-| Core | `00_system.md` | Identity, core principles |
-| Tech | `02_tech_stack.md` | Tech red lines, coding standards |
-| Custom | `90_custom_rules.md` | Team-specific constraints |
-| Context | `99_context_glue.md` | Auto-associate context documents |
+> ⛔ **Prohibited**: Auto-chaining from plan to code without user confirmation.
+
+### §2.3 IDE Collaboration
+
+Leverage IDE native capabilities (plan mode / agent mode / checkpoint) to drive execution rhythm.
+Protocols define "what to do, what to check" — do not fight IDE planning/execution capabilities.
 
-**End of Dispatcher.**
+### §2.4 Unmanaged Code
 
-> Mandatory CLI execution rules: see `04_cli_tools.md`.
+Target not registered in `map.json` and has no Task → **STOP & ASK**, prompt user to adopt via `/archi.inherit` or `/archi.scope`.

package/dist/templates/en/rules/03_data_governance.md

@@ -1,4 +1,4 @@
----
+---
 description: AI collaboration governance rules for JSON data files. Defines read/write specs, update timing & format constraints for global data files.
 globs: "**/*.json"
 applyTo: "**/*.json"
@@ -11,14 +11,18 @@ alwaysApply: true
 
 ## 1. Data File Registry
 
-| File | Type | Read When | Write When |
-|:---|:---|:---|:---|
-| `roadmap.json` | Roadmap | `/archi.plan`, `/archi.code` start | `/archi.start` creates; AI direct edit or `npx archi task` updates status |
-| `map.json` | Architecture Map | When touching code (via context_glue) | `/archi.plan` Step 3 (global sync); `/archi.inherit` Step 3.6; `/archi.map` |
-| `dictionary.json` | Glossary | When generating variable names | `/archi.plan` Step 3; step_5 auto-appends after code/fix |
-| `design_tokens.json` | Design Tokens [?UI] | When generating UI code | `/archi.start` creates; update on design changes |
-| `data_snapshot.json` | Data Snapshot [?Data] | `/archi.plan` Q1 design; `/archi.code` implementation | Plan phase designs Schema; Code phase syncs actual changes |
-| `error_codes.json` | Error Contracts | When writing error handling | `/archi.plan` Step 3; step_5 auto-appends after code/fix |
+| File | Read When | Write When |
+|:---|:---|:---|
+| `roadmap.json` | plan/code start | start creates; AI edit or `npx archi task` updates |
+| `map.json` | When touching code (via context_glue) | plan Step 3; inherit Step 3.6; /archi.map |
+| `dictionary.json` | When generating variable names | plan Step 3; code/fix step_5 auto-appends |
+| `design_tokens.json` [?UI] | When generating UI code | start creates; update on design changes |
+| `data_snapshot.json` [?Data] | plan design / code implementation | Plan designs Schema; Code syncs changes |
+| `error_codes.json` | When writing error handling | plan Step 3; code/fix step_5 auto-appends |
+| `api_snapshot.json` [?API] | When implementing endpoints | plan Step 3 registers; Code syncs |
+| `env_registry.json` [?API] | When introducing config items | Code appends immediately on new env var |
+| `command_api.json` [?CLI] | When implementing commands | plan Step 3 registers; Code syncs |
+| `public_api.json` [?Lib] | When adding/modifying exports | plan Step 3 registers; Code syncs |
 
 ---
 
@@ -26,19 +30,19 @@ alwaysApply: true
 
 ### 2.1 Format Constraints
 
-- **JSON Only**: The single source of truth for global data is `.json` files. `.md` views are auto-generated by `npx archi render`; prohibited from editing `.md` views directly.
-- **Schema Stability**: Managed in two tiers:
-  - **Tier 1 (Strict)**: `roadmap.json`, `plan.json` — CLI rendering/commands depend on these directly; structure is validated by Zod Schema; prohibited from changing fields arbitrarily.
-  - **Tier 2 (Flexible)**: `dictionary.json`, `error_codes.json`, `data_snapshot.json`, `design_tokens.json`, `map.json` — Only top-level keys are validated. If existing fields cannot adequately describe what needs to be recorded, you may freely extend fields (add new keys or new properties in array items) without modifying the CLI.
-- **Valid JSON**: Must ensure valid JSON after writing (no trailing commas, no comments).
+- **JSON Only**: `.json` is the single source of truth. `.md` views are auto-generated by `npx archi render`; forbidden to edit directly.
+- **Schema Stability**:
+  - **Tier 1 (Strict)**: `roadmap.json`, `plan.json` — CLI depends on these; Zod Schema validated; forbidden to change arbitrarily.
+  - **Tier 2 (Flexible)**: All other files only validate top-level keys. **All Tier 2 files may freely extend fields (new keys / new array item properties) without CLI changes.**
+- **Valid JSON**: No trailing commas, no comments.
 
 ### 2.2 Read/Write Discipline
 
 | Scenario | Rule |
 |:---|:---|
-| Need to consult data | Read `.json` file; prohibited from reading `.md` view (may be stale) |
-| Need to update Roadmap task status | Prefer `npx archi task <ID> --status <s>`; batch updates may edit JSON directly |
-| Need to update other data files | AI directly edits `.json` file |
+| Consult data | Read `.json`; forbidden to read `.md` view (may be stale) |
+| Update Roadmap status | Prefer `npx archi task <ID> --status <s>`; batch may edit JSON directly |
+| Update other data | AI directly edits `.json` |
 | After updates | Run `npx archi render` to regenerate `.md` views |
 
 ---
@@ -50,47 +54,47 @@ alwaysApply: true
 - **Structure**: `phases[] → tasks[]`, each task must have `id`, `title`, `status`, `deps`.
 - **Status values**: `pending` | `active` | `done` | `blocked`.
 - **Dependency integrity**: IDs in `deps` must exist in tasks.
-- **Slug rule**: `slug` is used for tasks folder naming, format `Snake_Case`.
+- **Slug rule**: `slug` used for tasks folder naming, format `Snake_Case`.
 
 ### `map.json`
 
-- **Directory Mapping**: Must reflect the real physical file tree.
+- **Directory Mapping**: Must reflect real physical file tree.
 - **Logical Topology**: Must register each Task Module's responsibility.
-- **Feature Relations** (field `featureRelations`): Records linkage relationships between aggregator tasks and their sources. Each entry: `{ aggregator, sources, evidence, checkNote }`. Written by AI during `/archi.plan` (when planning an aggregator task) or `/archi.inherit` (during reverse scanning); no manual maintenance needed.
-- **Self-Correction**: If code references violate the hierarchy defined in topology, must report error and stop generation.
-- **Extensible**: If existing fields cannot adequately describe the project architecture, you may add fields to items (e.g. `tags`, `owner`) or add new top-level keys.
+- **Feature Relations**: `featureRelations` records aggregator-source linkages, written by AI during plan/inherit.
+- **Self-Correction**: Code references violating topology hierarchy must report error and stop.
 
 ### `dictionary.json`
 
-- **Naming Authority**: This file is the supreme law of naming.
-- **Boundary**: Only register **project business domain** content. Architext framework concepts (scripts, scaffold, roadmap, plan, etc.) are prohibited from registration.
-- **entities**: Must consult `entities[].codeName` before generating variable names; prohibited from using words in `forbiddenSynonyms`.
-- **verbs**: Business action naming must consult `verbs[].codeName` for project-wide verb consistency.
-- **utilities**: Shared tools (e.g. logger, AppError, fetchClient) must be registered; AI must use registered utilities instead of raw APIs (refer to `replaces` field).
-- **components** [?UI]: Must search existing components before creating new ones; prioritize reuse.
-- **Extensible**: If existing fields cannot adequately describe a term/tool, you may add fields to array items (e.g. `tags`, `scope`, `deprecated`) or add new top-level arrays (e.g. `enums`, `constants`).
+- **Naming Authority**: `entities[].codeName` is the supreme law; forbidden to use `forbiddenSynonyms`.
+- **Boundary**: Only register project business domain; Architext framework concepts forbidden.
+- verbs maintain project-wide verb consistency; utilities must be registered and used instead of raw APIs.
+- [?UI]: components — search existing before creating new ones.
 
 ### `design_tokens.json` [?UI]
 
-- **Token Only**: Styles must strictly use Tokens; prohibited from hardcoding Hex/px/rem.
+- **Token Only**: Styles must use Tokens; forbidden to hardcode Hex/px/rem.
 - **Dark Mode**: Must define both `light` and `dark` values.
-- **Extensible**: If existing Token structure cannot cover project needs (e.g. `motion`, `breakpoints`, `z-index`), you may add new properties freely.
 
 ### `data_snapshot.json` [?Data]
 
-- **Structure**: `models[]` (name, fields, types, constraints) + `relationships[]` (inter-model relations: 1:1/1:N/M:N/self-ref).
-- **Design First**: Plan phase must define model structure and field types; prohibited from writing "TBD"; must be precise to field names and types.
-- **Sync Back**: After Code phase completion, must sync actual changes back to this file.
-- **Extensible**: If existing fields cannot adequately describe data models (e.g. need to record `indexes`, `triggers`, `seedData`), you may add fields to model items or at the top level.
+- **Structure**: `models[]` (name/fields/types/constraints) + `relationships[]` (1:1/1:N/M:N/self-ref).
+- **Design First**: Plan must define model structure, precise to field names and types; forbidden to write "TBD".
+- **Sync Back**: After Code phase, must sync actual changes back.
 
 ### `error_codes.json`
 
-- **Boundary**: Only register **project business domain** errors. Framework infrastructure errors (scripts/validate, dev-up, dev-reset, etc.) are handled by scripts themselves via exit code + stderr; prohibited from registration here.
-- **Structure**: `protocolMapping [?API]` (status code → behavior mapping) + `businessErrors` (business error registry).
-- **Code Format**: `ERR_[MODULE]_[REASON]` (e.g. `ERR_AUTH_INVALID_TOKEN`).
-- **statusCode**: Fill per project type (HTTP status / Exit code / leave empty).
-- **Design Before Code**: Must register error codes here before writing error handling code, including `message` and `recovery`.
-- **Extensible**: If existing fields cannot adequately describe error info (e.g. need to record `severity`, `retryable`, `httpBody`), you may add fields to items freely.
+- **Boundary**: Only register project business domain errors; framework infrastructure errors forbidden.
+- **Code Format**: `ERR_[MODULE]_[REASON]`.
+- **Design Before Code**: Must register error codes before writing error handling, including `message` and `recovery`.
+
+### Conditional File Rules
+
+| File | Core Rules |
+|:---|:---|
+| `api_snapshot.json` [?API] | endpoints[] registry; Register First — forbidden to implement unregistered endpoints; owner marks Task ID |
+| `env_registry.json` [?API] | Register on introduce; required/example mandatory |
+| `command_api.json` [?CLI] | Sync on modify; owner marks Task ID |
+| `public_api.json` [?Lib] | stable changes require /archi.edit; full TS signature; owner marks Task ID |
 
 ---
 
@@ -99,4 +103,4 @@ alwaysApply: true
 - **Location**: `tasks/<ID>_<Slug>/plan.json`
 - **Checkbox Updates**: AI sets `done` to `true` directly after completing steps during `/archi.code`.
 - **Append Rule**: `/archi.edit` appends new Phases while preserving completed history.
-- **Verification**: Run `npx archi plan <ID>` to verify completion after finishing.
+- **Verification**: Run `npx archi plan <ID>` to verify completion.

package/dist/templates/en/skills/archi-data-sync/SKILL.md

@@ -4,9 +4,9 @@ type: reviewer
 description: Data governance sync executor. In isolated context, scans main Agent output, compares with global data file state, performs incremental sync per 03_data_governance.md rules, returns change Diff.
 ---
 
-# Data governance sync executor
+# Data Governance Sync Executor
 
-## System flow position
+## System Flow Position
 
 ```
 /archi.* step_N → Verify phase
@@ -23,27 +23,27 @@ Main Agent Signoff (confirm Diff)
 
 ---
 
-## Authoritative rule source
+## Authoritative Rule Source
 
 `03_data_governance.md` is the single authoritative source for data governance. All behavior of this Skill must align with that file.
 
 ---
 
-## Sync scope
+## Sync Scope
 
 | Global file | Sync content | Trigger |
 |:---|:---|:---|
 | `dictionary.json` | New business entities · actions · shared tools · public components | Output contains unregistered business terms or tools |
 | `error_codes.json` | New business error codes | Output contains unregistered error scenarios |
-| 本任务涉及data时: `data_snapshot.json` | Schema changes | Output has data model add/modify |
-| 仅api项目: `api_snapshot.json` | New endpoints | Output has new HTTP/RPC endpoints |
-| 仅api项目: `env_registry.json` | New env vars | Output introduces new `process.env.X` |
-| 仅cli项目: `command_api.json` | New commands | Output has new CLI commands |
-| 仅lib项目: `public_api.json` | New public exports | Output has new public exports |
+| [?Data] `data_snapshot.json` | Schema changes | Output has data model add/modify |
+| [?API] `api_snapshot.json` | New endpoints | Output has new HTTP/RPC endpoints |
+| [?API] `env_registry.json` | New env vars | Output introduces new `process.env.X` |
+| [?CLI] `command_api.json` | New commands | Output has new CLI commands |
+| [?Lib] `public_api.json` | New public exports | Output has new public exports |
 
 ---
 
-## Execution protocol
+## Execution Protocol
 
 1. **Read global data files**: Load global files matching project features from table above
 2. **Scan main Agent output**: Identify new business entities, error codes, Schema, endpoints, etc.
@@ -52,13 +52,13 @@ Main Agent Signoff (confirm Diff)
 5. **Incremental sync**: Append/modify only, do not delete existing entries
 6. **Output change Diff**
 
-### Hard boundaries
+### Hard Boundaries
 
 - **No direct append** — Must check existing content boundary before write, avoid duplicates or conflicts
 - **No framework concept registration** — Sync only project business domain content
 - **No modify `03_data_governance.md`** — This Skill enforces rules, does not define them
 
-### Output format
+### Output Format
 
 ```
 ### Data Sync Results

package/dist/templates/en/skills/archi-decompose-roadmap/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: archi-decompose-roadmap
+type: subagent
 description: Architext task decomposition expert. Five-step method: calibrate project type for infrastructure checklist, extract business Tasks and Infra tasks via dual perspective, identify Polish tasks, route NFR cross-cutting concerns by weight (inject vs. standalone), build dependency chain and output parallel batches. Task type encoded by ID prefix (INF/FEAT/POLISH/EDIT); tag field carries business domain labels. Produces Tier 1 Schema-compliant roadmap.json tasks as input contracts for `/archi.plan`.
 ---
 
@@ -27,7 +28,7 @@ Brief → [This Skill] → roadmap.json tasks
 >
 > **Schema constraint (Tier 1 Strict)**: roadmap.json validated by CLI Zod Schema. **Adding or removing fields is forbidden.**
 
-## Invocation Mode
+## Invocation Modes
 
 | Mode | Triggered By | Input | Constraint |
 |:---|:---|:---|:---|
@@ -275,10 +276,6 @@ Route cross-cutting concerns by **effort weight**: lightweight → inject into g
 }
 ```
 
-> **ID prefix vs tag responsibility separation**:
-> - `id` prefix (`INF-` / `FEAT-` / `POLISH-` / `EDIT-`) = task type, determines `/archi.plan` spec acceptance format
-> - `tag` = business domain label, for human categorization only, does not affect AI behavior
-
 `deps` empty or all `done` → `pending`; has incomplete deps → `blocked`
 
 ---
@@ -291,35 +288,7 @@ Route cross-cutting concerns by **effort weight**: lightweight → inject into g
 
 Three outputs:
 
-**① Task data** (directly maps to `roadmap.json` phases/tasks):
-
-```json
-{
-  "phases": [
-    {
-      "id": "phase-infra",
-      "name": "Infrastructure",
-      "tasks": [
-        { "id": "INF-01", "title": "...", "status": "pending", "description": "...", "goal": "...", "deps": [], "tag": "Infra", "slug": "..." }
-      ]
-    },
-    {
-      "id": "phase-core",
-      "name": "Core Features",
-      "tasks": [
-        { "id": "FEAT-01", "title": "...", "status": "blocked", "description": "...", "goal": "...", "deps": ["INF-01"], "tag": "Core", "slug": "..." }
-      ]
-    },
-    {
-      "id": "phase-polish",
-      "name": "Polish & Launch",
-      "tasks": [
-        { "id": "POLISH-01", "title": "...", "status": "blocked", "description": "...", "goal": "...", "deps": ["FEAT-01"], "tag": "Quality", "slug": "..." }
-      ]
-    }
-  ]
-}
-```
+**① Task data** (directly maps to `roadmap.json` phases/tasks structure; each task follows Task JSON Schema above; phases ordered `phase-infra` → `phase-core` → `phase-polish`):
 
 **② NFR merge list** (return with task data; caller appends as `nfr` top-level field; `/archi.plan` step_1_load must read):
 

package/dist/templates/en/skills/archi-design-patterns/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: archi-design-patterns
+type: specialist
 description: Architext technical design structured pattern library. Defines standard formats and self-check lists for four core mechanism description patterns (State Machine / Pipeline / Decision Matrix / Protocol). Referenced by /archi.plan step_4 when generating design.md § 2, and by /archi.code step_5 when auditing implementation vs. design consistency.
 ---
 

package/dist/templates/en/skills/archi-feature-relations/SKILL.md

@@ -4,9 +4,9 @@ type: reviewer
 description: featureRelations linkage handler. In isolated context, handles map.json featureRelations register/check/cleanup, ensures aggregator Tasks maintain correct linkage with their sources.
 ---
 
-# featureRelations linkage handler
+# featureRelations Linkage Handler
 
-## System flow position
+## System Flow Position
 
 ```
 /archi.* step_N → Verify phase
@@ -22,7 +22,7 @@ Main Agent Signoff (confirm linkage prompts)
 
 ---
 
-## Modes and behavior
+## Modes and Behavior
 
 ### Mode `register` (caller: plan, inherit)
 
@@ -71,7 +71,7 @@ Remove featureRelations entries referencing removed Task, assess impact.
 
 ---
 
-## Output format
+## Output Format
 
 ### register mode
 

package/dist/templates/en/skills/archi-interview-protocol/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: archi-interview-protocol
+type: specialist
 description: Architext supplementary interview protocol. Standardizes how to ask about information gaps: multiple-choice first, AI recommendation + [Recommended] marking, [Z] Custom fallback, complete AI+/AI- analysis, option descriptions state concrete behavior. Produces standard Q-table and INPUT prompt line, referenced by /archi.start, /archi.scope, and /archi.plan supplementary confirmation steps.
 ---
 
@@ -19,7 +20,7 @@ Information gap detected
 > - Responsible for: how to ask (format / rules / tone)
 > - Not responsible for: what to ask (determined by caller's gap list), how to handle user answers (determined by caller)
 
-## Callers & Trigger Conditions
+## Invocation Modes
 
 | Caller | Trigger Step | Trigger Condition | Max Questions |
 |:---|:---|:---|:---|

package/dist/templates/en/skills/archi-plan-options/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: archi-plan-options
+type: subprocess
 description: Architext architecture decision option library. Defines candidate approaches and AI+/AI- analysis for five core dimensions (Core Structure / Interaction Pattern / Data Flow / Error Handling / Access & Scope), covering Web/CLI/API/Lib/Mobile/MiniApp/Extension/Desktop/AI Agent project types. Includes convention inheritance rules, project tag routing logic, and recommend vs. expand criteria. Referenced by /archi.plan step_2 Part 2 (architecture recommendation phase).
 ---
 
@@ -14,7 +15,7 @@ description: Architext architecture decision option library. Defines candidate a
     ↓
 Direct recommendation row (most dimensions) or Q-table (when user decision needed)
     ↓
-Written into Feature Proposal architecture recommendation table
+Written into Task Proposal architecture recommendation table
 ```
 
 > **Skill responsibility boundary**:
@@ -36,7 +37,7 @@ Read `02_tech_stack.md` Section 9 (project conventions).
 
 ### Step 2 · Project Tag Routing
 
-Use project tags activated in step_1_load (`[?UI]` / `[?Data]` / `[?CLI]` / `[?Lib]` / `[?API]` / `[?Mobile]` / `[?MiniApp]` / `[?Extension]` / `[?Desktop]` / `[?AI]`) to select applicable dimensions; skip inapplicable ones. Routing rules are in each dimension's heading.
+Use project tags activated in step_1_load (`ui` / `data` / `cli` / `lib` / `api` / `mobile` / `miniapp` / `extension` / `desktop` / `ai`) to select applicable dimensions; skip inapplicable ones. Routing rules are in each dimension's heading.
 
 ### Step 3 · Recommend vs. Expand
 
@@ -361,4 +362,4 @@ Only add supplementary handling if this feature has **special exception scenario
 
 ---
 
-> **Intermediate artifact**: This Skill is a subroutine. After producing a recommendation row or Q-table, control returns to `/archi.plan` step_2, where the caller assembles the output into the Feature Proposal's architecture recommendation table.
+> **Intermediate artifact**: This Skill is a subroutine. After producing a recommendation row or Q-table, control returns to `/archi.plan` step_2, where the caller assembles the output into the Task Proposal's architecture recommendation table.

package/dist/templates/en/skills/archi-silent-audit/SKILL.md

@@ -6,7 +6,7 @@ description: Embedded lightweight review. In an isolated context, reviews main A
 
 # Embedded Lightweight Review
 
-## System flow position
+## System Flow Position
 
 ```
 /archi.* step_N → Verify phase
@@ -27,25 +27,25 @@ Main Agent Signoff (must respond to findings)
 
 ---
 
-## Modes and review dimensions
+## Modes and Review Dimensions
 
 ### Mode `init` (caller: start, inherit)
 
 Review global file quality for new/inherited projects.
 
-| # | Dimension | Review points |
+| # | Dimension | Review Points |
 |:---|:---|:---|
 | 1 | **Vision-Roadmap alignment** | Roadmap task direction aligns with vision.md north star |
 | 2 | **Tech Stack consistency** | `02_tech_stack.md` matches actual deps/config |
 | 3 | **Global file completeness** | Required global files present (vision, roadmap, map, dictionary, tech_stack, custom_rules) |
 | 4 | **Zero info omission** | All Brief/code info routed to corresponding files |
-| 5 | 仅ui项目: **Design Tokens** | `design_tokens.json` has base colors/fonts/spacing |
+| 5 | [?UI] **Design Tokens** | `design_tokens.json` has base colors/fonts/spacing |
 
 ### Mode `plan-docs` (caller: plan)
 
 Review planning doc (spec/ui/plan) quality.
 
-| # | Dimension | Review points |
+| # | Dimension | Review Points |
 |:---|:---|:---|
 | 1 | **Design Fidelity** | spec § 2 fully covers confirmed functional design |
 | 2 | **Dimension Match** | spec § 2 dimension format matches Task Type |
@@ -54,39 +54,39 @@ Review planning doc (spec/ui/plan) quality.
 | 5 | **Notes Quality** | plan.json each task notes has deliverable+constraint+executable verification |
 | 6 | **Interface Exports** | INF task § 4 filled; interface declared when downstream deps exist |
 | 7 | **Constraints** | § 5 includes vision.md + tech_stack red lines |
-| 8 | 本任务涉及data时: **Data Integrity** | Entities and fields match confirmed core entities |
-| 9 | 仅Complex任务: **Design Trace** | design.md § 6 all ACs traceable |
-| 10 | 仅Complex任务: **Parameter Specificity** | design.md § 3 params concrete (no vague terms) |
-| 11 | 仅Complex任务: **Self-Check Pass** | design.md § 2 mechanism self-check list passes |
+| 8 | [?Data] **Data Integrity** | Entities and fields match confirmed core entities |
+| 9 | [?Complex] **Design Trace** | design.md § 6 all ACs traceable |
+| 10 | [?Complex] **Parameter Specificity** | design.md § 3 params concrete (no vague terms) |
+| 11 | [?Complex] **Self-Check Pass** | design.md § 2 mechanism self-check list passes |
 
 ### Mode `code-impl` (caller: code)
 
 Review code implementation quality.
 
-| # | Dimension | Review points |
+| # | Dimension | Review Points |
 |:---|:---|:---|
 | 1 | **Tech Consistency** | Matches `02_tech_stack.md` (libs/patterns/API style) |
 | 2 | **SOTA** | Reject outdated patterns; use tech_stack best practices |
 | 3 | **Security** | No sensitive info leak; input validated |
 | 4 | **Performance** | Avoid unnecessary large deps/full imports/useless computation/memory leaks |
-| 5 | 本任务涉及ui时: **Design Compliance** | Styles use Token/Preset only; no hardcoded magic values |
-| 6 | 本任务涉及ui时: **Accessibility** | Necessary a11y attributes present |
-| 7 | 本任务涉及data时: **Data Integrity** | Matches `data_snapshot.json`; field names/types consistent |
-| 8 | 仅i18n项目: **I18n** | No hardcoded strings; use Key/dictionary reference |
-| 9 | 仅Complex任务: **Design Compliance** | State transitions/flows/protocols match design.md § 2 |
-| 10 | 仅Complex任务: **Invariant Enforcement** | design.md § 4 invariants have assert/runtime checks in code |
-| 11 | 仅Complex任务: **Parameter Alignment** | Code values match design.md § 3 param table |
+| 5 | [?UI] **Design Compliance** | Styles use Token/Preset only; no hardcoded magic values |
+| 6 | [?UI] **Accessibility** | Necessary a11y attributes present |
+| 7 | [?Data] **Data Integrity** | Matches `data_snapshot.json`; field names/types consistent |
+| 8 | [?i18n] **I18n** | No hardcoded strings; use Key/dictionary reference |
+| 9 | [?Complex] **Design Compliance** | State transitions/flows/protocols match design.md § 2 |
+| 10 | [?Complex] **Invariant Enforcement** | design.md § 4 invariants have assert/runtime checks in code |
+| 11 | [?Complex] **Parameter Alignment** | Code values match design.md § 3 param table |
 
 ---
 
-## Execution protocol
+## Execution Protocol
 
 1. **Load context**: Load required docs and code per caller-provided file paths
 2. **Filter dimensions by mode**: Execute only dimensions for current mode
 3. **Review item by item**: Each dimension outputs PASS or finding (level+location+description)
 4. **Output finding list**: Return sorted by level
 
-### Finding levels
+### Finding Levels
 
 | Level | Meaning | Main Agent must |
 |:---|:---|:---|
@@ -94,7 +94,7 @@ Review code implementation quality.
 | `WARNING` | Risk | **Must explain** handling in signoff report |
 | `INFO` | Suggestion | May decide whether to handle |
 
-### Output format
+### Output Format
 
 ```
 ### Silent Audit Results (mode: <mode>)