easy-coding-harness 0.1.4

package/templates/common/bundled-skills/ec-meta/references/local-architecture/README.md

@@ -0,0 +1,76 @@
+# Local Architecture
+
+How an installed Easy Coding harness is laid out and why.
+
+## Two layers
+
+The harness deliberately separates **platform-native files** from **shared runtime data**:
+
+- **Platform-native** (agent discovers these natively): skills, hooks, sub-agent definitions,
+  and the main constraint file. They live in each platform's standard directory
+  (`.claude/`, `.agents/` + `.codex/`, `.qoder/`). The agent's own `/` or `$` discovery finds
+  them — the harness invents no new discovery mechanism.
+- **Shared runtime data** (`.easy-coding/`): `config.yaml`, `state.json`, `tasks/`, `memory/`,
+  `spec/`, and the project knowledge assets (SOUL/RULES/ABSTRACT/TEST_STRATEGY/CHANGELOG).
+  Skills and hooks read and write these.
+
+The CLI installs the platform-native files. Agent skills do all the thinking (project
+analysis, workflow operation). The CLI never analyzes the project.
+
+## `.easy-coding/` runtime layout
+
+```
+.easy-coding/
+  config.yaml        shared project config (in git)
+  state.json         personal workflow state (NOT in git)
+  SOUL.md            project identity + dialogue standards
+  RULES.md           coding rules (per-language sections)
+  ABSTRACT.md        architecture cognition
+  TEST_STRATEGY.md   project-level test baseline
+  CHANGELOG.md       architecture change log (follows ABSTRACT)
+  tasks/             one folder per task
+    project-init/    created by the CLI; ec-init completes it
+    {MM-DD-name}/    task.json · dev-spec.md · test-strategy.md · execution.jsonl
+  memory/
+    short/           sliding-window short memories (max 10, keep 5)
+    long/            MEMORY.md index · BUSINESS.md · TECHNICAL.md
+  spec/
+    main/            confirmed designs from ec-brainstorming
+    dev/             dev-spec candidates (default out of normal commits)
+```
+
+## Workflow state machine
+
+8 stages + 2 terminals, owned by ec-workflow:
+`INIT → ANALYSIS → WAITING_CONFIRM → IMPLEMENT → REVIEW → VERIFICATION → MEMORY_SHORT →
+MEMORY_LONG → COMPLETE`, plus `CLOSED` (user abort, no memory flow). WAITING_CONFIRM and
+VERIFICATION are hard gates. The current stage persists in `state.json`; hooks inject it as a
+breadcrumb so every reply can render the status line.
+
+## Task persistence
+
+Each task is a folder. `task.json` is metadata; `dev-spec.md` is the human-readable plan;
+`execution.jsonl` is an append-only plan-and-log (one `plan` record, then `dispatch`/`result`
+/`review`/`verify`/`handoff` records). Because plan and log live on disk, not in an agent's
+context window, a task survives session end and agent switches with zero information loss.
+
+## Memory system
+
+Short memory: one schema-v2 file per task, sliding window (max 10, keep 5). Long memory:
+three files (index + business + technical), distilled from out-of-window short memories with
+explicit conflict resolution. ABSTRACT.md is backfilled/updated when memory distillation
+detects an architecture change.
+
+## Project knowledge — four layers
+
+Identity (SOUL, rarely changes) · Constraints (RULES, stable) · Cognition (ABSTRACT, updated
+on architecture change) · Memory (short + long, updated every task). ec-workflow always reads
+SOUL + RULES + recent short memory; ec-analysis loads ABSTRACT and matching long memory on
+demand.
+
+## Dead-drop coordination
+
+`.easy-coding/` is a dead drop. Agent A writes results and leaves; agent B reads them and
+continues. All platform-agnostic artifacts (dev-spec, execution.jsonl, task.json, memory)
+make cross-agent handoff lossless. `state.json` records `last_agent` so a new agent knows a
+task was handed off rather than self-interrupted.

package/templates/common/bundled-skills/ec-meta/references/platform-files/README.md

