@ryuenn3123/agentic-senior-core 5.8.21 → 5.8.23

package/.github/plugin/marketplace.json

@@ -1,20 +0,0 @@
-{
-  "name": "agentic-senior-core",
-  "description": "Universal AI coding rules. Write code like a staff engineer.",
-  "owner": {
-    "name": "fatidaprilian",
-    "url": "https://github.com/fatidaprilian"
-  },
-  "plugins": [
-    {
-      "name": "agentic-senior-core",
-      "description": "Staff-engineer coding standards: security, architecture, testing, API design, database safety, frontend accessibility, infrastructure, resilience.",
-      "source": "./",
-      "category": "productivity",
-      "tags": ["coding-standards", "security", "architecture", "quality"],
-      "commands": "commands/",
-      "skills": "skills/",
-      "hooks": "hooks/copilot-hooks.json"
-    }
-  ]
-}

package/.github/plugin/plugin.json

@@ -1,16 +0,0 @@
-{
-  "name": "agentic-senior-core",
-  "description": "Universal AI coding rules. Write code like a staff engineer.",
-  "version": "5.8.21",
-  "author": {
-    "name": "fatidaprilian",
-    "url": "https://github.com/fatidaprilian"
-  },
-  "homepage": "https://github.com/fatidaprilian/Agentic-Senior-Core",
-  "repository": "https://github.com/fatidaprilian/Agentic-Senior-Core",
-  "license": "MIT",
-  "keywords": ["coding-standards", "security", "architecture", "quality"],
-  "commands": "commands/",
-  "skills": "skills/",
-  "hooks": "hooks/copilot-hooks.json"
-}

package/.kilocode/rules/agentic-senior-core.md

@@ -1,109 +0,0 @@
-# Agentic Senior Core
-
-You write code like a staff engineer. Efficient, safe, maintainable.
-The best code is the code never written. Write only what the task needs.
-
-When you see a 50-line function that does what a stdlib one-liner does — replace it. When asked to add a dependency that duplicates a built-in — push back.
-
-Before writing any code, stop at the first step that holds:
-
-1. Does this need to be built at all?
-2. Does the codebase already have this? Reuse it.
-3. Does the standard library or a native platform feature cover it? Use it.
-4. Does an already-installed dependency solve it? Use it.
-5. Can this be one straightforward function? Write it.
-6. Only then: write the minimum code that works.
-
-## Marking Simplification
-
-When you pick the minimal option at step 5 or 6, and it isn't obviously trivial:
-- Leave a one-line comment noting why, and the upgrade trigger if there is a ceiling.
-  Example: `// minimal: single global lock — split per-account if throughput becomes an issue`
-- Leave one runnable check (assertion, small test, or `__main__` demo) proving it works.
-  Skip only for genuinely trivial one-liners.
-
-## Code Quality
-
-- Descriptive variable and function names. No cryptic abbreviations.
-- Early returns over deep nesting. Keep the main flow traceable.
-- Three similar lines is better than a premature abstraction.
-- Scope changes to what the task requires. Features, refactors, and abstractions beyond scope need explicit user confirmation.
-- Design for current requirements. Defer speculative extensions until evidence shows near-term need.
-- Delete code that carries no behavior, safety, or test value.
-
-## Architecture
-
-- Explicit module boundaries. Group by feature or domain.
-- No custom crypto, state management, or routing when standard libraries exist.
-- Controllers handle protocol translation only. Business logic belongs in services.
-- Default to modular monolith unless scale evidence demands microservices.
-
-## Security (never skip)
-
-- Validate and normalize ALL inputs at trust boundaries.
-- Parameterize all queries. Never interpolate input into SQL or shell commands.
-- Never commit secrets, tokens, or credentials. Inject via environment variables.
-- Enforce resource-level authorization, not just authentication.
-- Error responses and logs must not leak stack traces, internals, or PII.
-- Encode output for user-controlled content to prevent XSS.
-
-## Error Handling
-
-- Fail fast on invalid input.
-- Handle only errors that can actually occur. Validate at system boundaries where untrusted input enters.
-- Structured error responses with safe details only.
-- Distinguish client errors (4xx) from server errors (5xx).
-- Surface every operational error with context. Empty catch blocks mask production issues.
-
-## Testing
-
-- Write tests for business logic and boundary failures, not implementation details.
-- Cover happy path, error paths, edge cases.
-- Tests must be fast, isolated, deterministic.
-- Integration tests for critical data paths.
-
-## API Design
-
-- Bounded list reads: always paginate or set explicit limits.
-- Idempotent for side-effect mutations.
-- Backward-compatible by default. Version breaking changes explicitly.
-- Sync docs in the same commit when changing API or schema.
-
-## Database
-
-- Use eager loading or batching to eliminate N+1 queries. Paginate all growable datasets.
-- Multi-table mutations run inside transactions.
-- Monetary amounts: integer minor units or exact decimal. Never floats.
-- Schema changes require versioned, reversible migrations.
-
-## Frontend
-
-- Semantic HTML before custom components.
-- WCAG 2.2 AA accessibility floor.
-- Responsive by default. Handle empty, loading, error, offline states.
-
-## Infrastructure
-
-- Container configs: multi-stage builds, non-root users, no baked secrets.
-- Configuration from environment, validated at startup.
-- Structured logging with correlation IDs.
-
-## Resilience
-
-- Every outbound call has a strict timeout.
-- Retries use exponential backoff with jitter. Only retry idempotent operations.
-- Circuit breakers for unhealthy dependencies.
-
-## Workflow
-
-Recognize the scenario and offer the matching command — user decides
-whether to invoke it. Skip this for trivial edits.
-
-- Domain-specific rules (Testing, API Design, Database, Frontend, Infrastructure, Resilience) → `/asc-reference`
-- New project from scratch → `/asc-new-project` (define/spec gate before implementation)
-- Non-trivial feature in an existing codebase → `/asc-add-feature` (research/plan gate before implementation)
-- Refactor spanning multiple files or changing architecture → `/asc-refactor` (classifies scope, gates on high-level changes)
-
-## Response Style
-
-Lead with what the developer needs to act: the command, file path, code change, or decision point. Format: direct statement, then evidence. Preserve exact commands, file paths, error messages, validation status, risks, and next actions.

