Skip to content
CodexWork
Any AIChatGPTClaudeCodexCopilotGeminiGrokOther agents

Use materials in your tool

All tool notes →

Build a small shared project tracker

Describe the project. Get a tracker preview to inspect before anything is published.

0608
Designed method · documented tool support

No recorded run of this exact instruction yet. Official sources document relevant tool support; the task method and synthetic sample are authored examples, not vendor-tested procedures.

A browser-local prototype is not a shared team tracker.

Read the full instruction ↓

What you supply

  • A synthetic brief with fields and example tasks
  • Intended audience, storage needs and access requirements

What it saves

  • Reviewable tracker version or local preview
  • Interaction check results
  • Storage and access notes

Designed example · synthetic data

See the finished example

Read the complete example →Starting materials →Editable Markdown ↓

The instruction

Build a small project tracker from my synthetic brief. Use only the supplied example data. Confirm fields, expected users and whether persistence is browser-local or shared. If shared storage or access is unavailable, create a clearly labeled local prototype and state the gap; do not call browser storage shared.

Provide add, edit and filter controls and a save method appropriate to the environment. Test creating a task, editing owner/due date, filtering, and saving/reopening. Record actual results and any untested actions in checks.md. Explain where data is stored, what survives refresh, and whether another browser or person can see edits. Do not claim access controls or shared persistence from appearance alone.

Save a reviewable version and a README with preview instructions, expected behavior, storage/access limits and remaining decisions. In Sites, save a version for review rather than deploying it; for local code, return a runnable preview with instructions. Ask for approval only after the result can be inspected. Do not publish, deploy, connect private accounts, grant access or add real personal data. Return the artifact/version and check notes.

Show plain text
Build a small project tracker from my synthetic brief. Use only the supplied example data. Confirm fields, expected users and whether persistence is browser-local or shared. If shared storage or access is unavailable, create a clearly labeled local prototype and state the gap; do not call browser storage shared.

Provide add, edit and filter controls and a save method appropriate to the environment. Test creating a task, editing owner/due date, filtering, and saving/reopening. Record actual results and any untested actions in checks.md. Explain where data is stored, what survives refresh, and whether another browser or person can see edits. Do not claim access controls or shared persistence from appearance alone.

Save a reviewable version and a README with preview instructions, expected behavior, storage/access limits and remaining decisions. In Sites, save a version for review rather than deploying it; for local code, return a runnable preview with instructions. Ask for approval only after the result can be inspected. Do not publish, deploy, connect private accounts, grant access or add real personal data. Return the artifact/version and check notes.

Stops in this kit

06

Approval, after you inspect the preview

Publishing, deploying or granting access

08

Fields, users and where data is stored

Checks to run

  1. Add/edit/filter/save work in an inspected preview, or failures are recorded.
  2. Data persistence is described accurately for this environment.
  3. Shared storage and visitor permissions are checked independently.
  4. The saved version is distinguished from a live deployment.
Open the checklist →

What has been tested

Designed method · documented tool support

No recorded run of this exact instruction yet. Official sources document relevant tool support; the task method and synthetic sample are authored examples, not vendor-tested procedures.

Checked 2026-10-13

Limits

  • A browser-local prototype is not a shared team tracker.
  • Sites hosting, storage and audience controls need supported access and actual configuration.
  • Saving a Sites version does not publish it; a deployment URL is production.
  • The sample is a designed specification, not a tested working tracker.

Optional tool setup

Using a kit

  1. Supply synthetic tasks and decide what “shared” must mean for this use.
  2. Have the agent build a reviewable version or local preview.
  3. Try add, edit, filter and save, then review storage and access before approving publication.
Use a kit in your tool →

ChatGPT

  1. Paste the instruction, attach the sample files or your own, and read the stops first.
  2. Pick Work for a multi-step task and supply the context it needs.
  3. For reuse, follow the documented skill or plugin setup on your surface. Downloading a kit does not install it.

Check the permissions for the tools and actions you use. The kit's stops are instructions to the agent; they do not create an enforced approval setting.

