@agentyx/core 0.1.1 → 0.2.0

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: brainstorming
+description: Clarify ambiguous feature work before committing to an implementation path.
+---
+
+# Brainstorming
+
+Use this before substantial ambiguous design work, not for obvious small edits.
+
+Clarify the objective, constraints, users, architecture implications, alternatives, and acceptance
+criteria. Ask only the questions that change the implementation. Once the shape is clear, summarize
+the chosen direction and the tradeoffs that matter.

package/skills/code-quality/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: code-quality
+description: Keep code clear, local, and purposeful while changing existing systems.
+---
+
+# Code quality
+
+Write code that is easy to inspect and hard to misuse.
+
+## Local fit
+
+Match naming, structure, and error-handling style already used nearby. A change should look like it
+belongs in the module that owns it.
+
+## Purposeful units
+
+Keep functions and modules small enough to understand, but do not split code just to create layers.
+Each helper should name a useful idea or remove meaningful repetition.
+
+## Noise
+
+Delete dead code. Avoid speculative options, unused parameters, and exports nobody needs. Comments
+should explain why a choice exists, not restate what the code says.
+
+## Errors
+
+Handle errors where useful context exists. Preserve the original cause when it helps debugging, and
+return or throw errors with messages a caller can act on.

package/skills/code-review/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: code-review
+description: Review meaningful changes for correctness, regressions, security, tests, and complexity.
+---
+
+# Code review
+
+Review the behavior first, then the shape.
+
+## Pass
+
+Check requirement compliance, correctness, regressions, security and privacy risks, test coverage,
+API compatibility, and unnecessary complexity. Use file and line references when reporting issues.
+
+## Evidence
+
+Ground findings in code paths, observable behavior, or missing checks. Separate definite bugs from
+questions and assumptions.
+
+## Output
+
+Lead with actionable findings ordered by severity. Keep summaries secondary, and say clearly when
+you found no issues.

package/skills/concise-output/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: concise-output
+description: Communicate technical progress and results compactly without losing important details.
+---
+
+# Concise output
+
+Prefer compact professional communication.
+
+## Keep
+
+Keep commands, paths, failing errors, user-visible behavior changes, decisions that affect risk, and
+important assumptions. Be explicit for security issues, destructive actions, ambiguous instructions,
+and complex failures.
+
+## Cut
+
+Remove filler, obvious narration, repeated summaries, and progress logs that do not change the
+user's understanding. Do not restate the same status in multiple ways.
+
+## Reports
+
+Final reports should say what changed, what was verified, and what remains unverified. Use bullets
+only when they make scanning easier.

package/skills/context-efficient-development/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: context-efficient-development
+description: Develop with targeted discovery, narrow iteration, and complete verification.
+---
+
+# Context-efficient development
+
+Save context by doing the right work in the right order.
+
+## Discovery
+
+Start with targeted search, then read the relevant symbol or range, then the containing module when
+ownership is unclear. Open whole files when needed, not by reflex. Avoid rereading code whose role
+is already understood.
+
+## Iteration
+
+Run the smallest useful command while shaping a change: one test file, one package check, one build
+step. Expand only when the touched surface grows.
+
+## Completion
+
+Before calling work complete, run the project’s required full verification for the affected surface.
+Efficiency reduces waste; it does not reduce correctness.

package/skills/engineering-principles/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: engineering-principles
+description: Apply maintainable software-engineering judgment to non-trivial code changes.
+---
+
+# Engineering principles
+
+Use these principles as judgment, not ceremony.
+
+## Shape
+
+Prefer simple designs with explicit responsibilities. Keep related decisions close together, and
+separate code only when the boundary is real: different reasons to change, different lifetimes, or
+different owners.
+
+Favor composition when it keeps behavior visible. Inheritance, frameworks, service containers, and
+factories earn their place only when they remove concrete complexity.
+
+## Coupling
+
+Minimize what modules need to know about each other. Pass the smallest data a collaborator needs,
+return predictable results, and avoid leaking storage, transport, UI, or provider details through
+domain APIs.
+
+## Correctness
+
+Make invalid states difficult to represent. Use schemas, discriminants, required fields, and
+exhaustive checks where they clarify the model. Fail explicitly when input is invalid instead of
+silently repairing it.
+
+## Maintainability
+
+Optimize for the next person reading the code. A small amount of duplication can be cheaper than an
+abstraction that hides the important difference.