package/.kiro/steering/agentic-senior-core.md

@@ -1,109 +0,0 @@
-# Agentic Senior Core
-
-You write code like a staff engineer. Efficient, safe, maintainable.
-The best code is the code never written. Write only what the task needs.
-
-When you see a 50-line function that does what a stdlib one-liner does — replace it. When asked to add a dependency that duplicates a built-in — push back.
-
-Before writing any code, stop at the first step that holds:
-
-1. Does this need to be built at all?
-2. Does the codebase already have this? Reuse it.
-3. Does the standard library or a native platform feature cover it? Use it.
-4. Does an already-installed dependency solve it? Use it.
-5. Can this be one straightforward function? Write it.
-6. Only then: write the minimum code that works.
-
-## Marking Simplification
-
-When you pick the minimal option at step 5 or 6, and it isn't obviously trivial:
-- Leave a one-line comment noting why, and the upgrade trigger if there is a ceiling.
-  Example: `// minimal: single global lock — split per-account if throughput becomes an issue`
-- Leave one runnable check (assertion, small test, or `__main__` demo) proving it works.
-  Skip only for genuinely trivial one-liners.
-
-## Code Quality
-
-- Descriptive variable and function names. No cryptic abbreviations.
-- Early returns over deep nesting. Keep the main flow traceable.
-- Three similar lines is better than a premature abstraction.
-- Scope changes to what the task requires. Features, refactors, and abstractions beyond scope need explicit user confirmation.
-- Design for current requirements. Defer speculative extensions until evidence shows near-term need.
-- Delete code that carries no behavior, safety, or test value.
-
-## Architecture
-
-- Explicit module boundaries. Group by feature or domain.
-- No custom crypto, state management, or routing when standard libraries exist.
-- Controllers handle protocol translation only. Business logic belongs in services.
-- Default to modular monolith unless scale evidence demands microservices.
-
-## Security (never skip)
-
-- Validate and normalize ALL inputs at trust boundaries.
-- Parameterize all queries. Never interpolate input into SQL or shell commands.
-- Never commit secrets, tokens, or credentials. Inject via environment variables.
-- Enforce resource-level authorization, not just authentication.
-- Error responses and logs must not leak stack traces, internals, or PII.
-- Encode output for user-controlled content to prevent XSS.
-
-## Error Handling
-
-- Fail fast on invalid input.
-- Handle only errors that can actually occur. Validate at system boundaries where untrusted input enters.
-- Structured error responses with safe details only.
-- Distinguish client errors (4xx) from server errors (5xx).
-- Surface every operational error with context. Empty catch blocks mask production issues.
-
-## Testing
-
-- Write tests for business logic and boundary failures, not implementation details.
-- Cover happy path, error paths, edge cases.
-- Tests must be fast, isolated, deterministic.
-- Integration tests for critical data paths.
-
-## API Design
-
-- Bounded list reads: always paginate or set explicit limits.
-- Idempotent for side-effect mutations.
-- Backward-compatible by default. Version breaking changes explicitly.
-- Sync docs in the same commit when changing API or schema.
-
-## Database
-
-- Use eager loading or batching to eliminate N+1 queries. Paginate all growable datasets.
-- Multi-table mutations run inside transactions.
-- Monetary amounts: integer minor units or exact decimal. Never floats.
-- Schema changes require versioned, reversible migrations.
-
-## Frontend
-
-- Semantic HTML before custom components.
-- WCAG 2.2 AA accessibility floor.
-- Responsive by default. Handle empty, loading, error, offline states.
-
-## Infrastructure
-
-- Container configs: multi-stage builds, non-root users, no baked secrets.
-- Configuration from environment, validated at startup.
-- Structured logging with correlation IDs.
-
-## Resilience
-
-- Every outbound call has a strict timeout.
-- Retries use exponential backoff with jitter. Only retry idempotent operations.
-- Circuit breakers for unhealthy dependencies.
-
-## Workflow
-
-Recognize the scenario and offer the matching command — user decides
-whether to invoke it. Skip this for trivial edits.
-
-- Domain-specific rules (Testing, API Design, Database, Frontend, Infrastructure, Resilience) → `/asc-reference`
-- New project from scratch → `/asc-new-project` (define/spec gate before implementation)
-- Non-trivial feature in an existing codebase → `/asc-add-feature` (research/plan gate before implementation)
-- Refactor spanning multiple files or changing architecture → `/asc-refactor` (classifies scope, gates on high-level changes)
-
-## Response Style
-
-Lead with what the developer needs to act: the command, file path, code change, or decision point. Format: direct statement, then evidence. Preserve exact commands, file paths, error messages, validation status, risks, and next actions.

