@ryuenn3123/agentic-senior-core 6.14.0 → 6.15.1

package/.agents/plugins/agentic-senior-core/skills/asc-debt/SKILL.md

@@ -1,82 +0,0 @@
----
-name: asc-debt
-description: >
-  Trigger this skill when the user says: "log this debt", "skip this for now", "defer this fix", "note this smell", "track this violation", "add to debt ledger", "we'll fix this later", "accept the shortcut", "I know this is bad but", "just do it for now", "TODO later", "catat debt", "skip dulu", "nanti aja benerinnya", "tunda perbaikan", "catat ini buat nanti". Also trigger when an ASC ladder nudge fires and the user accepts the shortcut rather than fixing it — log the deferred violation for later resolution. Do NOT trigger for actively resolving or refactoring existing debt items (use asc-refactor instead).
----
-
-# Debt Ledger
-
-Track deferred enforcement violations. When an ASC ladder nudge fires and the shortcut is accepted rather than fixed, log it here for later resolution.
-
-Grounded in: Cunningham's technical debt metaphor (1992). Entry format (ladder step + violation + status lifecycle) is an ASC-specific implementation.
-
-## Storage
-
-Entries persist in `.agent-context/state/debt-ledger.json` (or `.asc/debt-ledger.json`) via standard file read/write operations. The ledger is a JSON array of entry objects.
-
-## Stub Convention
-
-When introducing a temporary stub during development, mark it explicitly:
-```typescript
-// ASC-STUB: [reason for temporary code] [ASC-DEBT-001]
-```
-(or `# ASC-STUB: [reason] [ASC-DEBT-001]` in Python/Ruby).
-
-Every stub marker in source code MUST reference an open debt ID. Unregistered stubs will be blocked by the Git pre-commit runner.
-
-## Entry Format
-
-```json
-{
-  "id": "sequential integer (or ASC-DEBT-xxx)",
-  "file": "path/to/file.ts",
-  "ladderStep": "3",
-  "violation": "Added axios — stdlib fetch covers this",
-  "addedAt": "ISO-8601 timestamp",
-  "status": "open | resolved",
-  "resolvedAt": "ISO-8601 timestamp or null"
-}
-```
-
-## Operations
-
-### Add Entry
-
-When an enforcement nudge fires and the violation is deferred:
-
-1. Read the current ledger from `.agent-context/state/debt-ledger.json`. If missing, start with `[]`.
-2. Append a new entry with the next sequential `id`, the file path, ladder step, and a one-line violation summary.
-3. Write the updated ledger back to disk.
-4. Confirm: "Logged to debt ledger: [violation summary]"
-
-### List Open Debt
-
-1. Read the ledger.
-2. Filter to entries where `status` is `"open"`.
-3. Display as a table: ID, file, ladder step, violation, age.
-4. If no open entries, say so explicitly.
-
-### Resolve Entry
-
-When a deferred violation has been addressed:
-
-1. Read the ledger.
-2. Set the matching entry's `status` to `"resolved"` and `resolvedAt` to the current timestamp.
-3. Write the updated ledger.
-4. Confirm: "Resolved debt #[id]: [violation summary]"
-
-### Summary
-
-1. Read the ledger.
-2. Report: total entries, open count, resolved count, oldest open entry age.
-
-## When to Log
-
-Log a debt entry when ALL of these are true:
-- The PostToolUse enforcement hook fired a nudge
-- The agent acknowledged the nudge but proceeded without fixing the violation
-- The violation is deferrable (not a security issue — security violations must be fixed immediately)
-
-## Integration
-
-The `/asc` skill documents the enforcement loop. This ledger captures what enforcement flags but the session defers. Use `/asc-debt` at session end or before commits to review outstanding shortcuts.

package/.agents/plugins/agentic-senior-core/skills/asc-dedup/SKILL.md

