Skip to main content

Notion and Knowledge Management

Notion Skills in Codex: How to Maintain One Team Workflow

Notion says teams can download shared skills for Codex. Here is a way to inspect the files, compare a sample task, and manage updates without assuming the local copy stays current.

Conceptual diagram of a shared skill branching to a team page and local downloaded copy, with both paths reaching human review.
On this page
  1. Choose a task whose result someone can judge
  2. Keep the shared skill, downloaded files, and outputs distinct
  3. Put the stable method in the skill and the month’s facts in the request
  4. Inspect the bundle before using it locally
  5. Compare both briefs with the notes, using the same criteria
  6. Test the update path with a visible, harmless edit
  7. Confirm access and keep external actions under review
  8. Make the maintenance decision from the evidence collected

In a fictional monthly operations brief, the notes say that assigning a single owner for new requests has been proposed. Imagine that the draft brief says the owner has been assigned. That changed verb could send a team into its next meeting with the wrong understanding of a decision. If the team uses the brief-writing workflow in both Notion Agent and Codex, it needs to catch the error in either output and know which instructions each agent used.

Notion’s September 15, 2026 release says teams can share skills in Notion and download them for Codex as a SKILL.md file with approved supporting files. Its current Skills help describes the download steps and says an edited skill receives a badge prompting a new download. That makes a workflow across both agents worth evaluating. Neither page establishes that a particular workspace has access, that a particular download contains every dependency, or that an existing local copy updates when the Notion skill changes.

For an agency owner or operations lead, the decision is whether the team can maintain one set of instructions and get dependable, reviewable work in both places. Start with a drafting task whose input and success criteria are clear. Inspect the download, judge both outputs against the same requirements, and check what happens after a small edit. The exercise below is proposed. No Notion skill was downloaded or run for this article.

Choose a task whose result someone can judge

A portable skill needs a repeatable job with a recognizable result. A monthly operations brief is a useful candidate because the team can specify its input, audience, sections, and reviewer. The fictional notes for this exercise say that an intake handoff was delayed twice, assigning a single owner for new requests has been proposed but not approved, a staffing decision is planned for a forthcoming meeting, and the effect on delivery dates is unknown.

The brief should contain four sections: Main takeaway, Decisions needed, Risks, and Questions for the next meeting. Its reviewer should be able to trace every factual statement to the notes. The proposed owner belongs under a pending decision, not under completed changes. The unknown delivery impact should stay unknown. These rules give the reviewer something more useful than a preference for polished prose.

Status matters when a brief is passed along. A sentence that calls the owner assignment complete may cause someone to stop pursuing the decision. A prediction of a delivery delay may create urgency the notes do not support. Both sentences could sound plausible to a reader who never saw the input. The first acceptance criterion is therefore fidelity to status: proposed, decided, planned, and unknown must retain their meanings.

Choose Actual size to read the graphic closely.

Use fictional notes in the initial comparison so the same task data can be supplied in each environment without adding client information. Keep the first result as a draft for human review. Connected data and external write actions introduce other variables, including account permissions, data freshness, and the effect of an action. The team can evaluate those once it understands the drafting workflow.

Name the person who reviews the brief before making the skill. An instruction can require an agent to flag an absent owner or unresolved decision. It cannot confer authority to approve one. If the team does not know who owns that review, its process needs a decision before it needs a portable file.

Portability may add little value to a task performed in only one agent. Maintaining an export creates a second copy to review. A stronger candidate is a workflow people already need in both environments, with a stable method and enough recurring use to justify keeping the copies aligned. Rise’s test for work worth automating helps frame that choice around stable inputs, human judgment, failure consequences, and maintenance. Here, the reviewer still owns the decision status. That is a judgment about the team’s work, not a benefit established by Notion’s announcement.

Keep the shared skill, downloaded files, and outputs distinct

Notion describes skills as reusable instructions for how a team works. Its 3.7 release says related skills can be kept in a Notion database and shared individually or as a database. It says a user can choose a skill in Notion Agent chat with /, and that skills can also be set to run automatically. The supplied release text does not establish which of those controls is available in a particular workspace or when it became available there.

