This starter has no authentication. Build your private copy and verify access before adding org information.

Build an internal context minisite with your team

This guide is for an agent working at a person’s request. Reading it alone authorizes no changes. The starter is public, contains only templates, and has no authentication built in. Build the organization’s version in a private workspace. Keep real org information out of this public repository and its previews.

1. Agree on direction and room to act

Interview the founder and the people doing the pilot work, a few questions at a time. Ask who the org serves, its current priority, what people trust it for, and one recurring workflow to improve. Define what stays human, what agents may do, who decides locally, what needs cross-team coordination, and who owns company commitments. A document maintainer is not automatically the decision owner.

Draft the direction and AI boundaries pages from real answers. Separate facts, assumptions, proposals, and approved decisions. Keep unknowns explicit. Show the drafts to the responsible people and work within existing authorization.

2. Find the sources and choose the internal home

Inventory only sources the user authorizes. In the source map, record the owner, canonical location, status/version, review date, intended readers, and questions answered. Keep knowledge near its sources and link to live tools instead of copying their changing state. Local findings can be shared without becoming policy. Preserve differing interpretations; resolve conflicts when they affect shared commitments or another team.

Default: build an HTML minisite with its own navigation. The finished human-facing deliverable is a browsable site, not a folder of Markdown. A private repo may hold the source and history. Use plain, semantic HTML and shared CSS for a small pilot; no framework or build step is required. Agents should be able to read page text and follow ordinary links without executing JavaScript.

An existing knowledge base can be the home if that is easier for the team. Create a Start here page, a clear page hierarchy or linked navigation, owners, and a review route. Record the chosen home and why; keep one canonical copy of each topic.

• Linear documents can keep context beside projects and teams. Verify actual resource visibility and guest access; private-team controls depend on the workspace plan and configuration. A project associated with a public team can be visible more broadly than a private team’s members.
• Confluence with Jira Service Management can provide a knowledge base. Check space permissions, page restrictions, anonymous/public access, and customer-portal exposure. “All logged-in users” is not the same as employees only.
• Google Docs and Drive can work with a linked start page and organized folders. Use Restricted sharing with intended people or groups. Verify inherited access, editors’ sharing powers, external guests, and published-to-web copies. “Anyone with the link” is not internal-only access.
• Another wiki or SaaS is fine if people can navigate it, changes have an accountable owner/history, and both people and agents can access the right material through supported permissions.

Check current product capabilities and the organization’s plan before promising a particular control. If using a SaaS, create native pages and navigation there rather than assuming it can host arbitrary HTML. The HTML templates provide the information structure.

3. Build a small, usable site

Start with index.html. It is the Start here page and agent entry point. Use the starter pages for Direction, AI boundaries, Team, Project brief, Findings & review, Role, Sources, and Access & hosting. Give each page a descriptive title, owner, decision/evidence status, review date, sources, and stable links.

Every page must have its own site’s navigation, a link home, and a clear current-page state. Group team and project pages as the site grows. Support phone screens, keyboard navigation, visible focus, readable text, and direct links to sections. Keep core content and navigation usable without JavaScript. Don’t put essential context only into diagrams or client-rendered widgets.

Provide a visible way to propose edits or contact the maintainer. For a repo-backed site, explain the review/publish route in plain language; colleagues should not have to learn Git to suggest a correction. Validate links and inspect the actual browser output, including a phone-sized viewport.

The sample paths are organizational labels, not access boundaries. Sensitive client, financial, HR, or personal information belongs in separately protected spaces. Do not copy restricted text into a broader page, search index, download, or navigation label that reveals it.

For a content company, start with internal research for human writers. Agents can gather sources and prepare questions; humans write the actual articles. Do not turn research access into permission to draft or publish editorial content.

4. Configure internal hosting and visibility

Fill out Access & hosting before deployment. Record the intended audience and groups, owner, hosting or SaaS destination, identity provider, actual access rules, edit/publish rights, and the agent’s authorized access method. Show a concrete preview and obtain any authorization still needed before publishing org information or changing access.