@@ -1,56 +0,0 @@
----
-name: asc-dedup
-description: >
-  Trigger this skill when the user says: "find duplicate code", "check
-  for clones", "audit for duplication", "is this repeated elsewhere",
-  "scan for copy-paste", "run jscpd", "dedup report", "consolidate
-  duplicate logic", "this looks the same as the other file",
-  "we already have this somewhere", "why is this code repeated",
-  "isn't this a copy of", "cari kode duplikat", "ini kok sama kayak yang itu",
-  "ini udah ada kan". Use for whole-repo or whole-directory duplication
-  audits on demand — this is a deep, on-demand scan, distinct from the
-  continuous per-edit check already enforced by the dedup-gate hook. Do NOT
-  trigger for general code restructuring or refactoring without duplication/clone audit focus (use asc-refactor instead).
----
-
-# Duplicate Code Audit
-
-On-demand deep duplication scan using jscpd (token-level clone detection). Distinct from the continuous per-edit `dedup-gate` hook — this skill runs a full-scope scan and produces a ranked report.
-
-Grounded in: GitClear 2024 analysis (211M LOC, 8x increase in duplicated code blocks in AI-assisted repos). Token-level clone detection catches near-duplicates that differ in names/structure — something diff-only review tools and pattern matching cannot do.
-
-## When to Use
-
-- User asks to scan a directory, package, or entire repo for duplicated code
-- Before a refactoring pass, to identify consolidation targets
-- After a multi-file feature addition, to verify no accidental duplication was introduced
-
-## Scan Procedure
-
-1. Determine scope from user's request (specific directory, package, or full repo).
-2. Check for `.asc/dedup-config.json` — use `ignoreDirs` and `minTokens` from it if present.
-3. Run: `npx jscpd@5 "<scope>" --min-tokens <minTokens> --reporters console,json --output ./report/`
-   - If `bunx` is available, prefer `bunx jscpd` for speed (24-37x faster per jscpd v5 benchmarks).
-   - Apply `--ignore` flags from config `ignoreDirs`.
-4. Parse the JSON report and present findings ranked by number of duplicated lines (largest clusters first).
-
-## Report Format
-
-For each duplicate cluster, report:
-- **Files involved** and line ranges
-- **Duplicated lines count** and overlap percentage
-- **Consolidation recommendation** (only if pattern appears 3+ times — Rule of Three)
-
-## Consolidation Rules
-
-Per this repo's asc-refactor YAGNI and Rule of Three conventions:
-
-- **2 occurrences**: Report the duplication. Do NOT suggest a shared abstraction — "three similar lines is better than a premature abstraction."
-- **3+ occurrences**: Suggest the smallest safe consolidation — extract a shared function, component, or module. Explain what risk or friction the duplication creates and what the consolidated shape looks like.
-- **Structural boilerplate** (imports, prop types, export statements): Flag but do not count as actionable duplication — these are framework-mandated patterns, not logic clones.
-
-## Integration
-
-- The `dedup-gate` hook provides continuous per-edit detection (PostToolUse, scoped, fast).
-- This skill provides deep on-demand audits (full scope, thorough, user-triggered).
-- Findings from either can be logged to the debt ledger via `/asc-debt` if deferred.

package/.agents/plugins/agentic-senior-core/skills/asc-fingerprint/SKILL.md

