@event4u/agent-config 6.0.0 → 7.0.0

package/dist/agent-src/commands/chat-history/learn.md

@@ -1,184 +0,0 @@
----
-model_tier: medium
-name: chat-history-learn
-pack: meta
-tier: 2
-cluster: chat-history
-sub: learn
-skills: [learning-to-rule-or-skill]
-description: Pick a prior chat-history session and mine it for project-improving learnings — runs learning-to-rule-or-skill on the picked session, drafts proposal(s) under agents/proposals/
-suggestion:
-  eligible: true
-  trigger_description: "extract a learning from a past session, mine chat-history for proposals, what did we learn last session, codify a pattern from a prior session"
-  trigger_context: "user wants to derive a rule/skill/guideline proposal from the content of one prior session"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-<!-- cloud_safe: noop -->
-
-# /chat-history learn
-
-User-driven **learning extraction** from a prior session. Surfaces
-prior sessions logged in `agents/runtime/.agent-chat-history` as numbered options,
-the user picks **one**, the agent reads that session's entries and
-runs the [`learning-to-rule-or-skill`](../../skills/learning-to-rule-or-skill/SKILL.md)
-workflow on the content — surfacing repeated mistakes, successful
-patterns, or constraints worth codifying as a rule, skill, or
-guideline proposal.
-
-This is the **project-improvement** counterpart to
-[`/chat-history import`](import.md): `import` renders a session
-verbatim into the current chat for the user to act on; `learn`
-mines a session for proposals that improve the agent or the
-project itself.
-
-## When NOT to use
-
-- Pull a prior session into the current chat verbatim — use
-  [`/chat-history import`](import.md).
-- Capture a learning that originated **in the current** session —
-  invoke the [`learning-to-rule-or-skill`](../../skills/learning-to-rule-or-skill/SKILL.md)
-  skill directly. `learn` is for prior-session mining only.
-- Bulk-mine all sessions — out of scope for v1. One session per
-  invocation; multi-pick is v2.
-
-## Steps
-
-### 1. Check if enabled
-
-Read `chat_history.enabled` from `.agent-settings.yml`. If `false`
-or the section is missing, say so and stop:
-
-```
-> 📒 chat-history is disabled (chat_history.enabled = false).
-> Set it to true in .agent-settings.yml to start logging.
-```
-
-### 2. List sessions
-
-Run `scripts/chat_history.py sessions --json --limit 20 --summary`.
-The helper returns an array of
-`{id, count, first_ts, last_ts, preview, summary}` sorted by
-`last_ts` desc. The `summary` field is built inside the helper
-from ≤10 sampled entries per session (5 oldest + 5 newest) —
-token-cheap, no full-body read needed for the picker. Empty
-buckets are excluded by default.
-
-If the array is empty, stop:
-
-```
-> 📒 No prior sessions found in agents/runtime/.agent-chat-history.
-```
-
-### 3. Surface as numbered options
-
-Render each session as a numbered option (per the `user-interaction`
-rule — Iron Law: numbered options for any picker). Lead with the
-helper's `summary` field — the rough arc the user picks by
-(`<first user msg> → <last user msg>`, or
-`(N entries — no user prompts; t-mix: …)` for tool-only sessions).
-Keep the session `id` **internal** for step 5's `read --session <id>`
-call; never render it in the listing. Format:
-
-```
-> Pick a session to mine for learnings:
->
-> 1. {summary}
->    {YYYY-MM-DD HH:MM}  ·  {count} entries
-> 2. ...
-> ...
-> N. abort — do not extract any learning
-```
-
-Format the timestamp as `YYYY-MM-DD HH:MM` (drop seconds + timezone
-— orientation, not forensics). Do not truncate or rewrite `summary`
-— the helper already shapes it. Always include an explicit abort
-option last. Track option-number → `id` internally so step 5 calls
-`scripts/chat_history.py read --session <id>` with the right id.
-
-### 4. Wait for the pick
-
-**One question per turn** (per `ask-when-uncertain`). Do not chain
-the listing with anything else; do not auto-pick; do not surface a
-default. Wait for the user's response.
-
-If the user picks the abort option, stop without reading.
-
-### 5. Read the picked session
-
-Run `scripts/chat_history.py read --session <id>` with the picked
-`id`. Hold the entries in working memory — do **not** render them
-verbatim into the chat. The verbatim path is `import`'s job; here
-the entries are input to step 6.
-
-### 6. Run `learning-to-rule-or-skill`
-
-Apply the [`learning-to-rule-or-skill`](../../skills/learning-to-rule-or-skill/SKILL.md)
-procedure on the session content:
-
-1. **Scan** the entries for candidate learnings — repeated
-   mistakes, successful patterns, friction points, or constraints
-   stated by the user.
-2. **Pass each candidate through the Promotion Gate** (§ 0 of the
-   skill): repetition, impact, failure pattern, non-duplication,
-   scope fit, minimal. Drop candidates that fail any gate.
-3. **For each surviving candidate**, run § 4 (search protocol — all
-   four steps), then decide rule / skill / guideline / update / no
-   action per § 3 of the skill.
-4. **Draft a proposal** for every candidate that warrants one,
-   following § 8 of the skill (proposal template under
-   `agents/proposals/<id>.md`).
-
-If multiple candidates survive, draft them as **separate**
-proposals — do not merge unrelated learnings into one.
-
-### 7. Surface the result
-
-Hand back to the user with a structured summary per surviving
-candidate:
-
-```
-> 📒 Mined session {id} — {N} candidate(s) surfaced
-
-> 1. {learning title}
->    Decision: {rule|skill|guideline|update|no action}
->    Proposal: agents/proposals/{proposal_id}.md
->    Gate: {pass|fail — reason}
-> 2. ...
-```
-
-If no candidate cleared the Promotion Gate, say so explicitly:
-
-```
-> 📒 Mined session {id} — no candidate cleared the Promotion Gate.
-```
-
-Do **not** open a PR, do **not** commit the proposals — proposal
-files land in `agents/proposals/` (gitignored or curated per
-project policy) for the user to review and route via
-`upstream-contribute` or merge into `agents/overrides/`.
-
-## Gotchas
-
-- **Promotion Gate is hard.** A grep miss is not proof of
-  non-duplication — § 4 of the skill mandates the four-step search
-  protocol. Do not skip it.
-- **One pick per invocation.** Multi-pick is v2. If the user wants
-  to mine a second session, run `/chat-history learn` again.
-- **Read-only on the log.** This command never writes to
-  `agents/runtime/.agent-chat-history`. It writes proposal drafts under
-  `agents/proposals/` only.
-- **No auto-promotion.** Drafted proposals stay in `proposals/`
-  until the user routes them. `learn` never invokes
-  `upstream-contribute` itself.
-
-## See also
-
-- [`/chat-history import`](import.md) — verbatim render of a prior session
-- [`learning-to-rule-or-skill`](../../skills/learning-to-rule-or-skill/SKILL.md) — the workflow this command orchestrates
-- [`upstream-contribute`](../../skills/upstream-contribute/SKILL.md) — promote a project-scoped proposal upstream
-- [`scripts/chat_history.py`](../../../scripts/chat_history.py) — `sessions` and `read --session` CLI surface
-- [`user-interaction`](../../rules/user-interaction.md) — numbered-options Iron Law
-- [`ask-when-uncertain`](../../rules/ask-when-uncertain.md) — one-question-per-turn Iron Law