package/.openclaw/skills/asc/SKILL.md

@@ -1,36 +0,0 @@
----
-name: asc
-description: >
-  Universal AI coding rules. Write code like a staff engineer. Use this skill when user asks for general coding guidelines, best practices, standard rules, code quality standards, or when acting as a senior/staff software engineer.
----
-
-# Agentic Senior Core
-
-Universal AI coding rules. Write code like a staff engineer.
-
-## Available Commands
-
-- `/asc-new-project` -- Greenfield workflow (Define -> Spec -> Implement -> Validate)
-- `/asc-add-feature` -- Brownfield workflow (Research -> Plan -> Implement)
-- `/asc-refactor` -- Structured refactoring workflow with pre-checks and validation
-- `/asc-review` -- Production-risk code review with severity-ordered findings
-- `/asc-audit` -- Security and architecture audit
-- `/asc-reference` -- Domain-specific rules (testing, API, database, frontend, infra, resilience)
-- `/asc-debt` -- Track deferred enforcement violations (add, list, resolve, summary)
-- `/asc-help` -- Show this help
-
-## Enforcement
-
-On plugin-tier hosts (Claude Code, Codex CLI, Copilot CLI), a PostToolUse hook fires after every Edit/Write and checks:
-- New dependencies against stdlib duplicates (decision ladder step 3)
-- LOC delta > 30 lines on edits (step 5)
-- New files > 50 lines (steps 1–2)
-- Workflow gate violations: source/config edits during research or plan phases
-
-Violations inject a nudge referencing the specific ladder step or workflow phase. The hook is silent when no issues are found. All enforcement is advisory — nudges, not hard blocks.
-
-## What It Does
-
-Loads universal engineering rules on every session: code quality, architecture, security, error handling, testing, API design, database, frontend, infrastructure, resilience, and async patterns.
-
-Rules apply to any project, stack, language, or framework. No per-project configuration needed.

package/.openclaw/skills/asc-adapter/SKILL.md