@@ -1,49 +0,0 @@
----
-name: asc-fingerprint
-description: >
-  Trigger this skill when the user says: "map this codebase", "what are our conventions",
-  "document our patterns", "onboard to this repo", "fingerprint this repository",
-  "learn this repository structure", "petakan codebase", "pelajari struktur repo",
-  "apa aturan arsitektur di sini", "kebiasaan coding repo ini apa". Use it before substantial work in an unfamiliar
-  repository or when feature research repeatedly rediscovers the same conventions. Do NOT trigger for simple file finding or code searches within single files.
----
-
-# Repository Fingerprinting
-
-Extract this repository's actual architectural and procedural conventions before building
-anything substantial. The goal is evidence-backed alignment with this codebase, not a
-generic architecture score.
-
-## Phase 1: Read-only map
-
-1. Read local instructions and list the active runtime, test, and deployment surfaces.
-2. Find two or more analogous modules. Record their layer split, naming, validation,
-   error handling, user notification/toast provider, fallback patterns, tests, and
-   documentation conventions with file paths.
-3. Inspect recent Git history (up to 200 commits, or since the last fingerprint) for
-   repeated review corrections, reverts, and release conventions.
-4. Read a debt ledger only when it exists. Treat repeated entries as a possible
-   convention candidate, not as proof by itself.
-5. Report only falsifiable findings. Separate observations from recommendations and
-   include the file or commit evidence for every proposed convention.
-6. STOP and wait for approval before writing project files.
-
-## Phase 2: Record approved conventions
-
-1. If the target repository already has a project-level `CONVENTIONS.md`, update only
-   the approved sections. Otherwise create it at the target repository root.
-2. Do not overwrite the ASC package bundle or copy the universal ASC rule into the
-   target convention file.
-3. Keep each rule short, project-specific, and testable. Record the source evidence
-   beside the rule when it would otherwise be ambiguous.
-4. Recommend rerunning this skill only when repository structure or repeated feature
-   research shows that the document is stale.
-
-## Output
-
-Return:
-
-- factual repository map;
-- named analogous modules;
-- proposed conventions with evidence;
-- a short list of open questions or insufficient evidence.

package/.agents/plugins/agentic-senior-core/skills/asc-learn/SKILL.md

@@ -1,40 +0,0 @@
----
-name: asc-learn
-description: >
-  Trigger this skill when the user says: "learn this preference", "don't do this again", "remember my preference", "log this rule", "add to my design rules", "never use X", "always use Y for UI", "save this preference", "remember this style", "ingat preferensi ini", "jangan lakuin ini lagi", "catat aturan ini", "simpan gaya ini". Also trigger when mining explicit user corrections from conversation history to update adaptive preferences. Do NOT trigger for initial day-one design rule bootstrapping or cold start wizard (use asc-bootstrap instead).
----
-
-# Adaptive Preference Miner (`asc-learn`)
-
-Mines explicit user corrections and design preferences from conversation history, atomizes them into clean rules, and routes them to Track A (Syntactic/Compiled) or Track B (Taste/AGENTS.md).
-
-Grounded in: **TRACE (arXiv:2606.13174)** correction mining & **Supermemory** dual-scope preference isolation.
-
-## Workflow
-
-1. **Extract & Atomize**: Parse the user's explicit correction or preference into a single atomic rule.
-2. **Categorize Track**:
-   - **Track A (Syntactic / Concrete)**: Banned Tailwind classes, specific CSS patterns, forbidden AST structures, or exact code tokens.
-   - **Track B (Taste / Visual Vibe)**: Subjective UI aesthetic guidance (layout flow, typography feel, brand mood).
-3. **Select Scope**:
-   - **User Scope (`~/.gemini/config/`)**: Global personal preferences that follow the developer across all repositories.
-   - **Project Scope (`.agents/`)**: Repository-specific conventions.
-4. **Execute Dual-Track Routing**:
-   - For **Track A**: Pass rule to `addRule()` in `adaptive-preferences.mjs` and invoke `installGitPreCommitHook()` / `compileAndSaveValidator()` to generate deterministic Git pre-commit & `ascx validate` enforcement (capped at `DEFAULT_RULE_CAP = 25`).
-   - For **Track B**: Append the structured, deduped atomic rule to `AGENTS.md` / `SCRUTABLE_RULES.md` under `## Adaptive Preferences`.
-5. **Track B Governance & Budgeting (Anti-Bloat)**:
-   - Cap active taste rules at a maximum of **15 rules** per repository to prevent instruction density degradation (Gloaguen ETH Zurich 2026).
-   - When exceeding 15 rules, perform semantic compaction: merge overlapping guidelines (e.g. typography rules) and prune superseded preferences.
-
-## Atomic Rule Format
-
-```json
-{
-  "id": "rule_timestamp_hash",
-  "type": "syntactic | taste",
-  "pattern": "Concrete pattern or regex",
-  "reason": "Clear explanation of why this pattern is preferred or banned",
-  "source": "learn",
-  "scope": "user | project"
-}
-```