The current Skills help resolves an important setup distinction. A skill is a Notion page; sharing it gives someone page access, while enabling a shared skill in their Library makes it available in their own menu. Automatic selection requires the skill to live in a skills database with a Description property. Notion says automatic use is on by default once that description exists, and a user can turn it off. A standalone skill page can still be selected manually. Check these controls in the intended workspace rather than treating a shared page, an enabled skill, and automatic use as one setting.

The release says a skill can be downloaded for Codex and other named agents. Notion describes the download as a SKILL.md file with approved supporting files. That identifies the handoff format Notion describes. It is not an inventory of this team’s files, a record of what its local agent can read, or evidence that the two agents will interpret the instructions identically.

Keep three records for a trial: the instruction maintained in Notion, the files reviewed for local use, and each agent’s output. They answer different questions. A matching skill title does not prove matching instructions. Matching instructions do not prove matching context. Similar prose does not prove that either brief preserved the facts.

  • Material to inspect: Shared Notion skill: The skill and any workspace material it references; Downloaded local copy: SKILL.md, accompanying files, and their references
  • Access question: Shared Notion skill: Which skill controls and referenced pages can the intended user reach?; Downloaded local copy: Which files and tools can the local agent reach?
  • Version question: Shared Notion skill: What instruction is maintained in the workspace at the time of the trial?; Downloaded local copy: Which reviewed download is installed locally?
  • Output check: Shared Notion skill: Does the brief meet the agreed acceptance criteria?; Downloaded local copy: Does the brief meet those same criteria?

The table is a review plan, not a report of findings. Each cell requires evidence from the team’s own workspace and files. It keeps the output comparison consistent while allowing differences in access and context to be recorded separately.

Notion’s update wording reinforces the version distinction. The release says people using a shared skill in the workspace stay on its latest version. For downloaded skills, it says an edited skill is marked with a badge so users know to get the latest version. The Skills help recommends downloading again after a change. The first statement concerns the shared workspace skill; the badge and guidance describe a refresh step for a downloaded copy. Neither page establishes automatic synchronization of files already held locally.

Choose Actual size to read the graphic closely.

Put the stable method in the skill and the month’s facts in the request

Write instructions that should still apply next month. An illustrative instruction for this proposed exercise could say: “Produce a monthly operations brief from the supplied notes. Use the four agreed sections. Distinguish an approved decision from a proposal or a future decision. Identify missing owners, dates, impacts, and outcomes. Do not infer a result from a planned action.” This is example text for evaluating a workflow, not text taken from a Notion export.

The monthly request would contain that month’s notes. Separating method from task data gives the reviewer a route to a correction. If the Risks section is missing, check whether the standing instruction was present and followed. If the brief names a staffing owner absent from the notes, compare the output with the input. If the notes themselves use conflicting status words, resolve the input before blaming either agent.

Set acceptance criteria before anyone runs the task. For this example, require all four sections, accurate decision status, no invented owner or impact, a useful account of the handoff risk, and questions that identify information still needed. Record the passage in the output and the line in the notes that supports or contradicts it. A short brief may satisfy these criteria; a fluent, detailed one may fail them.

Here is what those criteria would mean for the fictional notes. A supported sentence could say, “The intake handoff was delayed twice, and assigning one owner remains a proposal.” A question could ask who will decide on that owner at the forthcoming meeting. “A new owner fixed the handoff” would fail twice: the assignment has not happened, and the notes contain no result. These sentences illustrate the review rule. They are not outputs observed from either agent.

Choose Actual size to read the graphic closely.

A reusable instruction should also avoid hiding current task facts in its supporting material. If the skill includes last month’s incident as an example, an agent might carry its owner or outcome into this month’s brief. The reviewer should ask whether an example is teaching structure or being treated as current source data. Label examples and supply the current facts separately so that boundary is easier to inspect.

The two environments may use different steps to select or load the skill. Record those setup steps without treating them as an outcome difference. Give both agents the same fictional notes and acceptance criteria. Then record any extra workspace page, local file, or tool result either agent used. If only Notion Agent can see a policy page, the comparison involves different context as well as different agents. The team may value that context, but it needs to account for it before attributing an output difference to the exported instruction.

Inspect the bundle before using it locally

If the workspace offers an export, begin with a file inventory. The Skills help directs a user to open the skill page, choose ••• then Download to local agents, and select a destination. It says Notion saves SKILL.md with attached files approved to share. List every file actually received. Read the main file, follow each reference to a supporting file, and mark whether that file is present and readable. Record the download date and any available version identifier alongside the inventory. No such inventory exists for this article because no export was performed.