package/dist/agent-src/commands/chat-history/show.md

@@ -1,113 +0,0 @@
----
-model_tier: medium
-name: chat-history-show
-pack: meta
-tier: 2
-cluster: chat-history
-sub: show
-skills: [chat-history]
-description: Show the status of the persistent chat-history log — file size, entry count, header fingerprint, age, and the last few entries
-suggestion:
-  eligible: false
-  rationale: "Status display only; no NL trigger distinct from 'show status'."
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-<!-- cloud_safe: noop -->
-
-# /chat-history show
-Inspect `agents/runtime/.agent-chat-history` — the JSONL log appended by the
-structural chat-history hooks (`ChatHistoryAppendHook`,
-`ChatHistoryHaltAppendHook`) for crash recovery.
-
-Shows:
-
-- Whether the file exists and whether logging is currently enabled
-- File size vs `max_size_kb`
-- Header metadata: schema version, `started`, `frequency`
-- Entry count and age of the oldest/newest entry
-- A peek at the last 3–5 entries so the user can see what was captured
-
-Read-only — this command never writes to the file.
-
-## When NOT to use
-
-- Wipe the file → delete `agents/runtime/.agent-chat-history` manually; it is
-  git-ignored and will be recreated on the next hook fire.
-- Configure logging behavior → edit `.agent-settings.yml` directly
-  (`chat_history.*`); see
-  [`layered-settings`](../../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules).
-
-## Steps
-
-### 1. Check if enabled
-
-Read `chat_history.enabled` from `.agent-settings.yml`. If `false` or
-the section is missing, say so and stop:
-
-```
-> 📒 chat-history is disabled (chat_history.enabled = false).
-> Set it to true in .agent-settings.yml to start logging.
-```
-
-### 2. Read status via helper
-
-Run `scripts/chat_history.py status`. The helper returns a JSON object
-with `exists`, `size_bytes`, `size_kb`, `entries`, `header`, and `path`.
-
-If `exists: false`, tell the user the file has not been created yet —
-it will be created on the next agent turn that writes an entry.
-
-### 3. Read last N entries
-
-Run `scripts/chat_history.py read --last 5` (or equivalent — see the
-helper's CLI). Capture timestamps and entry types without loading the
-full file.
-
-### 4. Present the summary
-
-Render a concise report:
-
-```
-> 📒 chat-history status
->
-> File:       agents/runtime/.agent-chat-history  ({size_kb} KB / {max_size_kb} KB)
-> Entries:    {entries}
-> Schema:     v{header.v}  (started {header.started})
-> Frequency:  {header.freq}
-> Overflow:   {on_overflow}
->
-> Last entries:
->   {ts_1}  {type_1}  {preview_1}
->   {ts_2}  {type_2}  {preview_2}
->   ...
-```
-
-Keep previews short (≤ 60 chars). Do not render the full entry text
-unless the user asks (avoids flooding the conversation with old log
-data, see [`token-efficiency`](../rules/token-efficiency.md)).
-
-### 5. Offer follow-ups (optional)
-
-If the file is close to `max_size_kb` (> 80 %), mention it — the next
-append may trigger overflow handling. To pull a specific prior
-session into the current chat verbatim, point the user at
-`/chat-history import`; to mine a prior session for project-improving
-learnings, `/chat-history learn`. The body filter on `s` is the v4
-isolation surface in both cases.
-
-## Gotchas
-
-- `agents/runtime/.agent-chat-history` is git-ignored. This command never commits.
-- The helper is the only way to read the file — do not cat or parse
-  the JSONL directly; entry shape is owned by `scripts/chat_history.py`.
-- If `exists: false` but the rule says logging is enabled, the file is
-  created lazily on the first append. That is expected — not an error.
-
-## See also
-
-- [`chat-history-platform-hooks`](../../../agents/settings/contexts/chat-history-platform-hooks.md) — the hook-only contract
-- [`agent-settings` template](../templates/agent-settings.md) — `chat_history.*` reference
-- [`scripts/chat_history.py`](../../../scripts/chat_history.py) — helper API (`status`, `read`, `sessions`, `prune-sessions`)

package/dist/agent-src/commands/fix/pr-bot-comments.md

@@ -1,157 +0,0 @@
----
-model_tier: medium
-name: fix-pr-bot-comments
-pack: engineering-base
-tier: 2
-cluster: fix
-sub: pr-bot-comments
-skills: [php-coder, quality-tools]
-description: Fix and reply to bot review comments (Copilot, Augment, Greptile, etc.) on a GitHub PR
-suggestion:
-  eligible: true
-  trigger_description: "address the Copilot/Greptile comments, fix the bot review feedback"
-  trigger_context: "open PR with bot review comments unresolved"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /fix pr-bot-comments
-## Input
-
-The user may or may not provide a PR URL.
-
-### PR detection
-
-1. If the user provides a GitHub PR URL → use that PR.
-2. If no URL is provided → **try to detect the PR automatically:**
-   - Determine the current Git branch (`git branch --show-current`).
-   - Search for an open PR on that branch via the GitHub API
-     (`GET /repos/{owner}/{repo}/pulls?head={owner}:{branch}&state=open`).
-   - If exactly one PR is found → tell the user: "I found PR #{number} ({title}) on branch `{branch}`. Is that the one?"
-   - Wait for confirmation before proceeding.
-   - If no PR or multiple PRs are found → ask the user for the PR URL.
-3. **Never** reuse a PR number from earlier in the conversation.
-
-## Mode selection
-
-After the PR is confirmed, ask the user (use numbered options per `user-interaction` rule):
-
-```
-> 1. Interactive — ask before each comment
-> 2. Automatic — handle all independently
-```
-
-- **Option 1** → follow the "Interactive flow" below.
-- **Option 2** → follow the "Auto flow" below.
-
-## Bot detection
-
-A comment is from a **bot** if the GitHub user has `type: "Bot"` or the login matches
-known bot accounts: `Copilot`, `github-actions[bot]`, `greptile[bot]`, `augment[bot]`,
-or any login ending in `[bot]`.
-
-## Instructions (shared)
-
-1. **Fetch all review comments** from the PR using the GitHub API (`/pulls/{number}/comments`).
-   Use `per_page: 100`. Filter for **bot comments** that have **no reply yet** from a human user.
-
-2. **For each unresolved bot comment**, read the affected file and surrounding context
-   to understand the code and the suggestion.
-
-3. **Report the total count** to the user: "Found X unresolved bot comments."
-
----
-
-## Interactive flow
-
-For each comment, present it to the user **before** taking action:
-
-### 1. Summarize the comment
-
-In the **user's language**, briefly explain:
-- Which file/line is affected
-- What the bot is suggesting
-- Your assessment: is it valid, partially valid, or not applicable?
-
-### 2. Offer options
-
-Present numbered options. Always include a "leave as-is" option. Examples:
-
-**If there's one clear fix:**
-> **Comment 1/3** — `WorkingTimeService.php:108`
-> Bot says: The guard condition only checks `job_start`, but the comment also mentions `job_stop`.
->
-> 1. Fix the comment (only mention `job_start`)
-> 2. Extend the guard condition (also check `job_stop`)
-> 3. Leave as-is, dismiss comment
-
-**If there are multiple valid approaches:**
-> **Comment 2/3** — `AbsencePlannerService.php:520`
-> Bot says: When an exception occurs mid-loop, log entries are missing.
->
-> 1. `writeLogBulk()` in einen `finally`-Block verschieben
-> 2. Die gesamte Schleife in eine DB-Transaction wrappen
-> 3. Leave as-is, dismiss comment
-
-### 3. Wait for the user's choice
-
-- Do NOT proceed until the user picks an option.
-- If the user asks a follow-up question, answer it before proceeding.
-- After the user chooses, apply the fix (or skip) and reply on GitHub.
-
-### 4. Move to the next comment
-
-Repeat until all comments are handled.
-
----
-
-## Auto flow
-
-Process all comments without asking. For each comment:
-
-1. Analyze whether the suggestion is valid.
-2. **If valid** — fix it and reply on GitHub.
-3. **If not valid** — reply on GitHub explaining why, do NOT change the code.
-
----
-
-## Common patterns to watch for
-
-- **Duplicate PHPDoc tags** → fix by keeping the more specific/typed version.
-- **Split PHPDoc blocks** → merge into a single docblock.
-- **Wrong PHPDoc tag order** → `@param` before `@return` before `@throws`.
-- **Conflicting PHPDoc types** → remove incorrect PHPDoc, trust the method signature.
-- **Broad ignore patterns / intentional config** → reply explaining rationale, don't change.
-- **Validation/logic bugs** → fix the code.
-
-## Reply style — write like a human developer, not an AI
-
-- The GitHub API token authenticates as the PR author. Write replies as if you ARE the developer.
-- Keep it casual, short, and natural. Like a real dev replying to a code review.
-- Vary your wording — never use the same opening phrase twice in a row.
-- Don't over-explain. A dev who fixed something doesn't write a paragraph about it.
-- Good examples: `"Good catch, fixed."`, `"Yep, consolidated into one docblock now."`,
-  `"Removed the duplicate 👍"`, `"That's intentional — [reason]"`
-- Never start multiple replies with "Fixed". Mix it up: "Done", "Good catch", "Yep", etc.
-
-### Bot icon prefix
-
-Read `personal.pr_comment_bot_icon` from `.agent-settings.yml`. If `true` (default),
-prefix every reply with `🤖 ` so reviewers can see at a glance that the reply was
-bot-authored.
-
-Example: `🤖 Good catch, fixed.`
-
-If `false` or `.agent-settings.yml` doesn't exist, do NOT add the prefix.
-
-## Replying via GitHub API
-
-Read `github.pr_reply_method` from `.agent-settings.yml` to determine the correct endpoint.
-See the `command-routing` skill → "GitHub API: Replying to PR review comments" for full details.
-
-## After all comments
-
-1. Run a PHP syntax check (`php -l`) on all modified files to verify nothing is broken.
-2. **Do NOT commit or push.** Just apply the fixes locally and reply to all comments on GitHub.

package/dist/agent-src/commands/fix/pr-developer-comments.md

@@ -1,163 +0,0 @@
----
-model_tier: medium
-name: fix-pr-developer-comments
-pack: engineering-base
-tier: 2
-cluster: fix
-sub: pr-developer-comments
-skills: [php-coder]
-description: Fix and reply to human reviewer comments on a GitHub PR
-suggestion:
-  eligible: true
-  trigger_description: "fix the human reviewer comments, address the developer feedback"
-  trigger_context: "open PR with unresolved human-reviewer comments"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /fix pr-developer-comments
-## Input
-
-The user may or may not provide a PR URL.
-
-### PR detection
-
-1. If the user provides a GitHub PR URL → use that PR.
-2. If no URL is provided → **try to detect the PR automatically:**
-   - Determine the current Git branch (`git branch --show-current`).
-   - Search for an open PR on that branch via the GitHub API
-     (`GET /repos/{owner}/{repo}/pulls?head={owner}:{branch}&state=open`).
-   - If exactly one PR is found → tell the user: "I found PR #{number} ({title}) on branch `{branch}`. Is that the one?"
-   - Wait for confirmation before proceeding.
-   - If no PR or multiple PRs are found → ask the user for the PR URL.
-3. **Never** reuse a PR number from earlier in the conversation.
-
-## Mode selection
-
-After the PR is confirmed, ask the user (use numbered options per `user-interaction` rule):
-
-```
-> 1. Interactive — ask before each comment
-> 2. Automatic — handle all independently
-```
-
-- **Option 1** → follow the "Interactive flow" below.
-- **Option 2** → follow the "Auto flow" below.
-
-## Human reviewer detection
-
-A comment is from a **human reviewer** if:
-- The GitHub user `type` is `"User"` (not `"Bot"`).
-- The login does NOT end in `[bot]`.
-- The user is NOT the PR author (don't process your own comments).
-
-## Instructions (shared)
-
-1. **Fetch all review comments** from the PR using the GitHub API (`/pulls/{number}/comments`).
-   Use `per_page: 100`. Also fetch **PR reviews** (`/pulls/{number}/reviews`) for top-level
-   review comments. Filter for **human reviewer comments** that have **no reply yet** from the PR author.
-
-2. **For each unresolved reviewer comment**, read the affected file and surrounding context
-   to understand the code and what the reviewer is asking for.
-
-3. **Report the total count** to the user: "Found X unresolved reviewer comments."
-
----
-
-## Interactive flow
-
-For each comment, present it to the user **before** taking action:
-
-### 1. Summarize the comment
-
-In the **user's language**, briefly explain:
-- Who wrote the comment (reviewer name/login)
-- Which file/line is affected
-- What the reviewer is requesting or asking
-- Your assessment: is it a valid concern, a question, a style preference, or a misunderstanding?
-
-### 2. Offer options
-
-Present numbered options. Always include a "skip" option. Adapt options to the comment type:
-
-**For a change request:**
-> **Comment 1/3** — @cjost1988 in `WorkingTimeService.php:108`
-> Reviewer asks: Why is the fallback `float`? `$time` is `$hours * 60`.
->
-> 1. Reply and explain why (no code change needed)
-> 2. Adjust type annotation to `float|int|string`
-> 3. Skip
-
-**For a bug report:**
-> **Comment 2/3** — @cjost1988 in `AbsencePlannerService.php:520`
-> Reviewer says: Race condition when two requests book simultaneously.
->
-> 1. Add locking mechanism (DB lock or cache lock)
-> 2. Reply: not relevant in current scope, create a ticket
-> 3. Skip
-
-**For a question (no code change needed):**
-> **Comment 3/3** — @cjost1988 in `KS21Client.php:42`
-> Reviewer asks: Is this fallback ever reached?
->
-> 1. Reply with explanation
-> 2. Skip
-
-### 3. Wait for the user's choice
-
-- Do NOT proceed until the user picks an option.
-- If the user wants to write a custom reply, let them dictate the text.
-- If the user asks a follow-up question, answer it before proceeding.
-- After the user chooses, apply the fix (or reply) and post on GitHub.
-
-### 4. Move to the next comment
-
-Repeat until all comments are handled.
-
----
-
-## Auto flow
-
-Process all comments without asking. For each comment:
-
-1. Analyze what the reviewer is requesting.
-2. **If it's a clear code fix** — fix it and reply on GitHub.
-3. **If it's a question** — reply with a concise explanation on GitHub.
-4. **If it's ambiguous or a design decision** — flag it to the user instead of guessing.
-   In auto mode, collect these and present them at the end: "These comments need your decision: ..."
-
----
-
-## Reply style — write like a human developer, not an AI
-
-- The GitHub API token authenticates as the PR author. Write replies as if you ARE the developer.
-- Keep it casual, short, and natural. Like a real dev replying to a code review.
-- Vary your wording — never use the same opening phrase twice in a row.
-- For reviewer questions: answer directly and concisely. Don't over-explain.
-- For fixes: confirm briefly what was changed.
-- Be respectful — these are colleagues, not bots. Don't dismiss feedback.
-- Good examples: `"Good point, fixed."`, `"Yep, that was a leftover — removed."`,
-  `"The fallback covers legacy data where getTime() returns a string."`
-- Never start multiple replies with the same phrase. Mix it up naturally.
-
-### Bot icon prefix
-
-Read `personal.pr_comment_bot_icon` from `.agent-settings.yml`. If `true` (default),
-prefix every reply with `🤖 ` so reviewers can see at a glance that the reply was
-bot-authored.
-
-Example: `🤖 Good point, fixed.`
-
-If `false` or `.agent-settings.yml` doesn't exist, do NOT add the prefix.
-
-## Replying via GitHub API
-
-Read `github.pr_reply_method` from `.agent-settings.yml` to determine the correct endpoint.
-See the `command-routing` skill → "GitHub API: Replying to PR review comments" for full details.
-
-## After all comments
-
-1. Run a PHP syntax check (`php -l`) on all modified files to verify nothing is broken.
-2. **Do NOT commit or push.** Just apply the fixes locally and reply to all comments on GitHub.