@anionzo/skill 1.6.0 → 1.7.0

package/skills/go-pipeline/examples.md

@@ -1,56 +0,0 @@
-# Examples
-
-## Example 1
-
-User request:
-
-```text
-The user-notifications spec is approved. Just build it all.
-```
-
-Expected result:
-
-- validate the spec
-- generate tasks from requirements
-- plan and implement each task
-- verify all ACs
-- present commit for approval
-
-Sample completed output:
-
-```
-Goal/Result: Pipeline complete — 4 tasks implemented, all ACs verified.
-
-Key Details:
-  Spec: user-notifications (approved)
-
-  Tasks completed: 4/4
-  1. Add notification model and database migration — DONE
-  2. Implement notification service with email + in-app delivery — DONE
-  3. Add user notification preferences API — DONE
-  4. Wire notification triggers into existing user events — DONE
-
-  Tasks blocked: 0
-
-  AC Coverage: 5/5 (100%)
-  - AC-1: Notifications created on user events — VERIFIED
-  - AC-2: Email delivery via SendGrid — VERIFIED
-  - AC-3: In-app notifications visible in UI — VERIFIED
-  - AC-4: User preferences respected — VERIFIED
-  - AC-5: Delivery failures logged — VERIFIED
-
-  Build: PASS
-  Tests: 58/58 PASS (12 new)
-  Lint: PASS
-
-  Commit proposal:
-  feat(notifications): implement user notification system
-
-  - Add notification model with email + in-app channels
-  - Implement notification service with delivery tracking
-  - Add user preferences API for per-channel control
-  - Wire notifications into user registration and order events
-  - All 5 acceptance criteria verified
-
-  Proceed? (yes / no / edit)
-```

package/skills/go-pipeline/meta.yaml

@@ -1,27 +0,0 @@
-name: go-pipeline
-version: 0.1.0
-category: workflow
-summary: Execute a full spec-to-commit pipeline in one continuous run with minimal review gates.
-summary_vi: "Th\u1EF1c thi to\xE0n b\u1ED9 pipeline t\u1EEB spec \u0111\u1EBFn commit trong m\u1ED9t l\u01B0\u1EE3t li\xEAn t\u1EE5c v\u1EDBi \xEDt gate review."
-triggers:
-  - go mode
-  - run all
-  - execute everything
-  - just build it
-inputs:
-  - approved spec document
-outputs:
-  - implemented tasks
-  - verification results
-  - conventional commit
-constraints:
-  - spec must be approved before starting
-  - commit requires user approval
-  - checkpoint on context budget
-related_skills:
-  - using-skills
-  - brainstorming
-  - planning
-  - feature-delivery
-  - verification-before-completion
-  - commit

package/skills/go-pipeline/references/output-template.md

@@ -1,17 +0,0 @@
-## Goal/Result
-
-- Pipeline status:
-
-## Key Details
-
-- Spec:
-- Tasks created:
-- Tasks completed:
-- Tasks blocked:
-- AC coverage:
-- Build/test status:
-- Commit proposal:
-
-## Next Action
-
--

package/skills/repo-onboarding/SKILL.md

@@ -1,56 +0,0 @@
-# Repo Onboarding
-
-## Purpose
-
-Understand a repository quickly enough to act safely and explain what matters.
-
-## When To Use
-
-Load this skill when:
-
-- entering a repo for the first time
-- a task depends on understanding architecture or conventions
-- the user asks what the project does or how it is organized
-
-## Workflow
-
-1. Read the top-level operating docs first, especially `AGENTS.md` and `README.md` when present.
-2. Inspect the most informative source files next:
-   - package manifests or build files
-   - app entrypoints and framework bootstraps
-   - core config files
-   - representative tests
-3. Identify:
-   - project purpose
-   - major components
-   - runtime model and key integrations
-   - important development or verification commands
-4. Call out what is verified from source versus what is still uncertain.
-5. Recommend the next files or directories to inspect for the user's likely goal.
-
-## Output Format
-
-Present results using the Shared Output Contract:
-
-1. **Goal/Result** — the repo understood and key findings
-2. **Key Details:**
-   - project purpose
-   - architecture summary
-   - major components and responsibilities
-   - important commands or workflows
-   - notable conventions or constraints
-   - open questions
-3. **Next Action** — `planning` (to plan a change), `research` (to go deeper on a topic), or `docs-writer` (to update documentation)
-
-## Red Flags
-
-- skipping repo docs and jumping straight into random source files
-- summarizing architecture from folder names alone
-- claiming a behavior without checking source or config
-- reading many low-value files while missing the actual entrypoints
-
-## Done Criteria
-
-This skill is complete when another engineer could start productive work from the summary without redoing the same orientation pass. Both the "Important Commands" and "Open Questions" fields must be populated.
-
-After this skill, the natural next step is `planning` (to plan a change) or `docs-writer` (if the goal is to update documentation).

package/skills/repo-onboarding/examples.md