@@ -0,0 +1,52 @@
+# Platform Files
+
+What lives in each platform directory and how the three platforms differ.
+
+## Directory map
+
+| | Claude Code | Codex | Qoder |
+|---|---|---|---|
+| Skills dir | `.claude/skills/` | `.agents/skills/` | `.qoder/skills/` |
+| Skill trigger | `/` | `$` | `/` |
+| Hooks dir | `.claude/hooks/` | `.codex/hooks/` | `.qoder/hooks/` |
+| Hook config | `.claude/settings.json` | `.codex/hooks.json` | `.qoder/settings.json` |
+| Main constraint | `CLAUDE.md` | `AGENTS.md` | `AGENTS.md` |
+| Sub-agent defs | `.claude/agents/*.md` | `.codex/agents/*.toml` | `.qoder/agents/*.md` |
+| CN variant | — | — | `.qodercn/` |
+
+Each skill is installed as `{skills-dir}/ec-{name}/SKILL.md`. The 12 skills are
+platform-agnostic — one template, resolved per platform at write time. The agent's native
+discovery surfaces them under `/ec-` or `$ec-`.
+
+## Skills and agents
+
+- **Skills** (`SKILL.md`): frontmatter `name` + `description`, then markdown instructions.
+  They carry the workflow logic. Platform differences — the skill trigger (`/` vs `$`), the
+  state-file path, and the sub-agent spawn instruction — are filled in from a small
+  placeholder map at install time, so one source template serves all three platforms.
+- **Sub-agent definitions**: role baselines for the implementer / reviewer / verifier
+  sub-agents. Claude/Qoder use markdown frontmatter; Codex uses TOML with
+  `developer_instructions`. At runtime the main agent still builds a concrete task card per
+  unit — these files are the standing role contract, not the per-unit card.
+
+## Hooks and settings
+
+Three Python hooks, shared verbatim across platforms (only the JSON wrapper differs):
+
+- `session-start.py` — ensures `state.json` exists; injects resume / init-required / handoff
+  breadcrumbs. Idempotent.
+- `inject-workflow-state.py` — injects the `workflow-state` and `current-task` breadcrumbs so
+  the status line can render.
+- `inject-subagent-context.py` — injects the sub-agent guard before an Agent tool call.
+
+Wrapper differences:
+
+- **Claude Code**: full event set — `SessionStart`, `UserPromptSubmit`, `PreToolUse(Agent)`.
+- **Codex**: no `SessionStart` and no Agent tool. `session-start.py` and
+  `inject-workflow-state.py` both hang off `UserPromptSubmit`; `inject-subagent-context.py`
+  is skipped. Codex hooks also require user-level enablement (`[features] hooks = true`).
+- **Qoder**: like Claude Code (has Agent tool + Stop) but uses `UserPromptSubmit` for state
+  injection. The `.qoder/settings.json` wrapper nests an extra `hooks` array.
+
+`session-start.py` is designed to be idempotent precisely because Codex/Qoder fire it on
+`UserPromptSubmit` rather than a real session-start event — repeated calls are safe.

