xenonbyte xsk-consume-point
Fold one or more researched point documents from .xsk/points/ into a single requirement document via xsk-write-req. Points that land in the requirement are archived as consumed; the rest stay active or are dropped only on user confirmation.
When to use
Match the intent, not the exact words. Common cues:
- "把这些 point 变成需求", "消费 point", "把调研结果写成需求"
- "consume points", "turn points into a requirement", "fold points into a req"
- any request to convert accumulated point documents into a structured requirement document
How it works
1. Resolve the selection. Inspect active .xsk/points/*.md outside archive. Respect explicitly selected slugs; otherwise list slug, status, and Aspect and ask which ready points to consume. Only points with status: ready may be selected. A selected researching or invalid point needs xsk-point first, without writes or archival here. If no unarchived point has status: ready, stop unless resuming an explicitly identified partial consume whose archived sources can be verified. Do not silently select other points or substitute the latest archive.
2. Guard the single-active requirement. Respect an explicitly named target and prior authorization to append. If one active requirement exists, confirm that goal and scope fit the selected conclusions; ask only when the target or scope is unresolved. If multiple active docs exist, list the offending paths and report the broken invariant before any write. Never silently fold a different need into the active doc or archive it to make room.
3. Preflight the whole batch. Before calling writer or changing any document, re-read each selected active point and confirm status: ready, valid slug/filename identity, and relevant evidence still applicable. On an explicitly identified retry, sources already archived as consumed are completed work only after verifying their content and incorporation into the same requirement; do not require those archived sources to be ready again. Check all source and archive targets, not one collision after earlier writes. Resolve contradictory conclusions, unnecessary duplicates, and missing dependencies; do not add unselected dependencies silently. A changed relevant fact needs fresh research/confirmation, not a blanket re-research based on age.
For retry, reconcile the existing requirement's incorporation mapping with active and archived point contents. An archive target that already exists is resumable only when it matches that source/conclusion and the same requirement, allowing the expected consumed metadata differences. Conflicting archives stop the batch before new mutation rather than overwriting them. Never trust a mapping or consumed flag without the matching incorporated content.
4. Hand off once to xsk-write-req. Retain each source snapshot and the archive target's observed state (absence, type, and content) from preflight for comparison after the handoff. Supply selected Aspect and Landed plan, necessary Research evidence, target identity, and existing authorization. Ask writer to preserve a compact mapping of point slug and adopted conclusion to requirement/acceptance. Keep evidence necessary to implement in the requirement itself, not only links to ignored archives. Suppress its commit offer and next-action menu; writer returns the saved path, changed paths, and audit result here without starting xsk-execute-req. Reuse already incorporated content on retry instead of appending it twice. If writer stops on a decision, audit failure, or write failure, archive nothing and report the incomplete handoff.
5. Revalidate before changing points. Before each partial source edit, drop, or archive write, re-read both the source and archive target and compare their current state with the snapshots validated for incorporation. Batch preflight does not remain valid across nested writer execution or earlier point operations. If either differs, including a newly appeared or replaced archive target, stop the remaining consume for reconciliation without overwriting or removing the changed files. Preserve the requirement and any archives already landed, report which point version was incorporated, and do not enter execution until reconciliation completes.
Partial adoption leaves the source active with the remaining content clearly identified; do not mark the entire point consumed. Apply a content-checked patch to the freshly validated source, preserving all unadopted content, rather than replacing it from an old full-file copy. Excluded and deferred points stay unchanged. Drop content only on the user's explicit decision, using xsk-point's drop procedure after the same source/target revalidation, without a second confirmation.
After successful incorporation, ensure .xsk/.gitignore contains the line points/archive/, creating or appending only the missing line and preserving existing rules. For each fully folded point, re-read the source and confirm it is still the content incorporated. Set status: consumed, consumed_at, and consumed_by: <requirement-slug>. Resolve that stable slug at either .xsk/requirements/<slug>.md or .xsk/requirements/archive/<slug>.md; for older consumed_by path values, extract the slug from the known requirement path and verify the matching document. Do not batch-rewrite history or reuse archived requirement slugs.
Use write-before-remove at .xsk/points/archive/<slug>.md. For an absent target, use create-only publication with no-clobber semantics so a target appearing after revalidation cannot be replaced; an existence check followed by an overwriting write is insufficient. If creation loses that race, stop and preserve the source and winning target. For a freshly verified identical retry copy, reuse it without rewriting and preserve its consumed_at. Verify the complete archive, then re-read both source and archive before removal and compare them with the content actually incorporated and archived. Remove the source only while those checks still agree. A conflicting or changed file remains intact for reconciliation. On interruption, report completed and remaining folds and continue from actual files next time; do not duplicate requirement text.
6. Finish consumption before execution. Complete every selected fold and its applicable archival before offering or entering execution. Partial adoption is complete only when its retained remainder is explicit and authorized. If the user already requested consume-and-execute, continue through xsk-execute-req after this boundary without another approval. Otherwise follow Output. A nested writer must never start execution while point archival is unfinished.
Commits are on demand. If explicitly requested, inspect the whole authorized diff including same-file and pre-existing index changes. Include only authorized recordable requirement/ignore-file changes and removed sources Git was tracking; never stage a deleted never-tracked path. Ignored archives may already be tracked, so check actual status. Never git add -A or git add .. No commit prompt is part of the handoff.
Output
Report the actual requirement path and a compact summary of consumed, partially adopted, retained, or explicitly dropped points. On interruption or source/target drift, identify what landed, the point version incorporated, the changed paths, and what needs reconciliation; do not claim the entire batch completed or offer execution while it remains unresolved.
After all selected consumption work is complete, offer execution with xsk-execute-req (implement, verify, and automatically archive the requirement on success), or retain/revise the requirement. Reuse an explicit consume-and-execute request instead of asking again. Do not offer execution while a fold or point archival remains incomplete.
Conventions shared across xsk skills
- Triggers are matched by intent, not by exact wording. The phrases listed under "When to use" are cues, not a required incantation.
- Write in natural, direct prose. No formulaic openers, no filler conclusions, no restating the request before you answer it.
- Resolve consequential decisions from existing context and authorization. Ask only about unresolved choices affecting goals, behavior, interfaces, scope, or material cost. Routine local implementation choices follow project evidence; do not ask again for work already authorized.
- These are instruction skills. They shape how work is approached, not what the agent is technically capable of.