@@ -1,115 +0,0 @@
-# Examples
-
-## Example 1
-
-User request:
-
-```text
-Can you explain how this service is structured before we add a queue worker?
-```
-
-Expected result:
-
-- read top-level docs first
-- inspect runtime entrypoints and worker-related modules
-- summarize current architecture and likely integration points
-
-### Completed output — Example 1
-
-```
-Project purpose: Order processing microservice — receives orders via REST API, persists to PostgreSQL, publishes events to RabbitMQ.
-
-Architecture summary: Express.js app using a layered structure (routes → controllers → services → repositories). Bull is already listed in package.json but no active queue consumer exists.
-
-Major components:
-- src/routes/       — REST endpoint definitions
-- src/controllers/  — request handling and validation
-- src/services/     — business logic (OrderService, PaymentService)
-- src/repositories/ — Knex-based database access
-- src/events/       — RabbitMQ publisher (no consumer yet)
-
-Important commands:
-- npm run dev       — start with hot reload
-- npm test          — jest unit + integration tests
-- npm run migrate   — run Knex migrations
-
-Notable conventions:
-- All services are instantiated via a simple DI container in src/container.ts
-- Tests use a shared test database seeded per suite
-
-Open questions:
-- Is Bull the intended queue driver, or should the new worker use the existing RabbitMQ publisher?
-- Are there any existing retry/dead-letter conventions?
-
-Recommended next reads: src/events/publisher.ts, src/container.ts, config/queue.ts (if present)
-```
-
-### Completed output — Example 2
-
-```
-Project purpose: Internal dashboard for managing feature flags and A/B test configurations.
-
-First things to read:
-1. README.md — setup instructions and architecture overview (up to date, last edited 2 weeks ago)
-2. package.json scripts — `npm run dev`, `npm test`, `npm run build`, `npm run seed`
-3. src/config/ — environment variable definitions and feature flag schema
-4. prisma/schema.prisma — data model (3 main tables: Flag, Variant, Assignment)
-
-Important commands:
-- npm run dev       — Next.js dev server on port 3000
-- npm test          — Vitest test suite (47 tests, all passing)
-- npm run seed      — seed local database with sample flags
-- npx prisma studio — open database GUI
-
-Directory overview:
-- src/app/          — Next.js App Router pages and layouts
-- src/lib/          — shared utilities (flag evaluation engine, auth helpers)
-- src/components/   — React UI components
-- prisma/           — database schema and migrations
-- e2e/              — Playwright end-to-end tests
-
-Notable conventions:
-- Server components by default; client components marked with "use client"
-- Flag evaluation happens server-side via src/lib/evaluate.ts
-- Auth is handled via NextAuth with GitHub OAuth only
-
-Recommended next step: Run `npm run dev && npm run seed` to get a local instance with sample data, then explore the flag management UI at /flags.
-```
-
-## Example 3 — Sample completed output
-
-User request:
-
-```text
-Can you explain how this service is structured before we add a queue worker?
-```
-
-### Completed output
-
-```
-Project purpose: Order processing microservice — receives orders via REST API, persists to PostgreSQL, publishes events to RabbitMQ.
-
-Architecture summary: Express.js app using a layered structure (routes → controllers → services → repositories). Bull is already listed in package.json but no active queue consumer exists.
-
-Major components:
-- src/routes/       — REST endpoint definitions
-- src/controllers/  — request handling and validation
-- src/services/     — business logic (OrderService, PaymentService)
-- src/repositories/ — Knex-based database access
-- src/events/       — RabbitMQ publisher (no consumer yet)
-
-Important commands:
-- npm run dev       — start with hot reload
-- npm test          — jest unit + integration tests
-- npm run migrate   — run Knex migrations
-
-Notable conventions:
-- All services are instantiated via a simple DI container in src/container.ts
-- Tests use a shared test database seeded per suite
-
-Open questions:
-- Is Bull the intended queue driver, or should the new worker use the existing RabbitMQ publisher?
-- Are there any existing retry/dead-letter conventions?
-
-Recommended next reads: src/events/publisher.ts, src/container.ts, config/queue.ts (if present)
-```

package/skills/repo-onboarding/meta.yaml

@@ -1,25 +0,0 @@
-name: repo-onboarding
-version: 0.1.0
-category: discovery
-summary: Build a practical map of an unfamiliar repository before making claims or edits.
-summary_vi: Xây dựng bản đồ thực tế của repo lạ trước khi đưa ra nhận định hoặc sửa code.
-triggers:
-  - explain this repo
-  - onboard into a codebase
-  - understand architecture before changing code
-inputs:
-  - repository files
-  - README and operating docs when present
-outputs:
-  - architecture summary
-  - important commands
-  - open questions and next reads
-constraints:
-  - prefer source-grounded observations
-  - do not infer architecture from names alone
-related_skills:
-  - using-skills
-  - planning
-  - research
-  - feature-delivery
-  - docs-writer

package/skills/repo-onboarding/references/output-template.md

@@ -1,24 +0,0 @@
-## Project Purpose
-
-- What the project is for
-
-## Architecture Summary
-
-- Runtime or framework:
-- Major subsystems:
-- External integrations:
-
-## Important Commands
-
-- install:
-- test:
-- build:
-- run:
-
-## Open Questions
-
-- Unknowns that still need deeper inspection
-
-## Recommended Next Reads
-
-- Files or directories to inspect next