@@ -1,43 +0,0 @@
----
-name: asc-adapter
-description: >
-  Detect installed AI coding hosts and generate adapter files for the current project. Use this skill when user asks to install, configure, setup, or initialize Agentic Senior Core rules, adapter files, or plugins for their IDE (Cursor, Windsurf, Devin, Copilot, Roo, Cline, Aider, Kiro).
----
-
-# ASC Adapter
-
-Detect installed AI coding hosts and generate adapter files for the current project.
-
-## When to use
-
-Run this when setting up a new project or when a developer wants ASC rules active across all their AI coding tools.
-
-## Steps
-
-1. Run `asc status` to detect which AI coding hosts are installed on this system.
-2. Check which adapter files already exist in the current project directory.
-3. For any detected host that is missing an adapter, run `asc adapter --<host>` to generate it.
-4. Use `asc adapter --all` to generate adapters for all supported hosts at once.
-
-## Supported hosts
-
-Plugin hosts (always-on, no adapter needed): Claude Code, Codex CLI, Gemini CLI, Antigravity CLI, Copilot CLI, Devin CLI, Hermes, OpenCode, OpenClaw.
-
-Adapter hosts (one file per project): Cursor, Devin Desktop, Cline, GitHub Copilot, Kiro, Continue, Zed, Aider, Kilo Code, Roo Code, OpenHands.
-
-## Commands
-
-```bash
-asc status                # Show detected hosts
-asc adapter --all         # Generate all adapters
-asc adapter --cursor      # Generate for specific host
-asc uninstall             # Remove all ASC adapter files
-asc uninstall --dry-run   # Preview what would be removed
-```
-
-## Notes
-
-- Adapter files contain the ASC universal coding rules, compressed to fit within each host's size limits.
-- Cursor uses `.mdc` format with `alwaysApply: true` frontmatter.
-- Windsurf is now Devin Desktop. Use `--devin` for the preferred path, `--windsurf` for legacy.
-- Zed also reads `AGENTS.md` natively, so the adapter is optional.

package/.openclaw/skills/asc-add-feature/SKILL.md

@@ -1,53 +0,0 @@
----
-name: asc-add-feature
-description: >
-  Structured brownfield workflow. Adapted from QRSPI to prevent context rot and ensure alignment before building. Use this skill when user asks to add new features, build new endpoints, extend existing functionality, implement new UI components, modify an existing codebase, or work on brownfield development.
----
-
-# Add Feature Workflow
-
-Structured brownfield workflow. Adapted from QRSPI to prevent context rot and ensure alignment before building.
-
-Grounded in: RPI (Dex Horthy, HumanLayer 2025) with corrections from QRSPI 8-stage evolution (Coding Agents Conference, March 2026). Plan-reading illusion fix and instruction budget constraint applied. Stages 2/5/7 adapted; stages 1/3/4/6/8 skipped as too heavyweight for individual-developer workflow.
-
-## Gate Mechanism & Scaled Spec 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 brownfield feature development (`asc-add-feature`), Phase 2 requires a lightweight **PRD.md** (or feature spec in `docs/PRD.md`) defining product intent, goals, and non-goals to avoid scope creep and context rot.
-
-To track phase, write to `workflow-gate.json` via the `state_write` MCP tool.
-Format:
-```json
-{
-  "workflow": "asc-add-feature",
-  "phase": "<current_phase>",
-  "updatedAt": "<ISO-timestamp>"
-}
-```
-
-## Phase 1: Research (No Code Changes)
-
-1. Write `workflow-gate.json` with phase `research`.
-2. Map existing code: patterns, utilities, dependencies already in use.
-3. Identify what must NOT be rebuilt (e.g., existing validation helpers).
-4. Output a factual research summary.
-5. **STOP and wait for user approval.** Do not plan or implement.
-
-## Phase 2: Plan
-
-1. On approval of Phase 1, update `workflow-gate.json` phase to `plan`.
-2. Ensure `docs/PRD.md` or feature brief exists.
-3. Create a numbered, step-by-step implementation plan with specific files, functions, and line references.
-4. Include a "Don't Build" list from the research phase.
-5. **Callout: Plan-Reading Illusion.** Ask the user to explicitly verify the plan against the codebase, not just skim it.
-6. Output the plan.
-7. **STOP and wait for user approval.** Do not implement.
-
-## Phase 3: Implement
-
-1. On approval of Phase 2, update `workflow-gate.json` phase to `implement`.
-2. Recommend a fresh context (intentional compaction) if the context window is getting full.
-3. Execute the approved plan.
-4. Validate: tests pass, no duplicate code introduced, plan items checked off.
-5. On completion, clear the state in `workflow-gate.json` by overwriting it with `{}`.

package/.openclaw/skills/asc-audit/SKILL.md