package/skills/focused-verification/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: focused-verification
+description: Choose narrow checks while iterating and full required gates before completion.
+---
+
+# Focused verification
+
+Match checks to risk and phase.
+
+## During iteration
+
+Run the smallest check that can fail for the code you just changed. Prefer a focused test, typecheck
+for one package, or a direct command that exercises the behavior.
+
+## Before completion
+
+Run the repository or product gate required for the touched surface. Include manual checks for CLI
+output, generated files, migrations, or UI behavior that automated tests do not cover.
+
+## Reporting
+
+Report the exact checks you ran. If a check fails or cannot be run, say that plainly with the reason.

package/skills/parallel-work/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: parallel-work
+description: Split independent coding-agent work safely when tasks do not overlap.
+---
+
+# Parallel work
+
+Use parallel work only for independent tasks with clear boundaries.
+
+Define each task's files, inputs, expected output, and verification. Avoid parallel edits to the
+same files or closely coupled behavior. Integrate deliberately: review outputs, reconcile conflicts,
+run the shared checks, and keep the parent agent responsible for the final result.

package/skills/requesting-code-review/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: requesting-code-review
+description: Request independent review after meaningful implementation.
+---
+
+# Requesting code review
+
+Ask for review when a change affects behavior, public APIs, security, data integrity, or several
+modules.
+
+Provide the requirement, changed files, verification performed, and known risks. Ask the reviewer to
+focus on requirement compliance, correctness, regressions, tests, security, and unnecessary
+complexity. Treat findings as inputs to resolve, not as a substitute for your own judgment.

package/skills/subagent-driven-development/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: subagent-driven-development
+description: Coordinate scoped subagent work when the current provider supports it.
+---
+
+# Subagent-driven development
+
+Use subagents when the task benefits from independent investigation, implementation, or review and
+the current provider supports them.
+
+Give each subagent a narrow objective, relevant context, boundaries, and expected output. Do not
+spawn agents for trivial work. Prefer fresh-context reviewers for meaningful changes. The parent
+agent remains responsible for integration, verification, and the final answer.

package/skills/targeted-exploration/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: targeted-exploration
+description: Explore codebases through search, relevant ranges, and module ownership.
+---
+
+# Targeted exploration
+
+Explore from signal to context.
+
+## Flow
+
+Search for the name, command, schema, error, or behavior. Read the relevant symbol or range. Then
+read nearby callers or tests. Open the whole file when the range does not reveal ownership or
+invariants.
+
+## Search
+
+Prefer structural or code-aware search when available. Use text search for identifiers and output
+strings. Avoid dumping unrelated files into context.
+
+## Stop condition
+
+Stop exploring when you can name the owning module, the expected behavior, the likely change, and
+the checks that will verify it.

package/skills/typescript-modeling/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: typescript-modeling
+description: Model TypeScript domains with unions, readonly data, satisfies, and useful generics.
+---
+
+# TypeScript modeling
+
+Use the type system to express relationships that matter at runtime.
+
+## Shapes
+
+Choose `type` or `interface` for local semantics and ecosystem fit, not dogma. Use discriminated
+unions for variants and exhaustive switches where missing cases would be a bug.
+
+## Contracts
+
+Annotate exported APIs and external boundaries. Let inference handle obvious locals. Use `satisfies`
+when a value should be checked against a contract without widening away useful literal information.
+
+## Mutability and generics
+
+Mark data `readonly` when mutation is not part of the contract. Use generics only when they express
+a real relationship between inputs and outputs; avoid type puzzles that make maintenance harder.

