This is my first time working on a task in this project.

Please first check whether OpenSpec already contains relevant context, then tell me:

1. Whether we need to create or update an OpenSpec change
2. Whether there is a suitable Superpower to use
3. What the minimum viable path forward is
4. Which actions require my confirmation

Will a future teammate, my future self, or a new Codex thread need to recover this context later?

OpenSpec is for preserving long-term valuable context, not for recording every conversation and small action.

Codex ran out of room in the model's context window.
Start a new thread or clear earlier history before retrying.

More tools are not always better.
More rules are not always better.

Complex workflows should be packaged only when needed,
not turned into Superpowers by default.

If a rule, tool, skill, or Superpower does not clearly help the current task, do not enable it.

Context is a budget, not a trash bin.

OpenSpec preserves context.
Superpowers package complex workflows.
Codex understands the task, selects tools, executes the process, and updates the record.

My goal is: [goal]
The background is: [background]
This scope includes: [scope]
This explicitly excludes: [out of scope]
Please first check the necessary context, then provide an execution plan.
If files need to be modified, first explain what you will change.
After completion, explain the validation method and result.

Please first assess this task's complexity and risk:

1. Whether OpenSpec is needed
2. Whether a Superpower is needed
3. What context needs to be read
4. Whether files will be modified or external systems affected
5. Which steps require my confirmation

Proceed only after that assessment.

Please create a stage summary based on the current context:

1. Current goal
2. Completed work
3. Remaining work
4. Key decisions
5. Validation results
6. Current risks
7. Recommended next steps

Write information that should be preserved long term into OpenSpec.

Ask Codex to perform more verifiable intermediate steps and fewer final leaps without context or validation.

If a task needs to recover context across people, time, or threads, record it in OpenSpec.

## Related Context

- Related specs:
  - user-auth
  - billing-plan

- Related changes:
  - add-team-invitation-flow

- Related code:
  - src/modules/auth/
  - src/modules/billing/
  - apps/web/pages/settings/

- Related docs / business context:
  - PRD: team-permission-v2
  - Test plan: billing-regression
  - Metric: paid-team-conversion-rate
  - Customer project: enterprise-onboarding

- Affected behavior:
  - Permission checks after user login
  - Feature visibility after team plan changes

- Out of scope:
  - No changes to the payment flow
  - No changes to invoice generation logic

Stable rules go into specs.
Iteration process goes into changes.
Long-term behavior after completion must be written back to specs.

After the task is complete, please help maintain the OpenSpec document relationships:

1. Check whether this change affects existing specs
2. If it does, update the corresponding specs
3. Add related specs, related code, related docs, and related changes to the change
4. Mark task completion status
5. Record validation commands and results
6. Decide whether the change can be archived
7. Clean up outdated or duplicate temporary notes to avoid hurting future retrieval

## Completion Summary

- Final outcome:
- Actual changes:
- Key decisions:
- Verification:
- Specs updated:
- Follow-up:

OpenSpec records reusable context, not model garbage.

Please help me improve the retrievability of the current OpenSpec:

1. Check openspec/specs/ and openspec/changes/
2. Identify documents with unclear names, missing relationships, or unclear status
3. Check whether active changes contain duplicate or outdated content
4. Check whether completed changes should be archived
5. Check whether specs are missing long-term rules that should have been written back from completed changes
6. Provide cleanup suggestions
7. Modify files only after I confirm

OpenSpec is not a chat backup. It is reusable project context.
Specs record long-term stable capabilities, behavior rules, and system agreements.
Changes record specific iterations, task progress, decisions, and validation results.
Every change should maintain related specs, related code, related docs, and related changes.
Every change should clearly state affected behavior and out of scope.
After a task is complete, check whether long-term behavior needs to be written back to specs.
Completed changes should be archived in time to prevent active changes from becoming noise.
Avoid low-value operation logs. Record only key decisions, validation results, risks, and follow-ups.
Whenever creating, updating, or archiving OpenSpec content, maintain document relationships.
Control context complexity. Read only OpenSpec content directly related to the current task.

