ecc_infisense 0.0.1

package/skills/component-templates/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: component-templates
+description: Templates and guidelines for creating ECC InfiSense components (agent, skill, command, rule).
+category: plugin
+---
+
+# Component Templates
+
+创建 ECC InfiSense 组件的模板和界定规范。
+
+## 四类组件的界定
+
+| 组件 | 一句话 | 职责 | 建议行数 |
+|------|--------|------|----------|
+| rule | 红线 | 策略/约束："什么能做、什么不能做" | ~30-50 |
+| command | 入口 | 调度/交互："做什么事"，分派给 agent | ~80-200 |
+| agent | 干活的 | 执行者："怎么做"，分步执行，引用 skill | ~200-400 |
+| skill | 字典 | 知识库："知道什么"，被 agent 引用 | ~100-600 |
+
+### 判断流程
+
+```
+约束/策略/禁止项？        → rule
+用户触发的入口？          → command
+分步执行流程？            → agent
+参考知识/模式/清单？      → skill
+```
+
+### 组件间引用关系
+
+```
+command ──(调度)──→ agent ──(引用知识)──→ skill
+                     │
+                     └──(遵守)──→ rule（始终加载）
+```
+
+---
+
+## Rule 模板
+
+文件：`rules/{common,cpp}/<TOPIC>.md`
+
+```markdown
+# <RULE_TITLE>
+
+For detailed patterns and examples, use `/<RELATED_COMMAND>`.
+
+## <SECTION_1_TITLE>
+
+| <COL_1> | <COL_2> |
+|---------|---------|
+| <ITEM>  | <GUIDELINE> |
+| <ITEM>  | <GUIDELINE> |
+
+## <SECTION_2_TITLE>
+
+- <CONSTRAINT_1>
+- <CONSTRAINT_2>
+- <CONSTRAINT_3>
+```
+
+规范：
+- 可选 frontmatter：仅 `paths`（文件匹配 glob）
+- 建议 30-50 行，纯表格 + 条目，无代码
+- 语气命令式（"必须"、"禁止"、"优先"）
+- 超过 60 行建议拆到 skill
+
+反模式：含代码示例、含执行步骤
+
+参考：`rules/common/testing.md`、`rules/cpp/security.md`
+
+---
+
+## Command 模板
+
+文件：`commands/infi-<NAME>.md`
+
+```markdown
+---
+description: <ONE_LINE_DESCRIPTION>
+category: <plugin|cpp>
+---
+
+# <COMMAND_TITLE>
+
+<PURPOSE_STATEMENT>
+
+## Usage
+
+<INVOCATION_AND_ARGUMENTS>
+
+## Workflow
+
+### Step 1: <PHASE_NAME>
+
+<WHAT_HAPPENS> (2-3 sentences).
+Delegate to `<AGENT_NAME>` agent.
+
+### Step 2: <PHASE_NAME>
+
+<WHAT_HAPPENS>.
+
+## Cross-References
+
+- Agent: `<AGENT_NAME>` — <RESPONSIBILITY>
+- Skill: `<SKILL_NAME>` — <KNOWLEDGE_PROVIDED>
+- Related: `/infi-<OTHER>` — <WHEN_TO_USE_INSTEAD>
+```
+
+规范：
+- Frontmatter 必填 `description`（一句话）、`category`（`plugin` 或 `cpp`）
+- 建议 80-200 行，只做调度和用户交互
+- 不含具体执行代码，只描述"做什么"和"委派给谁"
+- 必须有 Cross-References
+
+反模式：含 50+ 行执行逻辑、含 API 参考表、无 Cross-References
+
+参考：`commands/infi-component-creator.md`、`commands/infi-release.md`
+
+---
+
+## Agent 模板
+
+文件：`agents/<NAME>.md`
+
+```markdown
+---
+name: <AGENT_NAME>
+description: <ONE_LINE_EXPERTISE>
+tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Edit
+  - Write
+model: <opus|sonnet|haiku>
+category: <plugin|cpp>
+---
+
+# <AGENT_TITLE>
+
+<PHILOSOPHY_STATEMENT> (2-3 lines).
+
+## Step 1: <PHASE>
+
+<DETAILED_INSTRUCTIONS>.
+Reference `<SKILL_NAME>` for <KNOWLEDGE_AREA>.
+
+## Step 2: <PHASE>
+
+<DETAILED_INSTRUCTIONS>.
+
+## Step N: <FINAL_PHASE>
+
+<DETAILED_INSTRUCTIONS>.
+
+## Output Format
+
+<OUTPUT_STRUCTURE_DESCRIPTION>
+
+## Checklist
+
+- [ ] <VERIFICATION_ITEM_1>
+- [ ] <VERIFICATION_ITEM_2>
+
+## Anti-Patterns
+
+- Don't <BAD_PRACTICE> because <REASON>
+```
+
+规范：
+- Frontmatter 必填 `name`、`description`、`tools`、`model`、`category`（`plugin` 或 `cpp`）
+- `model`：`opus`（复杂推理）、`sonnet`（通用）、`haiku`（快速）
+- 建议 200-400 行，分步执行 + 决策逻辑
+- 代码示例仅用于说明步骤，不做 API 参考
+- 必须有 Output Format 和 Checklist
+
+反模式：含 100+ 行 API 参考表、无 Step 结构、不引用任何 skill
+
+参考：`agents/component-designer.md`、`agents/release-executor.md`
+
+---
+
+## Skill 模板
+
+文件：`skills/<NAME>/SKILL.md`
+
+```markdown
+---
+name: <SKILL_NAME>
+description: <ONE_LINE_KNOWLEDGE_DOMAIN>
+category: <plugin|cpp>
+---
+
+# <SKILL_TITLE>
+
+<OVERVIEW> (2-3 lines).
+
+## <KNOWLEDGE_SECTION_1>
+
+| <COL_1> | <COL_2> | <COL_3> |
+|---------|---------|---------|
+| <API>   | <DESC>  | `<CODE_EXAMPLE>` |
+
+## <KNOWLEDGE_SECTION_2>
+
+```cpp
+// <CODE_EXAMPLE_DEMONSTRATING_PATTERN>
+```
+
+## Quick Reference
+
+- <KEY_POINT_1>
+- <KEY_POINT_2>
+
+## When to Use
+
+- <SCENARIO_A>
+- <SCENARIO_B>
+
+## When NOT to Use
+
+- <SCENARIO_X> → use `<OTHER_SKILL>` instead
+- <SCENARIO_Y> → use `<OTHER_SKILL>` instead
+```
+
+规范：
+- Frontmatter 必填 `name`、`description`、`category`（`plugin` 或 `cpp`），可选 `argument-hint`
+- 建议 100-600 行，API 参考 + 模式库 + 代码示例 + 清单
+- 不含 "Step 1 → Step 2 → Step 3" 执行流程
+- 可有 `references/` 子目录存放详细参考
+- 建议有 When to Use / When NOT to Use
+
+反模式：含执行流程步骤、少于 50 行、无代码示例或参考表
+
+参考：`skills/component-templates/SKILL.md`（本文件）、`skills/release-workflow/SKILL.md`
+
+---
+
+## 命名约定
+
+### 文件路径与格式
+
+| 组件 | 文件路径 | 示例 |
+|------|---------|------|
+| rule | `rules/{common,cpp}/<topic>.md` | `rules/cpp/security.md` |
+| command | `commands/infi-<name>.md` | `commands/infi-release.md` |
+| agent | `agents/<name>.md` | `agents/component-designer.md` |
+| skill | `skills/<name>/SKILL.md` | `skills/release-workflow/SKILL.md` |
+
+所有文件名小写，用连字符分隔。
+
+### 命名规则
+
+| 规则 | 说明 | 正例 | 反例 |
+|------|------|------|------|
+| 全小写 + 连字符 | 禁止下划线、大写、空格 | `build-fix` | `build_fix`、`BuildFix` |
+| command 前缀 | 必须以 `infi-` 开头 | `infi-release` | `release`、`my-release` |
+| agent 无前缀 | 不加 `infi-`，直接描述角色 | `component-designer` | `infi-component-designer` |
+| skill 无前缀 | 不加 `infi-`，直接描述知识域 | `release-workflow` | `infi-release` |
+| rule 无前缀 | 按主题命名 | `security` | `infi-security` |
+| 长度限制 | `<name>` 部分 2-30 字符 | `release-workflow` (16)、`component-designer` (18) | `a` (1)、超长名称 |
+| 无功能词冗余 | 避免含 `manager`、`handler`、`helper` | `build-fix` | `build-fix-handler` |
+
+### 命名推导
+
+从 feature description 推导名称的建议步骤：
+
+1. **提取关键词** — 从描述中取 1-3 个核心词（英文）
+2. **组合** — 用连字符拼接：`<领域>-<动作>` 或 `<领域>-<细分>`
+3. **去重** — 检查现有组件，避免与已有名称冲突或语义重叠
+4. **一致性** — 参考同领域已有组件的命名风格（如 `*-cc` 系列、`cpp-*` 系列）
+
+示例推导：
+
+| 功能描述 | 推导过程 | 最终名称 |
+|---------|---------|---------|
+| "管理插件组件生命周期" | 关键词：component, templates | command: `infi-component-creator`，skill: `component-templates` |
+| "版本发布和变更日志管理" | 关键词：release, workflow | command: `infi-release`，skill: `release-workflow` |
+| "动态扫描生成插件索引" | 关键词：plugin, inspector | command: `infi-ecc-helper`，agent: `plugin-inspector` |
+
+### 名称验证清单
+
+验证一个组件名称是否合规：
+
+- [ ] 仅包含小写字母、数字、连字符
+- [ ] 连字符不在首尾，无连续连字符
+- [ ] `<name>` 部分长度在 2-30 字符之间
+- [ ] command 以 `infi-` 开头，其他组件类型不以 `infi-` 开头
+- [ ] 不与现有组件名称冲突（同类型内唯一）
+- [ ] 不与其他类型组件产生歧义（如 skill 和 agent 不重名）
+- [ ] 无冗余功能词（`manager`、`handler`、`helper`、`util`）
+
+---
+
+## When to Use
+
+- 创建新的 agent、skill、command 或 rule 时
+- 不确定一段内容该归入哪类组件时（参考判断流程）
+- 审查现有组件是否符合规范时
+
+## When NOT to Use
+
+- 修改已有组件的业务逻辑 → 直接编辑对应文件
+- 组件精简/删除决策 → 人工判断哪些经过实战验证