ChatGPT · dated notes →

Claude

  1. Paste the instruction, attach the sample files or your own, and read the stops first.
  2. In Cowork, choose the authorized folder containing your inputs where that feature is available. A generic kit-to-skill import was not established by the reviewed pages.
  3. In Claude Code, use CLAUDE.md for project guidance. AGENTS.md is read by default on supported versions (2.1.277+) only when project-path CLAUDE.md or CLAUDE.local.md does not take precedence; session and configuration exceptions apply.

Check the controls in your Claude surface. Anthropic describes approval handbacks, but the kit's stops do not enforce a product permission boundary.

Claude · dated notes →

Codex

  1. Paste the instruction, attach the sample files or your own, and read the stops first.
  2. For project guidance, use AGENTS.md. For a reusable skill, follow the supported setup, such as .agents/skills/<name>/SKILL.md in a repository.
  3. Check the sandbox and approval settings before you start the job.

Codex has sandbox and approval settings. Check them before a job that touches real files.

Codex · dated notes →

Copilot

  1. Paste the plain instruction into a Copilot chat you can access, and read the stops first.
  2. Check which file inputs and actions your tenant's actual surface supports before supplying files.
  3. Keep the kit as a manual prompt. The reviewed posts do not document importing it as a skill, plugin or agent.

Ask your administrator which actions, permissions and approval controls your organization has enabled. A kit's stops do not create those controls.

Copilot · dated notes →

Gemini

  1. Paste the instruction, attach the sample files or your own, and read the stops first.
  2. Where Skills is available, copy or import the skill using that surface's documented setup.
  3. Gemini app and Workspace skills do not sync. Set up the skill separately on each available surface you use.

Some Gemini Tasks may require confirmation. Check current eligibility and permissions before real account work; the kit's stops are instructions, not enforced approval settings.

Gemini · dated notes →

Grok

  1. Paste the plain instruction as a message and read the stops first.
  2. If Bot is available to you, show it the workflow; xAI describes routine learning by following along.
  3. Keep the instruction as plain text; we could not confirm SKILL.md support.

xAI describes approval handbacks for Grok Bot. Check what your account and connected apps allow before real actions.

Grok · dated notes →

Other agents

  1. Paste the plain instruction into an agent that accepts text, then supply inputs through its supported route and read the stops first.
  2. If your agent reads AGENTS.md, save the instruction there.
  3. If the named client supports Agent Skills, use the documented skill folder location and setup for that client and version.

This varies by agent. Look up its approval settings; the kit's stops stay in the instruction wherever you paste it.

Other agents · dated notes →
Markdown · README.md
# Build a small shared project tracker

Describe the project. Get a tracker preview to inspect before anything is published.

## Start

1. Edit [brief.md](build-shared-tracker/files/brief.md) and [input-template.md](build-shared-tracker/files/input-template.md).
2. Supply authorized inputs to your own file-capable agent with [instruction.txt](build-shared-tracker/files/instruction.txt).
3. Inspect the saved outputs using [checks.md](build-shared-tracker/files/checks.md) before using them. Keep original inputs.

## Inputs

- A synthetic brief with fields and example tasks
- Intended audience, storage needs and access requirements

## Outputs

- Reviewable tracker version or local preview
- Interaction check results
- Storage and access notes

## Steps

- Supply synthetic tasks and decide what “shared” must mean for this use.
- Have the agent build a reviewable version or local preview.
- Try add, edit, filter and save, then review storage and access before approving publication.

## Instruction

Build a small project tracker from my synthetic brief. Use only the supplied example data. Confirm fields, expected users and whether persistence is browser-local or shared. If shared storage or access is unavailable, create a clearly labeled local prototype and state the gap; do not call browser storage shared.

Provide add, edit and filter controls and a save method appropriate to the environment. Test creating a task, editing owner/due date, filtering, and saving/reopening. Record actual results and any untested actions in checks.md. Explain where data is stored, what survives refresh, and whether another browser or person can see edits. Do not claim access controls or shared persistence from appearance alone.

