@codepassion/skills 1.1.1 → 1.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (41) hide show
  1. package/README.md +6 -1
  2. package/SKILLS.md +6 -1
  3. package/bin/c9n-skills.js +28 -3
  4. package/install.sh +25 -2
  5. package/package.json +1 -1
  6. package/skills/c9n/SKILL.md +344 -0
  7. package/skills/c9n-deliverables/REFERENCE.md +97 -0
  8. package/skills/c9n-deliverables/SKILL.md +63 -0
  9. package/skills/c9n-deliverables/scripts/data-dictionary.cjs +49 -0
  10. package/skills/c9n-deliverables/scripts/export-openapi.cjs +35 -0
  11. package/skills/c9n-deliverables/scripts/md-to-pdf.mjs +73 -0
  12. package/skills/c9n-deliverables/scripts/openapi-to-pdf.mjs +78 -0
  13. package/skills/c9n-deliverables/scripts/snapshot-source.sh +23 -0
  14. package/skills/c9n-pipeline/SKILL.md +128 -0
  15. package/skills/c9n-pipeline/templates/Dockerfile.api +49 -0
  16. package/skills/c9n-pipeline/templates/Dockerfile.service +45 -0
  17. package/skills/c9n-pipeline/templates/Dockerfile.web +50 -0
  18. package/skills/c9n-pipeline/templates/dockerignore +18 -0
  19. package/skills/c9n-pipeline/templates/workflows/_build-job.partial.yml +13 -0
  20. package/skills/c9n-pipeline/templates/workflows/_deploy-job.partial.yml +17 -0
  21. package/skills/c9n-pipeline/templates/workflows/_migration-check.partial.yml +16 -0
  22. package/skills/c9n-pipeline/templates/workflows/ci.yml +38 -0
  23. package/skills/c9n-pipeline/templates/workflows/deployment.yml +21 -0
  24. package/skills/c9n-sentry/REFERENCE.md +172 -0
  25. package/skills/c9n-sentry/SKILL.md +53 -0
  26. package/skills/c9n-spec/SKILL.md +92 -0
  27. package/skills/c9n-spec/templates/.github/pull_request_template.md +29 -0
  28. package/skills/c9n-spec/templates/AGENTS.md +179 -0
  29. package/skills/c9n-spec/templates/CLAUDE.md +6 -0
  30. package/skills/c9n-spec/templates/CONTEXT.md +53 -0
  31. package/skills/c9n-spec/templates/DESIGN.md +73 -0
  32. package/skills/c9n-spec/templates/docs/SRS.md +37 -0
  33. package/skills/c9n-spec/templates/docs/adr/0001-spec-driven-iso29110-docs.md +44 -0
  34. package/skills/c9n-spec/templates/docs/adr/_TEMPLATE.md +26 -0
  35. package/skills/c9n-spec/templates/docs/agents/domain.md +43 -0
  36. package/skills/c9n-spec/templates/docs/agents/issue-tracker.md +22 -0
  37. package/skills/c9n-spec/templates/docs/agents/triage-labels.md +27 -0
  38. package/skills/c9n-spec/templates/docs/architecture.md +50 -0
  39. package/skills/c9n-spec/templates/docs/features/_TEMPLATE.md +34 -0
  40. package/skills/c9n-spec/templates/docs/test-plan.md +30 -0
  41. package/skills/c9n-spec/templates/docs/traceability.md +27 -0
