Add a manual site update skill
Accepted manual site-update skill covering deployed baselines, visual checks, authorized publication and verified delivery.
Objective and authorization
Create a reusable manual workflow to compare the deployed site with proposed changes, validate and visually check a concrete artifact, publish when authorized, and record verified delivery. The user approved adding the skill with “Do it” in the manager chat; this authorizes harness creation, not a live site refresh now.1
Ownership and bounded contract
Owner chat: manager 01a1241c-b623-7df3-a0d7-a85aa4a02811.
Sol harness-builder implements the bounded contract; the manager coordinates one
independent Astra acceptance pass and checkpoint.
Exact owned paths: .agents/skills/site-update/SKILL.md, harness/static-site.md,
README.md and this brief. The manager separately owns the original input, shared
indexes/log and Git. No other files, helpers, roles or test frameworks are included.
Preserve source authority, scope gates, existing task/chat ownership, reusable applicable human authorization, private-report/generated-only upload boundaries and archived bytes. No live build/deploy, network retrieval, new source, runtime test, automatic publishing, monitoring, account/paid/domain/authentication change or recursive delegation is included. Use existing scripts for offline validation only. Stop affected writes on ownership collision or a consequential policy conflict; report the specific issue to the manager. No numeric resource cap was supplied; this implementation is bounded to four files, offline checks and three dry workflow scenarios.
Deliverables and done criteria
- A short discoverable skill links the canonical guide and handles requested updates without treating ordinary knowledge editing as publication.
- The guide covers live-baseline evidence, proportionate content/behavior checks, actual visual checks, final checkpoint reconciliation, authorized existing-project upload, live verification and published-versus-later-note semantics.
- README exposes the skill; quick validation, read-only harness/knowledge validation and diff checks pass; three dry scenarios are assessed with limitations recorded.
- Independent Astra acceptance and manager checkpoint complete the task. No runtime skill reload or successful future deployment is claimed by creating these files.
Authority and dependent impact
harness/static-site.md remains the operating authority; the new skill links it instead
of duplicating its full procedure. README adds discovery. The guide replaces the broad
initial-implementation test paragraph with content-versus-behavior checks consistent
with workflow/model-routing/change-control. Existing builder/config/theme, role models,
scope receipts, IDEA-003 delivery history and evidence rules remain intact and need no
edits. Skill creation does not change automatic discovery defaults or add automatic
execution. The task and original input record authorization separately from future
publication decisions. Manager-owned indexes/log/Git are excluded from worker writes.
Progress and next action
Implementation and independent Astra acceptance are complete. Manager verified all four reviewed file hashes before adding these completion records. This task is ready for its coordinated Git checkpoint; no site refresh or runtime skill reload is claimed. Next use is a user-requested update in the existing owning chat.
Checks and results
Required context inspected: current project/index/open questions, harness-builder role,
maintain-harness, coordinate-work, skill-creator, workflow/model-routing/change-control,
OKF/file placement, static-site guide, builder interface and IDEA-003 execution record.
Worker checks passed: skill-creator quick_validate.py for site-update; read-only
validate_harness.py (0 errors); read-only validate_knowledge.py (321 Markdown files,
0 errors); git diff --check. New-file whitespace was separately inspected. Shared
indexes are intentionally not rebuilt by the worker. No scripts changed, so no runtime
tests or complete script suite were run.
Three dry workflow scenarios were assessed by tracing the written instructions against the builder interface and recorded initial deployment, without executing the workflow:
- A user requests a content refresh and explicitly authorizes its publication. The workflow reuses that applicable authorization, compares the matching live manifest plus commit and uncommitted changes, validates/previews the final coordinated artifact, then uses the existing project and verifies delivery. Unchanged accepted generator behavior does not trigger another full Astra review or script suite.
- A user edits a knowledge note or asks only to add this skill. Neither triggers upload. If a later request lacks publication authorization, prepare the concrete preview and ask only for the missing approval. New substantive idea/research work keeps its gates.
- The local report belongs to a newer private build, and proposed changes affect the template or inputs shift after review. The report is not relabeled live: record missing baseline limits, resolve material uncertainty, obtain behavior acceptance, and stop a stale artifact before upload. Preserve a matching report before cleanup; a blocked file chooser retains the artifact and offers exact manual attachment, without duplicating the project or broadening permissions. Later delivery notes do not cause a rebuild loop.
These are instruction-level dry assessments, not independent agent execution, actual
browser checks, deployment verification or runtime skill discovery. Validators cover
structure/local links and recorded evidence, not future workflow behavior or live content.
Independent Astra semantic acceptance passed with no blocking findings. Astra separately
assessed preview-only, authorized refresh with a mismatched baseline report, and template
change with a blocked upload chooser. It confirmed the guide preserves canonical mechanical
correction exceptions and requires commit/working-tree evidence for generator inputs beyond
the report's knowledge inventory. Skill quick validation and harness validation passed.
Manager matched the frozen four-file SHA-256 manifest before recording completion.
Acceptance is instruction-level; no build, browser, network or deployment was performed.
Manager workspace.py check passed: harness 0 errors, indexes regenerated, and
322 Markdown files validated with 0 errors. No scripts changed, so no script test
rerun was required.
Related work
IDEA-003 site brief and execution record retain the initial deployment evidence. This task does not reopen that completed delivery.
-
Exact request and approval transcribed in the linked manager input; assistant proposal is labeled separately. Not a platform export. ↩