docsector-reader: Skill for Claude Code

Docsector Feature Development

When to Use

• Create a new feature in Docsector.
• Evolve existing behavior with functional impact.
• Deliver a change that needs regression coverage and documentation updates.

Expected Outcome

• The relevant environment was mapped before implementation.
• Blocking questions were clarified, or non-blocking assumptions were made explicit.
• The feature is covered by regression tests in the narrowest possible scope.
• README.md is updated in the related section.
• Executable validation was run for the change, or a limitation was documented.

Procedure

1. Map the environment.

   • Find the nearest code path that actually decides the feature behavior.
   • Identify relevant files, components, composables, stores, routes, existing tests, and the potentially affected README.md section.
   • Form a local hypothesis: where the change belongs, which test can discriminate the expected behavior, and which narrow validation should be used.

2. Ask when in doubt.

   • If there is ambiguity about expected behavior, scope, naming, user experience, compatibility, or which README section must be updated, ask before editing.
   • Ask only the smallest set of genuinely blocking questions.
   • If the uncertainty is not blocking, proceed with the smallest reasonable assumption and record it in the final summary.

3. Implement regression tests.

   • Write or adjust a test that would fail without the feature and validates the expected behavior once the feature is applied.
   • Prefer the narrowest possible test first: validate the touched slice before broader checks unless they are necessary.
   • After the first substantive edit, immediately run the corresponding focused validation.

4. Implement the feature.

   • Make the smallest change needed to reach the desired behavior.
   • Fix the root cause instead of only working around the symptom.
   • Preserve Docsector's existing style and abstractions.

5. Update README.md.

   • Find the section most closely related to the delivered feature.
   • Document what changed, when to use it, and any relevant impact for project consumers.
   • If there is no exact section, update the nearest canonical section and state that explicitly in the final summary.