Save a reviewable version and a README with preview instructions, expected behavior, storage/access limits and remaining decisions. In Sites, save a version for review rather than deploying it; for local code, return a runnable preview with instructions. Ask for approval only after the result can be inspected. Do not publish, deploy, connect private accounts, grant access or add real personal data. Return the artifact/version and check notes.

## Decisions that need your context

- Fields, users and where data is stored
- Approval, after you inspect the preview
- Publishing, deploying or granting access

## Settled by the brief

No separately annotated settled rules are supplied. Follow the instruction as written.

## Check the output

- Add/edit/filter/save work in an inspected preview, or failures are recorded.
- Data persistence is described accurately for this environment.
- Shared storage and visitor permissions are checked independently.
- The saved version is distinguished from a live deployment.

## Limits

- A browser-local prototype is not a shared team tracker.
- Sites hosting, storage and audience controls need supported access and actual configuration.
- Saving a Sites version does not publish it; a deployment URL is production.
- The sample is a designed specification, not a tested working tracker.

## Materials

- [examples/build-shared-tracker/designed-example.html](build-shared-tracker/files/examples/build-shared-tracker/designed-example.html)
- [examples/build-shared-tracker/designed-example.md](build-shared-tracker/files/examples/build-shared-tracker/designed-example.md)
- [examples/build-shared-tracker/input.md](build-shared-tracker/files/examples/build-shared-tracker/input.md)

## Evidence

[Recorded context and file identities](build-shared-tracker/files/evidence.json)

Designed method · documented tool support

No recorded run of this exact instruction yet. Official sources document relevant tool support; the task method and synthetic sample are authored examples, not vendor-tested procedures.

Observed or source-checked: 2026-10-13.

## Revision and corrections

Revision: 2.0.0. Lifecycle: active.

[Current kit](https://codexwork.com/kits/build-shared-tracker/) · [Changes and corrections](https://codexwork.com/changes/)

[Rights and notices](build-shared-tracker/files/LICENSES.md) · [Sources](build-shared-tracker/files/sources.md) · [Manifest](build-shared-tracker/files/manifest.json)

Downloading these files does not run an agent, install a skill, create a schedule, or grant file or account permissions.
Open Markdown file ↗
SKILL.md
---
name: build-shared-tracker
description: "Describe the project. Get a tracker preview to inspect before anything is published."
---

# Build a small shared project tracker

Build a small project tracker from my synthetic brief. Use only the supplied example data. Confirm fields, expected users and whether persistence is browser-local or shared. If shared storage or access is unavailable, create a clearly labeled local prototype and state the gap; do not call browser storage shared.

Provide add, edit and filter controls and a save method appropriate to the environment. Test creating a task, editing owner/due date, filtering, and saving/reopening. Record actual results and any untested actions in checks.md. Explain where data is stored, what survives refresh, and whether another browser or person can see edits. Do not claim access controls or shared persistence from appearance alone.

Save a reviewable version and a README with preview instructions, expected behavior, storage/access limits and remaining decisions. In Sites, save a version for review rather than deploying it; for local code, return a runnable preview with instructions. Ask for approval only after the result can be inspected. Do not publish, deploy, connect private accounts, grant access or add real personal data. Return the artifact/version and check notes.

## Required inputs

- A synthetic brief with fields and example tasks
- Intended audience, storage needs and access requirements

## Expected outputs

- Reviewable tracker version or local preview
- Interaction check results
- Storage and access notes

## Checks

- Add/edit/filter/save work in an inspected preview, or failures are recorded.
- Data persistence is described accurately for this environment.
- Shared storage and visitor permissions are checked independently.
- The saved version is distinguished from a live deployment.

## Limits

- A browser-local prototype is not a shared team tracker.
- Sites hosting, storage and audience controls need supported access and actual configuration.
- Saving a Sites version does not publish it; a deployment URL is production.
- The sample is a designed specification, not a tested working tracker.

Revision: 2.0.0. [Read the complete kit](files/README.md) before use. This optional format is not a claim of support by every tool.
Open SKILL.md ↗