tmforum-oda
- 24 skills
- 0 followers
- 3 hours ago last updated
- ▌ Lint Usecase Draft · tmforum-odaChecks a draft TM Forum use-case DOCX or Markdown document's structure against document shapes known to convert badly through this repo's own docx2md.py pipeline, and flags anything likely to silently lose content before the document is ever submitted. Use this as a pre-submission QA pass for someone authoring a new or revised use case.
- ▌ Assess Change Impact · tmforum-odaGiven a TM Forum ODA component (TMFCxxx) or Open API (TMFxxx) id and a proposed change (deprecation, breaking version bump, removal), lists every TMFSxxx use case that depends on it, describes specifically how each one uses it, and drafts a maturity-weighted migration/impact report. Use this before deprecating, breaking, or removing a component or API.
- ▌ Process Usecase Media · tmforum-odaGiven a TMFSxxx use-case id, processes every image in its knowledge/use-cases/{ID}/media/ folder in turn -- classifies it, renames it descriptively, reverse-engineers UML sequence diagrams and information/data-model diagrams into PlantUML .puml files, and writes a text-description.md for everything else -- updating the use case's own document body to match. Use this to enrich a use case's raw extracted images into agent-friendly formats. Unlike other skills here, this one writes to knowledge/, not just reads it.
- ▌ Check Usecase Maturity · tmforum-odaGiven a TM Forum ODA use-case id (TMFSxxx), reads its cached frontmatter and returns a plain-language maturity/trust verdict -- whether it's safe to build against today. Reads only YAML frontmatter, no document-body parsing. Use this before starting requirements or test-case work against any TMFSxxx use case.
- ▌ Deliver Oda Requirement · tmforum-odaGiven a plain-language requirement, orchestrates the full Discover-to-Run chain of existing consumer skills against it -- finding or decomposing the requirement, capturing it as requirements, drafting architecture/event designs, gating on validate-design-against-oda, generating a Build-stage implementation (asking which of the two options to use, never defaulting), generating mocks/tests/conformance checks, and auditing the result. Use this for an end-to-end requirement delivery; it adds no ODA reasoning of its own -- every real decision is made by the skill it invokes at that step, not by this one.
- ▌ Implement Oda Component · tmforum-oda bundle⚠ Builds & deploys — the one skill in this plugin with real side effects (builds/pushes Docker images, can `helm install`). Build a complete TM Forum ODA Component implementation from scratch, including Node.js microservice source code, Dockerfiles, and Kubernetes Helm charts. Use this skill whenever the user wants to: - Create, build, scaffold, implement, or generate an ODA Component - Build an implementation for a standard TMForum component (TMFC001 through TMFC062) - Generate source code and/or Helm charts following the ODA Component standard - Ask "how do I build TMFC006?" or "I want to implement Service Catalog Management" Invoke whenever you see: "create ODA component", "build TMForum component", "scaffold TMFC", "implement ODA", "new ODA component", or any mention of TMFCxxx component codes. For a lightweight, language-agnostic scaffold with no side effects instead of this full opinionated Node.js/Helm stack, see generate-implementation-scaffold-from-usecase.
- ▌ Process Component Media · tmforum-odaGiven a TMFCxxx component id, processes every image in its knowledge/components/{ID}/media/ folder in turn -- classifies it, renames it descriptively, reverse-engineers structured diagrams (the component architecture overview, eTOM-SID ABE link diagrams, API/Resource/Operation diagrams) into PlantUML .puml files, and writes a text-description.md for everything else -- updating the component's own {ID}.md body to match. Use this to enrich a component's raw extracted images into agent-friendly formats. Unlike other skills here, this one writes to knowledge/, not just reads it.
- ▌ Validate Design Against Oda · tmforum-odaGiven a proposed component or API design that claims to extend or depend on existing ODA components/APIs, checks those claims against the real cached specs and flags drift -- fields, operations, or behavior the design assumes exist but don't. Use this before building against an assumed ODA capability, to confirm the assumption is real.
- ▌ Generate API Conformance Tests · tmforum-odaGiven a TMFxxx id and version, generates conformance test assertions directly from its cached OpenAPI schema -- required-field presence, enum-value validity, declared operations per path, and expected status codes -- using real sample payloads as fixtures where they exist and pass/fail. If a real implementation (a base URL or example request/response pairs) is supplied, also reports pass/fail per assertion; without one, produces a standalone suite ready to run once an implementation exists. Use this to check or generate conformance tests for one specific TM Forum Open API, not a whole use case's flow (see generate-test-cases-from-usecase for that).
- ▌ Draft New Usecase From Scenario · tmforum-odaGiven a business scenario description, drafts a new TMFSxxx-shaped use-case document matching this corpus's own observed structure, citing real existing component/API ids wherever the scenario matches existing ODA capability and flagging genuine gaps rather than inventing plausible-sounding new ids. Use this when a requirement doesn't match any existing use case or known gap closely enough to just reuse.
- ▌ Generate API Mocks From Usecase · tmforum-odaGiven a TMFSxxx use-case id, uses its linked APIs' cached OpenAPI schemas and real sample payloads to scaffold a mock server or example request/response fixtures for integration testing before a real backend exists. Use this when asked for API mocks, stub responses, or test fixtures for a use case's dependencies.
- ▌ Review Architecture Against Oda · tmforum-odaGiven a description of a proposed or existing multi-component architecture (not scoped to one use case or one component), reviews it against the cached ODA corpus for duplicated ownership (a capability the architecture assigns to a new/custom component that an existing TMFCxxx already owns), point-to-point coupling (a direct interaction where an existing cached Open API already mediates that exact interaction type), and component-boundary bypass (a described interaction that reaches into another component's internals instead of its declared coreFunction). Use this for a whole-architecture ODA conformance review; see validate-design-against-oda for checking one design's specific claimed dependencies, and the audit-implementation-against-* skills for auditing one use case or one component already built.
- ▌ Draft Event Design For Component · tmforum-odaGiven a TMFCxxx component id (or one identified via decompose-requirement-against-oda/recommend-oda-components-for-requirement) and the APIs it exposes or depends on, drafts published/subscribed event definitions in the same shape every cached component.yaml's eventNotification block already uses -- resource-level create/attributeValueChange/stateChange/delete events tied to real resource names, never invented event types. Use this when a design needs new events and no existing eventNotification entry already covers them.
- ▌ Generate Test Cases From Usecase · tmforum-odaGiven a TM Forum ODA use-case id (TMFSxxx), reads its sequence-diagram section and linked component/API frontmatter, then drafts BDD-style (Gherkin) test scenarios grounded in the real component/API IDs and cached OpenAPI schemas in knowledge/apis/ -- never invented ones. Mirrors oda-canvas's write-bdd-feature Gherkin conventions, pointed at real use-case content instead of hand-written scenarios. Use this when asked to generate test cases, BDD scenarios, or acceptance tests for a TMFSxxx use case.
- ▌ Capture Requirements From Usecase · tmforum-odaGiven a TMFSxxx use-case id, reads its Description/Scope/Objective sections and drafts user stories and acceptance criteria, citing the exact component/API ids from frontmatter for any integration touchpoint rather than inventing them. Use this to turn an existing use case into requirements a delivery team can work from.
- ▌ Decompose Requirement Against Oda · tmforum-odaGiven a plain-language requirement that `recommend-oda-components-for-requirement` couldn't match to an existing use case, produces a structured ODA-aligned decomposition (business intent, candidate eTOM processes, candidate components/APIs, candidate information entities, and explicit open questions) instead of leaving the requirement as unstructured prose. Use this when nothing in `knowledge/index/use-cases.json` matches closely enough to reuse.
- ▌ Feedback Propose Matrix Correction · tmforum-odaTurns knowledge/index/matrix-discrepancies.md's logged use-case/matrix disagreements into specific, submittable correction proposals for the next IG1228 revision -- e.g. which TMFCxxx rows should be added or removed for a given TMFSxxx use case. Use this to act on a logged discrepancy rather than just read about it.
- ▌ Propose Component Or API Extension · tmforum-odaGiven a capability gap (e.g. from knowledge/index/gaps-backlog.md) and the nearest existing component/API, drafts a proposed extension -- a new component skeleton in IG1242's real shape, or a new field/endpoint on an existing OpenAPI schema -- consistent with the corpus's own conventions and grounded in a real cached spec. Use this to design a fix for a gap, not just identify one.
- ▌ Audit Implementation Against Usecase · tmforum-odaGiven a TMFSxxx use-case id and an existing implementation (codebase, API contract, or integration config), checks whether the implementation actually follows the use case's described flow and calls the right real APIs, flagging drift from spec. Use this to audit an existing system against ODA, not to design a new one.
- ▌ Audit Implementation Against Component · tmforum-odaGiven a TMFCxxx component id and a description of an existing implementation, checks conformance at Component-boundary granularity, split explicitly the way component.yaml itself is split -- Core Function (does it expose/consume the real exposedAPIs/dependentAPIs) and Supporting Function (does it provide the managementFunction/securityFunction behaviors the spec describes) -- reported as two separate dimensions, never blended into one score. Use this to audit a component's full contract independent of any specific use case; see audit-implementation-against-usecase for flow-level auditing against one use case's narrative instead.
- ▌ Draft Architecture Diagram From Usecase · tmforum-odaGiven a TMFSxxx use-case id, reads its sequence-diagram images and linked component/API frontmatter, and emits a Mermaid sequence or architecture diagram as a design-doc-ready artifact, citing only real component/API ids. Use this when asked for an architecture diagram, sequence diagram, or component interaction diagram for a use case.
- ▌ Recommend Oda Components For Requirement · tmforum-odaGiven a plain-language business requirement (not yet a TMFSxxx id), finds the closest-matching existing use case(s) by name and component/API overlap, and proposes a starting architecture grounded in real component/API ids -- never invented ones. Use this at the start of a design, before a requirement has been mapped to a specific ODA use case.
- ▌ Feedback Harvest Gaps From Lessons Learned · tmforum-odaMines every TMFSxxx use case's "Lessons learned"/"Impacts identified" sections for capability gaps TM Forum's own authors have already written down -- proposed new ODA components or Open APIs that don't exist yet -- cross-checks each against the current knowledge/index/{components,apis}.json to confirm it's still genuinely missing, and consolidates cross-corroborated gaps (the same gap raised independently in multiple use cases) into one backlog entry. Use this to find what ODA is missing without re-reading the whole corpus by hand.
- ▌ Generate Implementation Scaffold From Usecase · tmforum-odaGiven a TMFSxxx use-case id (or an explicit component/API set from recommend-oda-components-for-requirement/decompose-requirement-against-oda), generates typed request/response models and route/handler stubs directly from its linked APIs' cached OpenAPI schemas, in a language of the caller's choosing -- with a TODO marker at every point real domain logic belongs. Also handles the case where a non-ODA legacy interface needs an anti-corruption adapter layer into the chosen ODA contract. Use this when a design needs implementation scaffolding, not implemented business logic, and does not want TM Forum's own opinionated Node.js/Helm reference stack (see implement-oda-component for that alternative).