When initializing OpenSpec, also preserve the rules for maintaining OpenSpec itself.

Before starting, please check this project's OpenSpec:

1. Read openspec/config.yaml
2. Review the project conventions in context
3. Review existing specs in openspec/specs/
4. Check whether openspec/changes/ contains an active change related to this task

If there is a related change, continue based on it.
If there is no related change, decide whether this task needs a new OpenSpec change.

Please first check whether OpenSpec already contains relevant context, then decide whether we need to create or update a change.

If another person would struggle to understand the task background without reading the chat history, record it in OpenSpec.

I want you to help install and configure OpenSpec in this project.

You may decide the appropriate granularity for OpenSpec records. My goal is to use OpenSpec to structure our iteration process, especially after a task is successfully completed, so that results, decisions, validation methods, and follow-up items are preserved.

Please prevent context from living only inside Codex conversations. This way, even if we later see "Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.", I can open a new thread and recover task context through OpenSpec without restating everything.

In addition to creating the basic OpenSpec structure, please write the OpenSpec maintenance principles into the project conventions so future OpenSpec records follow them.

Please focus on these principles:

1. OpenSpec is not a chat backup. It is reusable project context.
2. specs record long-term stable capabilities, behavior rules, and system agreements.
3. changes record specific iterations, task progress, decisions, and validation results.
4. Every change should maintain related specs, related code, related docs, and related changes.
5. Every change should clearly state affected behavior and out of scope.
6. After a task is complete, check whether long-term behavior needs to be written back to specs.
7. Completed changes should be archived in time to prevent active changes from becoming noise.
8. Avoid low-value operation logs. Record only key decisions, validation results, risks, and follow-ups.
9. Whenever Codex creates, updates, or archives OpenSpec content, it should maintain relationships between documents to improve future retrieval and context recovery.
10. Control context complexity. Read only content directly related to the current task.

Please search OpenSpec first and confirm whether there are specs or changes related to this task.

If you judge this to be a non-trivial change, please create an OpenSpec change first and record the requirement, solution, and task breakdown. Do not execute directly or produce the final conclusion first.

Based on the OpenSpec change, please break this task into executable tasks and mark the recommended execution order.

Please proceed through the tasks in the OpenSpec change one by one, and update task status after completion.

After completion, please run or perform the necessary validation and record the validation method and result in the OpenSpec change.

After the task is complete, please update OpenSpec:

1. Mark completed tasks
2. Record the actual changes or business output
3. Record key decisions
4. Record validation results
5. Update related specs, related code, related docs, and related changes
6. Decide whether specs need to be updated
7. Record remaining issues or follow-up items
8. If the change is complete, archive it

This is a new Codex thread. Please do not rely on previous chat history.

Please first read this project's OpenSpec:

1. openspec/config.yaml
2. openspec/specs/
3. openspec/changes/

Please find the active change that is still in progress and summarize:

- Current task goal
- Completed work
- Remaining work
- Key decisions
- Validated work
- Current risks
- Recommended next step

Then continue with the most reasonable next step.

Only load content directly related to the current task. Avoid loading unrelated history into the context all at once.

If new teammates repeatedly ask "how do I do this step?", or senior teammates have to walk people through it every time, consider turning it into a Superpower.

Do simple tasks directly.
Package only repeated complex tasks.
Practice uncertain workflows first, then package them.

Please first check OpenSpec and understand this task's context.

Then decide whether this task is suitable for an existing Superpower:

- If there is a suitable Superpower, use it first and explain which part of the task it will solve.
- If there is no suitable Superpower, complete the task using the normal Codex workflow.
- If you think this task will repeat in the future, suggest whether it should be turned into a new Superpower.

This is my first time handling a similar task in this project.

Please first check OpenSpec and the project documentation, then tell me:

1. Whether the current task already has relevant context
2. Whether there is a suitable Superpower
3. How you plan to complete this task in the fewest reasonable steps
4. Which actions require my confirmation

