docs: remove deleted project docs skill requirement

This commit is contained in:
inman committed 2026-09-09 17:23:56 +08:00
1 parent 515b545b32
commit bb115a3382
13 files changed
+114 -59

No files matched your search

@@ -1,30 +1,41 @@
# Concurrent Task Gate
# Concurrent Worktree Check
Complete this gate before the Planning Gate.
Complete this repository-local check before the Planning Gate. It does not require an external Skill, `task_context.py`, or a separate ownership registry.
## Commands
Run from the intended repository worktree:
```bash
git status --short
git branch --show-current
git rev-parse --show-toplevel
git worktree list --porcelain
git rev-parse HEAD
```
## Invariants
- One active task owns one worktree.
- One worktree carries edits for only one active task at a time.
- Concurrent tasks use different branches and worktrees.
- Never stash, reset, move, delete, or adopt unknown work automatically.
- Feature tasks write only their own task record and uniquely named supporting records.
- Keep the active task record present until ownership is released.
- Treat `start`, `touch`, `complete`, and `release` as serialized registry transactions; lock timeout or malformed registry state blocks the gate.
- Keep an active task record for repository-changing work.
- Treat task records as collaboration context, not locks. Git worktree identity and visible status are the authoritative local safety inputs.
- Feature-task write boundaries in this gate supersede legacy instructions to update shared or canonical project documents.
## Required Output
- Task ID:
- Mode: Feature | Integration
- Branch:
- Worktree:
- Base commit:
- Ownership result: Claimed | Resumed | Isolated | Blocked
- Other active local tasks:
- Existing changes in this worktree:
- Other local worktrees relevant to this scope:
- Overlap result: Clear | Isolated | Blocked
## Block Conditions
- The worktree belongs to another active task and isolation did not succeed.
- An unowned worktree contains staged, unstaged, or untracked changes.
- Existing changes overlap the intended edit and cannot be safely preserved or attributed.
- The intended branch or worktree is ambiguous, or isolation from a conflicting task did not succeed.
- No reliable committed base was selected for a new worktree.
- The runtime cannot keep later Git and file operations rooted in the isolated worktree.
@@ -2,14 +2,15 @@
Before planning, confirm:
- I know the task ID, mode, branch, worktree, base commit, and ownership result.
- I read the active task record and know its scope.
- I know the current branch, absolute worktree, base commit, Git status, and task scope.
- For repository-changing work, I read or created the active task record and know its scope.
- I know what this project is and what it is not.
- I treat current-state as the last integrated snapshot rather than live concurrent state.
- I checked active decisions and the architecture overview.
- I identified task-specific docs that need deeper reading.
- I inspected other local task records through `task_context.py status --json`.
- I inspected `git worktree list --porcelain` and any available peer task records relevant to this scope.
- I assessed code overlap separately from semantic or decision conflict.
- I reported missing peer records as unknown coordination state.
- I can name unknown, stale, or conflicting information.
- I know which updates remain task-scoped and which require Integration Gate.
- I did not rely on an external project-document Skill or task registry.
@@ -4,9 +4,9 @@ Use this gate to promote completed task facts into canonical project memory.
## Requirements
- Run in an exclusively owned integration worktree.
- Hold the repository integration lock.
- For a single completed Feature, create the Integration worktree from that Feature commit so its task-owned records are already inside the Integration task's recorded base. Verify the target default branch is an ancestor or reconcile it explicitly before canonical edits; starting from the older default branch and then introducing another task's record will correctly fail the drift gate.
- Run in an isolated integration worktree when concurrent edits may overlap. A user-requested direct governance update may run in the current worktree only after the repository-local worktree check confirms existing changes are known and non-overlapping.
- Do not require or emulate an external integration lock; use Git worktree isolation, visible status, and explicit conflict checks.
- For a single completed Feature, create the Integration worktree from that Feature commit so its task-owned records are already present. Verify the target default branch is an ancestor or reconcile it explicitly before canonical edits.
- Verify the task commits being integrated are present.
- Review source task records, task-prefixed supporting records, promotion candidates, and semantic conflicts in read-only mode.
- Write integration notes only to the integration task's own task record or `{task_id}__<slug>.md` supporting records.
+1 -1
View File
@@ -1,6 +1,6 @@
# Memory Index
Use this as the high-density entry point after the Concurrent Task Gate establishes task identity and worktree ownership.
Use this as the high-density entry point after the repository-local Concurrent Worktree Check establishes the current branch, worktree, status, and task scope.
## Startup Set
+11 -10
View File
@@ -1,12 +1,12 @@
# Planning Gate
A coding agent must complete this gate after the Concurrent Task Gate and before writing an implementation plan.
A coding agent must complete this gate after the repository-local Concurrent Worktree Check and before writing an implementation plan.
## Peer Scope Check
Run `task_context.py status --json`. For each other owner, read only the peer task record at `Path(owner.worktree) / owner.task_record`. Use its `Scope`, `Intent And Constraints`, and `Promotion Candidates` sections to assess overlap.
Use `git worktree list --porcelain` to identify other local worktrees. When an available peer task record or committed branch diff is relevant, use its scope and promotion candidates to assess overlap.
Do not inspect or modify arbitrary uncommitted files in another task's worktree. Report a missing or unreadable peer record as unknown coordination state; do not silently treat it as no overlap. Code-path overlap alone is a warning. Block when semantic decisions conflict or unresolved overlap could change the plan.
Do not inspect or modify arbitrary uncommitted files in another task's worktree. A missing peer task record is not itself a blocker, but unresolved overlap that could change the plan is. Code-path overlap alone is a warning. Block when semantic decisions conflict or overlapping unknown changes cannot be preserved safely.
## Required Output
@@ -14,12 +14,13 @@ Do not inspect or modify arbitrary uncommitted files in another task's worktree.
## Project Context Loaded
Task context:
- Task ID:
- Mode:
- Task record, if any:
- Mode, if applicable:
- Branch:
- Worktree:
- Base commit:
- Other active local tasks:
- Existing changes:
- Other relevant local worktrees:
- Overlap or semantic-conflict assessment:
Read:
@@ -43,8 +44,8 @@ Gate result:
The gate passes only when:
- task identity and worktree ownership are resolved
- the active task record exists and matches the owner task ID
- current branch, worktree, base commit, status, and task scope are resolved
- the active task record exists for repository-changing work and matches the current scope
- required documents were read
- task-relevant decisions were checked
- relevant evidence, reflection, and commitment indexes were checked when applicable
@@ -56,8 +57,8 @@ The gate passes only when:
Block planning when:
- worktree ownership is unresolved
- an unowned worktree is dirty and has not been explicitly adopted by a human
- the intended branch or worktree is unresolved
- existing overlapping changes cannot be attributed or preserved safely
- required worktree isolation failed or later operations cannot remain rooted there
- required documents are missing or a concurrency upgrade is incomplete
- current integrated state conflicts with the user request
@@ -1,7 +1,7 @@
# Read Before Coding
Before editing code, verify that the implementation plan passed both the Concurrent Task Gate and Planning Gate. Confirm the task ID, branch, worktree, owner, and active task record still match.
Before editing code, verify that the implementation plan passed both the repository-local worktree check and Planning Gate. Confirm the branch, absolute worktree, visible Git status, and current task scope still match; when a task record is being maintained, confirm it also matches.
If the plan is stale, ownership changed, or new peer scope affects the plan, return to `read-before-planning.md`. Keep every later file and Git operation rooted in the owned worktree.
If the plan is stale, the worktree changed, or new peer scope affects the plan, return to `read-before-planning.md`. Keep every later file and Git operation rooted in the checked worktree.
Read the source files directly related to the target modules. Record feature progress, discovered constraints, verification, and promotion candidates in `.project-docs/30-worklog/tasks/{task_id}.md`; leave canonical project memory to Integration Gate.
@@ -2,13 +2,13 @@
Before writing any coding plan, follow this order:
1. Run the Concurrent Task Gate.
1. Run the repository-local Concurrent Worktree Check in `concurrent-task-gate.md`.
2. Read `.project-docs/05-agent-entry/memory-index.md`.
3. Read the active task record at `.project-docs/30-worklog/tasks/{task_id}.md`.
3. Read the active task record, or create one for repository-changing work before planning.
4. Read `.project-docs/00-brief/project-positioning.md`.
5. Read `.project-docs/30-worklog/current-state.md` as the integrated snapshot.
6. Read `.project-docs/10-decisions/decision-index.md` and `.project-docs/20-architecture/system-overview.md`.
7. Inspect other locally active task scopes.
7. Inspect other locally active worktrees and any available task records for scope overlap.
Then read additional files when relevant:
@@ -21,4 +21,4 @@ Then read additional files when relevant:
- Follow-up, loop, timed check, or restart-point task: `.project-docs/80-commitments/commitments.md`
- Suspicious integrated context: `.project-docs/90-maintenance/stale-items.md`
Treat shared files as the last integrated snapshot, not as live state from concurrent feature tasks. Do not write a plan until both the Concurrent Task Gate and Planning Gate pass.
Treat shared files as the last integrated snapshot, not as live state from concurrent feature tasks. Do not write a plan until both the repository-local worktree check and Planning Gate pass. No external Skill or task registry is required.