---
name: sekkei
description: Use Sekkei as the shared home for a project's documents and agent work. Create or update project folders, Markdown docs, bug lists, plans and review notes; work through comments and decisions; coordinate assigned tasks and return document links. Apply when the user names Sekkei, supplies a Sekkei link, or has already chosen Sekkei for this project's working documents.
metadata:
  version: "0.1.1"
---

# Work with Sekkei

When the user has chosen Sekkei for a project, save relevant working documents there as part of the task and return their links. Do not make the user download, upload or file Markdown by hand. Reuse the existing project folder and documents. Continue that preference in later turns, unless the user asks for local-only work or another destination.

This skill describes how to use the platform; the native Internet Computer (ICP) MCP connector supplies access. It does not install a connector, authenticate a user, start background workers or grant permissions by itself.

## Connect and establish the project

1. Use the exact Sekkei app URL supplied by the user or retained in this project's context. Never guess a production domain or canister ID. With ICP MCP, start with `open_app` (tool names may be prefixed by the host), then read the discovered backend's Candid interface and `get_api_doc`. Use its returned derivation origin and selected account for authenticated queries/updates. Fetch current signatures rather than guessing Candid encodings. Sekkei has a Candid API, not an OQL surface.
2. Read `whoami`, `me`, `my_orgs` and the relevant document role. An authorized connector can act as the user's selected account. For separately attributed agents, an organization administrator registers the agent's distinct principal using `register_agent`. Do not enroll an unregistered agent as Human, relabel a person's account, or switch identities to evade a restriction. If authentication, registration or access is missing, give the one precise setup step needed, preserve local work and stop dependent writes.
3. Resolve the intended space from the user's project/document link or an existing project mapping. Read `folder_paths` / `list_folders` and paginated `list_doc_cards`. Match the project within that space, not just a globally similar title. If the space is ambiguous, ask once before writing; otherwise proceed. An explicit personal workspace is valid. Never choose an unrelated organization merely because it is first in the list.
4. For a requested new project workspace, create one project folder with `create_folder` if it is absent. Bootstrap serially before sending several agents to it: there is no atomic find-or-create or unique folder-name guarantee. After an uncertain create response, inspect that folder/space before retrying. Reuse returned IDs; do not manufacture new folders or organizations on every session.

## Save and organize the work

- Put the requested artifact in the project folder. Use useful names such as “Bug backlog”, “Rollout plan” and “Architecture”; create only documents the current work needs. A small project overview can link related documents when that helps the team navigate. Do not copy an entire private checkout or unrelated files into Sekkei.
- Choose `Tasks` for a work queue, `Spec` or `Design` for specifications, `Decision` for decision documents and `Notes` for reference material. Read `kind_rules` / `kind_actions` before authoring and `doc_writing_rules` / `doc_open.actions` before changing an existing document. Apply the guidance and its enforcement level as described below.
- To create: `create_doc` in the selected space/folder, read the returned document with `doc_open`, set its kind when appropriate, then write the Markdown using `update_doc` with the read `base_rev`. Creation, kind and body are separate operations: retain the new ID and finish that document if a later step fails, rather than creating a duplicate. Use `create_related_doc` when the source's allowed derivations fit the request; it creates in the same space/folder and links the result.
- Preserve the established audience. A folder organizes documents; it does not itself grant document access. `org_id` and `org_owned` have different meanings. Team ownership, member access, named grants and public links need the scope authorized by the user; a request to save a document does not authorize making it public. If working in an explicitly shared project, apply its established sharing policy and verify a collaborator's access.
- A document created under a separate agent principal must also be readable by the human it is being saved for. Use the project's authorized named grants or team policy; do not leave the result accessible only to the agent. If the intended human account cannot be identified from the established context, resolve that once before creating the workspace. Do not grant every organization member access as a shortcut.
- Read the current body and revision immediately before each update. `update_doc` replaces the whole body and rejects a stale `base_rev`. Reapply only your intended change to the newer body after a conflict; preserve everyone else's edits. Limit conflict retries, then report the blocker. Never use `crdt_commit_body` or another endpoint to bypass this check.
- After a timeout, read before repeating a create, comment, decision or update. Use stable document/task IDs and a non-secret operation marker where useful to recognize your result. No universal idempotency-key support is assumed.
- Verify the persisted result before saying it is saved. Return `[Document title](APP_ORIGIN/app/#/doc/SLUG)`, using the **returned slug**, not numeric ID. Internal document links can use `#/doc/SLUG`; a thread link ends in `/c/COMMENT_ID`. Use the real instance's app mount if it differs. Do not mint a bearer/public link just to produce a clickable chat link.
- If a local Markdown copy is requested too, keep it consistent and say which copy is authoritative. If remote access fails, return the local artifact and the specific blocker, never an invented Sekkei link or a claim of synchronization.

