skilly. Buy ad slot
All skills
Testing · Documentation / AGENT SKILL

cto-build-framework-validator

garochee33/DSH
0 installs 4 GitHub stars
0

Validate CTO Build Framework governance artifacts and file evidence tied to specific versions.
Validate CTO Build Framework governance artifacts and file version-bound evidence (runs, reviews, evidence packets) without inflating claims. Use for independent re-execution, internal-consistency reviews, and verdict filing.

BEFORE YOU INSTALL

Understand the trade-offs.

SECURITY REVIEW

Not yet assessed

Review the original instructions and requested permissions before installing.

No security review is available for this catalog entry yet.

SKILL QUALITY

Not yet assessed

How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.

No quality assessment is available for this catalog entry yet.

The full skill.

Original instructions from the publisher’s SKILL.md

# CTO Build Framework Validator

Repo-local skill for governance validation work that must be evidence-bounded and reproducible. The framework's principle is that the system that builds the software cannot be the sole auditor of it.

## Core Objective

Produce filed, version-bound validation artifacts from the framework SSOT:

- run execution records
- review verdicts
- evidence packets
- explicit proof limits

## Non-Negotiables (Proof Doctrine)

- Only claim what evidence supports.
- Do not change domain status labels unless explicitly authorized by the framework owner.
- Evidence must be version-bound (commit/version + environment + date).
- Treat independent re-execution as a separate validation mode from artifact-only review.

### Doctrine sources (read these once before first review)

- `governance/audit-separation.md` — why builder ≠ auditor
- `governance/core-loop.md` — six-phase governance cycle
- `governance/release-gates.md` — what a release requires
- `governance/llm-operating-discipline.md` — operating constraints for AI-driven validation
- `governance/dev-auditor-protocol.md` — auditor scope and limits
- `governance/rollback-protocol.md` — when to revert
- `governance/ui-validation-protocol.md` — UI evidence requirements

## Canonical Entry Points (Read First)

- Operator entrypoint: `kb/ROLE-ENTRYPOINTS.md` § Validator
- Artifact map (quick): `kb/ARTIFACT-MAP.md`
- Repo state snapshot: `validation/project-closeout-index.md`
- Domain truth: `validation/domain-matrix.md`
- Run traceability: `validation/validation-run-index.md`
- Evidence roadmap / change-control: `validation/evidence-expansion-roadmap.md`

## Validation Modes

### 1) Independent Re-Execution

1. Identify the target run in `validation/validation-run-index.md`.
2. Execute the corresponding checklist under `validation/runs/` with no skipped items.
3. File a completed verdict under `validation/reviews/` using the templates below.
4. Attach or reference artifacts (screenshots/logs) per the run's acceptance criteria.
5. State execution environment, commit/version, date/time, and operator identity.

### 2) Internal Consistency Review (Artifact-Only)

1. Open the evidence packet under `validation/evidence-packets/`.
2. Confirm each claim is bounded and traceable to referenced artifacts.
3. File reviewer verdict under `validation/reviews/`.
4. Explicitly mark the mode as `artifact review only` (not independent re-execution).

## Templates by Step

| Step | Template (in `validation/templates/`) | Output destination |
|------|---------------------------------------|---------------------|
| Record a re-execution run | `domain-validation-run-template.md` | `validation/runs/{domain}-{project}-{date}.md` |
| Record a domain-level result | `domain-validation-result-template.md` | `validation/runs/{domain}-{project}-result-{date}.md` |
| File reviewer verdict | `reviewer-verdict-template.md` | `validation/reviews/{domain}-{project}-review-{date}.md` |
| Build evidence packet | `evidence-packet-template.md` | `validation/evidence-packets/{domain}-{project}.md` |
| Wrap reconstructed-app run | `reconstructed-run-wrapper-template.md` | `validation/runs/{domain}-reconstructed-{date}.md` |
| Non-coder operator | `non-coder-operator-checklist.md` | `validation/runs/...` |
| Simulation log | `simulation-log-template.md` | `validation/simulations/...` |

## Filename Convention

- Runs: `{domain}-{project}-{YYYY-MM-DD}.md`
- Reviews: `{domain}-{project}-review-{YYYY-MM-DD}.md`
- Evidence packets: `{domain}-{project}.md` (no date — the packet is the canonical proof record)
- Independent re-execution artifacts: prefix with the run id (e.g. `AUTH-1-...`)

## Required Output Contract

Every filed verdict must include:

- validation mode: `independent re-execution` or `artifact review only`
- scope: what was verified and what was not
- status per item: `PASS`, `FAIL`, or `NOT TESTED`
- version bound: commit/version, environment, date
- evidence pointers: artifact paths or links
- operator identity: name + relationship to builder (independent / founder / contributor)
- claim discipline statement: no evidence, no claim

## Worked Example: AUTH-1

The AUTH-1 (auth-authorization) re-execution chain is the canonical example. When in doubt about format or rigor, mirror AUTH-1.

- Request packet: `validation/runs/AUTH-1-independent-reexecution-request-packet.md`
- Operator handoff: `validation/runs/AUTH-1-independent-operator-handoff.md`
- Re-execution checklist: `validation/runs/AUTH-1-independent-reexecution-checklist.md`
- Founder verification (separate, *not* independent): `validation/runs/AUTH-1-founder-verification-checklist-2026-03-19.md`
- Acceptance criteria: `validation/reviews/AUTH-1-independent-reexecution-acceptance-criteria.md`
- Verdict template: `validation/reviews/AUTH-1-independent-reexecution-template.md`
- Filed review (founder mode): `validation/reviews/auth-authorization-AUTH-1-review-2026-03-19.md`
- Evidence packet: `validation/evidence-packets/auth-authorization-AUTH-1-2026-03-19.md`

## Fast Navigation

- Find a domain/run quickly: `rg -n "AUTH-1|backend|deployment" validation`
- Find mode declarations and status labels: `rg -n "independent re-execution|artifact review only|PASS|FAIL|NOT TESTED" validation`
- List runs: `ls -la validation/runs`
- List reviews: `ls -la validation/reviews`
- List evidence packets: `ls -la validation/evidence-packets`
- List templates: `ls -la validation/templates`

## Refusal Conditions

- Refuse to mark `independent re-execution` if you only inspected artifacts.
- Refuse to upgrade domain status labels without explicit owner authorization.
- Refuse to assert compliance if version-bound evidence is missing.
- Refuse to file a verdict that lacks operator identity or execution environment.
- Refuse to author both a builder claim and a verdict on the same artifact in the same session.

## Filing Conventions

- One file per artifact (run, review, evidence packet).
- Stable IDs in filenames.
- Append-safe, auditable updates over in-place historical rewrites.
- Consistent verdict language across reviews.