feat: align update-docs skill with SOP -- 10 steps, verification-before-skip #140
No reviewers
Labels
No labels
domain:backend
domain:devops
domain:frontend
status:approved
status:in-progress
status:needs-fix
status:qa
type:bug
type:devops
type:feature
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ldraney/claude-custom!140
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "138-align-update-docs-skill-with-sop-add-mis"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Rewrites the
/update-docsskill to match all 10 steps fromsop-post-merge-docs. Adds three missing steps (verify deploy, nit-bundle creation, cross-pillar impact check) and replaces all "skip this step" language with verification-before-skip -- every step must report UPDATED, VERIFIED CURRENT, or NOT APPLICABLE (reason).Changes
commands/update-docs.md-- complete rewrite:sop-post-merge-docssop-post-merge-docsTest Plan
/update-docsafter a real PR merge and verify all 10 steps executeReview Checklist
sop-post-merge-docsRelated
PR #140 Review
DOMAIN REVIEW
Domain: Agent skill definition (markdown instruction file for Claude Code
/update-docscommand). No executable code, no compiled language, no tests applicable. Review focuses on correctness of instructions, internal consistency, alignment with platform conventions, and dependency safety.Findings:
Verification-Before-Skip pattern is well-designed. Every step now mandates exactly one of UPDATED, VERIFIED CURRENT, or NOT APPLICABLE (with reason). This eliminates ambiguous "SKIPPED" outcomes. The old file had 6 instances of "skip" language -- all removed in the new version.
Step 6/7 reordering is correct. Old flow was: move item (Step 5), then sync (Step 6). New flow: sync first (Step 6), then move (Step 7). This is the right order -- sync reconciles drift against Forgejo before the board item move is applied to a clean board state.
Step 8 (Memory) correctly scoped to behavioral lessons. The old Step 7 told agents to write project state (phase completion, current state) into MEMORY.md. The new Step 8 restricts to behavioral knowledge only and reports NOT APPLICABLE for project state. This aligns with
feedback_memory_scope.md.Old Step 8 (todo note creation) correctly removed. The old step used
mcp__pal-e-docs__create_notewithnote_type: "todo", which is now hard-blocked byhooks/check-note-template.sh(lines 28-39). The old instruction would have been denied at runtime. Replacing it with Steps 9 and 10 (Forgejo issues) is the correct path.Reference footer updated from
skill-update-docstosop-post-merge-docs. Correct -- the canonical source callout at the top establishes the SOP as authoritative.Step 9 references
template-issue-nit-bundle-- this template does not currently exist in the codebase. PR #139 (issue #137) appears to be the companion PR that adds nit-bundle support to the issue template hook. This creates a dependency: if #140 merges first, Step 9 will reference a template that does not exist yet. This is not a blocker because the step instructs the agent to "create a Forgejo issue using template-issue-nit-bundle" -- at worst, the agent creates a non-templated issue. But the merge order matters for clean execution. Recommend noting this dependency.Step 2 references
sop-ci-pipeline-recovery-- this SOP is referenced by slug. If it does not exist in pal-e-docs yet, Step 2's failure path ("follow sop-ci-pipeline-recovery") would leave the agent with no instructions. Worth confirming the SOP exists.Canonical source callout is a strong pattern. The callout "If this file and the SOP diverge, the SOP wins" is exactly right for a skill that implements an SOP. This prevents drift arguments.
BLOCKERS
None. This is a markdown instruction file, not executable code. The BLOCKER criteria (test coverage, input validation, secrets, DRY auth) do not apply to non-executable documentation.
NITS
Step 2 bash snippet is incomplete. The code block shows
source ~/secrets/pal-e-services/forgejo.envand a comment# Use mcp__woodpecker__list_pipelines or curl to check the latest pipeline on mainbut does not provide the actual curl command or MCP tool call. Every other step that uses bash (Step 1) provides the full command. Consider providing the concretemcp__woodpecker__list_pipelinescall or a curl example for consistency.Step 9 body format uses
\\\\n(escaped newline). The instruction says to include### Type\\nNit-Bundlein the issue body. The double-backslash may confuse agents about whether this is a literal\nstring or a newline. Consider using a code block with actual formatting instead.Completion summary template could be copy-paste ready. The summary shows
| NOT APPLICABLE -- no CIalternatives inline with pipes, which is clear for human readers but might cause agents to emit the pipe character literally. Minor -- agents are generally good at interpreting "option A | option B" patterns.PR #139 dependency not mentioned in Related section. If Step 9's
template-issue-nit-bundledepends on #139 merging first, the Related section should note "Depends on #139" or "Companion to #139."SOP COMPLIANCE
138-align-update-docs-skill-with-sop-add-misstarts with issue #138plan-pal-e-agencyPROCESS OBSERVATIONS
Deployment Frequency: This is a config/skill file change. No CI pipeline, no deployment artifact. Merging is effectively deploying since agents read this file from the repo directly.
Change Failure Risk: Low. The verification-before-skip pattern is strictly better than the old "skip if X" pattern. The main risk is Step 9/10 referencing templates or SOPs that do not yet exist, but agents handle missing references gracefully (they will ask or report NOT APPLICABLE).
Documentation: The PR body is thorough -- the Changes section itemizes every step with what changed and why. The review checklist in the PR body is a strong practice.
Merge Order Dependency: PR #139 (nit-bundle hook) and #140 (update-docs rewrite) should ideally merge in the order #139 then #140, so the template exists before the skill references it. Not a hard blocker but worth noting.
VERDICT: APPROVED
The rewrite correctly aligns the skill with the 10-step SOP, removes deprecated todo-note creation that would be blocked at runtime anyway, introduces the verification-before-skip pattern consistently, and reorders sync/move correctly. The missing plan slug in Related and the dependency on #139 are worth noting but not blocking. Clean, well-scoped PR.