opendatadiscovery
- 27 skills
- 0 followers
- 7 hours ago last updated
- ▌ Scan · opendatadiscoveryRun an audit scanner against ODD repositories. Reads scanner definition, picks unscanned items from coverage manifest, writes findings, updates navigation.
- ▌
- ▌ Panel · opendatadiscoveryRun the methodology meta-review — a single methodology-reviewer agent that traces the whole current methodology (APPROACH.md, the ADRs, the agent contracts, the skills, the playbooks, the case-law, the live artefacts), diffs against the prior review, runs fresh blind spot-checks against real source, and emits real gaps + improvement proposals at lineage/{repo}/meta-reviews/{date}/review.md. `/panel` runs it; `/panel --show` prints the latest; `/panel validate` runs the acceptance-corpus check.
- ▌ Probe · opendatadiscoveryRun the probe-driven validation rounds for the agentic ontology — Type 4 (adversarial — capability-negation / cross-product-fabrication / synonym-swap-with-negation, ≥2 of 3 PASS) and Type 6 (implicit-ADR confirmation — maintainer writes 5 ADRs they know are followed; ≥3 of 5 must surface in implicit-adrs.md top-10). Both rounds are MAINTAINER-AUTHORED; this skill is the protocol mechanics, not the answers.
- ▌ Enrich · opendatadiscoveryRun the file-analyser subagent against one or more substrate nodes to produce per-node semantic enrichment sidecars. Resolves a path / node-id / batch spec to substrate nodes; spawns file-analyser per node; validates the resulting sidecar against the schema; updates the manifest's `enrichment` block.
- ▌ Orient · opendatadiscoveryQuick orientation for a new session — shows system overview, current state, and available actions.
- ▌ Review · opendatadiscoveryVerify a `review-ready` work item (or an entire batch) meets every acceptance criterion and every Quality Bar gate. Reject by default — each check requires cited evidence. Must run in a session distinct from the `/implement` session that produced the item.
- ▌ Status · opendatadiscoveryShow current progress of the audit and implementation system — scanner completion, backlog counts, blockers.
- ▌ Triage · opendatadiscoveryConvert raw scanner findings into atomic work items in the backlog. Assigns priority, category, effort, and identifies file conflicts.
- ▌ Streams · opendatadiscoveryThe parallel-work janitor. Lists every active /contribute + /review + probe-run stream from state/active-streams.yaml, reconciles each against the LIVE working trees (never the records), flags STALE / ORPHANED streams, and offers resume / reclaim / discard — with the invariant that no resource is reclaimed until its work is captured. Run it to see what is in flight, to pick a non-colliding namespace before starting a stream, or to clean up after abandoned work.
- ▌
- ▌ Coverage · opendatadiscoveryShow scan coverage across all scanners — what's been analyzed, what remains, what changed since last scan.
- ▌ Navigate · opendatadiscoveryFind where a feature, component, or concept lives in the ODD codebase. Uses the navigation index for O(1) lookups.
- ▌
- ▌
- ▌ Enumerate · opendatadiscoveryGenerate or refresh coverage manifest for a scanner — lists ALL items in scope so scans can track progress across sessions.
- ▌ Implement · opendatadiscoveryWork a batch of backlog items end-to-end as a maintainer — hold the Implementation Quality Bar, run the Pre-authoring stance check, log follow-ups on disk, flip items to `review-ready`, and ship one PR per repo per batch.
- ▌
- ▌ Probe Run · opendatadiscoveryRun one or more dynamic-verification probes against a local ephemeral docker-compose mirror of the target system. Captures observation traces as committed artefacts at `lineage/{repo}/probe-runs/{date}-{probe_id}.yaml` and merges measured values back into `feature-flows.yaml`, `test-map.yaml`, and per-sidecar `confidence_per_field` annotations. Local-only execution per APPROACH.md section 5 rule 12 + section 9 — no remote infrastructure ever. Slice 2 of `adrs/drafts/dynamic-verification-layer.md`.
- ▌ Contribute · opendatadiscoveryResolve a GitHub issue on opendatadiscovery/odd-platform end-to-end as a virtual contributor — scope, reproduce, root-cause, plan (GATE 1), change code, add unit + integration tests, update docs + ontology, open a DRAFT PR (GATE 2). Composes the ontology / test / doc / adr machinery; posts clarifying + root-cause comments via a scoped-token GitHub App; never merges.
- ▌ Next Batch · opendatadiscoveryAutonomous batch driver for the rev-2 agentic-ontology sprint. Picks the next pending theme from state/sprint-themes.yaml, spawns 5 file-analyser subagents in parallel, then 5 reducers in parallel, merges deltas, refreshes coverage, appends the investigator-log entry, commits, pushes to remote, marks the theme done. Designed to be fired by `/loop` overnight without maintainer input.
- ▌ Ingest Docs · opendatadiscoveryIngest the live documentation manual into the ontology as ground-truth Doc nodes, then enrich them with doc→ontology DESCRIBES links. Runs the mechanical doc extractor (docs-ingest → doc-nodes.jsonl, split by heading/anchor, prose referenced from ../documentation), rebuilds the graph (embeds the doc prose), spawns the doc-analyser subagent per un-enriched page (live-URL verification + DESCRIBES to the concepts/features/code each page documents + doc-claim-vs-code drift), and reports the consistency dashboard. Per adrs/drafts/ground-truth-lineage.md (Phase 1).
- ▌ Probe Define · opendatadiscoveryGenerate probe-skeleton YAML files at `lineage/{repo}/probes/{P-NNN}.yaml` from `feature-flows.yaml`'s uncovered test-matrix cells. Each skeleton carries the feature_id + test_class + cross-references + a TODO-marked arrange/act/observe/assert block the maintainer fills in. Accelerates probe corpus growth — slice 4 of dynamic-verification ADR. Local-only per APPROACH.md section 5 rule 12.
- ▌
- ▌
- ▌ Reflect Feature · opendatadiscoveryRun the feature-reflector subagent (Layer 4b — top-down product-owner reflection) over one composed feature flow. Produces `lineage/{repo}/feature-reflections/detail/{F-NNN}.yaml` with a stepped-back product-owner narrative + 5-15 falsifiable user-facing hypotheses + per-hypothesis verdicts (confirmed / contradicted / partial / probe-needed) traced through the implementation chain. Contradictions are surfaced as bug-candidate / caveat-candidate findings — cross-file intent-vs-implementation drifts no single sidecar can see in isolation. Per APPROACH.md section 15 + rev-5 LSN-020 case-law.
- ▌