package/.agents/plugins/agentic-senior-core/skills/asc-new-project/SKILL.md

@@ -1,62 +0,0 @@
----
-name: asc-new-project
-description: >
-  Trigger this skill when the user says: "new project", "start from scratch", "scaffold this", "bootstrap project", "bootstrap repository", "bootstrap new app", "create a new app", "init a project", "set up a new repo", "greenfield", "plan the architecture", "design the system", "build me an app", "start a new codebase", "I want to build", "let's create", "bikin project baru", "buat aplikasi baru", "scaffold repo baru", "mulai dari awal". Also trigger for any request to create a new codebase, plan a new system architecture, or scaffold a new repository from zero. Do NOT trigger for adding features, routes, or components to an existing codebase (use asc-add-feature instead), or for UI style preference onboarding (use asc-bootstrap instead).
----
-
-# New Project Workflow
-
-Structured greenfield workflow. Prevents building before alignment on what to build.
-
-Grounded in: Spec-Driven Development (SDD) with scaffolding-spec approach. Core spec documents guide greenfield implementation (`PRD.md`, `Architecture.md`, `Schema.md`). Once implemented, the code becomes the primary ground truth, while docs are updated on structural changes.
-
-## Gate Mechanism & 3 Spec Document Requirement
-
-This workflow nudges the agent to stop at each phase boundary, same enforcement tier as the existing decision ladder — not a hard block. Bypasses are logged to the debt ledger.
-
-For greenfield projects (`asc-new-project`), Phase 2 requires creating the **3 Core SDD Documents** in `docs/` or project root:
-1. `PRD.md` — Product intent, goals, non-goals, user problems, and user feedback expectations.
-2. `Architecture.md` — System structure, module boundaries, tech stack choices, and global error handling, fallback, and notification strategy.
-3. `Schema.md` — Data contracts, database entities, API endpoints.
-
-*Note on Rules:* Coding conventions and project constraints are automatically loaded from global plugin rules (`agentic-senior-core.md`) or workspace `AGENTS.md`. No duplicate `docs/Rules.md` file is required.
-
-To track phase, write to `workflow-gate.json` via the `state_write` MCP tool.
-Format:
-```json
-{
-  "workflow": "asc-new-project",
-  "phase": "<current_phase>",
-  "updatedAt": "<ISO-timestamp>"
-}
-```
-
-## Phase 1: Define (No Code)
-
-1. Write `workflow-gate.json` with phase `research`.
-2. Clarify with the user: tech stack, target platform, constraints, non-goals.
-3. Propose a directory structure and module boundaries.
-4. Output a project brief summarizing decisions.
-5. **STOP and wait for user approval.** Do not write specs or code.
-
-## Phase 2: Spec (No Implementation Code)
-
-1. On approval of Phase 1, update `workflow-gate.json` phase to `plan`.
-2. Generate the 3 core SDD documents from templates (`docs/PRD.md`, `docs/Architecture.md`, `docs/Schema.md`).
-3. Verify exact file naming — check for typos like `Architectyre.md`.
-4. Output specs for review.
-5. **STOP and wait for user approval.** Do not implement code.
-
-## Phase 3: Implement
-
-1. On approval of Phase 2, update `workflow-gate.json` phase to `implement`.
-2. Run Anti Context-Blindness check: verify entities/tables mentioned in `Schema.md` or `Architecture.md` align with proposed code targets.
-3. Build against the approved specs. Apply the ASC decision ladder on every file.
-4. Run the decision ladder: does this need to exist? Does stdlib cover it? One function or full module?
-5. Generate a `.github/workflows/asc-quality-gate.yml` file that runs linter, type-check, and dependency audit on `push` and `pull_request`. Remind the user to enable Branch Protection in GitHub (require status checks to pass) to enforce this gate globally.
-
-## Phase 4: Validate
-
-1. Run tests. Check each spec's acceptance criteria.
-2. Confirm nothing was over-built beyond what the specs required.
-3. On completion, clear the state in `workflow-gate.json` by overwriting it with `{}`.