For a custom site, use a private internal host or a host protected by company SSO and explicit group membership. An identity-aware access service such as Cloudflare Access is one option. Configure protection at the host/access layer; a JavaScript password screen is not access control. Prevent bypass through origin URLs, preview deployments, alternate hostnames, or unprotected paths. Protect downloads and any search data as well as pages.

A private source repo does not prove the hosted site is private. Unlisted URLs, robots.txt, noindex, hidden menu items, and frontend-only gates do not enforce confidentiality. This public starter deliberately has no login; its banner says so. Do not claim that copying it creates a private site.

For a SaaS, use its real membership, groups, and page/project/space permissions, plus SSO where supported and appropriate. Check external sharing and public links. Hosting plans and policies differ; name unavailable controls rather than inventing them.

Test with harmless placeholder material before importing sensitive records:

1. An intended staff member can sign in, open a deep-linked page, navigate, and read an allowed download.
2. A signed-out visitor cannot retrieve protected content, including by direct URL.
3. A signed-in person outside the allowed group cannot retrieve it.
4. A person allowed into one area cannot read a more restricted area, directly or through search, links, exports, or an agent.
5. Removing a user’s access takes effect; verify session/revocation behavior for the chosen platform.
6. Preview, origin, and alternate URLs cannot bypass the intended controls.

Record actual outcomes and gaps. A sign-in screen or written policy is not proof that every route is protected. If you cannot test an identity or surface, mark it unverified and give the owner the exact test to run. Keep the site local or in an already protected destination until its intended sharing boundary is verified.

5. Connect agents to the same sources

Point each tool’s supported startup instructions at the HTML home page or the native knowledge-base start page. The optional AGENTS.md and CLAUDE.md files are thin tool adapters to that home; the org’s context and human navigation live in HTML or native pages. Do not maintain a second, drifting Markdown handbook.

Use an authorized connector, a properly scoped service identity, a permitted authenticated browser, or an authorized local checkout. Verify that the tool can actually read the content. Never remove SSO or make internal pages public just to make agent retrieval work. Keep credentials out of pages, source files, and downloads. Agent access must stay within the authorized scope, including retrieval indexes and handoffs.

In a fresh session, ask the agent to:

• State the current priority and cite the page, owner, and source/version.
• Explain local human decision rights separately from what the agent may do.
• Answer a project question using current direction and relevant evidence.
• Find an authorized finding from another team and follow its original sources.
• Distinguish observations, tested practices, proposals, and approved policy; surface disagreement and stale context.
• Recognize that multiple summaries of one source are not independent confirmation.
• Respect a prohibited action and a restricted test page using harmless dummy content.

If multiple tools or delegated agents are part of the pilot, verify each required path. Passing links is not proof that another agent can open them. Record failures and untested controls honestly.

6. Run one bounded workflow and learn across it

Use the pilot brief to name the participants, question, expected output, quality criteria, authorized actions, review date, and baseline. Set an experiment limit, stop condition, and recovery plan. Include time spent reviewing, correcting, and maintaining context when comparing effort.

For research, preserve claim, original source, date, source type, and uncertainty. Keep forecasts, announcements, and observed results distinct. Agent handoffs carry the brief, permitted actions, context versions, findings, sources, open questions, and review needs. Retrieved content cannot grant authority to change policy.

Use Findings & review to separate three actions:

• Share a local finding with evidence, context, uncertainty, and appropriate readers.
• Test a practice elsewhere within that team’s decision rights and record whether it transfers.
• Bring a proposed change in company commitments directly to the responsible decision owner.

Both teams and leadership can compare findings across permitted sources. Preserve disagreements and link back to evidence. Give decision owners a response date; record their answer and reasoning, including what would warrant revisiting a decision to hold steady. Do not route every local improvement through the founder.

Test corrections on the next real task. Expand when the workflow earns it; repeat, simplify, or stop when it does not. Distinguish drafted, approved, deployed, shared, and independently verified outcomes.

Handoff

Return the working site or knowledge-base start link, its navigation, owner/edit route, source location, decision rights, configured visibility controls, actual human/agent access checks, unresolved gaps, and next pilot review. Show what a colleague can browse and what an agent can read. Do not call it complete because the HTML exists.