package/skills/c9n-spec/templates/DESIGN.md ADDED
@@ -0,0 +1,73 @@
1
+ # DESIGN.md — {{PROJECT_NAME}} Visual Design System
2
+
3
+ Visual design language for AI-assisted UI generation. This governs the **web app**.
4
+
5
+ > **This file is intent + rules, not a token dump.** Raw token _values_ live in code and are the
6
+ > source of truth — never copy them here (they would drift). This file documents what code can't
7
+ > express: when to use what, and why.
8
+
9
+ ## Source of truth (read these for values)
10
+
11
+ | What | File |
12
+ | ----------------------------------- | ------------------------------------- |
13
+ | Palette, breakpoints, fonts, radius | `<tailwind.config.*>` |
14
+ | Semantic tokens (light/dark CSS) | `<globals.css>` |
15
+ | shadcn config | `<components.json>` |
16
+ | Component inventory | `<src/components/>` |
17
+
18
+ When generating UI, read the files above for exact values. Use this document for the rules below.
19
+
20
+ ---
21
+
22
+ ## Brand intent
23
+
24
+ <!-- One paragraph: what the product is, the feeling, the guiding aesthetic principle. -->
25
+
26
+ Guiding principles:
27
+
28
+ - **<Principle>** — …
29
+
30
+ ## Color usage rules
31
+
32
+ - **Semantic first.** Build with semantic tokens (`background`, `foreground`, `primary`, `muted`,
33
+ `accent`, `border`, `ring`) so light/dark mode works automatically. Reach for raw primitives
34
+ only for brand moments the semantic set can't express.
35
+ - **<Accent> = brand accent.** Primary CTAs, active states, key numbers. Used sparingly.
36
+ - **Destructive is functional, not decorative** — errors and irreversible actions only.
37
+
38
+ ## Typography rules
39
+
40
+ - **<Display face> for headings, <body face> for everything else.** Map new headings to an
41
+ existing tier; don't re-roll heading styles.
42
+ - **<Locale> note** — every text style must render the primary language cleanly; verify with real
43
+ content, not Latin placeholder.
44
+
45
+ ## Layout & spacing
46
+
47
+ - **Mobile-first** against the project breakpoints.
48
+ - Use the grid utilities for gutters/rhythm rather than ad-hoc padding.
49
+ - Radius is consistent — derive from the `--radius` token.
50
+
51
+ ## Components
52
+
53
+ - **shadcn is the base layer.** Extend primitives; don't fork them. Domain components compose them.
54
+ - **Match the existing component vocabulary** before inventing a new one — check the inventory.
55
+
56
+ ## Dark mode
57
+
58
+ Class-based. Both themes fully defined in code. Always build with semantic tokens; never hardcode
59
+ a hex that only works in one theme.
60
+
61
+ ---
62
+
63
+ ## Maintenance (behavior-change rule for design)
64
+
65
+ | Change | Action |
66
+ | ----------------------------------------------------------------- | ----------- |
67
+ | **Visual _intent_** changes (accent role, type-pairing, aesthetic) | Update this file |
68
+ | A **token _value_** changes in config/CSS | Code-only — no update here |
69
+ | New reusable component pattern with usage rules | Add a line under Components |
70
+
71
+ This file is a standing reference (like `CONTEXT.md`), not a gated per-feature work product. It is
72
+ **visual** design only; **software** design lives in `docs/architecture.md` and the `## Design`
73
+ sections of `docs/features/*.md`. See `AGENTS.md › Spec-Driven Development Protocol`.
package/skills/c9n-spec/templates/docs/SRS.md ADDED
@@ -0,0 +1,37 @@
1
+ # Software Requirements Specification (SRS) — Master Registry
2
+
3
+ ISO/IEC 29110 Requirements Specification work product. This is the **registry** of all features
4
+ and their requirement IDs. A feature starts as a section here; when it outgrows a section it
5
+ graduates to a single file `docs/features/<name>.md` (with a one-line pointer below); only when a
6
+ section within that file outgrows one file does it split into a `docs/features/<name>/` folder.
7
+
8
+ This registry is also the authoritative list of **feature IDs**: each feature's `Short-code` is
9
+ its unique ID (2–4 letter mnemonic) and prefixes all its requirement/test IDs. Short-codes are
10
+ append-only — a new feature picks a fresh, unused code; never reuse one. See
11
+ [`AGENTS.md`](../AGENTS.md) for the full ID convention and approval gates.
12
+
13
+ ---
14
+
15
+ ## Feature registry
16
+
17
+ | Feature | Short-code | Status | SRS location |
18
+ | ------- | ---------- | ------ | ------------ |
19
+ | <Example feature> | `EX` | Draft → SRS in progress | _(this file)_ |
20
+
21
+ > **As-built stubs** are reverse-documented from code, not grilled — requirements describe current
22
+ > behavior at low confidence and carry no test cases yet. Deepen a stub to the full chain
23
+ > (acceptance criteria + Test Cases + Traceability) when its module is next touched.
24
+
25
+ ---
26
+
27
+ ## Non-functional requirements (system-wide)
28
+
29
+ Each NFR is tagged **[verified]** (confirmed against the code as-built) or **[target]** (the
30
+ intended rule, not yet fully enforced — gap noted). Don't promote a target to verified without
31
+ checking the code.
32
+
33
+ | ID | Requirement | State |
34
+ | ------------- | ----------- | ----- |
35
+ | `SYS-NFR-001` | <e.g. errors reported via the central error path; no console.* for errors> | **[target]** |
36
+
37
+ Append new system-wide NFRs here; never renumber existing ones.
package/skills/c9n-spec/templates/docs/adr/0001-spec-driven-iso29110-docs.md ADDED
@@ -0,0 +1,44 @@
1
+ # ADR 0001 — Spec-Driven, ISO/IEC 29110-Aligned, Agent-Readable Documentation
2
+
3
+ - **Status:** Accepted
4
+ - **Date:** {{DATE}}
5
+ - **Deciders:** {{DECIDER}}
6
+
7
+ ## Context
8
+
9
+ AI agents (and humans) repeatedly lose context on a codebase: unstructured prompts, specs living
10
+ disconnected from code, and no gate between "idea" and "production code." We want spec-driven
11
+ development — approve a blueprint before code — with a recognized standard behind it. As a small
12
+ team (VSE), **ISO/IEC 29110** (Basic Profile, Software Implementation process) fits exactly.
13
+
14
+ ## Decision
15
+
16
+ Adopt a repo-resident `docs/` system as the single source of truth:
17
+
18
+ - Authoritative work products in `docs/` (PR-reviewed alongside code).
19
+ - ISO 29110 SI work products only: SRS, Architecture, Traceability, Test Cases. PM work products
20
+ stay in the issue tracker / project tools.
21
+ - Master-then-split organization; feature-prefixed append-only IDs (`PAY-REQ-001`).
22
+ - Three sequential approval gates (SRS → Design + Test Plan → Code).
23
+ - Enforcement by convention: Definition of Ready / Definition of Done in `AGENTS.md`, with the PR
24
+ template checklist as the merge gate. No hooks initially.
25
+ - Behavior-change rule decides when a change must update docs.
26
+ - Reverse-documentation: every existing module gets an **as-built stub** (requirements only, low
27
+ confidence, no test cases), deepened to the full chain when the module is next touched.
28
+
29
+ ## Consequences
30
+
31
+ **Positive:** Specs and code never drift (same PR); agents have a deterministic read-before
32
+ target; traceability satisfies the standard; predictable, low-hallucination changes.
33
+
34
+ **Negative / trade-offs considered:**
35
+
36
+ - Convention over hooks → relies on discipline + PR checklist (chosen for flexibility; hooks
37
+ remain a later backstop).
38
+ - Per-feature deep docs are lazy → the as-is system is only shallowly mapped until touched
39
+ (accepted to avoid documenting frozen code).
40
+
41
+ ## Alternatives rejected
42
+
43
+ - Specs living outside the repo (drift from code, invisible in PRs).
44
+ - Full deep reverse-scan of all modules up front (weeks documenting stable code).
package/skills/c9n-spec/templates/docs/adr/_TEMPLATE.md ADDED
@@ -0,0 +1,26 @@
1
+ # ADR NNNN — <Short title of the decision>
2
+
3
+ - **Status:** Proposed | Accepted | Superseded by ADR-XXXX
4
+ - **Date:** YYYY-MM-DD
5
+ - **Deciders:** <names>
6
+
7
+ > Only write an ADR when **all three** hold: (1) hard to reverse, (2) surprising without context,
8
+ > (3) the result of a real trade-off with genuine alternatives. Otherwise skip it.
9
+
10
+ ## Context
11
+
12
+ <!-- The forces at play: what problem, what constraints, what made this a real decision. -->
13
+
14
+ ## Decision
15
+
16
+ <!-- What we chose, stated plainly. -->
17
+
18
+ ## Consequences
19
+
20
+ **Positive:** …
21
+
22
+ **Negative / trade-offs considered:** …
23
+
24
+ ## Alternatives rejected
25
+
26
+ - <Alternative> — <why not>.
package/skills/c9n-spec/templates/docs/agents/domain.md ADDED
@@ -0,0 +1,43 @@
1
+ # Domain Docs
2
+
3
+ How the engineering skills should consume this repo's domain documentation when exploring the
4
+ codebase.
5
+
6
+ This repo is **single-context**: one `CONTEXT.md` + `docs/adr/` at the root.
7
+
8
+ ## Before exploring, read these
9
+
10
+ - **`CONTEXT.md`** at the repo root — the ubiquitous-language glossary.
11
+ - **`docs/adr/`** — read ADRs that touch the area you're about to work in.
12
+
13
+ > Note: this repo also runs a spec-driven, ISO/IEC 29110-aligned doc system (see `AGENTS.md`). For
14
+ > feature work, also consult `docs/SRS.md`, `docs/architecture.md`, and the relevant
15
+ > `docs/features/<name>.md` per the protocol in `AGENTS.md`.
16
+
17
+ If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest
18
+ creating them upfront. The producer skill (`/grill-with-docs`) creates them lazily when terms or
19
+ decisions actually get resolved.
20
+
21
+ ## File structure
22
+
23
+ ```text
24
+ /
25
+ ├── CONTEXT.md
26
+ ├── docs/adr/
27
+ │ └── 0001-spec-driven-iso29110-docs.md
28
+ └── apps/, packages/
29
+ ```
30
+
31
+ ## Use the glossary's vocabulary
32
+
33
+ When your output names a domain concept (an issue title, a refactor proposal, a hypothesis, a test
34
+ name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary avoids.
35
+
36
+ If the concept you need isn't in the glossary yet, that's a signal — either you're inventing
37
+ language the project doesn't use (reconsider) or there's a real gap (note it for `/grill-with-docs`).
38
+
39
+ ## Flag ADR conflicts
40
+
41
+ If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
42
+
43
+ > _Contradicts ADR-0001 (spec-driven ISO 29110 docs) — but worth reopening because…_
package/skills/c9n-spec/templates/docs/agents/issue-tracker.md ADDED
@@ -0,0 +1,22 @@
1
+ # Issue tracker: GitHub
2
+
3
+ Issues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
4
+
5
+ ## Conventions
6
+
7
+ - **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
8
+ - **Read an issue**: `gh issue view <number> --comments`.
9
+ - **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
10
+ - **Comment on an issue**: `gh issue comment <number> --body "..."`
11
+ - **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
12
+ - **Close**: `gh issue close <number> --comment "..."`
13
+
14
+ Infer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.
15
+
16
+ ## When a skill says "publish to the issue tracker"
17
+
18
+ Create a GitHub issue.
19
+
20
+ ## When a skill says "fetch the relevant ticket"
21
+
22
+ Run `gh issue view <number> --comments`.
package/skills/c9n-spec/templates/docs/agents/triage-labels.md ADDED
@@ -0,0 +1,27 @@
1
+ # Triage Labels
2
+
3
+ The skills speak in terms of five canonical triage roles. This file maps those roles to the actual
4
+ label strings used in this repo's issue tracker.
5
+
6
+ | Canonical role | Label in our tracker | Meaning |
7
+ | ----------------- | -------------------- | ---------------------------------------- |
8
+ | `needs-triage` | `needs-triage` | Maintainer needs to evaluate this issue |
9
+ | `needs-info` | `needs-info` | Waiting on reporter for more information |
10
+ | `ready-for-agent` | `ready-for-agent` | Fully specified, ready for an AFK agent |
11
+ | `ready-for-human` | `ready-for-human` | Requires human implementation |
12
+ | `wontfix` | `wontfix` | Will not be actioned |
13
+
14
+ When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label
15
+ string from this table. Edit the right-hand column to match whatever vocabulary you actually use.
16
+
17
+ ## Label provisioning
18
+
19
+ Create the labels on first use:
20
+
21
+ ```bash
22
+ gh label create needs-triage --description "Maintainer needs to evaluate" --color FBCA04
23
+ gh label create needs-info --description "Waiting on reporter" --color D4C5F9
24
+ gh label create ready-for-agent --description "Fully specified, AFK-ready" --color 0E8A16
25
+ gh label create ready-for-human --description "Needs human implementation" --color 1D76DB
26
+ gh label create wontfix --description "Will not be actioned" --color CCCCCC
27
+ ```
package/skills/c9n-spec/templates/docs/architecture.md ADDED
@@ -0,0 +1,50 @@
1
+ # Software Architecture — {{PROJECT_NAME}}
2
+
3
+ ISO/IEC 29110 Software Design work product (system level). This is the **as-is map** of the
4
+ shipped system: module boundaries, data model, and integration points. Per-feature design detail
5
+ lives in the `## Design` section of `docs/features/<name>.md`. Decisions with lasting consequences
6
+ are recorded as ADRs in `docs/adr/`.
7
+
8
+ ---
9
+
10
+ ## System context
11
+
12
+ <!-- One paragraph: runtime, apps, datastore, external integrations. Then a context diagram. -->
13
+
14
+ ```
15
+ <Actor> ─→ <Frontend> ─→ <API> ─→ <Database>
16
+ ├─→ <Integration A>
17
+ └─→ <Integration B>
18
+ ```
19
+
20
+ ## Module map
21
+
22
+ | Module | Prefix / location | Responsibility |
23
+ | ------ | ----------------- | -------------- |
24
+ | `<module>` | `/<route>` | … |
25
+
26
+ ## Module conventions
27
+
28
+ <!-- The shape every module follows. C9N API default: models/ (Zod namespaces) ·
29
+ use-cases/ (abstract static classes, execute() as a table of contents) ·
30
+ services/ (external integrations) · barrel exports · index.ts (routes).
31
+ See AGENTS.md for the full pattern. -->
32
+
33
+ ## Data model (key relationships)
34
+
35
+ ```
36
+ <Entity A> → <Entity B> (1:N)
37
+ …
38
+ ```
39
+
40
+ ## Integration boundaries
41
+
42
+ | Integration | Direction | Notes |
43
+ | ----------- | --------- | ----- |
44
+ | <Service> | out / in | … |
45
+
46
+ ## Per-feature design
47
+
48
+ Per-feature design lives in the `## Design` section of each `docs/features/<name>.md`. The
49
+ complete, authoritative list of features (with short-codes and links) is the registry in
50
+ [`SRS.md`](SRS.md) — not duplicated here.
package/skills/c9n-spec/templates/docs/features/_TEMPLATE.md ADDED
@@ -0,0 +1,34 @@
1
+ # <Feature Name> (`<SHORT-CODE>`)
2
+
3
+ > Per-feature deep doc. Short-code is the feature ID and prefixes every child ID
4
+ > (`<SHORT-CODE>-REQ-001`, `<SHORT-CODE>-TC-001`) — append-only, never renumber. Register the
5
+ > feature + short-code in [`../SRS.md`](../SRS.md). See [`../../AGENTS.md`](../../AGENTS.md) for
6
+ > the protocol and approval gates.
7
+
8
+ ## 1. Requirements
9
+
10
+ <!-- The _what_. Acceptance-criteria-grade once Gate 1 is approved. -->
11
+
12
+ | ID | Requirement | Acceptance criteria |
13
+ | ------------------- | ----------- | ------------------- |
14
+ | `<SHORT-CODE>-REQ-001` | … | … |
15
+
16
+ ## 2. Design
17
+
18
+ <!-- The _how_ (software design). Module(s), data flow, key decisions. Link ADRs if any. -->
19
+
20
+ ## 3. Test Plan
21
+
22
+ <!-- How we prove it: levels, scope, what's unit vs integration vs E2E. -->
23
+
24
+ ## 4. Test Cases
25
+
26
+ | ID | Scenario | Input | Expected | Traces to |
27
+ | ------------------ | -------- | ----- | -------- | --------- |
28
+ | `<SHORT-CODE>-TC-001` | … | … | … | `<SHORT-CODE>-REQ-001` |
29
+
30
+ ## 5. Traceability
31
+
32
+ | Requirement | Design element | Test cases |
33
+ | ------------------- | -------------- | ---------- |
34
+ | `<SHORT-CODE>-REQ-001` | § 2 <section> | `<SHORT-CODE>-TC-001` |
package/skills/c9n-spec/templates/docs/test-plan.md ADDED
@@ -0,0 +1,30 @@
1
+ # Test Plan — Master Strategy
2
+
3
+ ISO/IEC 29110 Test Cases & Procedures work product (system level). Defines how the system is
4
+ proven. Per-feature cases live in the `## Test Cases` section of `docs/features/<name>.md`.
5
+
6
+ ---
7
+
8
+ ## Test levels
9
+
10
+ | Level | Scope | Where |
11
+ | ------------ | ------------------------------------- | ------------------- |
12
+ | Unit | Use cases / services in isolation | <app> test suite |
13
+ | Integration | Route → use case → DB, external mocks | <app> test suite |
14
+ | Manual / E2E | End-to-end user flows | Documented per feature |
15
+
16
+ ## Conventions
17
+
18
+ - Test case IDs: `<FEATURE>-TC-NNN`, append-only (see [`AGENTS.md`](../AGENTS.md)).
19
+ - Each test case names: scenario, input, expected, and the requirement it traces to.
20
+ - A bug fix toward spec adds a **regression** test case rather than editing the SRS.
21
+
22
+ ## Per-feature plans
23
+
24
+ > **Characterization baselines.** As-built modules carry 🧪 _characterization_ cases — derived
25
+ > from the code to lock in **current behavior** for regression, not grilled specs. Promote a
26
+ > module to a grilled spec (acceptance criteria) when it is next deliberately changed.
27
+
28
+ | Feature | Plan | Cases |
29
+ | --------- | ----------------------------------------------- | ---------------------------------------------- |
30
+ | <Example> | [`features/<name>.md § 3`](features/<name>.md#3-test-plan) | [`§ 4`](features/<name>.md#4-test-cases) |
package/skills/c9n-spec/templates/docs/traceability.md ADDED
@@ -0,0 +1,27 @@
1
+ # Traceability Record — Master Index
2
+
3
+ ISO/IEC 29110 Traceability Record. Bidirectional links from each requirement to its design element
4
+ and test cases. Per-feature matrices live in the `## Traceability` section of
5
+ `docs/features/<name>.md`; this file indexes them and holds system-wide links.
6
+
7
+ Every behavior-changing requirement MUST appear here with at least one test case.
8
+
9
+ ---
10
+
11
+ ## Per-feature traceability
12
+
13
+ | Feature | Matrix |
14
+ | ------- | ------ |
15
+ | <Example> | [`features/<name>.md § 5`](features/<name>.md#5-traceability) |
16
+
17
+ > 🧪 = **characterization baseline** (cases lock current behavior). Promote to a grilled spec when
18
+ > the module is next deliberately changed.
19
+
20
+ ## How to read a matrix
21
+
22
+ | Requirement | Design element | Test cases |
23
+ | ------------- | -------------------------- | -------------------------- |
24
+ | `EX-REQ-001` | `<name>.md § 2 <section>` | `EX-TC-001`, `EX-TC-002` |
25
+
26
+ - **Forward:** requirement → which design implements it → which tests prove it.
27
+ - **Backward:** a failing `EX-TC-006` → the requirement it guards (`EX-REQ-003`).