package/.agents/plugins/agentic-senior-core/skills/asc-refactor/SKILL.md

@@ -1,62 +0,0 @@
----
-name: asc-refactor
-description: >
-  Trigger this skill when the user says: "refactor this", "clean up this code", "improve this structure", "rewrite this", "extract this into", "reduce duplication", "apply DRY", "apply SOLID", "migrate this", "simplify this module", "split this file", "decompose this", "this is messy", "make this cleaner", "too much coupling", "move this logic", "rapikan kode ini", "bersihin kodingan", "refactor ini", "perbaiki struktur kodingan". Also trigger for any request to restructure, modernize, or improve code organization without changing behavior. Do NOT trigger for building new features from scratch or greenfield projects (use asc-add-feature or asc-new-project instead).
----
-
-# Refactor Skill
-
-Structured refactoring workflow. Preserves existing behavior while improving structure.
-
-Grounded in: Fowler's Refactoring (read-understand-smallest scope-preserve behavior), Rule of Three (abstraction threshold), YAGNI principle (XP/Kent Beck). Empirical evidence: agents dominate low-level refactors (rename, extract, type changes) but struggle with multi-file architectural changes (arXiv, 15k+ instance study).
-
-## YAGNI Scan (Before Any Restructuring)
-
-Before changing structure, scan for speculative code to remove:
-- "Just in case" logic, unused feature flags, dead branches behind config toggles.
-- Abstractions wrapping a single implementation with no second consumer.
-- Premature extension points (plugin hooks, strategy patterns) with one concrete path.
-
-Removing speculative code is the highest-value, lowest-risk refactor type.
-
-## Classify Before Proceeding
-
-After reading the target code, classify the refactor:
-
-- **Low-level** (rename, extract method, type safety, dead code removal): proceed after explaining the change. No approval gate needed.
-- **High-level** (move module, change architecture, redesign abstractions, multi-file structural changes): write `workflow-gate.json` with `{"workflow": "asc-refactor", "phase": "plan"}`, output a plan with specific files and rationale, then **stop and wait for user approval** before implementing.
-
-## Before Editing
-
-1. **Verify Baseline**: Run project test runner (`ascx test`, `npm test`, or equivalent). Do not refactor on failing tests.
-2. Read the target code and understand existing patterns.
-3. Identify the smallest relevant scope for the refactor.
-4. Classify the refactor (see above). For high-level refactors, update `workflow-gate.json` to phase `implement` only after user approval.
-5. If the change touches UI, check accessibility and responsive behavior.
-6. If the change touches dependencies, verify current official docs.
-
-## Refactor Rules
-
-- Improve clarity, boundaries, naming, validation, error handling, and tests.
-- Action Feedback & Fallbacks: Preserve all user feedback indicators, error toasts, and dependency fallbacks. Refactoring must never silently drop error-handling branches.
-- Prioritize maintainability over compressed one-liners.
-- Keep the main flow traceable. Use early returns where they reduce nesting.
-- Introduce abstractions only when the repeated pattern is real and visible.
-- Split large files when the split makes the flow easier to understand.
-- Remove code that does not carry behavior, safety, clarity, maintainability, or test value.
-- Prefer the shorter implementation only when it keeps the same guarantees.
-- Run a final simplification pass before completion.
-- Update tests and docs whenever behavior contracts, public APIs, data shape, or UI contracts change.
-
-## For Every Change, Explain
-
-- What risk or friction existed.
-- What changed.
-- Why the new shape is safer or easier to maintain.
-
-## Validation
-
-- Existing behavior is preserved unless the user approved a change.
-- Edge cases, empty states, error paths, and rollback paths are handled.
-- Public contracts remain stable or are versioned.
-- Tests pass.