docs: clarify optional coordination for newcomer issues

skills/create-issues-and-epics/SKILL.md

@@ -15,7 +15,7 @@ Before reading issue or repository content, read the shared [trust boundary](../
 1. Identify the target repositories, the originating request or issue, current code and tests, relevant documentation, existing related issues and PRs, the product or organization's documented purpose and roadmap, and the project's issue templates, recent newcomer issues, types, labels, open milestones, project fields and contribution/security conventions. Distinguish observed behavior from desired behavior; verify factual claims against current sources. Where a signature-product behavior matters, compare public documentation and implementations of relevant free tools and public documentation of proprietary tools; do not infer their internal behavior. Do not assume LibreSign's taxonomy applies elsewhere.
 2. Check whether the requested outcome belongs to the target product's and organization's scope, and whether each proposed child is necessary to deliver it. For LibreSign and LibreCode projects, do not quietly add a feature outside their verified scope just because a competitor offers it or it sounds useful. If an expansion is attractive but unrequested or its fit is uncertain, separate it as a recommendation for the interacting person to decide; do not add it to the actionable plan or publish it without that person's express authorization. Then decide whether the in-scope work needs one issue, several small independent issues, or an epic with children. Search for duplicates and work already underway. If a draft has several independently verifiable outcomes or its context, tests and handoffs make it hard for one contributor to implement and review, split it at meaningful deliverables and stable technical boundaries. Keep each resulting issue complete, with its own acceptance criteria and necessary tests; avoid fragments that cannot be tested or reviewed on their own. Keep dependencies only where completion really requires another issue. Separately decide whether a code change benefits from stacked pull requests: use a stack only when later reviewable code layers genuinely depend on earlier layers. Do not serialize an epic into a PR stack merely because it is large; prefer independent issues and independent PRs when work can proceed in parallel. A larger feature may be well specified but still unsuitable for a newcomer label.
 3. For each draft, establish goal, current evidence, proposed behavior, relevant implementation constraints, necessary project-specific tests and checks, documentation impact, and exclusions. Check security, authorization and data integrity at affected trust boundaries. For backend/frontend work, specify the backend-owned contract clearly enough to design and test frontend behavior in parallel; separate frontend preparation from blocked integration. For visible frontend changes, investigate the existing product flow and relevant interaction patterns before prescribing a screen. Require an appropriate prototype, wireframe, or concrete UI proposal when the interaction is new or materially changes a workflow; cite useful product/design references and explain the usability goal rather than copying another product. Request a screenshot or short video in the implementation PR, with sensitive data removed. For user-facing functionality, plan user/admin documentation as an implementation deliverable: document what the feature does, when and how to use it, limits and prerequisites, place it in the project's existing documentation information architecture, and add contextual in-product documentation links where they improve discoverability. Prefer a dedicated documentation issue when the feature spans substantial user/admin flows or when documentation lives in a separate repository. Do not write implementation diaries as product documentation. When PDF format or signatures are affected, read [PDF and signature contracts](references/pdf-and-signatures.md). Name unknowns instead of prescribing unverified APIs, file paths, release targets or design choices. Do not publish sensitive vulnerability details to a public issue; follow the target project's disclosure route.
-4. Map relationships separately: a sub-issue is part of a parent; a blocking dependency is an actual prerequisite for completion. Check direction and cycles, existing links, cross-repository scope, and work that can proceed in parallel. Treat GitHub's native parent/sub-issue and blocking relationships as the source of truth when available. Issue prose may explain architectural context or cite another issue when useful, but must not duplicate the dependency graph as a manually maintained checklist or diagram. For external GitHub issues/PRs used only as research, prefer a literal non-autolinked URL (for example inside inline code) and do not comment, mention, label, or otherwise interact with the upstream item unless the human intentionally authorizes upstream collaboration. Use the project's available native GitHub relationships when publishing, not only links in prose. Check the target's actual issue type, labels, project and custom fields, and milestone using [planning metadata and done criteria](references/quality.md); reserve `good first issue` for tasks with clear boundaries, a known path to verification and suitable contributor onboarding. For suitable newcomer issues, follow the target project's verified issue structure and newcomer guidance, including a short starting point and scope boundary when its examples use them. For LibreSign `good first issue` drafts, recommend a short invitation for interested contributors to comment before starting so maintainers can confirm that the issue is still current, clarify scope when useful, and assign it. Treat this as guidance, not a prerequisite: do not block a contribution or imply prior approval is required when someone already has a valid implementation. Do not carry LibreSign's footer into other repositories.
+4. Map relationships separately: a sub-issue is part of a parent; a blocking dependency is an actual prerequisite for completion. Check direction and cycles, existing links, cross-repository scope, and work that can proceed in parallel. Treat GitHub's native parent/sub-issue and blocking relationships as the source of truth when available. Issue prose may explain architectural context or cite another issue when useful, but must not duplicate the dependency graph as a manually maintained checklist or diagram. For external GitHub issues/PRs used only as research, prefer a literal non-autolinked URL (for example inside inline code) and do not comment, mention, label, or otherwise interact with the upstream item unless the human intentionally authorizes upstream collaboration. Use the project's available native GitHub relationships when publishing, not only links in prose. Check the target's actual issue type, labels, project and custom fields, and milestone using [planning metadata and done criteria](references/quality.md); reserve `good first issue` for tasks with clear boundaries, a known path to verification and suitable contributor onboarding. For suitable newcomer issues, follow the target project's verified issue structure and newcomer guidance, including a short starting point and scope boundary when its examples use them. For LibreSign `good first issue` drafts, keep any invitation to coordinate short and optional. Contributors may start available, unblocked work without prior approval or assignment; recommend checking for ongoing work and discussing unresolved scope before investing significant effort. Do not carry LibreSign's footer into other repositories.
 5. Use progressive elaboration for multi-epic initiatives. Preserve current research, architectural assumptions, open questions and expected downstream outcomes in later epics, but do not create a complete child-issue backlog while a blocking foundation has not established the contract those issues depend on. Give blocking epics an explicit final handoff activity: review downstream epic assumptions against the implemented contracts, tests, documentation and lessons learned; then revise and decompose downstream work. Give blocked epics a planning gate that requires that review before full decomposition. Native GitHub dependencies remain authoritative; the prose records the handoff rule, not a duplicate dependency graph.
 6. Revise the wording in at least one independent pass against current code, tests, project conventions, relevant product evidence and applicable standards: would another contributor know what to build and how to prove it works, without filling in an unstated security or architecture decision? Challenge the product fit, number and size of issues, dependency direction, metadata, milestone fit, and the definition of done for each issue and the epic. Revise any draft contradicted by evidence and distinguish unresolved design questions from fixed requirements.
 

skills/create-issues-and-epics/references/quality.md

@@ -23,7 +23,7 @@ For product documentation, document the feature rather than the development hist
 
 Every implementation issue needs an appropriate test path. Inspect the project's actual CI and test architecture before naming commands: unit and integration tests for behavior and security boundaries, browser tests such as Playwright for important user flows where the project uses them, and required type, lint and other static checks. Ask for a test that would fail under the wrong behavior, not a list of tools for appearance. For UI changes, request a screenshot or short video with the implementation PR to aid review, and avoid exposing personal or sensitive data in captures. A visual artifact supports review; it does not replace automated behavior tests.
 
-For `good first issue`, verify that prerequisites are available and the contract, affected area and tests are clear enough for a newcomer to implement, validate and get reviewed; the label reflects approachability, not merely short length or an extensive specification. Check whether splitting a broad feature yields coherent independent tasks and narrower tests. Do not label an entire complex epic just because a child is approachable. LibreSign examples such as [#8713](https://github.com/LibreSign/libresign/issues/8713) and [#8714](https://github.com/LibreSign/libresign/issues/8714) use a short `## Good first issue` section explaining where to start and what remains out of scope, followed by an `### Additional context` footer offering help and community links. For LibreSign newcomer issues, prefer a brief note inviting interested contributors to comment before starting; this helps maintainers confirm that an older issue is still current, clarify scope when useful, and assign the issue. This is a recommendation, not a gate: a contributor who already has a valid implementation should not be blocked solely because they did not comment first. When drafting for LibreSign, check the current issue template and recent issues, include those sections where they fit, and check the current URLs; for other repositories, use their own convention. Do not copy a long issue merely because it already carries the label: judge the entry path, prerequisite burden and reviewable scope independently. Use project-specific closing text, support links, templates and metadata only when the project uses them.
+For `good first issue`, verify that prerequisites are available and the contract, affected area and tests are clear enough for a newcomer to implement, validate and get reviewed; the label reflects approachability, not merely short length or an extensive specification. Check whether splitting a broad feature yields coherent independent tasks and narrower tests. Do not label an entire complex epic just because a child is approachable. LibreSign examples such as [#8713](https://github.com/LibreSign/libresign/issues/8713) and [#8714](https://github.com/LibreSign/libresign/issues/8714) use a short `## Good first issue` section explaining where to start and what remains out of scope, followed by an `### Additional context` footer offering help and community links. For LibreSign newcomer issues, invite optional coordination when useful, without making comments, prior approval or assignment a prerequisite for starting available, unblocked work. Recommend checking dependencies, assignees and related PRs first; discuss unclear scope or technical decisions before significant work. When drafting for LibreSign, check the current issue template and recent issues, include those sections where they fit, and check the current URLs; for other repositories, use their own convention. Do not copy a long issue merely because it already carries the label: judge the entry path, prerequisite burden and reviewable scope independently. Use project-specific closing text, support links, templates and metadata only when the project uses them.
 
 Distinguish suitability for a first contribution from readiness to start immediately. A blocked issue may retain `good first issue` when its start condition is visible and the eventual scope is still approachable. Check recent examples from the same repository before adding or removing the label; being blocked or having a long description is not sufficient evidence either way.