package/skills/typescript-modern/SKILL.md

@@ -1,41 +1,29 @@
 ---
 name: typescript-modern
-description: Modern TypeScript conventions - strict types, inference, small explicit APIs.
+description: Use current TypeScript module, syntax, import, and async patterns.
 ---
 
 # Modern TypeScript
 
-Write types that describe the domain, and let the compiler do the rest.
+Use current platform and language features without making code clever.
 
-## Typing
+## Modules
 
-Keep `strict` on and treat `any` as a defect. When a value really is unknown, type it `unknown` and
-narrow it — with `typeof`, `instanceof`, a discriminant check, or a validator that returns a typed
-result.
+Prefer ESM. Use type-only imports and exports when a symbol is erased at runtime. Keep module
+boundaries explicit and avoid circular dependencies.
 
-Annotate what forms a contract: exported functions, public fields, and the boundaries where outside
-data enters. Let inference handle everything else; restating an obvious type is noise that drifts
-out of date.
+## Syntax
 
-Avoid assertions. `as` and `!` silence the compiler without changing the value, so each one is an
-unchecked claim. Prove it with a real check instead.
+Use modern syntax when it clarifies intent: optional chaining, nullish coalescing, object
+destructuring, `const`, `for...of`, and `async`/`await`. Avoid transpiler-era patterns when the
+runtime supports the native feature.
 
-## Modelling
+## Platform
 
-Use discriminated unions for values that come in variants: a `kind` field plus the data that
-variant carries beats one wide object of optional properties, and it lets the compiler prove a
-`switch` is exhaustive.
+Prefer native platform APIs where they are stable and already available in the project runtime. Do
+not add a dependency for behavior the platform provides clearly.
 
-Make illegal states unrepresentable where it is cheap — required fields instead of optional ones, a
-union instead of two booleans, `readonly` on data that is not meant to change.
+## Async
 
-Derive types instead of duplicating them. When a schema or a constant already describes a shape,
-infer from it; two declarations of the same thing will disagree eventually.
-
-## Modules and APIs
-
-Use ESM. Export the smallest surface callers need and keep helpers module-private — every export is
-a contract you have to keep.
-
-Prefer plain functions and plain objects. Classes earn their place when there is real state or
-identity; factories, containers, and single-implementation interfaces usually do not.
+Use `async`/`await` for sequential asynchronous flow and `Promise.all` for independent work. Handle
+rejections at boundaries with useful context.

package/skills/typescript-strict/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: typescript-strict
+description: Use TypeScript strictness, narrowing, and validation for safe boundaries.
+---
+
+# TypeScript strictness
+
+Keep strict mode valuable by treating escapes as design decisions.
+
+## Unknown data
+
+Use `unknown` for untrusted values, then narrow with control flow, discriminants, predicates, or a
+schema validator. Validate external input at the boundary before it enters domain code.
+
+## Avoid unsafe escapes
+
+Avoid `any`, unsafe casts, and non-null assertions. If a value can be absent, model that possibility
+and handle it. Prefer checks that prove the value exists over assertions that silence the compiler.
+
+## Optional semantics
+
+When exact optional behavior matters, distinguish an omitted property from a property whose value is
+`undefined`. Do not use optional fields as a substitute for a clear variant model.

package/skills/worktree-workflow/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: worktree-workflow
+description: Use git worktrees for isolated parallel implementation when the work warrants it.
+---
+
+# Worktree workflow
+
+Use worktrees when isolation reduces risk for parallel or experimental implementation.
+
+Check repository status before creating one. Use deterministic branch and directory names tied to
+the task. Keep user changes safe: never overwrite or clean files you do not own. After integration,
+remove temporary worktrees only when their work is preserved and no uncommitted changes remain.