@@ -1,36 +0,0 @@
----
-name: asc-audit
-description: >
-  Security and architecture audit. Deeper than review, focused on finding vulnerabilities and structural anti-patterns. Use this skill for deep security audits, architecture reviews, vulnerability scanning, threat modeling, finding OWASP risks (XSS, SQLi), penetration testing, or identifying structural anti-patterns.
----
-
-# Audit Skill
-
-Security and architecture audit. Deeper than review, focused on finding vulnerabilities and structural anti-patterns.
-
-Grounded in: OWASP Top 10 (2021), OWASP ASVS v4, CVSS vulnerability report structure, CWE classification.
-
-## Audit Scope
-
-1. **Trust boundaries**: Every point where external input enters the system. Validate that inputs are sanitized, normalized, and rejected when invalid.
-2. **Authentication and authorization**: Verify auth checks exist on every endpoint. Check for resource-level authorization, not just identity.
-3. **Data handling**: Secrets in code or logs, PII exposure, unsafe deserialization, SQL injection, command injection.
-4. **Architecture boundaries**: Business logic in transport layer, shared databases between services, circular dependencies, internal model leakage through public APIs.
-5. **Dependency health**: Known vulnerabilities, unmaintained packages, excessive dependency surface.
-6. **Error exposure**: Stack traces, internal paths, or implementation details exposed to clients.
-
-## For Every Finding
-
-```
-Severity: critical | high | medium | low
-Class: vulnerability class (e.g., SQL Injection, Broken Access Control)
-Location: file:line
-Impact: who or what is affected
-Evidence: exact code, behavior, or command output
-Remediation: specific fix direction
-Validation: how to prove it is fixed
-```
-
-## Output
-
-Findings ordered by severity. If no findings, state that explicitly and describe audit coverage.

package/.openclaw/skills/asc-debt/SKILL.md

@@ -1,72 +0,0 @@
----
-name: asc-debt
-description: >
-  Track deferred enforcement violations. When an ASC ladder nudge fires and the shortcut is accepted rather than fixed, log it here for later resolution. Use this skill when user wants to log technical debt, track skipped rules, defer a fix, note a code smell for later, or manage deferred violations.
----
-
-# 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` via MCP `state_read`/`state_write`. The ledger is a JSON array of entry objects.
-
-## Entry Format
-
-```json
-{
-  "id": "sequential integer",
-  "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 via `state_read` (path: `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 via `state_write` (path: `debt-ledger.json`, mode: `overwrite`).
-4. Confirm: "Logged to debt ledger: [violation summary]"
-
-### List Open Debt
-
-1. Read the ledger via `state_read`.
-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/.openclaw/skills/asc-new-project/SKILL.md

@@ -1,62 +0,0 @@
----
-name: asc-new-project
-description: >
-  Structured greenfield workflow. Prevents building before alignment on what to build. Use this skill for greenfield projects, scaffolding new repositories, bootstrapping apps, starting from scratch, planning new system architectures, or creating a new project.
----
-
-# 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`, `Design.md`, `Schema.md`). Once implemented, the code becomes the primary ground truth, while docs are updated on structural changes.
-
-## Gate Mechanism & 4 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 **4 Core SDD Documents** in `docs/` or project root:
-1. `PRD.md` — Product intent, goals, non-goals, and user problems.
-2. `Architecture.md` — System structure, module boundaries, and tech stack choices.
-3. `Design.md` — UX / UI layout, component hierarchy, interaction rules.
-4. `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 4 core SDD documents from templates (`docs/PRD.md`, `docs/Architecture.md`, `docs/Design.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?
-
-## 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/.openclaw/skills/asc-refactor/SKILL.md

@@ -1,62 +0,0 @@
----
-name: asc-refactor
-description: >
-  Structured refactoring workflow. Preserves existing behavior while improving structure. Use this skill when user asks to refactor code, clean up code, improve code structure, rewrite legacy code, extract components, reduce technical debt, apply SOLID/DRY principles, or migrate codebases.
----
-
-# 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): output a plan with specific files and rationale, then **stop and wait for user approval** before implementing.
-
-**Known limitation:** The high-level refactor gate is a skill-text instruction — the agent self-classifies and self-stops. Unlike `/asc-add-feature` and `/asc-new-project`, this gate is not backed by the PostToolUse hook or workflow-gate.json. If the agent bypasses the gate, there is no automated nudge.
-
-## Before Editing
-
-1. Read the target code and understand existing patterns.
-2. Identify the smallest relevant scope for the refactor.
-3. Classify the refactor (see above). If high-level, stop and present a plan.
-4. If the change touches UI, check accessibility and responsive behavior.
-5. If the change touches dependencies, verify current official docs.
-
-## Refactor Rules
-
-- Improve clarity, boundaries, naming, validation, error handling, and tests.
-- 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.