Before using the Superpower, please explain:

1. Which Superpower you plan to use
2. Which steps it will execute
3. Whether it will modify files
4. Whether any high-risk operations are involved
5. Which steps require my confirmation

This workflow may be used repeatedly by the team in the future.

Please help me judge whether it is suitable to turn into a Superpower.

If it is suitable, please organize:

1. Applicable scenarios
2. Non-applicable scenarios
3. Input requirements
4. Execution steps
5. Safety boundaries
6. Validation methods after completion
7. Whether OpenSpec needs to be updated

Based on the workflow above, please help me create a reusable team Superpower.

Requirements:

- Clear name
- Explain applicable scenarios
- Clearly describe execution steps
- Mark risky operations
- Include validation methods
- Include how to update OpenSpec after task completion
- Make it callable by new teammates through natural language

Please first check whether OpenSpec already contains relevant context.

Focus on:

1. openspec/config.yaml
2. openspec/specs/
3. openspec/changes/

Please summarize content related to this task and decide:

- Whether there is a related active change
- Whether a new OpenSpec change is needed
- Whether there is a suitable Superpower
- What the minimum viable path forward is

Please create an OpenSpec change for this task.

Requirements:

1. The change name should be clear and searchable
2. The proposal should state background, goals, non-goals, and impact scope
3. The design should record key solution decisions, trade-offs, risks, and boundaries
4. The tasks should be broken into executable steps
5. Add related specs, related code, related docs, and related changes
6. Avoid unrelated background and keep the documents concise

Please continue based on the existing OpenSpec change.

First read the change's proposal, design, and tasks, then summarize:

1. Current goal
2. Completed tasks
3. Remaining tasks
4. Key decisions
5. Current risks
6. Most reasonable next action

Then continue according to the tasks.

Please decide whether the current task is suitable for a Superpower.

Judgment criteria:

1. Whether it is a repeated task
2. Whether the steps are complex or easy to miss
3. Whether there is an existing stable process
4. Whether using a Superpower is simpler than direct execution
5. Whether the context it consumes is worth it

If suitable, explain which Superpower to use.
If not suitable, complete the task using the normal Codex workflow.

Please control context complexity.

Read only OpenSpec, code, materials, and tool instructions directly related to the current task.
Do not load unrelated specs, unrelated changes, or unnecessary Superpowers.
If more context is needed, explain why before continuing.

Before execution, please confirm:

1. Which OpenSpec change corresponds to this task
2. What content needs to be modified, organized, or produced
3. Which behaviors, workflows, documents, data, or users will be affected
4. What is explicitly out of scope
5. What validation needs to be performed
6. Whether any high-risk operations require my confirmation

After the task is complete, please update OpenSpec:

1. Mark task completion status
2. Record actual changes or business output
3. Record key decisions
4. Record validation methods and results
5. Update related specs, related code, related docs, and related changes
6. Decide whether specs need to be updated
7. Decide whether the change can be archived

This is a new Codex thread. Please do not rely on previous chat history.

Please recover context through OpenSpec:

1. Read openspec/config.yaml
2. Check openspec/specs/
3. Check openspec/changes/
4. Find the most relevant active change
5. Summarize task goal, completed work, remaining work, key decisions, validation results, and next step

Only load content related to the current task. Avoid consuming too much context.

Before archiving this OpenSpec change, please check:

1. Whether all tasks are complete
2. Whether validation results have been recorded
3. Whether long-term behavior has been written back to specs
4. Whether related specs, related code, related docs, and related changes are complete
5. Whether any follow-up remains
6. Whether outdated or duplicate content needs to be cleaned up

Archive only after confirming everything is ready.

Please help me check OpenSpec retrieval quality.

Focus on finding:

1. Specs or changes with unclear names
2. Changes missing related context
3. Completed changes that have not been archived
4. Content that should have been written back to specs but has not been
5. Duplicate, outdated, or low-value context
6. Issues that may affect Codex retrieval efficiency