package/skills/release-workflow/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: release-workflow
+description: Conventions and reference data for ECC InfiSense release management — commits, changelog, versioning, and safety.
+category: plugin
+---
+
+# Release Workflow
+
+发布管理的约定和参考数据，涵盖提交规范、变更日志格式、版本管理和安全检查。
+
+## Conventional Commits 格式
+
+Format: `<type>(<scope>): <subject>`
+
+| Type | Description | Changelog Category |
+|------|-------------|--------------------|
+| `feat` | New feature | Added |
+| `fix` | Bug fix | Fixed |
+| `docs` | Documentation only | Documentation |
+| `refactor` | No behavior change | Changed |
+| `test` | Tests | (omit) |
+| `chore` | Build, CI, tooling | Changed |
+| `perf` | Performance | Performance |
+
+### Subject Rules
+
+- Lowercase first character
+- Imperative mood ("add", not "added" or "adds")
+- Max 72 characters
+- No trailing period
+- One logical change per commit
+
+### Breaking Changes
+
+- Add `!` after type: `feat!: remove deprecated API`
+- Add `BREAKING CHANGE:` footer in commit body
+
+## Path → Scope Mapping
+
+Map changed file paths to commit scope:
+
+| Path Pattern | Scope | Type Inference |
+|-------------|-------|----------------|
+| `commands/` | `commands` | New file → `feat`, modify → `fix` or `docs` |
+| `skills/` | `skills` | New file → `feat`, modify → `fix` or `docs` |
+| `agents/` | `agents` | New file → `feat`, modify → `fix` or `docs` |
+| `rules/` | `rules` | `docs` or `refactor` |
+| `scripts/` | `scripts` | `fix` or `refactor` |
+| `hooks/` | `hooks` | New → `feat`, modify → `fix` |
+| `tests/` | `tests` | `test` |
+| `*.md` (root-level) | omit scope | `docs` |
+| `package.json`, `plugin.json` | `release` | `chore` |
+| Other | infer from content | `chore` |
+
+### Multi-scope Grouping
+
+When changes span multiple scopes:
+- Same logical change → ONE commit, use the primary scope
+- Unrelated changes → separate atomic commits
+- Documentation updates (CHANGELOG, README, GUIDE) → bundle with the last commit
+
+## Keep a Changelog Format
+
+Reference: [keepachangelog.com](https://keepachangelog.com/)
+
+```markdown
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+## [Unreleased]
+
+### Added
+- feat(scope): description of new feature
+
+### Changed
+- refactor(scope): description of change
+
+### Fixed
+- fix(scope): description of bug fix
+
+### Performance
+- perf(scope): description of optimization
+
+### Documentation
+- docs(scope): description of doc change
+
+## [X.Y.Z] - YYYY-MM-DD
+
+### Added
+- ...
+```
+
+### Rules
+
+- Always maintain an `[Unreleased]` section at the top
+- On version release, move entries to `## [X.Y.Z] - YYYY-MM-DD`
+- Leave `[Unreleased]` empty after moving
+- Entries use format: `- type(scope): description`
+- Omit `test` type entries from changelog
+- Category order: Added → Changed → Deprecated → Removed → Fixed → Security → Performance → Documentation
+
+## Semantic Versioning
+
+Reference: [semver.org](https://semver.org/)
+
+| Bump | When | Example |
+|------|------|---------|
+| `patch` | Bug fixes, doc updates, minor tweaks | `0.1.1 → 0.1.2` |
+| `minor` | New features, new commands/skills/agents | `0.1.2 → 0.2.0` |
+| `major` | Breaking changes, removed features | `0.2.0 → 1.0.0` |
+
+### Version Sync Locations
+
+When bumping version, update ALL of these:
+1. `package.json` — `version` field
+2. `.claude-plugin/plugin.json` — `version` field
+3. `CHANGELOG.md` — move Unreleased to versioned section
+
+## Safety Check Patterns
+
+### Dangerous Files (Never Commit)
+
+| Pattern | Risk |
+|---------|------|
+| `.env*` | Environment variables with secrets |
+| `credentials*` | Credential files |
+| `*secret*` | Files containing secrets |
+| `*token*` | API token files |
+| `*.key` | Private key files |
+| `*.pem` | Certificate/key files |
+| `node_modules/` | Dependencies (use .gitignore) |
+| Binary > 1MB | Large binary files |
+
+### Debug Code Patterns
+
+| Pattern | Language | Description |
+|---------|----------|-------------|
+| `console.log` | JavaScript | Debug logging |
+| `debugger` | JavaScript | Debugger breakpoint |
+| `printf.*debug` | C/C++ | Debug printing |
+| `#if 0` | C/C++ | Disabled code block |
+| `// TODO` (no ticket) | Any | Untracked work item |
+| `>>>>>>>` | Any | Merge conflict marker |
+
+### Commit Message Validation
+
+A valid commit message must:
+- [ ] Match format: `<type>(<scope>): <subject>` or `<type>: <subject>`
+- [ ] Use a recognized type (feat, fix, docs, refactor, test, chore, perf)
+- [ ] Have lowercase subject
+- [ ] Be max 72 characters on first line
+- [ ] Not end with a period
+- [ ] Use imperative mood
+
+## npm Publish Checklist
+
+Before publishing:
+- [ ] All tests pass (`npm test`)
+- [ ] Working tree is clean
+- [ ] CHANGELOG.md updated
+- [ ] Version bumped in package.json
+- [ ] Version synced to plugin.json
+- [ ] README.md and GUIDE.md counts updated
+- [ ] Git tagged with `v<version>`
+- [ ] Pushed to remote with tags
+
+## When to Use
+
+- Committing changes to the ECC InfiSense plugin
+- Publishing a new version to npm
+- Checking release status
+- Deciding on version bump level
+- Formatting changelog entries
+
+## When NOT to Use
+
+- C++ project releases → use project-specific release tooling
+- Generic git operations → use standard git commands
+- npm package development → use npm documentation directly