personal-ai-runtime

Use to launch, supervise, or evaluate one stateless bounded subagent job with a context pack, allowed scope, forbidden scope, validation requirements, structured output contract, and state patch proposal.

Normalize, inspect, or clean up CHANGELOG.md files into versioned, categorized, user-readable release history. Use when the user asks to check,整理,標準化,normalize, rewrite, or prepare a changelog; before releases or tags; or when CHANGELOG.md contains loose notes, commit-log residue, AI conversation residue, TODOs, missing dates, ordering issues, or uncategorized entries.

Use to prepare bounded context packs for stateless subagents, selecting only required specs, diffs, artifacts, constraints, allowed scope, forbidden scope, validation requirements, and output contracts.

Use to turn ambiguity, validation gaps, breaking changes, survived mutations, or spec/test conflicts into human-readable decision options such as accept, update spec, reject, refine tests, or defer.

Use after Devil's Advocate Review to resolve numbered objections from Low to High before workflow atomic decomposition, producing spec patch requirements, human decisions, and pass or blocked gate status.

Use before finalizing a plan or spec to challenge hidden assumptions, edge cases, overdesign, architecture risk, compatibility gaps, migration cost, testing cost, and spec/implementation drift.

Use to analyze git diffs, commits, or file changes for changed components, behavior-change candidates, affected modules, unrelated edits, and verification scope.

Use to identify impacted components, specs, tests, contracts, risks, and validation gaps from diff, inferred intent, test results, or mutation results.

Use to infer developer intent from diff, prompt, plan, commit, or PR context, including confidence, uncertainty, mismatch with spec, and risk notes.

Use to generate or select focused just-in-time tests from diff, intent, impact, spec refs, and risk items while preserving traceability and treating generated tests as candidates.

Use to validate test effectiveness with mutation tooling or scoped manual mutation checks, reporting killed, survived, equivalent, skipped, or blocked mutation results honestly.

Check and initialize Git boundaries for nested child projects under modules/ or poc-modules/. Use when editing, documenting, scaffolding, testing, or organizing a child project that is expected to be its own repository.

Use to maintain durable workflow state for spec-driven execution, including workflow_step, atomic item status, dependency graph, ready/running/blocked/completed queues, merge gates, usage gates, and commit checkpoints.

Convert an existing playbook into one or more executable agent skills, extract a single skill, split a large playbook into orchestrator and child skills, check alignment between playbook and skills, resync after playbook changes, and update Playbook / Skill README mappings.

Run a brief preflight before complex, ambiguous, risky, multi-step, architecture, migration, refactor, or behavior-changing work; clarify understanding, assumptions, uncertainty, risks, and next steps before modifying files.

Convert one-off prompts, successful examples, repeated task instructions, or conversation-tested workflows into human-readable agent playbooks. Use when the user asks to turn a prompt into a playbook, generalize a successful prompt, create an agent-playbooks markdown file from repeated instructions, or update playbook README mappings without automatically extracting a normal task skill.

Use to design tests from accepted specs or atomic items, preserving spec-to-test traceability, edge cases, error cases, invariants, and validation hooks before or alongside implementation.

Use to create, revise, or normalize a formal correctness spec from clarified requirements, including scope, non-goals, rules, invariants, acceptance criteria, testing implications, and README/spec file placement.

Use when requirements, plans, acceptance criteria, inputs, outputs, edge cases, or behavior-change policy are unclear and must be clarified into testable spec candidates before implementation.

Use for spec-driven implementation and verification workflows, including module or poc-module phase work, atomic item execution, spec/test evolution, diff-aware verification, JIT test selection, mutation-aware validation, human decision gates, and durable orchestrator-state handoffs.

Use after human decisions or validation gap analysis to update specs, tests, workflow notes, indexes, and traceability so code, tests, and correctness contracts evolve together.

Use to interpret test, JIT test, or mutation results and classify weak tests, effective tests, validation gaps, spec gaps, implementation issues, and recommended improvements.

Use to decide whether generated, JIT, candidate, or mutation-validated tests should remain ephemeral, become trusted tests, be persisted as regression tests, be refined, or be discarded.

Use when creating, reading, updating, normalizing, or converting text files where UTF-8 encoding, Traditional Chinese defaults, PowerShell text I/O, or suspected mojibake may affect the result.

Use when a revised spec is ready to split into selected workflow slices, atomic implementation items, bootstrap prerequisites, dependency edges, verification loops, and traceable work items.