Output suggestions first. Do not modify files directly.

I want to advance a new requirement or feature: [describe the requirement or feature]

Please first check OpenSpec:

1. Whether related specs already exist
2. Whether related active changes already exist
3. Whether a new OpenSpec change is needed

If needed, create the proposal, design, and tasks first.
Then proceed according to the tasks and update OpenSpec after completion.

I want to handle an issue or defect: [describe the issue]

Please first check OpenSpec and related context, then decide whether this issue involves existing specs or active changes.

If the scope is clear and small, handle it directly.
If it involves behavior changes, data flow, APIs, state logic, business rules, customer impact, or future tracking, create or update an OpenSpec change.

After completion, record the cause, fix, and validation method.

Please help me perform a pre-commit, pre-delivery, or pre-external-sync check:

1. Review the current git diff, document changes, or business output
2. Summarize this change or conclusion
3. Decide whether OpenSpec needs to be updated
4. Run the necessary tests, lint, build, acceptance criteria checks, data definition checks, or business review
5. Check whether obvious risks exist
6. Recommend whether it is ready for commit, delivery, or external sync

Please review this product requirement: [describe the requirement or paste the PRD]

Focus on:

1. Whether background, goals, and non-goals are clear
2. Whether user scenarios and core flows are complete
3. Whether acceptance criteria are verifiable
4. Whether dependencies, risks, and boundaries are explicit
5. Whether an OpenSpec change needs to be created or updated
6. Which questions require confirmation from product, design, engineering, QA, or business owners

Please review this test plan: [describe the test plan]

Focus on:

1. Whether test scope and out-of-scope items are clear
2. Whether test data, environment, and preconditions are explicit
3. Whether positive, negative, boundary, compatibility, and regression scenarios are covered
4. Whether acceptance criteria can be validated by tests
5. Whether high-risk gaps exist
6. How test results and remaining risks should be written back to OpenSpec

Please help me organize this business plan or retrospective: [describe the business item]

Focus on outputting:

1. Background and goals
2. Execution process or plan
3. Key results and deviations
4. Confirmed decisions
5. Risks, issues, and follow-up items
6. Which long-term business rules or metric definitions need to be written into OpenSpec

Based on the current OpenSpec change and completed work, please create a stage summary:

1. Completed work
2. Remaining work
3. Confirmed decisions
4. Rejected alternatives and why they were rejected
5. Validation results
6. Current risks
7. Recommended next steps

Please update OpenSpec with information that needs to be preserved long term. Do not leave it only in chat.

Help me initialize OpenSpec and write OpenSpec maintenance principles into the project conventions.

Requirements:

1. Create or check openspec/config.yaml
2. Write short, executable OpenSpec maintenance principles into context
3. Distinguish the responsibilities of specs and changes
4. Make clear that every change needs to maintain related specs, related code, related docs, and related changes
5. Make clear that after a change is complete, we should check whether specs need to be updated
6. Make clear that completed changes should be archived in time
7. Make clear that OpenSpec should not record low-value operation logs
8. Make clear that Codex should read only necessary context for the current task to avoid context pollution
9. If needed, create openspec/specs/openspec-maintenance/spec.md as the long-term maintenance standard

Please first explain which principles you plan to write, then modify files.

Please handle this task according to the standard OpenSpec actions: [describe the task]

First decide which OpenSpec Superpower should be used:

1. `openspec-start-task`: check context before starting a task
2. `openspec-create-change`: create a change for a non-trivial modification
3. `openspec-continue-change`: continue an existing change
4. `openspec-finish-change`: close out and judge archive readiness after completion
5. `openspec-maintenance`: improve OpenSpec retrieval quality

Please explain the Superpower you selected, why you selected it, what context it will read, whether it will modify files, and which operations require my confirmation.

OpenSpec prevents context from being lost.
Superpowers make complex workflows reusable.
Codex makes execution automated, verifiable, and preservable.
Context budget determines model attention, so keep simple things simple and load only what is needed.