package/templates/common/skills/ec-analysis/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: ec-analysis
+description: ANALYSIS-stage skill. Use when ec-workflow enters ANALYSIS. Produces the dev-spec (narrative plan), the execution plan (execution.jsonl), and the test strategy, then ends in WAITING_CONFIRM. Grounds every conclusion in real code, never restates the requirement.
+---
+
+# ec-analysis — turn a requirement into a confirmable plan
+
+ec-workflow dispatches you when a task enters ANALYSIS. You read the codebase, decide *how*
+to implement, and present a plan the user can confirm. You do not write business code.
+
+Communicate with the user in the user's language.
+
+## Inputs to load (in this order)
+
+1. `.easy-coding/SOUL.md`, `.easy-coding/RULES.md` (always).
+2. `.easy-coding/ABSTRACT.md` — only when the task touches architecture, crosses modules, or
+   adds a feature. A single-file bugfix or doc edit can skip it.
+3. Long memory: read `MEMORY.md` index, then only the `BUSINESS.md`/`TECHNICAL.md` entries
+   whose domain/tags/related_files match this task. No unbounded full scans.
+4. The actual source files the task touches — read them. A plan that does not cite real
+   files, classes, and call paths is rejected by your own self-check below.
+
+## Cross-repo handling
+
+If the task spans repositories: declare them in the dev-spec (trigger repo + involved repos
+by **name**, never local paths). For each involved repo, read its ABSTRACT to understand the
+interface. Cache any local path the user provides only in `state.json.repo_paths`. If a repo
+name cannot be located locally, ask the user for the path before proceeding.
+
+## Required output: the analysis document
+
+Write `.easy-coding/tasks/{task-id}/dev-spec.md` covering these mandatory sections. Omit a
+conditional section entirely if it does not apply — never pad to fill the template.
+
+```
+### Project mode        {startup | iterative}
+### Task type           {feature | bugfix | refactor | perf | frontend}
+### Requirement parse    goal / input / output / boundary (what it explicitly will NOT do)
+### Current state        real code, files, call paths, existing interfaces — with evidence
+### Conflicts            requirement vs RULES / vs ABSTRACT / vs current code / vs dev-spec
+### Decisions needed     anything affecting tech route, interface, or scope; else "none"
+### Impact               modules / core classes / DB change y-n / interface change y-n / related memories
+### Change scope         table below — FILE ENCODING column is mandatory
+### Change plan          one-line overall approach / backend / frontend / migration / risk
+### Implementation units the unit table below — drives execution.jsonl
+### Test strategy        the testability table + test points below
+### Risks                concrete failure points
+```
+
+**Change-scope table** (the encoding column prevents corrupting project files):
+
+| File | Change type | Encoding | Core change |
+|---|---|---|---|
+| `path` | new/modify/delete | "project encoding X, evidence: ..." or "keep original X" | ... |
+
+Encoding rule: modifying an existing file must keep its original encoding; new files declare
+the project encoding with evidence; if evidence conflicts or is unknown, mark "needs user
+confirmation". The user may override any encoding cell before confirming.
+
+## Implementation units → execution.jsonl
+
+Decompose the work into units, then append ONE `plan` record to
+`.easy-coding/tasks/{task-id}/execution.jsonl`:
+
+```json
+{"type":"plan","strategy":"parallel","units":[{"id":"U1","title":"...","type":"backend","files":["..."],"depends_on":[],"rules_sections":["naming","error-handling"],"abstract_modules":["user-service"]}],"parallel_groups":[{"level":0,"units":["U1","U2"]},{"level":1,"units":["U3"]}]}
+```
+
+Strategy selection (drives whether ec-implementing spawns sub-agents):
+- `single` — one unit. Main agent implements directly.
+- `sequential` — multiple units with a hard dependency chain.
+- `parallel` — two or more independent units. ec-implementing MUST use sub-agents.
+
+Each unit carries `rules_sections` and `abstract_modules` so ec-implementing can build a
+precise task card without the sub-agent re-reading the whole repo. `depends_on` sets the
+parallel-group levels.
+
+## Test strategy (presented with the plan, saved for VERIFICATION)
+
+**1. Testability table** — classify every change:
+
+| Change | Kind | Verdict | Reason |
+|---|---|---|---|
+| calculateDiscount | pure function | [must-test] | clear input/output |
+| useCartStore | state hook | [should-test] | transitions assertable |
+| SearchPanel | UI interaction | [depends] | on project test infra |
+| Header.module.css | pure style | [no-test] | no behavior |
+
+Rules: pure functions/utils → [must-test]; state hooks/service layer → [should-test]; API
+param building → [should-test]; UI interaction → [depends]; pure style/config → [no-test].
+Bug fixes always require a regression test.
+
+**2. Test points** — for each [must-test]/[should-test] item, concrete cases, plus the
+owning unit and the verify command.
+
+**3. No-test reasons** — one line each; the user can overturn any verdict at confirmation.
+
+Write the confirmed strategy to `.easy-coding/tasks/{task-id}/test-strategy.md` (the
+VERIFICATION baseline).
+
+## Self-check before presenting (reject your own draft if any fails)
+
+- Does every "Current state" claim cite a real file/class/line?
+- Is there a concrete change plan, not just "loaded these files"?
+- Did you omit conditional sections that do not apply?
+- Are units, dependencies, and strategy internally consistent with the change scope?
+
+## End state
+
+Present the full plan, then set stage to WAITING_CONFIRM and hand control back to
+ec-workflow. On a revision request, re-output the COMPLETE revised plan (not just a diff)
+and re-enter WAITING_CONFIRM; overwrite the `plan` record in execution.jsonl with the new
+strategy. Never start implementing from this skill.

