Appropriate use
Use for Slack updates, stand-ups, end-of-day reports, manager summaries, or team handoffs.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use as a substitute for source reports, performance evaluation, or an automatic broadcast without review.
- 8
- versioned workflow phases
- 3
- explicit approval gates
- 5
- defined result states
- 8
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Time-window and source preflight Gate 1 · approve sources
Confirm date, timezone, team, products, source systems, included work, private channels, and publication audience.
window · timezone · audience · source access
Phase 2: Activity collection
Collect ticket updates, test runs, defects, fix verification, automation changes, rollout checks, incidents, and environment issues from authoritative records.
source record · timestamp · owner · status
Phase 3: Evidence and status validation
Verify that claimed tests have results, build identity, evidence links, and current status. Separate planned, started, completed, and blocked work.
done · in progress · planned · blocked · stale
Phase 4: Priority and relevance selection
Select updates that affect release confidence, customer impact, team dependencies, decisions, or next-day work. Avoid activity-count noise.
impact · decision · blocker · risk · next action
Phase 5: Draft construction
Create concise sections for completed work, findings, blockers, release status, automation, next actions, and help needed.
plain language · exact versions · no duplicate detail
Phase 6: Privacy and accuracy review
Remove secrets, restricted customer detail, unsupported conclusions, blame, and internal evidence links inappropriate for the audience.
redaction · confidence · audience-safe wording
Phase 7: User review Gate 2 · approve summary
Present the source-backed draft and unresolved ambiguities. Bind approval to the selected time window and source snapshot.
edits · omissions · audience · channel
Phase 8: Publish and archive Gate 3 · publish
Post or save idempotently, record the published text and source references, and avoid editing historical summaries without a visible correction.
message ID · published at · source index · correction
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve sources | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · approve summary | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · publish | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
READY
The summary is current, source-backed, audience-safe, and complete for the agreed scope.
READY WITH GAPS
Known source or coverage gaps are explicitly stated.
NEEDS REVIEW
Material ambiguity, privacy concern, or unsupported claim remains.
NO MATERIAL UPDATE
No meaningful change occurred in the selected window.
SOURCE CONFLICT
Authoritative records disagree and require resolution.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Completed work | Ticket or execution record | Status and build are current. |
| Defect | Issue link and triage status | Severity and release impact are not guessed. |
| Blocker | Owner and next action | The blocker is current and actionable. |
| Release | Release or rollout decision | Candidate and stage are identified. |
| Automation | PR, CI, or audit record | Progress describes verified change, not effort alone. |
| Next action | Owned plan | Action, owner, and dependency are concrete. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
No invented progress
Missing source data remains missing.
Runtime control
Status freshness
Stale ticket labels do not override newer verified reports.
Runtime control
Audience privacy
Customer, security, incident, and credential details follow channel policy.
Runtime control
No blame language
The summary describes facts, ownership, and next actions.
Runtime control
Publication approval
The skill drafts by default and posts only after explicit approval.
Runtime control
Correction history
Material corrections are visible rather than silently replacing history.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
SOURCE CONFLICT
Resolve inconsistent authoritative records before publication.
NEEDS REVIEW
Privacy, accuracy, or scope needs user confirmation.
READY WITH GAPS
Publish with explicit source or coverage limitations.
NO MATERIAL UPDATE
Publish a minimal no-change note only when useful.
READY
Publish the concise verified summary.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. Source systems may lag behind actual work.
- Limit 2. A concise summary necessarily omits lower-impact detail.
- Limit 3. Private incidents and customer issues may require separate restricted updates.
- Limit 4. Cross-timezone work needs an explicit reporting window.
- Limit 5. Ticket count is not a meaningful measure of QA value.
- Limit 6. Automated posting can amplify an incorrect summary, so review remains important.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
summary-context.jsonVersioned output produced by the workflow.
source-index.yamlVersioned output produced by the workflow.
activity-ledger.jsonlVersioned output produced by the workflow.
draft.mdVersioned output produced by the workflow.
redaction-review.mdVersioned output produced by the workflow.
approval.jsonVersioned output produced by the workflow.
published-message.mdVersioned output produced by the workflow.
daily-summary.htmlVersioned output produced by the workflow.
artifacts/qa/qa-daily-summary/<run-id>/ ├── summary-context.json ├── source-index.yaml ├── activity-ledger.jsonl ├── draft.md ├── redaction-review.md ├── approval.json ├── published-message.md └── daily-summary.html
Example
Example request and controlled output
Input
Prepare my QA daily update for Bangkok time. Include SCOS 3.1.14 testing, PIXI rollout, the webOS issue, automation progress, blockers, and tomorrow's plan.
Output excerpt
QA Daily Update Completed - Finished the required SCOS 3.1.14 OTA and reboot checks on the current candidate. - Verified the PIXI staged-rollout health snapshot at 20%. Findings - The webOS 6 repeat-launch black-screen issue remains reproducible on one model and is under triage. Automation - Studio Player E2E and benchmark work reached the verified milestone recorded in the project tracker. Blocker - One required SCOS image asset is still unavailable. Next - Resume the blocked SCOS path when the asset is published. - Continue model comparison for the webOS issue.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/qa-daily-summary
Produces a concise daily or stand-up update from verified work records without inventing progress, hiding blockers, or exposing restricted detail.