Next, identify dependencies. An instruction may point to a Notion page, a local folder, a template, a named database, or a connected tool. Check each dependency in the environment where the local skill would run. A reference to the team’s current policy page may be useful inside Notion but incomplete locally if the agent cannot access that page. Copying an old policy into a bundle could make the instruction run while making its answer stale. The team must decide how a current, authorized version will be supplied.

Read every supporting file as content and as a potential instruction. A formatting template might only define headings. A separate file might include sensitive client material, an obsolete rule, or a request to send or edit something. Notion says exports contain approved supporting files, but the release text does not identify the files in a particular download or explain how this team approved them. Inspection is how the team establishes what is present.

Choose Actual size to read the graphic closely.

An inventory can be compact while still resolving the useful questions. For each file, record its path, purpose, references, information it contains, and any action it asks the agent to take. Mark dependencies as present, missing, inaccessible, or requiring a decision. If a template is missing, the task may need a corrected export or a revised instruction. If a policy link is inaccessible, the team may need an authorized input for each run. If a file instructs an agent to publish the brief, resolve that instruction before using the bundle for a drafting trial.

The need for this check extends beyond Notion. An August 2026 research preprint analyzed 138,133 public SKILL.md files and reported packaging and routing defects in many of them. Its static review did not test this Notion export or compare Notion Agent with Codex. It supports inspecting references and instructions before use, but it cannot predict the result of this team’s proposed trial.

An instruction to act is distinct from permission to act. A downloaded skill does not, by itself, show what tools a local agent can use. Conversely, an agent may have tools available that the brief does not need. Review the instruction and the actual environment together. Keep the initial task limited to a draft so the team can assess the skill’s content before expanding its authority.

Store the reviewed inventory with the local version. Otherwise, a later claim that the team used “the Notion skill” could mean the workspace page at that time, an older download, or a locally altered copy. Those differences matter when someone tries to explain an incorrect brief or reproduce a useful one.

Compare both briefs with the notes, using the same criteria

Once the files have been inspected and both environments are available, run the same fictional notes through each skill. Preserve the complete task input, the instruction version, any extra context used, and the full output. Findings for both agents remain pending until that exercise happens.

Start with structure: are Main takeaway, Decisions needed, Risks, and Questions for the next meeting present and useful? Then trace each factual sentence to the notes. A sentence saying that a single intake owner has been assigned would contradict the proposed status. A sentence saying the staffing decision is pending would preserve its status. A prediction that delivery will be late would exceed the notes, which say the impact is unknown. These are illustrative review judgments, not observed agent outputs.

Check what each brief does with missing information. It could say that the intake owner has not been named and ask who will take the role. That keeps the gap visible. Supplying a plausible name would create a fact. An operations lead may forward the brief without the source notes, so this check concerns the reliability of the record the team creates, not just sentence-level accuracy.

Choose Actual size to read the graphic closely.

Use the same review dimensions for both results: required sections, decision status, support for factual statements, handling of unknowns, and usefulness to the human reviewer. For each dimension, capture a finding and the passage that supports it. Do not mark results as equivalent because two briefs look alike. They may share an unsupported claim, or one may use accurate information available only through additional context.

A finding can be precise without becoming a score. For example: “Codex output, Decisions needed: says the owner was assigned; source note says assignment was proposed; review outcome: revise.” The same format could record that a Notion output preserved the proposal correctly, if a real run showed it. Until then, neither result is a finding. This keeps an evaluation method from being mistaken for a benchmark.

When a difference appears, classify it before editing. A missing section may point to unavailable instructions or to an instruction the agent did not follow. An invented owner may come from an ambiguous example, an unsupported addition in the output, or contradictory input notes. A different risk assessment may come from a workspace page available to one agent. The next test should change one relevant variable while keeping the notes and acceptance criteria stable. No failure or repair has been observed here.

Keep unsuccessful outputs in the record. A revised instruction that produces a better brief is useful, but the earlier result explains why the revision was needed. If reviewers disagree about whether a phrase accurately describes a pending decision, improve the acceptance criterion as well. The exercise can sharpen the team’s definition of a good brief even if it does not yet justify using the workflow across agents.

Test the update path with a visible, harmless edit

