# Website project guidance
Public starter adapted from The Dreaming Jester's website workflow.
## Purpose
Build a small, clear website around what the project actually offers. Explain the product before adding promotional language. Keep availability, destinations and claims factual.
## Working in this directory
- Read the existing source, project README and package scripts before editing.
- Preserve the owner's approved identity, copy and visual direction unless the request changes them.
- Prefer semantic HTML, responsive CSS and a small amount of JavaScript. Use the existing framework when the project has one.
- Keep unrelated product source, business records and credentials outside the website output.
- Use the skills in `.agents/skills/` when their descriptions match the task.
## Roles
The implementation agent makes the requested change and verifies it. A reviewer can inspect the completed diff independently when the owner or project guidance authorises delegation. The publishing agent releases the verified commit only within the owner's existing publishing permission.
## Quality
Inspect a desktop and narrow phone layout. Test the changed interactions with keyboard controls, visible focus and reduced motion. Run the project's actual check, test and build commands. Choose tests that prove behaviour; a text-only change rarely needs a new test.
## Publishing
A push to a connected production branch may immediately publish the site. Check the existing deployment configuration before pushing. Do not change account access, DNS, billing or repository visibility as part of an ordinary website edit.
Report the deployed commit and what was verified. If a check or deployment is incomplete, say so clearly.
---
name: website-change
description: Implement a requested change in an existing website while preserving its approved identity, content and hosting arrangement.
---
# Website change
Read the nearest AGENTS.md, project README and relevant source before choosing an implementation. Use the owner's latest feedback to define the change; do not rewrite unrelated sections.
Identify the content and interactions affected. Keep product status and destinations factual. If content is missing, build the structure that can be completed without inventing a release, client, price or download.
Use the existing site architecture. Prefer native links, scrolling and semantic controls. Make new interactions usable with a keyboard, visible focus, a narrow viewport and reduced motion. Keep the core content and downloads available when JavaScript is unavailable.
Run the project's applicable checks and build. Inspect desktop and phone layouts and test the interactions you changed. For meaningful behaviour changes, add tests that cover the user's action and resulting state.
Prepare a concise handoff with the requested change, files affected, verification and any remaining limitation. Leave publication to the authorised release step.
---
name: website-review
description: Review a completed website change for behavioural defects, accessibility problems, broken destinations and unintended publication of private material.
---
# Website review
Read the request, applicable project guidance and completed diff. Review the resulting experience rather than the author's explanation of why it should work.
Check changed interactions, keyboard access, narrow layouts, destination validity and content availability. Look for regressions in navigation, focus, loading and failure states. Check that downloads contain their referenced supporting files and that private records or credentials cannot enter the deployed output.
Run focused checks when they help establish an observable failure. Do not add tests that only mirror source text, rewrite unrelated code or publish the site during review.
Report actionable findings with severity, reproduction and the affected location. Separate verified defects from untested concerns. If there are no findings, say so and state the review's practical limits.
If this review is delegated, the owner or applicable project guidance must already authorise delegation. Review permissions do not grant publishing or account access permissions.
---
name: website-release
description: Release a verified website commit through its existing Git-connected hosting route and confirm the resulting deployment within the owner's publishing permission.
---
# Website release
Read the existing repository and hosting configuration. Confirm the production branch, build command and output directory from the project's current records or hosting status.
Review the exact diff and local state before committing. Resolve relevant check failures and review findings. Preserve unrelated uncommitted work and never include credentials or private records in a release.
A production push is publication. Proceed only when the owner has authorised the requested change and its publication. When permission is missing, finish the reviewable branch or local result before requesting that decision.
Commit the completed change and push through the established Git route. Confirm the remote branch matches the intended commit, then verify the host's deployment result for that commit. Do not replace a failed Git integration with a manual upload while claiming automatic deployment works.
Verify the public route and changed files or interactions. Report the commit, deployment result, checks and any unresolved limitation. Do not change repository visibility, DNS, credentials, billing or access as a routine release step.
