coding-meta

name	coding-meta
description	Understand and customize the local Coding architecture inside a user project. Use when modifying .coding plus Claude Code hooks, settings, agents, skills, commands, selectable workflow templates, registry-backed spec refresh, cross-session memory (coding mem) generated by coding init, or AI-facing bundled skills (coding-session-insight, coding-spec-bootstrap) and bundled-skill auto-dispatch flow.

Coding Meta

This skill is for local Coding users who have already run coding init in a project. After reading it, an AI should understand the Coding architecture, operating model, and customization entry points inside that user project, then modify the generated .coding/ and platform directory files according to the user's request.

Coding v0.6 adds two architectural surfaces on top of the pre-v0.6 workflow / persistence / platform model. First, cross-session memory: coding mem list | search | context | extract | projects reads raw Claude Code JSONL already on disk, slices by --phase brainstorm|implement|all, and never uploads anything. Second, a dual-package npm release: @limenglin/coding (CLI) and @limenglin/coding-core (SDK with /task, /mem, /testing subpaths) ship in lockstep on one version. Treat these as first-class customization surfaces alongside the Claude Code integration files.

The default operating scope is local files in the user project:

• .coding/: workflow, config, tasks, spec, workspace, scripts, and runtime state.
• Platform directory: .claude/ (settings, hooks, agents, skills, commands).
• Raw conversation logs queryable via coding mem: ~/.claude/projects/.

Do not assume the user has the Coding source repository. Do not default to modifying the global npm install directory or node_modules — both @limenglin/coding and @limenglin/coding-core ship as published packages sharing one version and one git tag per release.

How To Use

1. Read references/local-architecture/overview.md first to establish the local Coding system model.
2. If the request involves platform integration files, read references/platform-files/platform-map.md and the relevant platform file notes.
3. If the user wants to change behavior, read references/customize-local/overview.md, then open the specific customization topic.
4. Before editing, read the actual files in the user project and treat local content as authoritative.

References

Local Architecture

• references/local-architecture/overview.md: The layered local Coding architecture (workflow / persistence / platform) and customization principles.
• references/local-architecture/generated-files.md: Files generated by coding init and their customization boundaries.
• references/local-architecture/workflow.md: Phases, routing, workflow-state blocks, and selectable workflow templates (native, tdd, marketplace) in .coding/workflow.md.
• references/local-architecture/task-system.md: Task directories, active task, JSONL context, parent/child task trees, and task runtime.
• references/local-architecture/spec-system.md: How .coding/spec/ is organized, injected, and refreshed from a registry.spec source.
• references/local-architecture/workspace-memory.md: .coding/workspace/ journals plus coding mem cross-session recall and the @limenglin/coding-core/mem SDK.
• references/local-architecture/context-injection.md: Hooks and sub-agent preludes.
• references/local-architecture/bundled-skills.md: Auto-dispatched bundled skills (coding-meta, coding-spec-bootstrap, coding-session-insight) and how getBundledSkillTemplates() ships them to every platform skill root.

Platform Files

• references/platform-files/overview.md: How shared .coding/ files relate to the .claude/ directory and how Claude Code integrates via hooks.
• references/platform-files/platform-map.md: The .claude/ directory layout for skills, agents, hooks, and commands.
• references/platform-files/hooks-and-settings.md: How .claude/settings.json and hooks connect to Coding.
• references/platform-files/agents.md: The coding-research / coding-implement / coding-check sub-agent files.
• references/platform-files/skills-and-commands.md: Differences between skills and commands, plus how to change them.

Local Customization

• references/customize-local/overview.md: Choose the right local customization entry point for the user's request.
• references/customize-local/change-workflow.md: Change phases, routing, next actions, workflow-state, and the selected workflow template.
• references/customize-local/change-task-lifecycle.md: Change task creation, status, archive behavior, parent/child links, archive slug collision handling, and lifecycle hooks.
• references/customize-local/change-context-loading.md: Change how tasks, specs, journals, hook context, and coding mem recall are loaded.
• references/customize-local/change-hooks.md: Change Claude Code hooks, settings, task lifecycle hooks (hooks.after_*), and shell session bridges.
• references/customize-local/change-agents.md: Change research, implement, and check agent behavior.
• references/customize-local/change-skills-or-commands.md: Add or modify local skills and commands; covers upstream bundled-skill auto-dispatch.
• references/customize-local/change-spec-structure.md: Adjust the project spec structure under .coding/spec/, including registry-backed sources.
• references/customize-local/add-project-local-conventions.md: Put team rules into project-local specs or local skills.

Current Rules

• .coding/workflow.md is the local workflow source of truth; its initial content was selected from a workflow template (built-in native, tdd, or a marketplace template) at coding init time and can be re-selected via coding workflow --template <id>.
• .coding/config.yaml is the project-level Coding configuration entry point. It hosts task lifecycle hooks (hooks.after_create / after_start / after_finish / after_archive), journal shape (session_commit_message / max_journal_lines / session_auto_commit), and the spec registry block (registry.spec.source + registry.spec.template).
• .coding/spec/ stores the user's project-specific coding conventions and design constraints. When registry.spec is set, files are refreshed by coding update; local edits surface as "modified by user" conflicts in .coding/.template-hashes.json.
• .coding/tasks/ stores task PRDs, design notes, implement plans, research files, and JSONL context. Tasks form parent/child trees: task.py create --parent <slug>, task.py add-subtask <parent> <child>, task.py remove-subtask <parent> <child>, and task.py list-context <task>. task.py create rejects a slug already present in .coding/tasks/archive/**.
• .coding/workspace/ stores deliberately written developer journals. Raw cross-session dialogue is not stored here — it lives on disk under ~/.claude/projects/ and is recovered via coding mem search|extract|context. The bundled coding-session-insight skill teaches when to reach for mem.
• Bundled multi-file skills (coding-meta, coding-spec-bootstrap, coding-session-insight) are auto-dispatched to the platform skill root by getBundledSkillTemplates() in packages/cli/src/templates/common/index.ts. Dropping a new directory under packages/cli/src/templates/common/bundled-skills/ (upstream) ships it on the next .

Do Not

• Do not treat Coding upstream source code as the default target for local customization.
• Do not modify the global npm install directory or node_modules/@limenglin/coding or node_modules/@limenglin/coding-core to implement project needs; both packages ship in lockstep.
• Do not overwrite user-modified local files with default templates; check .coding/.template-hashes.json first and prefer .new sidecar files over destructive overwrites.
• Do not put team-private project rules into any public bundled skill (coding-meta, coding-spec-bootstrap, coding-session-insight); put project rules in .coding/spec/, a project-local skill, the current task, or the workspace journal — coding update will overwrite anything inside a bundled skill directory.
• Do not describe removed or never-shipped mechanisms as current Coding behavior; cross-check against the local .coding/config.yaml and the installed CLI's coding --help before claiming a knob exists.