package/templates/common/skills/ec-brainstorming/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: ec-brainstorming
+description: Pre-implementation design skill. Use when the user runs {{skill_trigger}}ec-brainstorming, asks to brainstorm/explore/shape a design, or when a startup project needs its first direction after ec-init. Turns an idea into a confirmed design doc through one-question-at-a-time dialogue. Hard gate — no implementation before the user approves the design.
+---
+
+# ec-brainstorming — ideas into confirmed designs
+
+Adapted from the Superpowers brainstorming method for the Easy Coding context. You turn a
+raw idea into a validated design through natural, collaborative, one-question-at-a-time
+dialogue, then hand a confirmed design doc to ec-workflow. You never write implementation
+code here.
+
+Communicate with the user in the user's language.
+
+## Hard gate
+
+```
+<HARD-GATE>
+Do NOT invoke any implementation skill, write any code, or scaffold anything until you have
+presented a design AND the user has approved it. This applies to EVERY idea regardless of
+perceived simplicity.
+</HARD-GATE>
+```
+
+### Anti-pattern: "this is too simple to need a design"
+
+Every idea goes through this. A todo list, a one-function utility, a config change — all of
+them. "Simple" work is exactly where unexamined assumptions waste the most effort. The design
+can be three sentences for a truly simple idea, but you MUST present it and get approval.
+
+## Flow
+
+1. **Explore context.** Read `.easy-coding/SOUL.md`, `.easy-coding/RULES.md`, and (for
+   iterative projects) `.easy-coding/ABSTRACT.md` to understand positioning and existing
+   architecture. Check recent files and commits.
+2. **Scope check first.** If the idea describes multiple independent subsystems (e.g. "a
+   platform with chat, billing, and analytics"), flag it immediately. Help the user
+   decompose into independent pieces — what they are, how they relate, what order to build —
+   then brainstorm only the first piece through the normal flow. Do not spend questions
+   refining a thing that must be split first.
+3. **Clarify, one question at a time.** Multiple-choice preferred to lower the user's load;
+   open questions are fine but never stacked. Focus on purpose, constraints, success
+   criteria, boundaries. One question per message.
+4. **Propose 2-3 approaches** with tradeoffs and complexity. Lead with your recommendation
+   and the reason for it.
+5. **Present the design in sections** scaled to complexity (a few sentences if simple, more
+   if nuanced). Confirm each section before moving on. Cover: goal, core design, interfaces,
+   data flow, error handling, boundary conditions.
+6. **Design self-review** (fix inline, no second pass needed):
+   - Placeholder scan — any TBD/TODO/incomplete sections?
+   - Internal consistency — do sections contradict each other?
+   - Scope check — focused enough for one implementation cycle, or needs decomposition?
+   - Ambiguity — could any requirement be read two ways? Pick one, make it explicit.
+   - RULES check — does anything violate `.easy-coding/RULES.md`?
+   - YAGNI — strip features that do not serve the stated goal.
+7. **User review gate.** Save the design to `.easy-coding/spec/{topic}-design.md`, then ask
+   the user to review the written doc before proceeding. Make requested changes and re-run
+   the self-review. Proceed only on explicit approval.
+
+## Relationship to ec-workflow
+
+The confirmed design doc is an INPUT to ec-workflow's ANALYSIS stage — it does not replace
+ANALYSIS (brainstorming is design; ANALYSIS is the implementation plan). After approval, tell
+the user to run `{{skill_trigger}}ec-workflow` to start building.
+
+## Boundaries
+
+- Write no implementation code, scaffold nothing, take no implementation action.
+- Do not call other ec-* skills or touch state.json / the state machine.
+- One question per message — never overwhelm.

package/templates/common/skills/ec-git/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: ec-git
+description: Git discipline skill for Easy Coding projects. Use when the task involves git pull/merge/rebase/commit/push/PR. Enforces the .easy-coding commit policy, warns on committing in-progress tasks, handles .easy-coding conflicts with user-confirmed semantic merge, and covers cross-repo commit sets. Does not touch the workflow state machine.
+---
+
+# ec-git — git discipline
+
+Activate for any git operation inside an Easy Coding project: pull, merge, rebase, commit,
+push, PR. You manage git hygiene only — you never change `state.json` stage fields or trigger
+stage transitions.
+
+Communicate with the user in the user's language.
+
+## Commit policy for .easy-coding/
+
+| Path | In commit set? | Why |
+|---|---|---|
+| `state.json` | **never** | personal runtime state, differs per developer |
+| `config.yaml` | yes | shared team config |
+| `tasks/*/task.json` `dev-spec.md` `execution.jsonl` `test-strategy.md` | yes | per-task folders, no merge conflicts; team-readable decision record |
+| `SOUL.md` `RULES.md` `ABSTRACT.md` `TEST_STRATEGY.md` `CHANGELOG.md` | yes | shared project knowledge |
+| `memory/` | yes | shared knowledge sinks |
+| `spec/` | yes | spec store |
+| `spec/dev/` | only if user explicitly asks | dev-spec candidates for the *current* requirement, default out of commit |
+
+`.easy-coding/` changes are part of the commit set by default (treated like code changes),
+with `state.json` always excluded. The CLI already added `state.json` to `.gitignore`.
+
+## Rules
+
+1. **In-progress warning.** If the commit touches a task folder whose status is not COMPLETE,
+   warn: "Task «X» is not finished — commit the intermediate state?" and wait.
+2. **Conflict handling for `.easy-coding/`** (mostly `memory/`): first explain the conflict
+   details to the user, get confirmation, then do an inductive semantic merge — never blindly
+   pick ours/theirs. This requirement applies only to conflicts inside `.easy-coding/`.
+3. **Cross-repo commit sets.** When a task spans repos (per the dev-spec / `state.json`
+   `repo_paths`), the commit/push covers every involved repo. Read `repo_paths` to locate
+   each one, check changes, and commit/push them as one coherent change set — do not leave a
+   sub-repo behind.
+4. **No false success.** Never claim a commit or push succeeded without reading the command
+   output. A failed push reported as success is a serious error.
+
+## Boundaries
+
+- Do not touch `state.json` stage fields or run stage transitions — git only.
+- Do not commit `state.json`.
+- Do not commit `spec/dev/` unless the user explicitly asks.

package/templates/common/skills/ec-implementing/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: ec-implementing
+description: IMPLEMENT-stage skill. Use when ec-workflow enters IMPLEMENT with a confirmed plan. Executes execution.jsonl units under strict file-scope control, enforces RULES compliance and encoding preservation, writes tests per strategy, and dispatches sub-agents for parallel work.
+---
+
+# ec-implementing — execute the confirmed plan
+
+ec-workflow dispatches you when a confirmed task enters IMPLEMENT. You turn the plan into
+code without re-opening decisions. Inputs: `dev-spec.md` (confirmed), `execution.jsonl`
+(plan record), `.easy-coding/RULES.md`, `.easy-coding/ABSTRACT.md`, `test-strategy.md`.
+
+Communicate with the user in the user's language.
+
+## Core discipline (non-negotiable)
+
+1. **Scope is law.** Only modify files listed in the dev-spec change-scope table. If you
+   discover you need another file, STOP and return to ANALYSIS to amend the plan. No
+   "while I'm here" edits.
+2. **RULES compliance.** Before each write, re-check the RULES sections relevant to that
+   file (use the unit's `rules_sections`). Violation → fix before writing, not after.
+3. **Encoding preservation.** Modifying an existing file keeps its original encoding
+   (UTF-8 / GBK / ...); never silently convert. New files follow the encoding declared in
+   the dev-spec.
+4. **Comment language.** Follow the project's existing comment language as recorded in RULES.
+   Do not decide it here.
+5. **Step-wise reporting.** After each file/module, emit a one-line progress note (file +
+   what changed). Do not batch everything into one final dump.
+6. **Self-audit gate.** When the unit is done, audit: are all edits within scope? any
+   undeclared dependency change? any leftover TODO/FIXME you introduced? Report failures;
+   never skip silently.
+7. **Tests (soft rule).** Write tests for [must-test]/[should-test] items per
+   test-strategy.md. Soft means: no project test infra → not forced; infra exists → required.
+
+## Sub-agent dispatch (mandatory when strategy = parallel)
+
+Read the `plan` record. Then:
+
+- `single` → main agent implements directly, no sub-agents.
+- `sequential` → main agent implements units one by one in dependency order.
+- `parallel` → you MUST use sub-agents, one per unit, batched by `parallel_groups` level.
+
+Parallel dispatch loop:
+1. Sort `parallel_groups` by level.
+2. Read RULES.md and ABSTRACT.md once.
+3. For each unit in the current level, build a **task card** (next section) and dispatch.
+4. Dispatch all units in the level concurrently via {{sub_agent_dispatch}}.
+   Platform spawn rule: {{platform_spawn_instruction}}
+5. Append a `dispatch` record per unit, then a `result` record per returned unit, to
+   execution.jsonl.
+6. After the level returns: check for file conflicts (two units touched the same file),
+   collect `issues` and `needs_attention`. Resolve conflicts before advancing.
+7. Advance to the next level. After all levels, summarize.
+
+## Task card — the sub-agent contract
+
+The main agent builds the card; the sub-agent never hunts for context itself. Card template:
+
+```
+# Task Card
+## Identity
+You are an Easy Coding implementation sub-agent. Complete the assigned unit and return
+structured results. Reply content IS the return value, not a message to a human.
+## Hard constraints
+- Do not call any Skill tool.
+- Do not read .claude/skills, .agents/skills, or any .easy-coding/ file.
+- Modify only files in "Editable scope".
+- Make no stage-transition decisions.
+## Task           {unit description extracted from dev-spec}
+## Editable scope {unit.files}
+## Coding rules   {RULES.md sections selected by unit.rules_sections}
+## Architecture   {ABSTRACT.md sections selected by unit.abstract_modules}
+## Output format
+Return: changed_files[], summary (one line), issues[], needs_attention[].
+```
+
+This enforces the three-layer escape guard: task boundary (only its files), stage boundary
+(no knowledge of the state machine), output boundary (structured return only). The sub-agent
+gets pre-digested context — it does not open RULES or ABSTRACT itself.
+
+## On unit failure or conflict
+
+A returned `issues` entry or a detected file conflict is handled by the MAIN agent. If a fix
+is needed, re-dispatch the unit with a `dispatch` record carrying a `reason` field. Do not
+let sub-agents re-dispatch each other.
+
+## End state
+
+All units done and self-audited → hand back to ec-workflow to advance to REVIEW. If you
+hit something that invalidates the plan, return to ANALYSIS instead of improvising.

package/templates/common/skills/ec-init/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: ec-init
+description: One-time project knowledge initialization after the easy-coding CLI install. Use when the user runs {{skill_trigger}}ec-init or hook context shows [easy-coding:init-required]. Idempotent. Detects startup vs iterative projects automatically and generates SOUL, RULES, ABSTRACT, and TEST_STRATEGY.
+---
+
+# ec-init — project knowledge initialization
+
+The CLI is a dumb file mover; you are the smart half. You analyze the project and produce
+the knowledge assets every later stage depends on. This runs once per project; re-runs are
+safe.
+
+Communicate with the user in the user's language.
+
+## Entry guard (idempotency — run first)
+
+1. Read `.easy-coding/tasks/project-init/task.json`.
+   - File missing → the CLI never ran. Tell the user to run `easy-coding init` first. Stop.
+   - `status == "COMPLETE"` → already initialized. Show a short summary (project mode,
+     generated files, init date from `init_log`) and exit without changing anything.
+   - `status == "PENDING"` → proceed.
+2. Repeated calls must never duplicate files or corrupt existing ones.
+
+## Project mode detection (automatic — never ask the user)
+
+Scan the project root, excluding `.easy-coding/`, platform dirs (`.claude/`, `.agents/`,
+`.codex/`, `.qoder/`), lockfiles, and pure config skeletons (package.json, tsconfig,
+linter configs, CI yaml).
+
+- Substantive source files exist (.ts/.js/.java/.py/.go/.rs/... containing real logic)
+  → **iterative** (existing project).
+- Empty, or config skeleton only → **startup** (new project).
+
+Record the verdict in `config.yaml` under `project.mode` and in `init_log`.
+
+## Iterative project flow
+
+After each step append `{step, summary, timestamp}` to `init_log` in task.json — a later
+agent must be able to see what was generated and on what evidence.
+
+1. **SOUL.md — project identity.** Analyze README, package metadata, and code purpose. Write:
+   - What this project is (2-3 sentences, concrete, no marketing fluff)
+   - Dialogue standards (language to use with the user, tone, verbosity expectations)
+   - Hard prohibitions (e.g. never commit secrets, never edit generated directories)
+   Keep it under ~40 lines; SOUL is loaded on every task.
+2. **RULES.md — coding rules grounded in evidence,** not generic best practice. Detect:
+   - Languages and versions (from configs and sources)
+   - Naming conventions actually in use (scan representative files)
+   - Comment language: if more than 70% of existing comments are Chinese, the rule is
+     "comments in Chinese"; same logic for English; mixed → follow each file's dominant language
+   - Error handling style, import ordering, formatter/linter in use (read their configs)
+   Structure as one section per language plus a General section. Every rule must be
+   mechanically checkable — "be clean" is not a rule; "exported functions carry explicit
+   return types" is.
+3. **ABSTRACT.md — architecture cognition.** Scan directory structure and entrypoints. Write:
+   modules and their responsibilities, core data flow, tech stack with versions, external
+   dependencies and services, build and run commands. Use a named section per module —
+   later stages extract sections by name (the `abstract_modules` field in execution plans).
+4. **TEST_STRATEGY.md — project test baseline:** detected framework, test command, where
+   tests live, naming conventions, coverage expectations, which classes of code this project
+   tests vs skips. Also fill `config.yaml` `test.framework` and `test.command` with commands
+   you verified exist (read package.json scripts or equivalent — do not guess).
+5. **Memory init** — ensure `.easy-coding/memory/short/` and `memory/long/` exist with the
+   three long files (MEMORY.md, BUSINESS.md, TECHNICAL.md). Never write fake entries.
+6. **Mark complete** — task.json `status:"COMPLETE"` plus a final `init_log` entry. Tell the
+   user initialization is done and daily work goes through `{{skill_trigger}}ec-workflow`.
+
+## Startup project flow
+
+1. **Lightweight interview** — 3-5 questions, strictly one at a time, multiple-choice
+   preferred: project name and positioning, primary language and framework, test framework
+   preference, special coding conventions (optional), comment language (optional).
+2. Generate from the answers:
+   - SOUL.md (identity from answers, dialogue standards, prohibitions)
+   - RULES.md (baseline rules for the chosen language; mark sections "refine as code grows")
+   - TEST_STRATEGY.md (skeleton for the chosen framework)
+3. **Skip ABSTRACT.md** — no architecture exists yet. Note in init_log:
+   "ABSTRACT pending; ec-memory backfills after the first substantive task." (ec-memory
+   detects the missing file during MEMORY_LONG and generates it from the then-current code.)
+4. Memory init and completion marking, same as iterative steps 5-6.
+5. Recommend: design first with `{{skill_trigger}}ec-brainstorming`, then build via
+   `{{skill_trigger}}ec-workflow`.
+
+## Quality bar for generated files
+
+- Every claim grounded in observed evidence — file paths and configs you actually read.
+  No filler like "follow best practices".
+- SOUL stays short. RULES and ABSTRACT run as long as the evidence supports, in named
+  sections. TEST_STRATEGY must be concrete enough that ec-verification can derive runnable
+  commands from it.
+
+## Boundaries
+
+- Never modify business source code, dependencies, or git state.
+- Never create workflow tasks or touch `current_task` / `current_stage` in state.json.
+- Never regenerate knowledge files for a COMPLETE project-init — the user edits them
+  manually or asks ec-meta for guided customization.

package/templates/common/skills/ec-memory/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: ec-memory
+description: MEMORY_SHORT and MEMORY_LONG stage skill — part of the archive flow, triggered only after user acceptance. Use when ec-workflow enters the memory stages. Writes schema-v2 short memory with a sliding window, distills long memory into BUSINESS/TECHNICAL with conflict resolution, and backfills ABSTRACT on architecture changes.
+---
+
+# ec-memory — archive what was learned
+
+ec-workflow dispatches you during MEMORY_SHORT and MEMORY_LONG, which run only after the
+user accepts the task. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
+`verify` records are precise source material), the changed-files list, existing memory files.
+
+Communicate with the user in the user's language. Memory file content follows the project's
+recorded comment/doc language.
+
+## MEMORY_SHORT — write one short memory entry
+
+Create one file under `.easy-coding/memory/short/` with schema-v2 frontmatter:
+
+```yaml
+---
+id: SM-{YYYYMMDD}-{NN}
+date: {YYYY-MM-DD}
+task_type: {feature | bugfix | refactor | perf}
+domain: {business domain}
+tags: [tag1, tag2]
+related_files: [file1, file2]
+target_long: {business | technical | both | none}
+---
+{body: what was done, why this approach, key decisions. Pull facts from execution.jsonl
+result/verify records, not from a fuzzy memory of the conversation.}
+```
+
+If the task was cross-repo, record the repo names involved and the collaboration reason.
+
+**Sliding window:** keep at most 10 short memories. When the count exceeds 10, keep the
+latest 5; the rest become long-term distillation candidates (do not delete them here — the
+MEMORY_LONG retirement check decides their fate).
+
+## MEMORY_LONG — distill durable knowledge
+
+Three-file long memory:
+- `MEMORY.md` — index of all entries with status (active | deprecated | superseded | deleted).
+- `BUSINESS.md` — business rules, domain knowledge, product decisions.
+- `TECHNICAL.md` — architecture decisions, implementation patterns, gotchas.
+
+Distillation flow:
+1. Read the `target_long` of out-of-window short memories; route to business/technical.
+2. **Progressive loading** — read only the existing long entries matching this round's
+   domain/tags/related_files. No unbounded whole-repo memory scan.
+3. **Conflict resolution** by priority: current code > latest user confirmation > this
+   round's candidate > older long memory. On conflict, explain it before consolidating —
+   never silently pick a side.
+4. **Retirement check** (triggered when short memories >= 10): for older entries decide
+   delete (no value) / merge (semantic duplicate) / deprecate (was valid, now superseded).
+5. Update the `MEMORY.md` index to reflect every change.
+
+## ABSTRACT backfill / update
+
+While distilling technical memory, if you detect an architecture change — module added or
+removed, core flow changed, tech stack changed, or (startup projects) ABSTRACT.md does not
+exist yet — update `.easy-coding/ABSTRACT.md` and append a CHANGELOG.md entry (what changed,
+why). For startup projects this is where the first ABSTRACT gets generated from the now-real
+code.
+
+## Boundaries
+
+- Run only inside the archive flow. Memory for an unaccepted or closed task is dirty data.
+- Prefer merge/deprecate over destructive delete. Ask before destructive consolidation.
+- The main agent confirms and writes; a memory sub-agent may draft but not finalize.