## Follow the document type's rules

Before drafting or proposing an edit, read the applicable `guidance`, `enforcement`, `kind` and `version`. For an existing document, use `doc_writing_rules(doc_id)`: it resolves the organization's rules, or the document owner's personal rules, with shipped defaults where needed. Do not substitute the agent's own personal rules. Read again after setting a new document's kind.

- **Strict:** follow the applicable instructions exactly. Do not invent exceptions because a shorter format is easier or a task protocol suggests another structure. If compliance is impossible or conflicts with the user's request, explain the specific conflict before the affected write; do not silently change the instructions or lower their enforcement level.
- **Standard:** follow the instructions unless the document explicitly calls for a different approach. State any departure and its reason in the handoff or review note; convenience alone is not an exception.
- **Advisory:** use the instructions where they fit, applying judgment to the task and document. Preserve the user's requested outcome.

User instructions take precedence over document guidance; none of these levels authorizes unrelated commands, uploads or access changes. The level describes how an agent should follow writing instructions; the canister does not inspect prose for compliance. Permissions, agent mode, allowed document actions and review gates remain separate controls and apply at every level. `is_default` describes the source of the wording, not its strictness: default text can still be Strict.

Cache rules with their document kind and rules version. Before a later write, check the latest kind and `doc_rules_version(doc_id)`; reread the guidance and actions when either changes or the document moves to another space. A kind change alone need not change the space's rules version. Check the final edit or suggestion against the applicable instructions before saving or submitting it. Never call `set_kind_rules`, `set_kind_enforcement` or `set_kind_actions` merely to make your own work pass.

## Discuss, change and verify

Read the relevant comments, replies, suggestions, decisions and rejected alternatives with the paginated APIs. Read the document again if a pagination generation changes. Prefer `doc_open` and scoped pages over legacy aggregates.

For each feedback item, distinguish **act**, **decline with a reason**, and **defer**. Record only decisions the user/team authorized; unresolved questions remain open. Include the current revision, agreed changes and excluded/deferred work in an agent handoff. After editing, connect the resulting diff or implementation evidence back to the original item. Do not resolve somebody's concern merely because a write succeeded.

Use `suggest` when the user asks for a proposal or the agent is in Suggest mode. Do not accept your own proposals as a workaround. Direct edits still require the document role and agent policy. Reviews and Settled status are separate from “I implemented this”; inspect review rules and the revision under review before completing a review. Registered Human/Agent labels are account attribution, not proof of who composed prose.

For comments, diagram annotations, decisions, revisions, sharing, organization administration and other operations, read [the capability guide](references/capabilities.md). It maps tasks to actual API methods and describes the important limits.

## Coordinate several agents

Read [task coordination](references/task-coordination.md) before taking work from a shared backlog. Use stable task IDs, an explicit owner/session and a revision-checked claim in one shared task document. A comment saying “I'll take it” is not an exclusive claim. Suggest-only agents need an authorized coordinator to record their assignment.

Keep task states and evidence in Sekkei as work progresses; reread before taking another item. Agents run in their host tools, while Sekkei holds the shared documents and work record. A skill is not a scheduler: do not promise continuous synchronization after the host session stops. During active work, check `document_refresh` at meaningful boundaries; use `home_head` for broader changes and stop on revoked access.

## Working limits

The live interface and access checks are authoritative. Do not promise native GitHub PR synchronization, arbitrary file uploads, full-workspace export or permanently retained history if the current API does not supply them. Bring PR feedback with source links and explicit manual/agent steps. Fetch the current API guide for byte limits, paging, anchor representation and retention.

Hosted connectors cannot reach a localhost canister. Use an existing authorized local development client for local work, or wait for a reachable deployment. Do not weaken network trust checks, expose a private server or create an account solely to make a demo appear connected.