A good first brief does not settle maintenance. The shared skill can change after a local copy has been downloaded. Notion says an edited skill receives a badge so people know to get the latest version. The supplied release text does not say that an existing local Codex file updates itself.

Choose a change whose effect is easy to see. In this fictional exercise, change the required order from Main takeaway, Decisions needed, Risks, Questions to Main takeaway, Risks, Decisions needed, Questions. Save the original Notion instruction and reviewed local files first. After the edit, record the new Notion instruction and whether a badge appears. Inspect the existing local files. If a fresh download is offered, inspect its contents before replacing anything, then use the same notes again and label each output with its instruction version.

The sequence distinguishes several possible observations: what changed in the workspace instruction, what remained in the older local files, what arrived in a new download, and what each agent produced. None can be inferred from the announcement alone. A section-order edit has limited reach. It can expose a version difference, but it cannot prove that future changes to supporting files, access, or approval rules will behave the same way.

Choose Actual size to read the graphic closely.

Until the team has observed its update process, give the local bundle a named maintainer and a version record. That person can review a changed skill, inspect a new download, compare it with the installed files, and update the local copy through the team’s usual process. This is an operational recommendation for traceability, not a claim about a required Notion procedure.

Local adaptations need the same attention. Suppose someone changes the downloaded instruction to point at a local template. The change may help, but the next download could replace it or create two versions with the same title. Decide whether that adaptation belongs in the shared Notion skill, remains a documented local change, or should be removed. The useful record is which instruction produced which brief and who reviews the next change.

Confirm access and keep external actions under review

Before demonstrating portability, confirm which skill controls the intended users can access: creation, sharing, personal enablement, invocation, automatic use, and download. The current Skills help explains the page, Library, and database controls, but neither it nor the release establishes each feature’s plan eligibility or rollout in this particular account. An ops owner should base the trial on visible workspace controls.

External app connections raise a separate access question. Notion’s MCP help page, undated in the supplied text and captured September 30, 2026, says Notion Agent MCP connections require a Business or Enterprise plan. It says admins may limit available servers and that connections can be added on web and desktop, but not mobile. Its troubleshooting section says the Add Custom MCP button appears only for admins when the workspace allows custom servers. The release describes Custom MCP connections as beta on Business and Enterprise plans. These conditions do not establish the plan rules for creating or exporting a skill.

Choose Actual size to read the graphic closely.

The MCP help page says a personal connection uses that person’s account and available permissions; teammates connect their own accounts. It says supported tools can be configured to run automatically or require approval. Notion advises setting the Agent to ask permission before it creates or updates content in a connected app. Review the connection settings and keep proposed write actions approval gated. The release’s reference to confirmations does not establish that every action pauses for approval in every configuration. Source: Notion MCP help.

The monthly brief needs no MCP connection for its first trial. Creating an issue from a risk, updating a database, or sending a completed brief would be a later workflow step. Define its input, proposed action, reviewer, and connected account separately. An accurate draft is evidence about the drafting task; it does not establish that the agent should be allowed to change another system.

Choose Actual size to read the graphic closely.

Make the maintenance decision from the evidence collected

The trial should leave the ops owner with four answers. Were the skill controls and download available to the intended people? Did the inspected files contain the instructions and dependencies this task required? Did each agent produce a brief that preserved the notes and met the agreed criteria? After an edit, what happened to the shared instruction, older local files, and any fresh download?

If those answers satisfy the monthly-brief task, the team can choose Notion as the maintained instruction, name an owner for the local bundle, and record when that bundle is refreshed. If a check fails, repair the specific failure before expanding the workflow. A missing file calls for an export or instruction review. An invented decision calls for a closer look at the notes, examples, output, and human check. An unavailable control calls for an access decision.

If access or update behavior remains unknown, keep the decision about using the workflow across both agents open. The team can use a useful drafting method in one environment while gathering the missing evidence for the other. Notion’s announcement describes a skill that can travel as files. The team can rely on the workflow when it can inspect the files, judge the results, understand the permissions, and track changes to its local copy.

For the related access decision, read how to review a Notion Agent MCP connection.

Checked for this article

Sources

  1. Notion 3.7: Agent skills for your whole team
  2. Create and manage skills
  3. Connect MCP servers to your Notion Agent
  4. What Keeps Agent Skills from Being Reusable? Evidence from 138K SKILL.md Files

Keep going

All articles